An agent-native system is one where a non-human actor writes to the system of record as a peer — holding an identity, spending permissions, leaving a history — rather than running alongside it as a script that pokes an API. That definition sounds like a small shift in wording and it is not. It promotes a design decision most product teams treat as cosmetic into the load-bearing one: how many kinds of thing does the system model?
The software category already has an answer, and the answer is: several. Documents live in one product, tasks in another, decisions in a third, processes in a fourth, and integrations are strung between them to keep the story consistent. Every one of those boundaries is a seam, and seams are where the plan and the work drift apart. A person can carry a broken link between a decision and the work it implies in their head for a while. An agent has no such channel — the data model is the entire world it can read, and a link that does not exist in the data does not exist at all.
ML LABS builds and operates OrgDo, a coordination product in the internal portfolio at Escape Velocity Labs, a sister practice under the same owner. Its architecture answers the how-many-types question in the smallest way the domain allows, and that one answer propagates into the permission model, the audit design, and what an agent is allowed to do unattended. The rest of this piece is what that subtraction buys and what it costs.
Collapse The Types Into One
OrgDo's model is three levels deep and one type wide. A workspace contains products; a product contains nodes; a node is the only content type in the system. Each node carries a kind — item or doc — and a state that is open, closed, or blocked. Everything a coordination tool needs on top of that (labels, ordering, links, discussion, decisions) applies uniformly, because there is only one kind of thing to apply it to.
The consequence is that work and knowledge stop being two products joined by an integration and become one graph, read by one query and driven by one API. A specification and the task that implements it are the same shape of object with different kinds, and the relationship between them is an edge, not a URL pasted into a description field.
- One primitive means one permission model, one audit path, and one API surface for an agent to learn — the surface area an agent can be wrong about shrinks with the type count.
- Links between knowledge and work are first-class edges in the same graph, not cross-product references that can break without anything reporting it.
- Isolation lives under the application, not inside it: Postgres row-level security keyed on the workspace, so a query that forgets its tenant returns nothing rather than someone else's data.
A minimal type system on the surface can still be strict underneath — the constraint is what makes it coherent. This runs hard against the instinct to model every distinction the domain has a word for, but the discipline of keeping one coherent model rather than several leaky ones (Fowler, 2014) applies with extra force when a non-human principal is the one reading the model. Incoherence that a person papers over with judgment, an agent executes.
Agents Are Principals, Not Automation
The second decision in OrgDo was refusing to treat agents as an automation layer bolted onto a human tool. Automation rules are triggers and side effects: they have no identity of their own, no permission set that can be scoped or revoked, and no accountable trail — which means that when one does something unexpected, there is nothing to interview. An agent in OrgDo is a principal instead: an actor with an identity, permissions, and a history, indistinguishable in the data model from a person performing the same action.
That symmetry is the point. An agent's work is governed by the same rules, visible in the same history, and reversible through the same mechanisms as anyone else's, which is what makes agent participation safe to allow rather than merely impressive to demo. The framework for managing AI risk through accountability and traceability (NIST, 2023) points at the same requirement from the governance side: an actor you did not model as an actor is an actor you cannot govern. The guidance on building effective agents (Anthropic, 2024) points at it from the engineering side — reliability comes from a simple, legible environment and well-specified tools, not from a cleverer loop on top of a messy one.
Modeling an agent as a principal is not the same as letting it act freely, and the two questions should never be collapsed. Identity and permissions decide whether an action can be attributed and revoked; a separate design decision decides which actions an agent may take at all without a human in the path. The pattern that keeps consequential execution deterministic is the other half of this: the model is allowed to propose, and a rules engine — not the model — is what actually commits anything irreversible.
Every Mutation Writes Its Proof
Once an agent can change state, the audit trail stops being a compliance artifact and becomes the safety mechanism. Every mutation in OrgDo — human or agent, no exceptions and no fast path — routes through a single layer that writes a hash-chained audit row in the same database transaction as the change itself. Each row commits to the one before it by carrying its hash, and the chain runs back to a genesis hash, so a row cannot be quietly rewritten or removed without breaking every hash that follows it.
Writing the audit inside the transaction is the load-bearing choice, not an implementation detail. An audit written afterwards — in a queue, in a hook, in a background job — can fail while the mutation succeeds. The record and the reality then disagree, and the disagreement is undetectable precisely because the thing that would have reported it is the thing that failed. Written atomically, the two cannot diverge: either both landed or neither did.
An audit trail written after the fact is a story. One written inside the transaction is evidence.
An incident review needs three answers: what happened, who did it, and in what order. A tamper-evident chain written at the point of mutation makes those a query rather than a reconstruction, and it answers identically whether the actor was a person or a model. That is not overhead bolted onto an agent system — it is the mechanism that makes the agent system something you can hand to an auditor, a regulator, or a nervous executive. The same discipline extends past the boundary of your own product, where the acting identity may not even be yours to issue: the design that carries trusted identity into a system you do not control is the federated version of the same contract.
When Coordination Cost Exceeds Work
There is a boundary where the seams between separate tools stop being an annoyance and become the dominant cost. It arrives when more effort goes into keeping the plan and the work synchronized than into doing the work — when someone's real job has quietly become reconciling the tracker against the doc against the decision log. A tax distributed across everyone appears on nobody's budget, and a cost with no owner is a cost with no name — which is why this boundary has to be looked for rather than waited for. Look for it in the second-order places: time spent agreeing on status, work done twice, decisions relitigated because the record of the first decision could not be found.
Adding agents to that environment does not relieve the pressure; it multiplies it, because a tireless actor now generates state across every seam at once. Research on hidden technical debt (NeurIPS, 2015) named the shape of this problem a decade before agents made it urgent: the interesting component is a small fraction of a real system, and the glue holding it to everything else is the rest. Agents do not shrink the glue. They run it faster than anyone is reading it.
The design question that decided everything else in OrgDo was not which agent framework to adopt — it was how many kinds of thing the system models before any agent is allowed to write to it. That is the question to answer first, and it is answered in the schema, not in the prompt.
First Steps
- Count the places where your plan and your work live separately, and the human effort spent keeping them in agreement. That number is your seam cost, and it is the number an agent multiplies rather than reduces.
- Route every mutation through one audited path before you grant an agent write access, so that an agent's action is attributable and reversible by construction rather than by investigation.
- Model each agent as a principal with an identity and a permission set. If you cannot revoke one the way you would revoke an employee's access, you have not modeled it as an actor.
Design The Graph Before Agents
The durable order is data model first, agents second: one primitive, one state machine, one audited mutation path, one layer where tenant isolation is enforced beneath the application rather than remembered inside it. Built that way, an arriving agent inherits a system that is legible and safe to operate. Built the other way, it inherits four seams and a write token, and the drift it produces is discovered by whoever is eventually asked to explain an outcome nobody can reconstruct. The event-sourced view of state as the replay of what happened (Fowler, 2005) is the same instinct arriving from a different direction: the history is not a report about the system, it is the system.
Here is the bar, and it can be checked today without buying anything. Can you name every kind of thing your system models, and defend each one? For any change in the record, can you show who made it and in what order, from a log that could not have been rewritten afterwards? Can you revoke an agent's permissions the way you would revoke a person's — at the same layer, with the same effect? Three yeses and agent autonomy becomes an engineering decision with a known blast radius; the companion piece on what enterprise agent deployment actually takes is then the operational half of the job. One no and autonomy is a bet placed on the hope that nothing surprising happens.
Turning that bar into a concrete architecture — the primitive, the audited path, the isolation boundary, each one proven against your own data and your own workload before build budget is committed — is the work an AI system design exists to do, and its fee is credited against the build that follows. The schema is where agent safety is decided. Everything after it is enforcement.
References
- Fowler, M. BoundedContext. martinfowler.com, 2014.
- National Institute of Standards and Technology. AI Risk Management Framework. NIST, 2023.
- Anthropic. Building Effective Agents. Anthropic Engineering, 2024.
- Fowler, M. Event Sourcing. martinfowler.com, 2005.
- Sculley, D., et al. Hidden Technical Debt in Machine Learning Systems. NeurIPS, 2015.
