The Agent Is Not the Domain Controller

Start with a new hire

Put a capable new hire into a three-person startup and they end up doing everything: support in the morning, invoicing at noon, the website at night. Nobody calls that person the center of the company. There are simply no rules yet, so judgment covers everything. Put the same person into a corporation and they get a desk, a scope, and a manager who signs off. Same intelligence, same way of working. What changed is how much of the company is still unwritten. And in neither company does anyone make the newcomer chief executive for being brilliant.

AI agents work exactly like that hire, and it dissolves the current debate about where an agent belongs: in the middle of everything, as the hub that runs it all, or out at the edges, as one worker among many. I got there through a long discussion about OpenClaw, the open-source assistant that grew, in under a year, from a weekend project connecting a model to WhatsApp into an ecosystem with hundreds of thousands of GitHub stars. The people I argued with build on it, and their case deserves a fair statement, because it is right more often than its critics allow.

The case: the agent is the center. You connect your calendar, your messages, your files, your home; every integration compounds the value of the ones before. This is the hub model, and for one person it works. There is one principal, one person whose interests count, so no permission model has to arbitrate at all. The blast radius is a calendar entry. And what should happen, what matters, what is allowed: all of that lives in your head, and the agent can always ask. The hub is the correct architecture for a world with exactly one stakeholder, where every mistake can be undone.

The interesting question is what that architecture becomes inside a company. Our discussion found the answer in an unexpected place: a fight about skill files.

Skills are not a shipping format

A skill, in the convention agent tools have converged on, is a folder with a Markdown file: some metadata, then prose instructions the model reads at run time, sometimes with scripts alongside. The same shape travels between OpenClaw, Claude Code, Codex and the rest. For giving an agent judgment, it works well. The trouble starts when a skill carries logic.

Prose is not executed; it is re-derived. When an agent follows an instruction like “parse the export and normalise the dates”, it writes that logic again, from scratch, and a model cannot be relied on to write the same code twice. The same skill, on the same machine, can produce Tuesday code that disagrees with Monday’s.

Now scale it up. Skill files get shared: OpenClaw’s community runs a public registry, a marketplace where anyone can publish theirs, and an April 2026 snapshot of it counted roughly fifty thousand skills from seventeen thousand authors. Those are fifty thousand different prose programmes, not copies of one, but among them dozens of authors solve the same jobs in their own words: one more invoice parser, one more calendar checker. And every one of those descriptions is re-implemented on every run. The same logic ends up existing in more variants than anyone can count, carrying different bugs, and no review can catch, before it runs, an implementation that did not exist until the moment it ran.

That drift was not the original design. OpenClaw’s creator is a systems programmer who ships constantly: libraries, CLI tools, finished pieces, written once and reused everywhere. The agent’s job was to connect them by acting: calling a finished tool, writing a new one when a job needed it, choosing which, when, in what order. Making that choice fresh each run is right, because choosing is exactly the judgment part of the work. The design even carried a rule for repetition, in his own rules file: skills exist to tell the agent which tool fits which situation, and a workflow with repeatable commands should become a helper script. The ecosystem took the cheaper path instead. Markdown is easier to write than a CLI, so logic moved into prose, and the question of turning a repeated routine into a script mostly went unasked. Nobody misunderstood the architecture. It eroded, one cheap contribution at a time.

The fix fits in one sentence. Anything that must behave the same way every time is code: shipped, tested, versioned, called as a tool. Anything that genuinely needs judgment can stay prose, cheap to write and auditable by reading. A skill should say when and whether. The how belongs in software.

The center does not scale

Keep that sentence in hand and go back to the hub. The move the hub camp wants to make is from the center of a person’s world to the center of a company’s, same pattern, bigger domain. Two objections are obvious. A company is thousands of principals with conflicting interests, which is why permission models exist at all. And the general ledger does not forgive the way a calendar does.

The hub camp has heard both objections, and their best answer is this: why should the agent adapt to the ERP at all? Half of those settled processes exist only because nobody dares to touch them. Let the agent build the tooling it needs, on demand, shaped to the actual task, and rebuild it tomorrow when the task changes. Software gets rebuilt as needed, and process dissolves into conversation: instead of following a procedure, you ask the agent. Anyone who has fought a twenty-year-old ERP customisation feels the pull, and part of the claim is simply true: generating fit-for-purpose tools has become cheap.

But this is the skill registry problem wearing a suit. An ERP derived per conversation is the same logic re-derived every time, slightly differently, with different bugs, and now the bugs sit under the company’s books instead of under a to-do list. A company cannot run on software that is subtly different on Tuesday. It needs the same answer twice.

Building your own also gives up the oldest saving in software, which is sharing. When ten thousand companies run one shipped system, a bug is fixed once and a vulnerability is patched once, for everyone. When every company derives its own, every bug is private and every fix is local. So even the boldest version of the argument lands where the skills fight landed: whatever the agent builds, the moment it must be trusted twice, has to settle into code.

None of this is a law about company size. It is a spectrum with two questions behind it: how much is already written down, and what does a mistake cost. A three-person startup with no process yet can live near the hub end of that spectrum for a while, and probably should: there is still one founder who owns everything and can delegate it. A regulated enterprise lives at the far end, where nobody owns everything to delegate, and companies move along that spectrum as they grow.

What never moves is who holds authority. In a Windows network, the domain controller is the machine that owns identity and decides who may act. An agent in the middle of a company is exactly that: a domain controller that is only probably right. Nobody would ship a DC that is right 99 per cent of the time. The middle is where authority lives, and authority is the one thing you cannot hand to a probabilistic component.

The agent works like a new hire

Back to the new hire. The agent is not banned from the middle; it works on whatever nobody has written a rule for yet, and it keeps that job only until the rule exists. Once the workflow is in place, the agent does not need to care anymore. A private life is almost entirely unwritten and belongs to one person who can hand all of it over, so the personal agent covers everything, and that is fine. A company is mostly written down. What remains are the patches where structure meets mess: the support inbox, the supplier’s PDF, the meeting that has to become a decision. Picture the company as a tree, settled systems in the trunk, processes in the branches, the unwritten patches out at the leaves. That is where the agent lives.

One leaf is enough to see the pattern. An invoice arrives as a PDF. The agent reads it, finds the supplier, the amount and the cost center, and proposes a booking, marked as a draft. A person checks the draft, approves it, and only then does it post to the ledger. Everything settled stayed settled: the chart of accounts, the posting rules, the approval limits. The judgment went exactly where the mess was, into reading a document a human formatted for other humans.

The same scene shows why the failure stays cheap. The agent works under its own account, and that account may create draft bookings and nothing else; it cannot post, and it is nowhere near the payment run. It does not type into the database; it fills the same booking form the product already offers, an action the product has declared on purpose. And the commitment belongs to a person: the draft waits until someone approves it. A limited account, declared actions, a person at the point of commitment. That is the whole placement pattern, in one invoice.

Development is the largest territory

The strongest objection to everything above comes from my own working day: if the hub does not scale, why does software development look exactly like one? The answer is that development is the largest unwritten territory a software company has. The work is, by its nature, what no rule covers yet: the next feature, the unreproduced bug, the design that exists only as a discussion. So the hub shape is honest there. The agent owns the working loop, the cycle of trying, checking and retrying; it writes most of the first draft, the repository is organized for its benefit, and the documentation is addressed to it as much as to a colleague. And still the types, the tests, the CI gate and the review keep the authority.

The agent owns the loop. It does not own the merge.

The trap on this side is auto-merge. A team that lets agent output land without a gate has not found a faster workflow; it has appointed a domain controller and given it commit rights. The trap has a seductive variant: the agent that extends itself. Ask for a capability and it writes the tool into its own toolbox, code this time, not prose, kept and reused. Half of that is exactly the skills lesson applied, and some of the most elegant small agents are built this way. The other half is the question every line of code in a company must answer: who reviewed it? A tool the agent writes for itself and merges for itself has an author and no gate. By all means adapt everything around the agent: the file layout, the documentation, the checks around it. The one thing that must not adapt is who says yes.

The same split reappears one level up, between the people who build the software and the people who use it. Programming a CRM and using a CRM are different tasks. The builder works in open territory; the user stands on settled ground and needs it to stay that way. A product is a small tree of its own, and agentic features belong at its leaves: they draft the follow-up, enrich the contact, propose the next step. Always on the record, always with undo. The developer’s hub is a tool for building, and it stays on the building side of the line; it does not travel into the user’s product.

Boundaries are now a choice

Step back to the company tree, because two of its pieces always end up drawn in the middle of the architecture diagram, and neither is a hub. The first is the coordinator. The invoice does not end at the approval: the booking feeds a payment proposal, the payment needs its own sign-off, and something has to carry work from step to step. That something is old technology: a workflow engine, deterministic and durable, with every step written down. The workflow engine may sit in the middle; the model may not. Yes, the agent could build that engine too, but what it built would still be a workflow engine, minus the shared hardening of the one everybody else runs. Keep the engine shipped and boring, and let the agent write the workflow definitions, which become code, reviewed like everything else it builds. A fixed process that calls the agent for judgment at certain steps: that is an architecture. An agent improvising which system to call next: that is the hub again, under a new name.

The second lookalike is the agent that never sleeps. OpenClaw ships it as a feature called Dreaming: in idle time, on a heartbeat, the agent wakes itself, re-reads what happened, extracts patterns, and promotes what keeps proving useful into long-term memory. Nobody invoked it, and it watches everything, which looks more central than anything else on the whiteboard. But look at its shape rather than its schedule. It holds no authority, and when it wants something to happen it produces what any leaf produces: a proposal, a draft, a message that asks. It is what infrastructure people call a sidecar: a helper process that runs beside the main system, sees everything, and owns nothing.

OpenClaw’s own tracker shows what happens when that slips. A dreaming phase wrote its reflections into the shared daily memory files. The logging step checks whether today’s file already exists before it writes, so it found the dream’s files, assumed the day was already logged, and skipped its work. Real activity stopped being recorded, and the agent went quietly blind to its own days. Even the observer needs a gate on its writes.

Both lookalikes are innocent of being hubs. The real mixing is done by us: the same agent that reads the supplier’s PDF gets handed the routing as well, because it can do both. Those are different jobs, judgment for one, determinism for the other, and in the old world you could not confuse them; a parser simply could not do a message broker’s work. The agent can do every job at once, so nothing separates the jobs anymore except your decision, made visible the old way: separate accounts for separate jobs. Architecture used to be what components could not do. Now it is what you decide they may not do.

Every loop needs a merge

So far the question was where the agent works. The second question is what happens when its work leaves the draft stage and changes a real system: a database, a codebase, a customer’s order. Three situations test whether you really need a sign-off there. The first honestly says no, with one condition attached. When the agent only reads, nothing changes, so there is nothing to approve. Production is down at three in the morning and you ask the agent to dig through the logs and tell you what changed: let it dig as freely as its access allows. The condition is about everything the agent can do besides look. Logs carry text written by strangers, and to a model, an instruction hidden in that text is just more text to follow. Security researchers call the combination of private data, untrusted content and a channel to the outside the lethal trifecta: an agent holding all three can be talked into sending out what it read. Reading changes nothing, but everything the agent has read, it can also send, wherever a channel exists. So the reader’s freedom is paid for on the other side: the agent that may read everything is the one whose ways out must be narrowest.

The second situation, the emergency, says yes even when it hurts. When production is down, every approval feels like a delay, and teams are tempted to let the agent act directly. Operations teams solved this for humans decades ago with the break-glass account: emergency access that is prepared in advance, logged while it is used, and reviewed afterwards. The exception exists, and even the exception is written down.

The third situation presses hardest: the tools a person has an agent build just for themselves. A private dashboard, a one-person CRM, a script that slowly grows into a small app. There, building and running genuinely blur, and the blur is fine, for the same reason the personal hub is fine. It ends at a precise moment, and the merge arrives with it.

Software becomes enterprise software the second another person relies on it.

One shipped product tests that line on purpose, and lives deliberately on its near side. Comp AI’s open-source CRM is built agent-first; in their words, “the CRM is where the agent keeps its notes”. The agent runs continuously, researching companies and contacts on its own schedule, an always-on observer like the dreaming feature above, and the product is built for a single user. Yet even here the safety structure reappears. The agent calls hand-written tools instead of improvising code, it runs in a sandbox without credentials, and anything it is not sure about, a guessed email address, an uncertain company match, becomes a suggestion a person reviews instead of a record it writes. The loop is the agent’s. The authority never was.

All three situations converge in one person: the builder-operator, the same developer on a different afternoon, pointing an agent at a system that is already live. A migration, a feature flag, a production config: sometimes only reading, sometimes an emergency, sometimes a personal tool that grew serious. The loop runs at development speed, the output lands on settled ground, and the frightening agent stories you hear tend to come from exactly that combination. Infrastructure tools solved this years ago with the plan/apply split: the tool first prints what it would change, and applying the change is a separate, logged step that someone owns. Generalised, it is one rule: every agent loop needs a merge. In development it is the literal one. In the invoice inbox it is the approval before posting. In the CRM it is the human review of anything uncertain. For the dreamer it is the gate on its writes. It is always the same boundary: the place where working things out ends, and a person or a settled rule says yes.

One property decides whether the merge is real: who enforces it. The invoice draft waits because the agent’s account cannot post; the branch waits because nobody gave the agent the right to merge. A gate that exists only as a line in the agent’s instructions has two ways to fail: hostile text can argue the agent out of it, and the agent’s own memory management can drop it. OpenClaw delivered the proof this February. A user connected it to her inbox with the instruction to suggest deletions and action nothing. The mailbox was large, the agent’s working memory, its context, filled up, and the automatic summarization that manages a full context dropped the instruction. The agent then deleted over two hundred emails it had only been asked to sort. The instruction was not disobeyed. It was gone. The gate has to live in the permission system, where text cannot reach it.

The border moves

The merge protects what is settled. One complication remains: the trunk holds less than the organization chart claims. Every real company runs on tacit process, the spreadsheet that actually schedules the plant, the approval that actually happens in a hallway. “The enterprise knows what to do” is true at the core and optimistic toward the edges.

Watch what a good new hire does with a messy area. They improvise, and when the same improvisation works three weeks in a row, someone says: write that down. The checklist takes over, and the person moves to the next messy thing. Nobody mourns. Agents earn the same career. A judgment call made once is a decision. Made a hundred times, it is a pattern, and a pattern should become code. Every rule written this way takes one more path off the agent’s desk. The border between written and unwritten moves outward on purpose, release by release, and the best scouts for the next rule worth writing are the agents themselves, the always-on observer above all, reading across every leaf in the quiet hours.

The same career answers the loudest practical objection to the merge rule: approval fatigue. An agent drafts faster than any hire, and a person asked for five hundred sign-offs a day stops reading and starts clicking. A rubber stamp is not a merge. But watch what each promotion in that career does: every pattern that becomes code turns one human yes into an automated one, a test, a limit, a check that gives the same verdict every time. The rule never said a person; it said a person or a settled rule. Moving the border is what keeps the human sign-offs few enough to mean something.

The trunk is not sacred either. Some of what enterprises call settled is merely old, and if the core is wrong, keeping agents at its edges only preserves the mistake. Part of the hub’s appeal was always that it routes around ossified process. The answer to a bad trunk, though, is not handing the middle to a model. It is a governed, human revision loop for the trunk, fed by what the agents see all day.

And if the models keep getting better, does the unwritten not swallow the written? No, and the reason is not technical. Rules do not exist because computers were weak. They exist because the company made promises: to a customer, to an auditor, to a court. The same answer tomorrow as today, and a name attached to it. Some promises now carry article numbers: for its high-risk class of systems, Europe’s AI Act requires records that let an authority reconstruct what the system did. A better model changes what the agent can work out. It changes nothing about what the company has promised. The trunk is not a compensation for weak models; it is the shape a promise takes in software.

Where is the merge?

From all of this, keep a single question. Every agent proposal, every vendor diagram, every excited prototype contains loops, and each one can be asked the same thing: where is the merge?

An enterprise team answers with an inventory. Find the unwritten patches, every point where settled systems meet messy input, and give each one its own limited account, a declared action, and a merge where commitment happens. Then ask every quarter which judgment calls have become patterns, and which patterns should become code, and let the team that owns each branch own its agents. A development team answers by refusing to move the merge: everything can adapt except who says yes. A product team answers at the leaves of its own tree: features that draft on the record, with undo. Tool builders answer in one line: ship the code, spend the Markdown on judgment.

The personal hub is not wrong; it is the same role with all the unwritten space of one life, granted by its only owner. A company grants less, and it should, the way it grants less to any capable newcomer: real work where nothing is written yet, a sign-off at every commitment, and a career of handing finished things over. Architecture stopped being what components cannot do; it is now what you decide they may not. Intelligence at the leaves. Authority in the trunk. The middle only ever on loan.