Subscribe

Abner Ballardo | Exploring AI-Native Ventures

Former CIO, Scotiabank Peru | Enterprise technology, architecture & transformation
Subscribe

Venture Notes

Short observations from exploring and building AI-native ventures—decisions, experiments, discoveries, and unresolved questions.

VN-007 — Exploring a Portable Knowledge Layer

Another CIO commented that his organization had accepted not always using the latest AI models and tools because it could not sustain the pace of change. I can understand that choice. It also made me think about the opportunity for an AI-native startup designed from the start to adapt closer to that pace. If that ability improves how the business operates, the advantage could be powerful.

I'm exploring that possibility by looking at how to preserve startup knowledge while keeping tool and agent choices open. That includes representing decisions and project context in artifacts that different tools could access. My experience at OKA helps me think about making those changes manageable. There, I built an IT organization capable of continuously updating software dependencies, supported by architecture, automation, and technical excellence. I'm looking for a decomposable design for this exploration: separate parts with defined responsibilities for maintaining knowledge and making it available to tools.

I expect that separation could make tool changes easier, but defining and maintaining the boundaries takes work now. The knowledge's representation and delivery may also need to change; access to the same artifacts would not ensure consistent interpretation or behavior. I'm still working through how much adaptation and revalidation each change would require, and whether this approach could help the startup adapt faster in ways that create a business advantage.

VN-006 — Skills and Agents Have a Maintenance Lifecycle

As I build skills and agents, I keep finding the same procedures, instructions, and best practices in different places. My instinct is to look for ways to reuse them instead of copying them into each new workflow. That reminded me of something familiar from software development.

In software, copying the same logic into several places makes the next change harder. You have to find every copy, update it, and check that the pieces still work together. I am beginning to see the same problem with skills and agents. What works today may need to change as the tools evolve. I need to be able to understand the structure and change it without rebuilding everything each time.

My working hypothesis is that skills and agents need the same attention to architecture and maintenance that I would give software. I’m working through which instructions belong in a shared structure and which need to stay specific to each task, including how to check that changes preserve the intended behavior. The goal is familiar from software development: build a foundation I can keep improving without making every improvement a rewrite.

VN-005 — Reading Well Enough to Remain in Control

Over the past few days, I've used LLMs to research, challenge ideas, explore scenarios, and document decisions as I build. They make it easier to produce documents. That reminded me of a skill I developed as a developer.

I've worked on projects with millions of lines of code. To understand a change, I needed a mental map of the architecture, the code, and the documentation. I had to see where a piece fit and notice when it didn't. Now the material isn't only code. LLMs can also generate decision records, procedures, and documents about how an organization works. Those pieces need to make sense together, too.

My working hypothesis is that, in an AI-native organization, the scarce skill may not be writing. It may be reading well enough to keep that larger map in mind and remain in control. I don't yet know how a team can maintain it as the volume grows. But more output only helps if someone can understand what connects and what no longer fits.

VN-004 — Designing Organizations for Agents

The more I think about building with agents, the more I keep coming back to context. An agent can only work with what it can access and interpret: goals, current state, constraints, permissions, history, and a clear definition of its responsibility.

Most organizational processes were built for people, not agents. People bridge missing context through memory, meetings, relationships, and experience. Agents cannot safely rely on the same informal gaps. Simply adding an agent to an existing process does not make that process agent-ready.

My working hypothesis is that an AI-native company must redesign context, handoffs, controls, and accountability from the ground up around the strengths and limits of both humans and agents. I do not yet know how much must change. But I suspect that context design—not access to the next model—will be one of the hardest parts of creating an AI-native organization.

VN-003 — What I Mean by AI-Native

In my research, I keep finding examples of companies using AI to make existing work faster or more efficient. I have not found a blueprint that answers the bigger question I care about: what changes when AI is part of the company's design from the beginning?

For now, I distinguish between AI-enabled and AI-native. An AI-enabled company improves parts of an existing business with AI. An AI-native company treats generative AI as a basic building material across the whole company: its product and customer experience, workflows, operating model, roles, context, handoffs, permissions, economics, and human accountability. It is not only an AI feature added to the business; it changes how the business is designed and run.

This is a working definition, not an industry standard. The absence of a blueprint is one of the reasons to start this journey—and to make the definition itself something I will need to test and revise.

VN-002 — Foundations Before Acceleration

Foundations have mattered in almost everything I have built. If I want to build generative AI-native startups, I need to understand what sits underneath the tools I will use.

I am not trying to become a researcher or train a foundation model from scratch. But I do want to understand how foundation models are trained, how inference works, and how context limits, retrieval, tool use, evaluation, reliability, and cost shape what can be built. Without that foundation, it would be too easy to mistake a convincing demo for sound product or company design.

The open question is how deep I need to go before building. I do not want study to become an excuse to delay. I want it to help me make better choices once I start getting my hands dirty.

VN-001 — Choosing the Venture Path

Today I decided that my next professional chapter will be building AI-native ventures.

The decision comes from experience. I have been an Agile practitioner since 2003. By the time Agile became a corporate priority, I already had years of hands-on practice behind me. That experience gave me a point of view I could not have developed by watching from the outside.

I see a similar moment with generative AI. My final day at work will be August 28, and I want to give myself time to learn by doing—to get my hands dirty building AI-native startups, not only reading or talking about them. The venture may work or it may not. Of course I want it to work, but either outcome will give me real experience. That learning is the most important part of the decision I am making now.