How to Become an AI-Native Company: A 10-Point Manifesto

Most companies believe they are "doing AI" because employees have chatbot subscriptions. Walk the floor and it looks like this: an analyst copies rows out of the ERP into a chat window, retypes context the company has explained a thousand times, gets a decent paragraph back, and pastes it into an email. The model did its job. The company did not do its part.

That gap is what "AI-native" actually names. An AI-native company is not the one with the most licenses. It is the one where AI has the same three things a trusted new hire gets: access to the systems, context about the business, and rules for how to work. Everything below is those three things, built in a deliberate order.

This is written for PE operators because the payoff doubles there: whatever you build once at a portfolio company becomes a pattern you can carry to the next one. But the ten points hold for any operating company.

1. Diligence the work before you automate it

You cannot make a company AI-native if nobody can say, precisely, what work the company does. So the first artifact is not software. It is a written map: which workflows exist, which systems they run through, who owns each decision, where the hours actually go, and which recurring exceptions consume your most experienced people's afternoons.

This is diligence pointed at your own operation, and it decides everything downstream -- which systems the gateway must reach, what the company brain must contain, and which work is worth an agent. Skip it and you will automate the org chart's idea of the work instead of the work itself. The fastest way to build the map is to ask the people doing the work which routine exception they would be relieved never to chase again.

2. Build one governed gateway across the stack

Every system the company runs -- ERP, CRM, billing, ticketing, dispatch -- should be reachable by AI through a single governed gateway, not through forty ad-hoc integrations. In practice today that means MCP, the Model Context Protocol: a standard interface that turns each system's API into tools an AI can call.

One gateway earns you four things at once. Security review happens once, at the doorway. Permissions live in one place instead of scattered across vendor consoles. Every call is logged, so you can answer "what touched the billing system last Tuesday" in seconds. And when you replace a system, the agents keep working, because they talk to the gateway, not to the old vendor's quirks.

The alternative -- which many companies already have without deciding to -- is shadow integration: API keys pasted into spreadsheets, browser extensions with write access, one enthusiast's duct-taped script running under their personal login. Let your team connect AI to your systems. Just make them walk through a doorway you can see.

3. Turn tribal knowledge into a company asset

AI output is only as specific as the context it reads. The first layer of a company brain is the static context: who you are, what you sell and to whom, how you price, what good looks like, the house rules, and the definitions that make your numbers mean something -- what "active customer" counts, when revenue is recognized, which margin the weekly report uses.

Most of this already exists. It is scattered across drives, old board decks, and the heads of tenured employees. The job is to write it down in plain text, in one place, versioned, with a named owner. Unglamorous, and the single highest-leverage document work the company can do: without it, every AI interaction re-explains the company from scratch and gets generic answers back, because it was handed a generic company.

4. Keep the operating picture current

Static context makes AI sound like it works at your company. Live context makes it useful this week: meeting notes, decisions buried in email and Slack threads, active project status, the priorities that changed on Monday.

This is a different problem from point 3 -- plumbing, not authorship. The live sources connect through the gateway from point 2, so freshness is automatic rather than someone's Friday chore. A brain that is six weeks stale is worse than no brain, because people trust it exactly once.

It is also a judgment problem. Not everything belongs in the brain: compensation, HR matters, and legal privilege usually stay out. Decide deliberately, and write the exclusions down -- that decision is the first entry in the governance work coming in point 8.

5. Codify the playbook every AI must follow

Systems connected, brain built -- now AI needs to be told how to behave inside your company. That is the harness: the standing instructions that say what the brain contains and when to consult it, which systems it may reach through the gateway and for what, how to write in your voice, which decisions it must never make alone, and when to stop and hand the work to a human.

The simplest way to think about it: you are onboarding a sharp new hire who read the manual but has zero tenure. The harness is the induction -- the difference between "technically capable" and "safe to delegate to."

Treat it like code. Versioned, reviewed, owned by a named person. A harness nobody maintains drifts out of date in a quarter, and then the AI is confidently following last year's rules.

The build order

Ten layers, one operating system

Foundation → feedback

1. 01Map the work
2. 02One gateway
3. 03Company brain
4. 04Live context
5. 05Write the harness
6. 06Onboard the team
7. 07Route the models
8. 08Set autonomy rules
9. 09Build governed agents
10. 10Measure outcomes

6. Make frontline adoption a compounding advantage

Adoption is where most AI programs actually die, and it does not die loudly. It dies as quiet non-use. Handing out licenses is not onboarding; training people by role, inside the harness, on their own workflows is. Start where relief is felt fastest -- the exception someone no longer has to chase -- because relief, not mandate, is what makes usage stick.

Then close the loop. When someone corrects an AI output, that correction should land back in the harness or the brain -- not evaporate in a chat log. One sentence added to the harness ("purchase orders above the threshold always route through the controller") fixes that mistake for every person, permanently.

This is the flywheel that separates AI-native companies from AI-subscribed ones: the harness gets measurably better every month because of what the team did inside it.

7. Match model spend to the value of each job

Not every task needs the strongest model, and no task should depend on a single vendor's roadmap. So the harness talks to models through a routing layer: heavy reasoning and drafting go to a frontier model, bulk extraction and classification go to a fast, cheap one, and the assignments are based on evaluations against your own tasks -- not on leaderboard rankings that were not measuring your work.

The second reason is leverage. Model prices, terms, and behavior all change on someone else's schedule. Because the harness sits above the models rather than inside one vendor's product, switching is a routing-config change, not a re-platforming. That is the position you want to be negotiating renewals from.

8. Set the approval matrix before agents take action

Before any agent takes an action, three lists exist in writing: actions AI may take alone, actions that require a named human approver, and actions that are off-limits entirely. Every agent action is logged, so the audit trail exists before anyone asks for it.

And one structural rule that does not bend: the systems of record stay in charge. Billing, ERP, CRM, and compliance systems own the transactions. AI works through them -- through the gateway, with their validations intact -- never around them. The moment an AI layer quietly becomes a second ledger, you have created a reconciliation problem wearing an innovation costume.

Do this before point 9, not after. Governance retrofitted after an incident is how AI programs get frozen by their own boards. Written in advance, it is a page of decisions. Written afterward, it is a remediation project.

9. Deploy agents where they create operating leverage

With points 1 through 8 in place, agents are the payoff: work that starts, runs, and finishes without a person driving. Start with agents that prepare rather than decide -- assembling the reconciliation and flagging what does not match, triaging the exception queue overnight, drafting the weekly operating report from live numbers. A person still makes the consequential call; they just stop spending their day gathering the material to make it.

Notice this is point 9, not point 1. Most agent projects fail because they are built first -- a demo bolted onto no map, no gateway, no brain, no rules. It impresses in the meeting and dies in production, because production is exactly where access, context, and rules are missing. An agent built on this stack inherits its access from point 2, its knowledge from points 3 and 4, its instructions from point 5, its model from point 7, and its limits from point 8. That is the difference between a demo and a colleague.

10. Underwrite the upside -- and prove it at exit

Every automation gets underwritten like a deal: a baseline, an expected range, an owner, and a date. Then the observed result goes next to the projection, and the gap gets explained. What does not pay gets killed without ceremony. What works gets fed back into the harness and into the next projection.

For a PE operator this is the point that makes the rest bankable. An AI line in the value bridge survives IC and exit diligence only if it is a measured improvement with a retraceable methodology -- a broad synergy claim does not price. And the discipline runs both ways: if the measurements keep disagreeing with this manifesto, the manifesto is what changes. A thesis that cannot be falsified is decoration.

Why this is a portfolio play

Inside one company, the ten points are an operating improvement. Across a portfolio, they become assets. The harness written at the first distributor is the starting draft for the second. The gateway pattern built for one ERP is a known quantity the next time that ERP appears. The projected-versus-actual record from company one makes company two's underwriting sharper.

None of that compounding is automatic. It happens only if the patterns are captured as shared property -- which is exactly what points 5, 6, and 10 exist to do. A firm that runs this loop across ten portfolio companies is not running ten AI projects. It is building one capability with ten proving grounds.

Where MigrateForce fits -- honestly

MigrateForce gives the PE team a repeatable way to move from an AI thesis to an operating decision. It starts with the work that determines whether a target or portfolio company is ready, turns that evidence into an underwritten value-creation plan, and carries the approved interventions into governed execution. The point is not to run more AI pilots. It is to identify where AI can create value, name the assumptions and owners, and give the investment committee and operating team a way to measure whether the value arrived.

Across a portfolio, each engagement should strengthen the next one. The work map, management evidence, operating benchmarks, intervention design, and projected-versus-actual record become reusable judgment -- not generic templates. That gives an operating partner a clearer view of what to replicate, where to intervene, and which claims have earned the right to appear in the value bridge.

MigrateForce is decision support, not a substitute for operating judgment. It keeps the economics, trade-offs, approvals, and results visible so the team can act with more confidence, challenge the downside case, and build a more credible AI value-creation playbook over the hold period.