A year building an AI-Native Pomelo: infrastructure, processes, and teams

About a year ago, I became obsessed with an idea: to understand if it was possible to apply the way AI-Native companies operate and scale it at Pomelo. Through this analysis, I began to identify patterns that repeated over and over again. Small teams, agents actively participating in daily work, specifications as the axis of coordination, and a speed of execution hard to explain from traditional structures.

The question stopped being technological and became organizational. Was it possible to bring these principles to Pomelo, a company that operates hundreds of clients, millions of transactions, and issuance on a global scale? The answer is yes:

• In 12 months, we multiplied the engineering throughput by 6X;
• We improved the Time to delivery by 3.2X;
• We improved practically all the health indicators of our platform, including Uptime, Processing Capacity, and operational resilience;

And perhaps more importantly, we began to transform how we build our product, how we organize ourselves, and how our platform and team operate. Find the details below.

Where did I start?

The first observation in AI-Native companies was almost uncomfortable: what is traditionally resolved with teams of ten or fifteen people began to be resolved with three or four people working alongside agents. Not because they worked more, nor because they were better, but because they were operating under a completely different logic.

That's why I can state something: thinking that artificial intelligence is limited to automating flows or generating code is shortsighted. The real change appears when you stop transforming the existing organization and start redesigning it from scratch. And the real challenge is to do this with a live business, with hundreds of people operating hundreds of clients in almost a dozen countries.

Context is the raw material

For an agent to function, its main raw material is context. Without context, it doesn’t know what to do or respond to; with the right context, it amplifies the performance of any person or team.

In an AI-Native organization, documentation ceases to be a deliverable that is written once and becomes outdated, and turns into the place where an idea evolves: from a conversation about a business problem to a product definition, to technical decisions, until it becomes the context consumed by the agents that build and validate. It stops being called "documentation" and becomes "specifications": the common language that connects business, product, engineering, and agents. When that happens, the quality of conversations improves and much of the loss of context between teams starts to disappear.

Hence, Spec Driven Development (SDD) began to make sense for us, not as a methodology but as a logical consequence of working alongside AI. Today, when you define something, Claude asks if you want to create a specification. In a startup of three to ten people, this flows almost naturally. Our challenge was different: for hundreds of people to generate specifications with a consistent quality level, for business, product, and engineering to share a single work framework, and for agents to receive structured context without speed destroying quality.

One of the most important lessons was understanding that SDD does not scale because people write better specifications. It scales when the organization is capable of turning its knowledge into something accessible and usable by agents continuously.

First things first: infrastructure

That’s why, before transforming the way we work, we transformed the infrastructure. We incorporated a layer of MCPs as the main source of context for the agents and as a mechanism to connect systems, knowledge, and skills: a layer of distributed capabilities within the organization. In other words, we prepared the infrastructure for a world where work is mixed, with people and agents working simultaneously.

On that foundation, we built a layer of agents connected to that context and an AI-Gateway that allowed us to manage models, costs, environments, and responsibilities on a completely different scale. Today 100% of our AI usage goes through that gateway, and new products are already being born MCP-first. None of this is necessary for a small AI-Native company, but it is essential for a company at scale.

With these changes, we were able to provide agents with the context of existing products, and we validated something key: the better the quality of context, the better the quality of the agents. That pushed us to the next step: turning it into a continuous, simple, and automatic practice, as happens in an AI-Native. And to achieve this, we had to rethink all our processes.

Processes determine how information flows: how a business need transforms into a product definition, then into a functional specification, and finally into a technical definition. One of the most interesting surprises of the journey was that the functional specifications we now build alongside the AI reach a level of depth, precision, and context that a person could hardly produce alone. And that result becomes the best possible input for product, architecture, engineering, and agents.

The constant iteration between business, product, and technology, amplified by AI, ends up producing something more important than a productivity improvement: it is the rail to become a superior organization to what you had before. That is the concept that truly allows evolution. It's not about evolving the tools, but about evolving the processes to evolve the organization.

A new generation of builders

When talking about the future of software development, the conversation often gets reduced to a rather limited question: will AI replace developers? I believe we are looking at the problem from the wrong perspective. The real transformation is not about how much code a developer writes, but about what it means to build software.

In this model, the engineer ceases to be primarily an implementer and becomes the designer of a software generation factory. They define specifications, design agents, decide what context they receive, establish validation mechanisms and quality controls, ensure security, scalability, and observability, and validate that the result generated by the system is consistent with the original intention. Agents require a massive amount of engineering behind them: access to information, context, organizational knowledge, and people capable of designing them, building them, orchestrating them, and keeping them running at scale.

Specifications become a central piece because they are the mechanism that allows transferring intention at scale: they not only help a person understand what to build, but also enable the coordination of a complete set of agents working on the same need.

The bottleneck has shifted from building to reviewing: today we produce more than we can review. And that is exactly the problem you want to have. When the speed of construction is no longer the limiting factor, the quality of decisions takes center stage.

Fewer layers, more teams: the micro-squads

It is increasingly often heard that artificial intelligence is eliminating middle management, and almost always the explanation is the same: efficiency, cost reduction, fewer layers. After this year of learning, I believe efficiency is a consequence, not the cause. What really happens is that AI amplifies the two ends of the organization simultaneously.

On one hand, people with more context greatly increase their ability to analyze, design, decide, and lead. On the other, those closer to execution start working accompanied by agents that build, validate, document, review, and operate alongside them. When both ends grow simultaneously, a significant portion of the work that historically occurred in the middle is naturally redistributed. Not because someone eliminates it, but because it becomes unnecessary. So far this year, that has translated into removing one to two layers of management per area: not due to cuts, but because the change itself made them unnecessary and allowed us to expand horizontally and multiply our micro-squads, generating more production capacity and increasing our engineering throughput.

The distance between an idea and its execution is shortened, and much of the energy previously spent coordinating is now available for building. This is where micro-squads emerged: smaller, more autonomous teams in a more horizontal organization. The goal shifted from optimizing a structure by mandate to multiplying the number of teams capable of generating real delivery.

For me, that is one of the most important differences between adopting AI tools and building an AI-Native organization: the former seeks efficiency; the latter aims to transform the organization into a truly superior version of its predecessor.

It's not just software

If I had to summarize this entire journey into a single idea, it would be this: artificial intelligence is not only changing the way we build software. It represents a generational leap in the way digital businesses are built.

A new generation of engineers is emerging with AI-amplified capabilities, aligned with a concept I've been writing about for years and which is more relevant today than ever: the product engineer. A much broader technology role than the traditional one, immersed not only in the technology that builds software but in the deep understanding of the product, the business, and the end-to-end operation of the company.

I take it for what it is: a commitment to evolution. Not with an abstract idea of transformation, but with the evolution towards a superior Pomelo compared to what we had a year ago. And this is just the beginning.