A paradigm for autonomous systems

Intent-Driven
Computing

Programs produce intents, not effects.

Every effect is governed, and every decision comes with a receipt you can verify.

A manifesto  ·  2026

IHow the promises are kept

Everything on this page follows from the two sentences above. Three words describe how they are kept.

Structural. You do not build either promise. You do not configure it, wrap it, instrument it, or remember to apply it. The substrate keeps both promises for every program, every time, by construction.

Inescapable. They cannot be circumvented. Not because a bypass is blocked, but because a bypass is inexpressible. There is no primitive to reach for, no flag to unset, no path around the boundary. What is expressible is governed; what would be ungoverned cannot be written.

Proven. Not probabilistic. Guardrails, filters, and aligned models are probabilities: they usually hold. These promises are theorems, machine-checked, with the governance kernel extracted from the proofs themselves. Not tested and hoped. Proved.

Intent-driven computing is a computational model in which programs produce intents rather than execute effects, so that governance, authorization, audit, and replay are enforced structurally rather than retroactively.

That sentence is the category. The rest of this page is why it matters.

IIWhat an intent is

For sixty years, computing has rested on one assumption: the program is the effect. When requests.post(url) runs, the request fires. Computation and consequence are fused. There is no moment between them where anyone can ask: should this happen?

Intent-driven computing splits that atom. A program never touches the network, the filesystem, or any external system. It has no hands; it cannot reach, it can only ask. What it produces is an intent: a finite, structured piece of data that says what it wants to happen.

send_invoice  →  email/send
  to:      "client@co.com"
  subject: "Invoice #4821"
  body:    draft

The runtime examines the intent, applies the creator's policy, records the decision, and only then realizes the effect.

That gap between proposing and doing is where everything lives: authorization, audit, replay, accountability. Traditional computing has no such gap. That is why governing it has always meant guessing.

IIIA paradigm, not a feature

Think of functional programming. You can write functional code in Python or Java. Discipline gets you far. But nothing stops the mutation; the language will not hold the line for you. Haskell will. Purity there is not a habit, it is a construction property of the language.

Intent-driven computing has the same shape. You can practice it in any stack today: put a mediation layer at your agent's boundary, log the decisions, review the proposals. That is real, and it is better than nothing. But an arbitrary program in a general-purpose language can still reach the network directly. The discipline is yours to keep, and yours to break.

An enforcing form is a language in which the ungoverned effect cannot be written: it has no primitive for one, so circumvention is not a rule you might break, it is a sentence you cannot form. You can practice the paradigm anywhere. You can prove it in the enforcing form.

Paradigms with a forcing function do not stay optional. SQL injection was once every developer's problem, and escaping strings carefully was the accepted defense. Then prepared statements separated code from data, and concatenated SQL stopped being a style and became negligence; it fails code review on sight. The day a structural fix exists, the disciplined workaround starts its slide into malpractice. Autonomous systems acting on the world, under liability and regulation, are that day arriving for ungoverned effects.

IVWhy this works when everything else is a guess

There is a mathematical reason governance keeps failing when it is bolted on. Rice's theorem: no procedure can decide arbitrary properties of arbitrary programs. If your policy engine inspects a program that can do anything, it is guessing. Monitoring, filters, post-hoc review: all of it operates after computation has been expressed in effect-capable form, and all of it inherits the same limit.

Intents are not arbitrary programs. They are finite data. "Send this email to this address" can be examined completely, decided deterministically, and recorded exactly. The undecidability barrier does not apply, because the question changed. Governance over programs is impossible in general. Governance over intents is just a decision over data.

This is the whole trick, and it cannot be retrofitted. Either your architecture has an intent boundary or it does not.

VThe receipt

Every intent produces a decision record: what was proposed, what policy applied, what was decided, and why. The records form a tamper-evident hash chain. An auditor does not have to trust the platform; the chain can be verified independently, offline.

Precision matters here, so here is exactly what stands behind each promise. The mediation can be proved, not merely asserted: when the governing kernel is itself extracted from machine-checked proofs, its decisions are theorems rather than tests. This is not hypothetical. A reference implementation of the paradigm exists whose kernel is machine-checked with zero admitted assumptions, deciding in microseconds. The receipt is recorded and verifiable: every decision lands in the ledger by construction, because there is no path around the boundary that skips the record.

Contrast this with how the industry currently governs AI: content filters, aligned models, prompt-level rules. Those are probabilistic. They hold most of the time, and nobody can say which time is the exception. A proof has no exception rate. That is the difference between a guardrail and a theorem.

Together the two promises buy an asymmetry no wrapper can offer: a forbidden effect cannot happen, and a permitted effect that fails cannot hide.

VIStructural means you inherit it

Most governance today is ceremony: wrappers, middleware, policy files, YAML overlays, approval pipelines, logging you have to remember to add. Every piece is something a developer builds, maintains, and can forget.

In intent-driven computing there is no ceremony to perform, because there is nothing to add. You write what should happen. Governance, the audit trail, replay, and the receipt are properties of the execution model, the way garbage collection is a property of the runtime rather than a discipline you practice. An average author gets the same guarantees as an expert one, because the guarantees never depended on the author.

This inverts the oldest assumption about governance: that it slows you down. Ceremony slows you down. Structure does not. You stop engineering "how do I make this effect safe" and just say what you intend.

VIIIt holds at every depth

The obvious escape route is generation: if a program can write a new program, surely the new one slips the boundary. It cannot. In an enforcing implementation, the step from code-as-data to a running program is itself a governed effect. A generated program is a proposal, inspected structurally before it may exist, and whatever it goes on to produce are intents like any other. Governance is uniform at every level of the tower, programs writing programs writing programs, and that uniformity is one of the proved theorems, not a policy. Even the program that writes programs cannot write its way out.

The same holds between machines as within them. One machine calling another is an intent like any other, mediated and receipted at the boundary it crosses. Composition does not thin the guarantee.

VIIITrust is the bottleneck

Be precise about what is holding AI back. It is not capability. Models can already draft the email, move the money, sign the machine-to-machine transaction. What they cannot do, in any architecture where computation and effect are fused, is prove what they did and did not do. So we hold them back, and we are right to.

Every current answer to that problem asks for trust: trust the benchmark, the brand, the alignment, the vendor's dashboard. Trust that usually holds is exactly what a bank, a hospital, a court, or a counterparty cannot accept, because nobody can say which time is the exception. Broad adoption of AI in consequential domains is gated here, on trust, and probabilistic trust does not scale.

Intent-driven computing replaces asked-for trust with verification. You do not have to trust the model, the author of a machine, or the platform that runs it. Conduct is governed by your policy and every decision carries a receipt you can check yourself. That is what makes a machine written by a stranger safe to run, safe to buy, safe to transact with: an economy of machines becomes possible because trust attaches to the receipt, not the reputation. Trustworthy AI, in the only sense that scales, means verifiable AI. This is the precondition for handing real work to autonomous systems, and it cannot be added later.

IXThis did not come from nowhere

Computing has been circling this boundary for decades. Event sourcing separated state changes from state. Capability-based security replaced ambient authority with explicit grants. Algebraic effect systems in language theory separated the description of an effect from its execution. Desired-state infrastructure, Kubernetes and Terraform, replaced imperative scripts with declared outcomes a runtime converges toward.

Each of these separated intent from realization somewhere, and each won its ground. Intent-driven computing is what they converge to when the separation becomes total: every effect, not some; mandatory, not opt-in; proved, not promised. If you have used any of them, you already believe a piece of this.

XWhat this is not

It is not no-code. The intent layer is a higher abstraction, not an absence of depth.

It is not AI safety. It proves effects are mediated and decisions are recorded: verifiable conduct, not certified wisdom. It does not prove your goals are wise.

It is not better logging. Logs are observational; they capture what someone remembered to record. The intent stream is complete by construction.

XIThe question

Every era of computing moved the level at which people work: from the hardware, to the machine, to the question (SQL), to the document (HTML), to the desired state (Kubernetes). Each time, programs stopped saying how and started saying what, and a runtime handled the rest. Intent-driven computing is that same move for systems that act on their own.

So the question to ask of any architecture that runs autonomous systems is simple: where is the intent boundary? If computation and effect are fused, governance will always be approximate, audit will always be incomplete, and replay will always be reconstruction.

Programs produce intents, not effects. Every effect is governed and carries a receipt you can verify. Not because the developer built it that way. Because nothing else can be built.

XIIThe theory

The book

Intent-Driven Computing
Volume 1 of the mashin intelligence series. The formal theory: the computational model, the proofs, and the paradigm, treated in full.

The paradigm is developed in a series of papers published on arXiv:

XIIIImplementations

mashin is an enforcing form of the paradigm, and its reference implementation: mashinTalk, a compiled language in which ungoverned effects are inexpressible, on a runtime whose kernel is extracted from machine-checked proofs. It is where the paradigm is proved, not just practiced.

The paradigm can also be practiced in a general-purpose stack: mediate every effect at one boundary, represent proposed actions as structured data, decide them against explicit policy, and record every decision in an append-only log. You will hold the discipline by convention rather than construction, and the completeness will be conditional rather than proved. That is still a better architecture than fused computation and effect, and it is how paradigms spread.

What a governed system must provide, regardless of how it is built, is set out in an open, technology-neutral standard: the Governed AI Requirements standard.