Your business isn't queryable (and your agents know it)
Every business framework you studied was designed for humans in meetings. This is the operating layer for what comes next.
During my masters program it wasn’t uncommon to spend a week evaluating a single framework. TOGAF for enterprise architecture. ITIL for service management. COSO for internal controls. RACI for decision rights. Lean for process improvement. BIZBOK for the gaps between all of them.
They gave me vocabulary. Mental models. A sense of where the edges were. Useful, the way a map of a city is useful before you’ve walked any of the streets.
Then I started running businesses with agents. And I realized the map was drawn for pedestrians.
Every one of those frameworks has the same hidden assumption baked in: humans are doing the work, humans have bounded attention, and the framework exists to coordinate humans across that bound. RACI tells you who’s responsible because, without it, two people will assume the other one did it. ITIL prescribes change advisory boards because humans make bad decisions under pressure and a slow, structured process catches errors. TOGAF produces architecture diagrams because the people who need to act on a decision aren’t in the room when it’s made.
Take away the human bandwidth constraint and most of what a business framework does becomes ceremony.
Agents don’t forget what was decided last Tuesday, as long as it’s in their context window. They can query 47 tables before you finish reading the meeting agenda, but they’ll hallucinate a number if the table doesn’t exist. They have no persistent memory across sessions. Their intelligence is jagged: superhuman at some tasks, confidently wrong about basic things.
The honest framing:
Humans are bad at attention and memory across time. Agents are bad at persistent learning and consistency across sessions. A framework that only compensates for human bandwidth limits is the wrong framework. But agents still need structure — just structure that’s queryable rather than coordinative.
The ceremony isn’t what makes the frameworks valuable. The data model underneath is.
A few weeks before I started drafting this post, I read Jack Dorsey and Roelof Botha’s piece for Sequoia, published in March 2026. The core argument landed hard: hierarchy isn’t an ideology, it’s an information routing protocol. It was invented to move decisions through organizations that couldn’t move information fast enough. Middle management existed to pre-compute decisions at scale. Every reorg since, from matrix structures to Holacracy to Spotify squads, rearranged the routing without replacing what was doing the routing.
The copilot framing gets this wrong too: putting AI inside the existing structure improves throughput without touching the architecture.
Their answer is a company world model: atomic capabilities, an intelligence layer that composes them, and a small number of human roles. No product manager decides what to build. The intelligence layer recognizes the moment and composes what’s needed.
But the piece stops at the architectural sketch. How does the world model stay accurate over time? What happens when declared state drifts from observed state? Who’s accountable when the model is wrong? There’s no answer for drift detection, no audit trail, no enforcement mechanism. The vision is clear. The operating manual doesn’t exist.
So I built one.
The four things left standing
So I started asking a different question about every framework: strip away the meetings, the diagrams, the certifications, and the coordination rituals. What’s left?
Almost always the same four things.
Tables. Every framework secretly assumes certain entities and relationships: services, incidents, and change requests (ITIL); decisions and responsible parties (RACI); controls and the risks they’re meant to catch (COSO). Those assumptions are tables. The entities are rows. The relationships are foreign keys.
Constraints. Every framework has things it forbids. ITIL says a change can’t deploy without an owner. COSO says a control can’t be owned by the person it governs. RACI says every decision needs exactly one accountable party. Those prohibitions are NOT NULL columns, CHECK constraints, and pre-action validators. They’re not policies written in a manual. They’re schema. And when an agent tries to violate one, the database rejects the write before it lands. The enforcement is mechanical, not supervisory.
Loops. Every framework has a measure-decide-act cycle. Lean’s Plan-Do-Check-Act. ITIL’s incident-to-resolution flow. OKR check-ins. DMAIC’s Define-Measure-Analyze-Improve-Control. Each of those cycles is a scheduled agent reading from an event queue, detecting something, and writing a response. The meeting where humans do this is the slow version of the loop. The database trigger and the scheduled job are the fast version.
Queries. Every framework teaches humans to ask certain questions. “Who owns this decision?” “What’s the current status of this incident?” “Is this OKR on track?” Those questions are saved views. They’re SQL. They don’t need to live in a meeting agenda. They run at 7:15 AM and the results are waiting for you when you open your laptop.
The test I use: if a framework’s value can’t be expressed as tables, constraints, scheduled jobs, and saved queries, it’s ceremony. It’s not something an agent can use.
Capability modeling: the first translation
The framework that survives this filter most cleanly is capability modeling, and it’s worth understanding why.
A capability is a stable description of something a business can do. “Publish weekly content” is a capability. How it gets delivered changes: the skill changes, the operator changes, the tools change. The capability stays the same because it describes the function, not the implementation. In my model, a capability is what you get when a skill meets an operator. The skill is the how. The operator is the who. The capability is the what.
This matters because a single capability can have mixed operators: human decides the surface, agent researches, agent distributes, human audits. The capability is stable. The operator assignment shifts as trust and reliability change.
In an agent-native business, capability modeling is the spine. Every skill maps to a capability it delivers. Every OKR targets a capability. Every KPI tree measures one. Every decision affects one. When something breaks, you query which capabilities are affected. When you’re adding a new agent, you check which capabilities are already covered. The map isn’t a diagram. It’s a table with a parent_id column for hierarchy and a junction table linking skills to capabilities.
The consulting exercise becomes a schema. The PowerPoint becomes a query. And the constraint layer rejects a capability record without a verified skill link. The enforcement is structural, not a review meeting.
If you use Claude Code, Cursor, Codex, etc…., you already do this for your codebase. CLAUDE.md/AGENTS.md tells agents what the repo is, what conventions to follow, where to find things. Your business needs the same declaration: what it can do, what it’s trying to achieve, what rules govern it, and how to tell when it’s drifting. Capabilities are the spine of that declaration. Goals measure the spine. Constraints protect it.
OKRs as queries
The second framework worth examining closely is OKRs, because the agent-native version of it is almost unrecognizable from the original.
In an agent-native business, a key result is a SQL query that returns a number. Not a description of what the number measures. Not a link to a spreadsheet someone is updating. An actual query, stored in a column called query, that runs on a schedule and writes its output to current_value. The OKR check-in isn’t a meeting where someone reports progress. It’s a scheduled job that ran at 7:15 AM and already wrote the result. Progress is always real. It’s never self-reported.
“Reach 500 free subscribers by July 15th” becomes a row in an objectives table and a row in a key_results table where the query column is something like SELECT COUNT(*) FROM subscribers WHERE tier = 'free'. A scheduled job runs it every morning. The current value is always accurate. If the key result falls behind, an anomaly detector writes a gap. The gap routes to the operator. No meeting required.
You’re removing the gap between declared progress and observed progress. In a human OKR system, those two things drift apart because humans self-report. Here, the only progress that exists is the progress the query can measure. That constraint forces you to be specific about what you’re trying to accomplish.
“Grow the audience” can’t be a key result because you can’t write a query for it. “500 free subscribers by July 15th” can. The discipline the agent requires is more honest than the discipline the quarterly meeting requires.
The three states
Three states matter in any agent-native business, and conflating them is the most common mistake. Most agent systems only track one. That gap is what breaks things.
Two weeks after we declared The Compounding Founder’s publishing cadence as weekly, we had two gaps in the observed record. The config file still said weekly. Nobody flagged it. That’s what having only declared state looks like.
Reference state is what should exist according to some standard or template. If you’ve adopted a framework, the reference state is what that framework says a healthy implementation looks like. If you’re using an industry benchmark for open rates, the reference state is the benchmark.
Declared state is what you claim exists. Your config file. Your business declaration. What you told the agent at startup.
Observed state is what evidence shows actually happened. Metrics. Agent logs. Decisions with recorded outcomes. Briefings with timestamps.
Drift between these three states is the signal. When your declared state says you publish weekly and your observed state shows two gaps in the last six weeks, that’s drift. When your reference state says every decision needs an accountable owner and your observed state shows twelve decisions with no owner logged, that’s drift. The job of the retrospective loop isn’t to run the business. It’s to find the drift and surface it.
Most agent systems only track declared state. They have the config, the prompt, the system message, and they treat it as the truth. No observed state to compare against. No reference state to know what good looks like. When things go wrong, there’s no structural way to find out. A human checks in and notices. Or doesn’t notice for a while.
Building all three states, and treating the drift between them as first-class information, is what separates a business that agents can run from one they can only assist.
Build the spine first
This doesn’t require building everything at once. I’ve walked you through two translations in this post: capability modeling and OKRs as queries. The full set I work with is seven (also DMAIC retrospective loops, KPI trees, decision rights, three lines of defense, and ITIL services). They aren’t a mandate. They’re a menu. Capability modeling is the only one that’s mandatory from the start, because it’s the spine everything else hangs from. The others come in as the business scales and the need becomes real.
A business in its first month needs capability modeling and maybe a simple OKR query for its one key metric. It doesn’t need a full ITIL incident management system or formal three-lines-of-defense segregation of duties. Those come later, when agents are making enough consequential decisions that oversight needs to be structural.
The dependency order matters too. OKRs and KPI trees both depend on having capability modeling in place, because both need something stable to target and measure. Decision rights depend on having a clear capability map because rights are scoped to capabilities. Three lines of defense depend on decision rights because you can’t segregate duties you haven’t defined. DMAIC depends on all of it, because the retrospective loop needs something to learn from.
Spine first. Diagnostics. Controls. Then the learning loop.
Task-capable, business-blind
The point of all of this isn’t to rebuild your business in Postgres. A Postgres schema and an MCP server are not what I’m recommending here.
The point is to ask the question that most businesses using agents haven’t asked: what would your business look like if it were a queryable, auditable entity instead of a collection of documents and meetings and conversations that live partly in the heads of the human operators?
Right now, your agents are task-capable and business-blind. They can write the email, draft the post, run the analysis. They can’t tell you which decision from six weeks ago is causing the problem today. They can’t surface the drift between what you said you’d do and what actually happened. They can’t find the gap before it becomes a crisis. Not because they lack intelligence. Because there’s nothing to query.
Start with the spine. Write down what your business can do in stable terms. Not the tools you use. Not the agents you run. Not the current process. The capabilities. That’s one column in a spreadsheet or five lines in a markdown file. Everything in this post hangs from that list.
Dorsey and Botha described the destination: a company organized as an intelligence rather than a hierarchy. This framework is an attempt at the operating manual.
In the next post, I’ll show you what happens when you actually build this. A Postgres brain, an MCP server, and the morning an operator agent found six problems at 7:15 AM without being asked. That’s not a debugging story. That’s a control plane working.