{"slug": "a-case-for-an-autonomy-kernel", "title": "A Case for an Autonomy Kernel", "summary": "A new \"autonomy kernel\" is proposed as a persistent runtime layer beneath autonomous agents and AI models, designed to govern authority, record actions, and enable long-lived processes. The kernel traces all agent authority back to a single principal and separates purpose from power, addressing the lack of a shared substrate for agents that must act on behalf of users for days rather than seconds. This layer would sit below existing tools and models, providing a stable interface that agents and frameworks do not need to reimplement and cannot break.", "body_md": "## The Substrate\n\nAutonomous agents today are created by a prompt and discarded at the\nend of the session. But we increasingly ask them to hold real\nauthority and act on our behalf for days rather than seconds, and\nthere is no shared layer underneath them that governs what an agent\nmay do, records what it did, retains what it learned, and can stop\nit on demand. An autonomy kernel would be that layer: a runtime beneath\nthe agents and the models they reason with. Agents are disposable\nand models are replaceable; the layer beneath them should be\nneither.\n\nUnderneath that runtime is one organizing idea: authority has a\nsingle root, the principal. Every agent, every action, every grant\nof power traces back to a principal who authorized it and answers\nfor it. Purpose descends one chain (principal to intent, goal, task,\nprocess, action) and power descends another (principal to policy,\ncapability, lease, syscall), and the two meet at a single gate\nbefore any action runs. That authority model is the part most agent\ntooling skips, and it is the core of what this proposes.\n\n## Preface: Naming the Substrate\n\nThe operating system kernel solved a specific problem: every program\nspoke to the hardware in its own way, reimplemented the same\nprimitives, and failed in its own way. The kernel was the layer\nbetween hardware and software that made the rest possible. It\ndefined an interface, held it stable, and became the part nothing\nelse had to reimplement.\n\nAutonomous agents are at a similar point. Agents sit above, models\nbelow, and between them is mostly glue code and convention. The\nshift underway is from prompts and sessions to long-lived processes:\nwork that persists and can be named, paused, inspected, and audited.\nThat shift needs a defined layer to run on.\n\nThree layers, then: the agent is a process; the model is the\nreasoning engine inside it; the kernel is the runtime beneath both.\nThe model is the most capable layer and the least permanent. The\nkernel changes slowly. The ordering here is by endurance rather than\nimportance: what reasons gets replaced, what governs persists.\n\nThis layer sits beneath existing tools rather than replacing them.\nFrameworks, assistants, workflow tools, and the models themselves\nare userspace, where the work happens. The kernel’s role is to be\nthe part none of them has to reimplement and the part none of them\ncan quietly break. Today’s tools would be the first things to run on\nit.\n\nThis document has two parts, and it keeps them separate. Part I is a\nworldview: an opinionated account of what autonomous systems are and\nhow they should behave, which you can accept or argue with. Part II\nis a boundary: a contract you can build against even if you reject\nthe worldview entirely. A standard requires agreement about\ninterfaces, not about meaning.\n\n## Part I: The Worldview\n\nNine claims. Some are positions you may reject; some are invariants\nthe design treats as non-negotiable. Each is labeled.\n\n###\nIAgents Are Processes ontology\n\nAn agent is a process: a unit of work with a beginning, a\nlifecycle, state, and an end. This is a logical abstraction, like\na database transaction or an account, rather than a number in a\nscheduler. The point is that a process can be named, listed,\npaused, resumed, and inspected while it runs, by something other\nthan itself.\n\nThe alternative is to grant authority to something you can’t name,\ninspect, or hold to account. A process you can observe is a\nprocess you can govern, and only what can be governed can be\ntrusted with anything that matters. Everything below depends on\nthere being a named entity for the rest to attach to: the kernel\nhas to know what is running, why, on whose behalf, what it may do,\nwhat it has done, and when it must stop.\n\n###\nIIAgents Are Disposable\nfollows from I\n\nIf an agent is a process, any single instance is expendable. The\nagent is the unit of execution rather than the unit of meaning.\nContinuity does not live in the instance: what has to survive\n(intent, authority, memory, the record) belongs to the system, not\nto the worker that happened to hold it.\n\nThis is an engineering decision rather than a comment on worth. A\nsystem that can’t survive the loss of any single worker is fragile\nby construction. Treating instances as disposable buys the freedom\nto kill, restart, fork, and replace a running agent without losing\nwhat the work was for.\n\n###\nIIIModels Are Replaceable ontology\n\nThe model is the reasoning engine, and engines get swapped and\nretired. Build directly on a model and you inherit its shelf life:\nwhen it is deprecated, so is your stack, and the vendor’s roadmap\nbecomes yours. Build on a kernel and the model becomes a\ncomponent: the most capable component, but a replaceable one\nbehind a stable interface. An agent should be able to change the\nmodel it reasons with without changing what it is, what it may do,\nor what it owes.\n\nThe same logic applies one layer down. It is not enough for models\nto be replaceable if the layer beneath them is locked: no single\nimplementation of the kernel, and no single vendor of it, should\nbecome the next thing you can’t leave. The boundary itself has to\nbe open and portable. What that requires is the subject of Part\nII.\n\n###\nIVIntent Must Be Traceable\ninvariant\n\nEvery action must trace to an authorizing principal and a reason\nit was permitted. The requirement is not that intent be elaborate,\nonly that it be present and followable. An action with no\nrecoverable reason is a defect regardless of its result; as\nexecution gets cheaper, unaccountable automation mostly produces\nvolume.\n\nThe kernel’s responsibility here is **lineage**: an\nunbroken link from an action back to who authorized it and why,\nenforced where execution, identity, and auditing meet. The kernel\ndoes not own the meaning. One reference decomposition,\n*Principal → Intent → Goal → Task → Process → Action*, is a\nuseful map of the path from reason to deed, and only one of\nseveral possible. How richly intent is modeled is a userspace\nconcern; *that* it is traceable at all is not.\n\n###\nVAuthority Must Be Explicit\ninvariant\n\nThe default is deny. Authority is never assumed, inherited by\nproximity, or earned by good behavior; it is granted explicitly,\nscoped, leased, and set to expire. Trust and authority are\nseparate: an agent can be trusted completely and still permitted\nnothing. Authority that can’t be traced to a grant should be\ntreated as a vulnerability. Implicit authority is ambient risk;\nexplicit authority is bounded risk.\n\nA reference path maps this onto existing access models (*Policy → Capability → Lease → Syscall*) as one option among several. The invariant is stronger than any\nparticular pipeline: declared bounds are inescapable. An agent\ncannot exceed or escalate its granted authority, not through\nerror, not when its model is swapped beneath it, not under\nfailure, and not when its own reasoning argues the bounds should\nnot apply. The grant is the ceiling, and it holds whether or not\nthe agent agrees with it.\n\n###\nVIEverything Must Be Auditable\ninvariant\n\nRecording an action is part of performing it, not a separate step\nthat gets skipped under load. An action that was not logged is\ntreated as not having happened. That is the operational definition\nrather than a slogan. The audit log is not a debug trace or a\nmonitoring feed; it is the system’s source of truth.\n\nBecause of this, the audit record is also the durable substrate\nthe rest is rebuilt from: state, continuity, and memory derive\nfrom it rather than from the volatile state of any agent or the\ncontext of any model. Agents are disposable and models are\nreplaceable precisely because the record is neither.\n\n###\nVIIThe Principal Is Sovereign\ninvariant\n\nAuthority has a single root: the principal. Every agent has an\nowner, the principal who ultimately answers for the work and from\nwhom all of its authority descends, and that owner can halt,\nsuspend, or revoke any agent, intent, or grant at any time, for\nany reason or none. This is the answer to the first question\nanyone asks before handing work to an autonomous system:\n*can it be stopped?* Yes.\n\nThe stop has to be unbypassable and always available: it must work\nmid-action, while the model is unreachable, while the system is\ndegraded, and specifically when the agent’s own reasoning objects\nto being stopped. Autonomy is granted, and what is granted is\nrevocable. This is mechanism rather than policy: the kernel does\nnot decide *when* to pull the cord, only that the cord\nexists, reaches every running agent, and can’t be detached.\n\n###\nVIIIMemory Is Governed\ndiscipline built on the kernel\n\nThe transcript and memory are different things. The transcript is\nthe full, ordered record of what happened. Memory is the smaller,\ncurated result: the distilled lessons and corrections that let a\nnew agent resume where the last one stopped. Conflating the two is\nhow systems drown in their own history.\n\nMemory is built on the durable record (VI) rather than maintained\nas a second store beside it; it is a curated projection of the\naudit substrate. Every memory has an owner, a retention horizon,\nand a reason to exist, and every memory is erasable. The division\nis deliberate: the audit record is immutable, because\naccountability needs an unalterable past; memory is erasable,\nbecause what gets carried forward should be revisable, and because\nprivacy and law require deletion.\n\n###\nIXThe Kernel Must Be Small\nkeystone\n\nThis is the constraint that governs all the others: mechanism\nbelongs in the kernel, policy in userspace. A small kernel is the\nprecondition for a large ecosystem: the less the foundation\nmandates, the more can be built on it without permission.\n\nThe kernel owns only what can’t be safely delegated: execution,\nidentity, authority, communication, and auditing (durability lives\ninside auditing, since a record that does not persist is useless).\nThat is the whole list. Intent taxonomy is userspace. Memory is\nuserspace, a projection over the durable record. The kernel\nprovides the mechanisms these are built on without becoming them.\nSmallness here is the design goal, something to protect rather\nthan a limitation to work around.\n\n## Part II: The Boundary\n\nThe contract. These hold even if you reject the worldview above;\nonce it exists in running code, they are what would make this a\nstandard rather than a position paper. Written for anyone concerned\nabout lock-in.\n\nThe standard is the boundary, not the build.\nA standard is an interface others target; the codebase that\nimplements it stays swappable. Many implementations have to sit\nbehind one contract (large and small, open and proprietary), and an\nagent built against the boundary should not need to know which one\nit runs on. The line is defined where agents meet the runtime; what\nimplements it is yours to choose, build, or buy. If only one\nspecific program can satisfy it, it is a product, not a standard.\n\nUserspace does not break. The interface\nbeneath agents is stable, versioned, and backward-compatible. Work\nbuilt against it keeps working as the implementation underneath\nchanges. You should be able to build against the boundary for years\nwithout it shifting beneath you, because backward compatibility is\nwritten into the contract rather than offered as a best effort.\n\nState is portable; exit is guaranteed.\nPrincipals, intents, memory, and audit are expressible in open\nformats and exportable in full, including away from any single\nprovider of the foundation itself. Portability is a property of the\nboundary from the first day, not a concession negotiated later.\nEverything that is yours can be taken with you.\n\nAccountability is non-transferable. Every\naction is attributable to a principal who answers for it. Autonomy\ndelegates execution, never responsibility. “The agent did it” is not\na defense. The grant of authority and the assignment of\nanswerability are the same act and can’t be separated: there is\nalways an identifiable principal, and the system always records\nwhich one.\n\n## Part III: How This Becomes Real\n\nA standard is only credible if it commits to things it can be\nmeasured against. These are the commitments.\n\nGovernance. The boundary should eventually\nbecome vendor-neutral, advancing by rough consensus and running code\nrather than by decree. The mechanism for that is a shared\nconformance suite any implementation can be tested against. That\nsuite does not exist yet; building it in the open is the project’s\nfirst deliverable, and contributions are the point.\n\nAdoption is meant to be additive. The path\nfrom current prompt-and-session tools should run forward rather than\nthrough a rewrite: you put the layer under what you already run, and\nwhat you already run keeps working. Nothing should have to be thrown\nout to adopt it.\n\n“Build for decades” reduces to falsifiable constraints.\nThe claim rests on three things you can hold the project to: a\nversioned, backward-compatible contract; no dependence on any single\nmodel or vendor, the foundation’s own included; and durable state in\nopen, exportable formats. A foundation like this succeeds when it\nbecomes unremarkable enough to ignore, when the work above it\nassumes it is there and stops thinking about it.\n\nThe pattern is not new. Operating systems made software portable\nacross machines; processes made computation governable; files made\ndata durable; permissions made multi-user systems possible. An agent\nkernel is the next step: making autonomous work portable across\nmodels, organizations, and time, and governable by the principals it\nserves. The need is not more capable sessions; it is durable runtime\nsemantics for autonomous work.\n\nThe goal is not to make agents seem alive. It is to make them safe\nto run.", "url": "https://wpnews.pro/news/a-case-for-an-autonomy-kernel", "canonical_source": "https://autonomykernel.org/", "published_at": "2026-05-30 23:29:32+00:00", "updated_at": "2026-05-30 23:46:15.181819+00:00", "lang": "en", "topics": ["ai-agents", "ai-safety", "ai-infrastructure", "ai-policy", "ai-research"], "entities": [], "alternates": {"html": "https://wpnews.pro/news/a-case-for-an-autonomy-kernel", "markdown": "https://wpnews.pro/news/a-case-for-an-autonomy-kernel.md", "text": "https://wpnews.pro/news/a-case-for-an-autonomy-kernel.txt", "jsonld": "https://wpnews.pro/news/a-case-for-an-autonomy-kernel.jsonld"}}