Quick take

An AI-native company is not a company that uses AI. It is a company whose operating model — decisions, ownership, interfaces, capital, and failure boundaries — has been built so AI compounds inside it instead of evaporating around it.

The model will change. The system around it should not.

This is a manifesto. It is opinionated, deliberately. Twelve tenets, four movements, one test. Borrow what works. Argue with the rest.

Movement I — Strategy

1. The operating model is the strategy

The model is the most expensive dependency in your stack. It is not the brain. The brain is everything you build around it: context assembly, retrieval, validation, retries, telemetry, fallback, escalation.

Two companies buy the same frontier model on the same Tuesday. One ships in six weeks with a deterministic fallback, a typed validator, and an eval gate on every PR. The other ships in six months with a notebook of “good prompts” and a Slack channel for incidents. Same model. Different company.

If your AI plan begins with “which model should we buy,” you are solving the easiest problem in the room. The moat is everything around the model.

2. Capital allocation is the first product decision

Great AI teams do not start with a roadmap. They start with a kill list. Capital is finite. Attention is finite. Support burden is finite.

Three questions before any AI initiative gets funded:

1. Does this increase margin, reduce risk, or improve speed?
2. Can we measure that effect within one to three quarters?
3. Do we own the fallback if the model or vendor changes?

If the answer to all three is not yes, the default is no.

The most common pattern across Series B–D companies that quietly stalled in 2024–2025: somewhere between $1M and $3M of engineering and infra burned on internal copilots that never crossed adoption threshold, plus a duplicate prompt orchestration layer because two teams built one in parallel. Neither project had a measurable failure mode. Both had a sponsor.

A four-dimension scorecard makes the next budget meeting honest:

• Adoption — are real users using it in a real workflow?
• Reliability — does it fail in bounded, observable ways?
• Margin — does it reduce cost or improve unit economics?
• Speed — does it shorten a real business cycle time?

If you cannot defend it with numbers, the project is not innovative. It is unpriced.

3. Decision latency is a P&L variable

Slow decisions look like caution. In practice, they are hidden expense. Every day a real decision sits unresolved, the business pays in delay, rework, and attention.

Headcount is an input. Throughput is an outcome. Adding the tenth engineer to a system that takes nine days to approve a deploy adds nine more days of waiting, not 10% more output.

Track four numbers with the same seriousness as revenue:

• time from issue raised to decision made
• time from decision made to action taken
• escalations per decision class
• decisions reopened after approval

Ambiguous ownership is the most expensive architecture in your company.

Movement II — Architecture

4. Build firewalls, not masterpieces

A statistical engine cannot be expected to behave like deterministic infrastructure. If your architecture only works when the model is correct 100% of the time, it is not architecture. It is wishful thinking with a demo budget.

Three failure modes, three firewalls. They are not the same thing and they are not solved by the same code:

• Inbound sanitization. What data is permitted into the prompt context. PII strippers, schema enforcers, retrieved-document trust scoring. This is also where indirect prompt injection — instructions hidden in a vendor PDF, a customer message, or a tool output — gets caught before it reaches the model.
• Outbound validation. A typed schema checker stands between the model and the operational database. Malformed JSON, out-of-range values, and policy-violating outputs are rejected at the boundary, not absorbed by downstream services.
• Operational fallback. Circuit breakers for vendor outages and rate limits. If the model returns invalid output three times in a row, the system degrades to a deterministic path — not a stack trace in front of the user.

Each of these is a separate piece of code with a separate owner, a separate test surface, and a separate failure mode. A “kill switch” that catches all three is a slide, not a system.

You cannot prompt your way out of entropy. You have to architect your way out of it.

5. Evaluation is the spine

If you cannot define an eval suite before shipping a feature, you do not understand the system well enough to ship it.

A five-level maturity ladder:

1. Vibes-based. Someone eyeballs prompts before release.
2. Spreadsheet. Suite exists, runs occasionally, blocks nothing.
3. CI/CD-integrated. Evals run on every PR. A failed gate stays failed.
4. Continuous telemetry. Production samples scored asynchronously. Incidents become regression tests.
5. Governance as moat. Evaluation shapes architecture before code. Margin, latency, and sovereignty tradeoffs are quantified, not asserted.

Below Level 3 is not a production system. It is a demo with a pager.

Level 4 is where most organizations get stuck, and the reason is rarely effort. Judge models drift, ground truth ages, sampling bias creeps in, and your asynchronous scoring quietly stops tracking the failure mode you cared about. Mature teams hold a small, hand-labeled golden set as the anchor, treat the judge model as a versioned dependency, and re-calibrate when either changes.

Eval portability is a year-two survival trait. If your eval suite is hand-tuned to one model’s tokenizer and one vendor’s output quirks, you have not built an eval suite. You have built a benchmark for the model you are about to be unable to leave.

6. Agentic systems run on a reliability contract

Agents are not magical workers. They are autonomous systems with more ways to fail. The reliability discipline gets stricter, not looser.

Every production agent answers five questions in one meeting, without hand-waving:

• what is it allowed to do?
• what is it explicitly not allowed to do?
• what metrics prove it is healthy?
• what happens when the model degrades?
• who can stop it, and how fast?

But the five questions are a meeting checklist. The contract is a published artifact with SLOs, blast-radius caps in dollars or rows or API calls, rollback latency targets, and a named owner per failure mode. Blast radius is the real design variable: data scope, action scope, time scope, permission scope, fallback scope.

Kill switches are not weakness. They are governance that can move faster than the failure. A useful test of any AI control: could an engineer follow this rule at 2 a.m. without calling a committee?

A roadmap that ships an agent without answers to these questions is a roadmap that has shipped a liability with a product label. Every initiative names how it turns off, how it knows it is hurting, how fast it reverts, and what manual path exists when the model degrades.

Companion: Agent Reliability Contract template . Rollback document template .

Autonomy without a reliability contract is just an incident waiting for a timeline.

Movement III — Economics & Externals

7. Unit economics live at the workflow, not the model call

Teams fixate on tokens because tokens are visible. The real bill sits around the model: retries, context assembly, human correction, support escalation, and the work of proving the output is acceptable.

Route by value and by risk. Trivial work stays cheap and local. High-stakes work earns expensive inference and stronger checks. A finance-aware leader can answer, without hand-waving:

• what each class of request costs to serve, end to end
• where the rework happens
• what failure costs when the model is wrong
• which parts of the workflow justify premium inference

The cost question nobody owns until it explodes: when product ships a feature that 10x’s tokens, who pays? If the answer is “we’ll figure it out,” you have not designed an operating model. You have deferred a fight.

Compute placement is part of this calculation, not a separate one. For high-frequency agentic workloads, a chain of round-trips across regions and vendors compounds into real latency tax and real egress cost. Local-first, hardware-aware patterns earn their place where the workload mix justifies them — and create a worse outcome where it does not. Measure first, place compute second.

A cheaper model that fails gracefully beats an expensive model that fails silently.

8. Sovereignty is an architecture constraint

Privacy is not a feature you bolt on before an enterprise contract closes. It is the shape of the system.

A sovereign system controls the full lifecycle of every piece of data — where it lives, who can access it, how long it persists, and what happens when someone asks you to delete it. In practice, four concrete patterns:

• Customer-managed keys. BYOK or hold-your-own-key. If your cloud provider holds the only copy of the encryption key, “we cannot access your data” is a policy promise, not a verifiable claim.
• Regional routing with storage isolation. EU data does not leave EU infrastructure. The application layer handles the routing. The deployment pipeline ships multi-region.
• Scoped, short-lived access. No ambient credentials. Service-to-service tokens with explicit grants and automatic expiry.
• Immutable audit trails. Append-only, tamper-evident logging of every access, transformation, and movement.

“We use AWS” is not an answer to “where does my data live.” Sovereignty is about specificity.

The compounding bill arrives when you try to add this later. The discount arrives when you build it in early and close enterprise contracts without an architectural retrofit.

9. The threat model is the manifesto

An AI manifesto without a threat model is marketing copy. Four risks every operator names explicitly:

• Indirect prompt injection. Instructions hidden in retrieved documents, tool outputs, and user uploads — not just in the user’s direct prompt. Treat every retrieved string as potentially adversarial. Validate before it reaches the model. Strip before it reaches the agent.
• Silent quality drift. The model returns slightly worse reasoning. The tone shifts. The retrieval starts ignoring critical documents. There is no stack trace. Only asynchronous production scoring, anchored to a golden set, catches this before customers do.
• Vendor and model lock-in by accident. Fine-tunes, preference data calibrated to one model family, and prompts hand-tuned to a specific tokenizer compound. By year two, your “swappable” model is a six-month migration. Discipline preserves optionality: prompt abstraction, eval portability, vendor-neutral preference data, and a quarterly review of what would break if the vendor changed terms tomorrow.
• Agent blast radius creep. Permissions accumulate. The agent that summarizes documents quietly gains write access to your billing API because someone needed it once. Audit scope quarterly. Treat agent permissions like database credentials, not like configuration.

Threat modeling is not a one-time exercise. It is the bill of materials your system runs on.

Movement IV — People & Failure

10. Interfaces beat titles

Most AI hiring plans try to fix an interface problem with resumes. They rarely work.

A working leadership system is not a roster of senior titles. It is a decision map. Four owners with explicit decision rights and explicit escalation paths:

• Product — user outcomes, adoption, business tradeoffs.
• Platform — safe defaults, deployment paths, observability, paved roads.
• Applied AI — workflow behavior, routing, prompting, retrieval, evaluation quality.
• Governance — risk boundaries, sovereignty controls, escalation thresholds.

The titles can be anything. The interfaces cannot be ambiguous. If the answers depend on who is online that day, the system is not operational.

The same logic governs platform teams. A platform exists to make repeated decisions disappear into the default path — identity, routing, eval harnesses, logging, safe deployment, fallback behavior. The moment platform becomes a queue that has to bless every use case, the queue is the product and waiting is the cost. A platform should remove waiting, not become a waiting room.

Hiring works after the operating contract is clear, not before. New hires scale the current operating model, good or bad. Org debt is interface debt with better branding.

11. Anti-fragility requires portability discipline

Resilience is surviving the shock. Anti-fragility is using the shock to remove the next one.

Fragility hides in the org chart and in the stack. One engineer who knows the routing. One vendor whose terms changed last week. One fine-tune that took six months to train and would take six months to migrate. That is not an organization or a system. That is a single point of failure wearing a department badge or a model card.

Four design choices build strength:

• Modular ownership. No critical function depends on one person’s memory. Deputies are named.
• Resettable interfaces. A model, vendor, or workflow can be swapped without a rewrite. This is not free. It requires prompt abstraction, eval portability, vendor-neutral preference data, and a regular drill where the team actually proves a swap is possible.
• Fast learning loops. Every failure produces a tighter eval, a better fallback, or a clearer operating boundary.
• Cross-training on the boring parts. Alerts, evals, fallback logic, access boundaries. The unglamorous work is what keeps the organization elastic.

A short anti-fragility check:

• Can you swap a model without rewriting the product?
• Can you lose a key engineer without losing the system?
• Can you absorb a vendor price increase without panic?
• Can you turn a production incident into an improved control?

If any answer is no, the organization is more brittle than it thinks. The most expensive lie an AI organization tells itself is that the model is swappable when nobody has tried.

12. The year-two test

A lot of AI organizations look healthy in month three and brittle by year two. The model did not fail. The operating model did. Prototype energy is easy to create. Durable coordination is not.

The single question that separates the two:

Can the AI system survive a senior person going on vacation for two weeks?

If the answer is “not really,” the organization is still running on hidden tribal knowledge.

If the answer is “yes, with documented ownership, a published reliability contract, an eval suite that blocks releases, and a fallback path the on-call engineer can execute at 2 a.m.,” the company is moving from prototype to production.

That is the only year-two test that matters. Everything else in this manifesto is in service of passing it.

What this manifesto is not

It is not a prediction about which model wins. It is not a framework for replacing engineers with agents. It is not a defense of any vendor, any cloud, or any stack.

It is a statement about how serious companies organize for AI when the easy money, the demo budgets, and the hype cycles are done — and only the operating model is left to do the work.

The model will change.

The system around it should not.

Law Zava writes about the operating model behind serious AI execution. Companion artifacts: Agent Reliability Contract template · Rollback document template · Eval Suite starter kit . The canonical reading path is at /blog .