Building an AI-native company
In July 2025, we signed the articles of association for Orbitant.
I remember that at the time, the big revolution everyone was talking about was ‘Cursor autocomplete’, so as the team began to grow over the following months, we decided to cement our commitment by purchasing annual subscriptions.
Until I tried Claude Code.
What really mattered wasn’t switching tools but realising that the entire company, not just the development workflow, was ill-suited for what was to come.
We were using AI as a productivity boost for processes designed for humans. And not putting it at the center made me feel like this:
Pin by Matthew Choi on Briefing inspo | Ferrari 458 Italia, Ferrari 458, Ferrari
This article aims to outline our journey towards becoming an AI-native company.
Disclaimer: if you’re expecting a repository with ten .md files promising a legion of agents to run your business whilst you spend just two hours a week on it, this isn’t the post for you. This is about the other side of things: hard work, friction, doubts, and decisions that cost time and money.
Putting what lies ahead into context
There is no doubt that humanity is evolving by leaps and bounds. To put it into perspective:
- From the Stone Age to Agriculture: 100,000 years.
- From Agriculture to steam power: 12,000 years.
- From steam to AI: 200 years.
In other words: between 2000 and 2014, 100 years’ worth of progress was packed into just 14.
The prediction for the years ahead is that this growth will accelerate even further thanks to the latest technological developments.
AI learns and generates a compounding effect (previous technology lacked the capacity to improve at this speed on its own), which virtually guarantees exponential growth.
Moving beyond pilot mode
Most companies are stuck in an endless pilot phase. They have Copilot in the IDE, a wrapper around GPT in some internal script, a RAG proof of concept in customer support that never makes it to production.
The tools work, but they don’t really make much of a difference to the company.
The problem isn’t AI. The problem is that the organisational chart, the KPIs, the SDLC, the business cycle and the entire company’s operating system are designed to be run by humans.
Sticking AI on top of a process optimised for humans yields, at best, a twenty per cent increase in efficiency. Trapped at a local maximum that some C-level executive would call a ‘historic revolution’ in boardrooms.
What does change the order of magnitude is redesigning the system from the ground up.
That, to me, is what it means to be ‘AI native’
The foundations of an AI-native company
The challenge is to think differently (and it’s no small feat). Your brain and your organisation have spent decades optimising themselves so that a human can understand, navigate and execute. But now we must also design so that an agent can do the same.
Vercel recently released Zero, a systems language in the same league as C or Rust. The difference is that its compiler and toolchain were designed from day one to be used by agents, not just engineers.
Stripe recently launched Link’s wallet for agents: with it, an agent can make payments programmatically using single-use cards and shared tokens, without ever seeing the customer’s actual credentials.
These features aren’t improvised, but designed with the agent as the primary user.
If you’re still not convinced that processes for agents and humans can be very different, watch this video to see how two AIs optimise their communication by speaking in GibberLink, setting English aside to start exchanging structured data packets (because it’s much more efficient).
Now, apply that same principle two levels higher. An AI-native company, then, is not simply a company with agents, but a company where every workflow, every decision and every artefact flows through an intelligent layer.
AI thus ceases to be a tool and becomes the operating system.
And when you think of it that way, four layers emerge that need to be designed into your new architecture.
Layer 1: context
Pre-AI companies operate as open loops. You decide, you execute, and the result gets stuck in people’s heads, Slack threads, a comment on GitHub or meetings that nobody ever reads again.
An AI-native company is queryable: every significant action produces an artefact that the central system can read and learn from.
Specifically: recorded and summarised meetings, unified conversations, dashboards that cross-reference revenue, sales, engineering, hiring and ops, and agents with as much context as you would give an employee.
At Orbitant, we unify context via documentation, APIs, MCPs and agents. Company reports are generated by agents, and we correlate data that was previously kept separate (CRM with ERP, for example).
And, as we are remote-first, we receive qualitative updates on the status of projects without the need for follow-up meetings, by monitoring meetings and the development and product pipelines.
Layer 2: processes
Where there used to be open cycles, there are now closed, self-correcting cycles. Furthermore, each process captures information, feeds it back into the system and improves it.
The most concrete way to view this is as the next step in test-driven development. The human writes the spec and the tests that define what constitutes success. The agents generate the implementation and iterate on it until the tests pass.
There are already repositories in production that do not contain a single line of hand-written code, only specs and test harnesses. The human defines what to build and judges the result, but the ‘how’ is the agent’s job.
Our team is internally building the company’s know-how packaged into Claude plugins, which allow both people and agents to activate them, abstracting their implementation:
Layer 3: organisation
Human middleware ceases to make sense in this new universe (or at least changes radically). If your company is queryable, rich in artefacts and readable by AI, you don’t need layers of people passing information on.
Every layer you remove is pure speed by freeing up context (and you also eliminate much of the political manoeuvring, which in large companies represents a significant conflict of interest).
What remains (and seems to make some sense) are three archetypes.
- IC / builder-operator: They build and operate; it’s not just for engineering roles. Everyone builds and turns up to meetings with prototypes and the final product, not slides.
- DRI, directly responsible individual: one name, one outcome. Strategy and client results, with nowhere to hide. This isn’t the classic manager (for me, it would be the evolution of the Team Lead), but rather someone with direct accountability for the business outcome. They are the ultimate owner of the project, with a strong focus not so much on ‘finishing the project on time’, but on generating business impact.
- AI founder: continues to build, remains the first power user. Belief in these tools is not delegated.
And a new department also springs to mind: AR (Agentic Resources). HR for digital employees: onboarding, assignment, feedback, evaluation, fine-tuning.
When an agent carries out real tasks and measures their impact, the question ceases to be technical and becomes organizational.
Layer 4: product and business
The time & materials model isn’t dead, but it falls short. When a team delivers in a week what used to take six, charging by the hour penalises those who work faster.
I don’t have a definitive answer on pricing, and I’m still in many discussions, but the principle remains the same: if you add value, you’ll eventually be able to recoup it at some point.
The next step in software development, as I see it, is what I call Business-Driven Development. Understanding metrics, context and business objectives, deciding what to build, and worrying less and less about the ‘how’. This forces the engineer to stay closely attuned to the product, the customer and the business.
It’s not about being a faster executor, but about being someone who captures context, models it and orchestrates it.
This has always been about solving valuable business problems (technology has never been the main focus). And this is often difficult to internalise in the world of development. But now it is more important than ever to do so if we want to adapt.
To manage all these changes and ensure they are consistent, we have set up an internal Developer Experience (DevExp) team specifically to ensure that the SDLC process with AI is consistent, effective, and efficient.
In this example I’m showing, an agent assesses the quality of tickets before passing them to the execution pipeline (tickets are one of the first bottlenecks in terms of quality when working with Spec Driven Development). primeros cuellos de botella en cuanto a calidad trabajando con Spec Driven Development).
Training as an offensive strategy
If your product is your own team (as is the case for us), how could you not invest in it at a time like this?
This year we have decided to adopt a zero-EBITDA policy: we want to reinvest the margin in training, tools, and experimentation.
An engineer from an American company trained us to become power users of Claude Code. From there, we developed our own methodology, documented it, and trained the entire team.
An expert CPO is currently providing us with twelve weeks of training in product methodology. As I said before, I firmly believe that the future of engineers lies in getting even closer to the product, the problem to be solved, and the business.
We’ve also created a weekly session called Asteroids, where someone from our team shares a discovery or insight related to AI in five minutes. Every quarter, we do the same for three hours but share broader insights at a project level in what we call ‘Super Standups.'
We have also empowered the non-technical team (because the transformation is cultural, not just about the tech stack). To this end, we created a two-hour training session on Claude Cowork that you can reuse for your team.
The advantage of starting young
The reality is that large companies could be left behind in this race.
They have legacy systems, rigid organisational charts, thousands of people to retrain, vendors that fund the status quo, and committees that prioritise caution.
The young, agile company may lack scale, but it gains something far more valuable right now: adaptability.
To carry out this transition, you need a seasoned senior team that is open to change, no legacy systems to defend, a culture of discarding work when a better way emerges, and a conviction that cannot be delegated.
This conviction can only be built by sitting down with a coding agent. It cannot be delegated to the CTO or to a consultant, nor can it be bought in a report.
We are a small and fledgling company. We have a seasoned senior team that is open to change. We are part of Afianza, a larger group that provides us with financial muscle and a research lab.
That combination, rare as it is, I believe, gives us a solid foundation on which to build an ambitious AI-native project.
Don’t wait
Let’s be honest: agents today fail. They lose context, repeat mistakes, hallucinate, and do things you didn’t ask them to. Anyone who tells you they have a magic template that lets their agents run the business on their own is either selling you a pipe dream or has a very specific use case. Today’s technology is good for some workflows and mediocre for others.
But that’s no excuse not to get started. It’s actually the reason to start building now, because the curve won’t flatten itself. Companies that are on board when it starts working properly will have years’ head start in accumulated data, methodology, and culture.
Those who wait for it to “be ready” will be too late, just as those who waited for the cloud to be ready in 2012 were too late.
The moat isn’t in the model (anyone with an API key has the model). The moat lies in having spent months iterating with your team, in having accumulated context that no older company possesses, and in having built the culture that allows you to keep adapting.
Start at the top
You can’t set a vision you don’t understand. The reason is more operational than philosophical: these tools change their capabilities every three months. A vision based on what you heard in a keynote last quarter is already obsolete by the time you present it.
I design my own agents and my own system with Obsidian, which helps me every week to do more with less. And it has been precisely the exercise of exploring and creating this over months (as well as spending many hours reading and writing) that has helped me shape my vision on everything I’ve shared in this article.
We still have everything to build, but we’re on our way. I hope more companies and professionals will take up this challenge, choosing to do what is right over what is easy.
Want to know a little more about who wrote this article? 👇
Felipe Polo
Entrepreneur and founder of Orbitant.
He shares insights on scaling consultancy firms, leadership, applied AI and software engineering.
‘If you’d like to follow our journey in building an AI-native company, you can follow me on Twitter.’