AI-native is not a chatbot. It is a graph that never sleeps.

Almost every company I talk to has done the same two things: bought seats for a chat assistant, and told the engineers to code with a copilot. Then they wait for the transformation, and it does not arrive.

It does not arrive because neither of those things changes how the company works. They make individuals somewhat faster inside processes that are unchanged. Going AI-native is a different move, and it starts somewhere most people skip.

Start with why, or nothing else lands

Before any tool, everyone in the company has to understand why we are doing this.

The answer is not "because AI is important." It is specific and it is measurable: processes become more efficient, faster and cheaper — by a margin that changes what is worth attempting at all, not by a few percent. Stanford HAI's AI Index put GPT-3.5-level inference at roughly $20 per million tokens in November 2022 and around $0.07 by October 2024. That is 280× cheaper in under two years. Work that was uneconomical to even consider is now a line item.

If your team cannot say that back to you in one sentence, no amount of tooling will save the initiative. And there is data on how common that failure is: McKinsey's study of AI-native operators found 88% of organizations use AI somewhere, roughly 1% consider themselves mature, and about two-thirds never scaled past isolated pilots. The tools were never the bottleneck.

The hard part is the mindset, and warmth is how you move it

This is the part I would spend the most leadership time on, and the part I see handled worst.

Asking people to work in public, to record their meetings, to hand execution to a system — that is not a tooling request. It is a request to change how they understand their own value. Some of them will hear "you are being replaced," because that is the reasonable thing to hear if nobody tells you otherwise.

So change management is not a phase of this project. It is the project. And the single thing that determines whether it works is the warmth with which you communicate it. Not the deck, not the roadmap, not the memo. Whether the person in front of you believes you are on their side while everything they know about their job changes underneath them.

You cannot delegate that to a system. It is the first thing I would protect and the last thing I would automate.

We are going to be outmatched. Plan for it honestly.

Here is the thing I think leaders need to say out loud instead of dancing around: humans are going to be surpassed on judgment and on raw compute. Not in every domain and not this quarter, but the direction is not seriously in doubt, and pretending otherwise makes you sound either uninformed or dishonest to your own team.

That should change what people spend their day on. If the machine is going to be better at executing the process, then humans should stop thinking about running processes and move to the two places where we are not competing:

Fundamental, strategic decisions about the direction of the company. What we build, what we refuse to build, which market, which bet, what we are willing to be wrong about. Execution goes to the system. Direction stays with people.

Human warmth for other humans. This one is permanent, and I want to be unambiguous about it. An engineer who shipped a bad quarter needs a person to tell them it is recoverable. A team going through a reorg needs someone visibly carrying the anxiety with them instead of forwarding it. A customer who just got burned needs a human taking responsibility on the call, not an excellent summary of what went wrong. Someone whose parent is sick needs their manager to be warm first and operational second.

That work is not a fallback for cases the model cannot reach. It is the job — and it gets more important as everything mechanical accelerates, because a company shipping five times faster produces five times more uncertainty for the people inside it to absorb. The WEF's Future of Jobs Report has leadership and social influence as the fastest-rising skill in employer-rated importance since 2023, up 22 percentage points, the biggest jump in the survey. Employers going AI-native are not betting that people become less human. They are betting hard on the opposite.

Loops that run 24/7, and graphs for everything you execute

Now the architecture. Two pieces, and neither is a chatbot.

AI loops that run around the clock. A loop takes real-world signal — telemetry, tickets, billing events, code changes — runs it through a policy layer that says what the system may and may not do without asking, calls tools, passes a quality gate, ships, and measures what happened. Then it goes around again. YC's Tom Blomfield frames the test cleanly: if the loop can close without a human in the middle, the product improves while everyone is asleep. If a human is the gate, the loop stops at 3am and waits.

Engineering graphs for every execution. This is the piece almost nobody has, and it is where quality is actually decided. A graph is a network with conditionals, agents holding distinct roles, each one reaching the context under different rules, and the human intervening only at specific gates. Orchestration, parallel work, adversarial verification, judging, synthesis. Not one model doing everything — a topology that forces verification before commitment. I wrote about this in detail in The prompt was never the hard part. The graph is., and everything there applies to company operations, not just to product.

The gates are the interesting design problem. Too many and you have rebuilt middle management in software. Too few and the system commits things nobody sanctioned. Put the human where being wrong is expensive and irreversible, and nowhere else.

The context layer is the whole game — and so is its security

If I could only get one thing right, it would be this.

A graph is only as good as the context its agents can reach, and a company's context is mostly not in its database. It is in conversations. Which means the work is: capture everything, structure it, and defend it.

Capture. Record every meeting and transcribe it automatically — every one, not the important ones, because you do not know which meeting mattered until you need it. Ask everyone to work in public channels; a decision made in a DM is a decision the company cannot learn from and a new hire cannot find. GitLab has run handbook-first and public-by-default for over a decade across 1,300+ people in 65 countries, and they did it long before there was a model to feed. Store it strictly, not casually.

For the audio side we built TranscribeGo precisely because this turned out to be the bottleneck — meetings, calls, voice notes, anything you record anywhere, including straight from WhatsApp, transcribed and kept. It is the tool we use ourselves, and it exists because we needed the substrate before we could build anything on top of it.

Structure. The corpus feeds a company brain: one place where everything is indexed and reachable, where anyone can ask a question in plain language, and where the loops go to read. And the brain does not only answer — it executes.

Defend. The moment you decide to record everything, you have built a system capable of surveillance. That is a plain description, not a warning shot. Whether it becomes an asset or a liability is settled entirely by the controls around it, and those controls have to exist before the corpus does. My background is nuclear engineering, and the discipline that transfers is that safety is architecture, not a feature you add at the end, and it assumes the failure will happen.

Concretely: consent decided per jurisdiction and per room, because employees, candidates and customers are not the same case. Classification at the moment of ingestion — clinical, legal and compensation conversations cannot sit in the same undifferentiated pool as a standup, and you will never go back and sort it later. Retention with an actual clock. Residency and encryption you can point to. An audit trail, so you can answer who asked what and what came back.

And the control most teams get wrong: permissions enforced at retrieval, not on documents. If the brain reads across the whole corpus, it will happily synthesize an answer out of material the person asking could never open. Enforce access per user at the moment of retrieval or you have built the most efficient leak in the company's history. Some of the data-layer choices behind this I covered in The database was the last thing we optimized for agents.

Design the gates so information flows up

Once the context layer exists, the design question becomes who reaches what.

Different parts of the company need different doors into the same brain, and the gates should be deliberate. But the direction that matters most is upward: whoever is deciding direction needs visibility into as much as possible, as fast as possible. That is the entire leadership argument for this architecture. Not dashboards — the ability to ask any question about the state of the company and get a grounded answer in seconds, so decisions happen at the speed the market actually moves.

Bill Gates made this argument in 1999 in Business @ the Speed of Thought, where he described a "digital nervous system": every system and process unified on one infrastructure so information reaches the people who need it, and companies compete on velocity rather than on quality or on re-engineering. He was right about the shape and about twenty-five years early on the tooling. What he described as a nervous system is what we can now actually build — with the difference that this one does not just carry the signal, it acts on it.

What I would actually do, in order

1. Explain why. Efficiency, speed, cost — specific, measurable, repeatable by anyone on the team.
2. Run the change with warmth. Budget more leadership time here than feels reasonable.
3. Move humans off execution and onto direction, and be honest about why.
4. Turn on capture: record everything, transcribe everything, public channels by default.
5. Build the context layer and its controls in the same quarter. Never one without the other.
6. Build graphs for your real executions, with humans only at the expensive gates.
7. Close the loops so they run at 3am.
8. Open the gates upward so decisions get faster.
9. Measure it. Instrument the loops and check they are actually faster, rather than trusting that they feel faster.

None of this needs a model you have to train, and none of it needs a platform you have to buy. It needs decisions about how your company remembers, who can see what, and where a person has to be in the path.

We do not record everything because the data is valuable. We record it because a company that cannot remember what it decided is condemned to decide it again — and because the people doing the deciding deserve to spend their attention on each other instead.

---

Sources and further reading

• Federico Caccia, The prompt was never the hard part. The graph is. — Rather Labs
• Federico Caccia, The database was the last thing we optimized for agents — Rather Labs
• Bill Gates with Collins Hemingway, Business @ the Speed of Thought: Using a Digital Nervous System (1999)
• Tom Blomfield (Y Combinator), Building and Structuring an AI Native Company, Startup School Paris — transcribed with TranscribeGo
• McKinsey, The seven operating truths of AI-native companies
• Stanford HAI, AI Index Report 2025
• GitLab, Handbook-first communication
• World Economic Forum, Future of Jobs Report 2025