Article

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

MigrateForce Team

In this article

Build order for AI at an operating company: map the work, one gateway, company context, a harness, adoption, model routing, approvals -- then agents you can govern and measure.

Most companies think they are "doing AI" because people have chatbot seats. What you actually see: someone copies ERP rows into a chat window, retypes context the company has already explained a hundred times, gets a usable paragraph, and pastes it into email. The model worked. The company still did not give it access, context, or rules.

That is the bar for "AI-native." Licenses are not the bar. An AI-native company gives AI the same three things a trusted new hire gets: access to systems, context about the business, and rules for how work gets done. The ten points below are those three things, in build order.

Written for PE operators because a pattern built once at a portfolio company can transfer to the next. The sequence still holds for any operating company.

1. Diligence the work before you automate it

You cannot make a company AI-native if nobody can state what work the company does. The first artifact is not software. It is a written map: workflows, systems, decision owners, where hours go, and which recurring exceptions burn experienced people.

That map decides what the gateway must reach, what company context must hold, and which work is worth an agent. Skip it and you automate the org chart's story of the work, not the work. Fastest way to build it: ask the people doing the work which routine exception they would be glad never to chase again.

2. Build one governed gateway across the stack

ERP, CRM, billing, ticketing, dispatch -- AI should reach them through one governed gateway, not forty one-off integrations. In practice that means MCP (Model Context Protocol): a standard interface that turns each system's API into tools an AI can call.

One gateway concentrates the controls: security review at a single doorway, permissions in one place, every call logged, and agents that keep working when you swap a vendor because they talk to the gateway, not the old API's quirks.

The common alternative is already happening without a decision: API keys in spreadsheets, browser extensions with write access, a personal script under someone's login. Let the team connect AI to systems. Make them use a doorway you can see.

3. Write the static company context down

AI output is only as specific as the context it gets. Static context is: who you are, what you sell and to whom, how you price, what good looks like, house rules, and the definitions that make numbers mean something -- what counts as an active customer, when revenue is recognized, which margin the weekly report uses.

Most of this already exists in drives, old board decks, and tenured heads. Put it in plain text, one place, versioned, with a named owner. Without it, every AI session re-explains the company and returns generic answers.

4. Keep operating context current

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

This is plumbing, not authorship. Connect live sources through the gateway from point 2 so freshness is not a Friday chore. A brain six weeks stale is worse than none -- people trust it once, then stop.

Not everything belongs there. Compensation, HR, and legal privilege usually stay out. Write the exclusions down; that is the first governance entry for point 8.

5. Codify the playbook every AI must follow

Connected systems and a company brain still need standing instructions: what the brain contains and when to use it, which systems the gateway may reach and for what, how to write, which decisions require a human, and when to stop.

Treat that harness like code: versioned, reviewed, owned. A harness nobody maintains drifts in a quarter, and the AI keeps following last year's rules with confidence.

Build order

Ten steps before agents pay off

Access → context → rules
  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
Map work, open one gateway, write context and a harness, then put agents behind approvals you can measure.

6. Onboard people by role -- and feed corrections back

Most AI programs fail as quiet non-use, not as a loud rejection. Seats are not onboarding. Train by role, inside the harness, on real workflows. Start where someone feels relief first -- an exception they no longer chase -- because relief sticks better than a mandate.

When someone corrects an AI output, put the fix in the harness or the brain. One sentence ("POs above the threshold always route through the controller") stops the same mistake for everyone. That is what separates AI-native from AI-subscribed: the harness gets better from actual use.

7. Route models by job value, not by brand

Not every task needs the strongest model, and no task should depend on one vendor's roadmap. Route through the harness: heavy reasoning and drafting to a frontier model, bulk extraction and classification to a fast cheap one, based on evals on your tasks -- not public leaderboards.

Prices, terms, and model behavior change on someone else's schedule. If the harness sits above the models, switching is a routing change, not a re-platforming.

8. Write the approval matrix before agents act

Before any agent acts, three lists exist in writing: what AI may do alone, what needs a named human approver, and what is off-limits. Log every action so the audit trail exists before anyone asks.

Hard rule: systems of record stay in charge. Billing, ERP, CRM, and compliance own the transactions. AI works through them -- via the gateway, with their validations -- never around them. An AI layer that becomes a second ledger is a reconciliation problem, not a product win.

Do this before point 9. Governance after an incident is how boards freeze AI programs. Written first, it is a page of decisions. Written later, it is remediation.

9. Deploy agents that prepare work -- then decide later

With 1--8 in place, agents can run work without a person driving every step. Start with prepare-not-decide: assemble reconciliations and flag mismatches, triage the exception queue overnight, draft the weekly operating report from live numbers. A person still makes the consequential call; they stop spending the day gathering material for it.

Agents fail when they are built first -- a demo with no map, gateway, brain, or rules. Production is where access, context, and rules are missing. An agent on this stack inherits access from point 2, knowledge from 3 and 4, instructions from 5, model choice from 7, and limits from 8.

10. Underwrite each automation -- and compare actuals

Underwrite every automation like a deal: baseline, expected range, owner, date. Put observed results next to the projection and explain the gap. Kill what does not pay. Feed what works back into the harness and the next projection.

For PE, this is what makes an AI line survive IC and exit diligence: measured improvement with a retraceable method. A broad synergy claim does not price. If results keep disagreeing with this checklist, change the checklist.

Why this matters across a portfolio

Inside one company, these ten points are operating discipline. Across a portfolio, they become reusable assets: the harness from the first distributor is a draft for the second; the gateway pattern for one ERP is known quantity next time; projected-versus-actual from company one sharpens underwriting at company two.

That only happens if patterns are captured as shared property -- which is what points 5, 6, and 10 force. Ten portfolio companies on this loop are not ten AI projects. They are one operating capability with ten test sites.

Where MigrateForce fits

MigrateForce is decision support for the PE operating loop: readiness evidence, an underwritten value-creation plan, and governed execution for supported migration paths. It does not replace operating judgment, and it does not own the systems of record.

Outputs depend on the evidence people provide, the assumptions the team chooses, and the change work after the model is done. Use it to name owners and assumptions, keep approvals visible, and check whether projected value showed up -- not to invent more pilots.

Keep reading

All posts

Start with the work map

Run a free readiness assessment on a company you operate. Six dimensions, three scenarios, assumptions kept visible.