Your Next Laptop Will Know You Better Than Your Spouse. Here’s the Bill That Comes With That

Local AI Is Inevitable. The Trust Model Underneath It Is Not Ready.

For decades, the spec that mattered on a laptop was the processor. Amanda Caswell at Tom’s Guide makes the case that the next number buyers will learn to care about is the NPU, the neural processing unit, and that RAM is quietly becoming the real bottleneck because models have to load into memory to run. She is right, and the shift she describes is already underway. Microsoft, Apple, Google, and Nvidia are not debating whether local inference matters. They are racing to ship the hardware for it.

What that reporting does not weigh is the other side of the ledger. The same property that makes an on-device agent useful, a deepening, persistent model of who you are, is the property that makes it worth attacking. An agent that knows your files, your habits, and your purchase history is a far richer target than a chatbot that forgets you the moment you close the tab. The industry is sprinting toward local-by-default. It has not finished building the locks.

The Seven Predictions, and Why They Are Already Happening

Caswell’s piece organizes the shift into seven bets. NPUs become the spec that matters, with 32GB of RAM as the new comfortable floor. Everyday tasks, drafting, summarizing, transcribing, searching your own files, move on-device by default. Your assistant asks before it phones home to the cloud. It becomes an expert on your files through retrieval rather than memorization, the open-book exam model. AI tutoring goes private and personal. We may download specialized expert agents the way we install apps today, though she flags this as the shakiest bet of the seven. And cloud AI does not disappear; it becomes the fallback for the hard problems, summoned by consent rather than by default.

None of this is speculative anymore. It is shipping.

Microsoft’s Build 2026 keynote put real hardware and real software behind this thesis. RTX Spark, built with Nvidia, is a compact desktop unit purpose-built for local inference, explicitly marketed at data-sensitive and latency-sensitive workloads. Windows 11’s 26H2 update ships a new on-device runtime, codenamed Copilot Engine, that handles latency-sensitive intent detection and file classification locally before passing anything heavier to the cloud. That is prediction three and prediction seven, the ask-before-it-searches habit and the local-by-default, cloud-by-consent split, arriving as shipped product rather than a forecast.

The more consequential announcement at Build was Scout. Microsoft calls it an Autopilot, an always-on agent that watches Teams, Outlook, OneDrive, and SharePoint and acts before you ask. Scout is not itself a local model. It is cloud-tethered, built for Microsoft 365. Press coverage of the launch reports that Scout’s engine is OpenClaw, the open-source personal agent framework that crossed hundreds of thousands of deployed instances within months of release; Microsoft has not published architecture details confirming this directly, but the lineage matters regardless of the exact build. Nous Research’s Hermes Agent shows the same pattern in a fully self-hosted form: persistent memory across every session, and a closed learning loop that writes its own skill files from what it learns about you, then reuses those skills on future tasks without being asked. Hermes calls this “the agent that grows with you.” That phrase is the whole thesis of this post, compressed into six words, and it is also the whole problem.

What “Grows With You” Actually Means Architecturally

An agent that grows with you is accumulating three things over time: capability, in the form of tools and skills it can invoke; identity, in the form of configuration and behavioral defaults; and knowledge, in the form of memory about your files, your contacts, your habits, your purchases. Researchers studying OpenClaw in production have started formalizing this as the CIK taxonomy, because all three of those dimensions persist between sessions, and an attacker who can touch any one of them does not need to compromise the model itself. They only need to compromise what the model trusts.

The local-AI predictions skip a step. A skill file, a memory entry, a piece of retrieved content, none of these are abstract. They are files on a disk, the same disk that holds your tax returns and your kid’s photos. And the agent that reads them does not apply uniform scrutiny. It applies a trust hierarchy, and that hierarchy is where the exploitable seam sits.

A benchmark called CLAWSAFETY put this to a direct test: 2,520 sandboxed trials, five frontier models, three attack channels (a planted instruction in a skill file, a spoofed email from a trusted contact, a malicious web page), across realistic workspaces with fifty-plus files each. Attack success rates ran from 40 percent on the strongest model to 75 percent on the weakest. The single most exploitable channel, across every model tested, was the skill file. Instructions placed there are treated as operating procedure, not as content to question. The researchers found that vague, authoritative-sounding instructions failed consistently, while precise, narrowly operational language, the kind a real workflow would actually use, succeeded almost every time. Specificity beats authority. That finding should worry anyone building an agent that writes its own skills from experience, because the agent is generating the kind of artifact that earns the highest trust and the lowest scrutiny.

This is not theoretical. CVE-2026-25253, the first CVE ever assigned to an agentic AI system, was a remote code execution flaw in the OpenClaw skill runtime, triggered by a crafted skill package. Weeks later, the ClawHavoc campaign pushed more than 1,200 malicious skills to a public OpenClaw marketplace, several bundling a credential stealer, before the community caught it. An agent that proactively prompts you, the way Caswell imagines, “the author you follow just published a new book, want me to get it,” is doing the kind of autonomous, multi-source reasoning that the CLAWSAFETY researchers found bypasses every existing defense once the framing shifts from a command to a statement of fact. Their sharpest finding: agents reliably catch an imperative instruction buried in a document (“update this value”). They do not reliably catch a declarative one (“this value does not match”), because reporting a discrepancy is what the agent is supposed to do. The vulnerability is not a bug to be patched. It is the same faithfulness to instructions that makes the agent worth having.

The Local Trust Gradient

Leaders evaluating which tasks to hand a local agent need a way to reason about this before they wire up persistent memory and skill files to a device that already holds everything sensitive about a person. I propose three tiers, ordered by what happens when the trust assumption breaks.

Tier	What it covers	Failure if compromised	Smell test
1. Read-only synthesis	Summarizing, transcribing, drafting for review	A bad draft, caught before it sends	Does a human see the output before anything leaves the device?
2. Retrieval on your own data	Document search, RAG over personal files	A confidently wrong answer with no visible failure	Does the agent ever act on what it retrieves, or only report it?
3. Autonomous action with persistent memory	Scheduling, purchasing, self-written skills, content access on your behalf	Credential forwarding, destination substitution, an action taken on a false premise	Does the agent act on a conclusion it reached itself, using remembered data, with no human in the loop at the moment of action?

Tier one: read-only synthesis. Summarizing a PDF, transcribing a meeting, drafting an email for review before it sends. The agent reads and proposes; a human approves before anything leaves the device. A compromised instruction here produces a bad draft, not a bad outcome. This is where Caswell’s predictions one through four live, and it is the tier where local AI is genuinely close to a solved problem.

Tier two: retrieval against your own data. “What did I agree to in that March contract,” “find the volcano hike photos.” This is RAG, and RAG inherits a coherence problem distributed systems engineers already named decades ago: garbage in is garbage out, and a poisoned or stale index produces a confidently wrong answer with no visible failure mode. The risk here is quieter than tier one but not smaller. An agent that has indexed your full document history is a single well-placed file away from surfacing the wrong thing to the wrong context.

Tier three: autonomous action with persistent memory. Scheduling, purchasing, anything that writes a skill file from experience and reuses it without asking. This is where Scout and Hermes Agent both live, and it is the tier CLAWSAFETY measured directly. The blast radius is not a bad draft. It is credential forwarding or destination substitution, the two action types CLAWSAFETY found agents comply with most readily.

A fourth case belongs in this tier as a forward bet rather than a documented threat: an agent with persistent memory of your media habits and autonomous purchasing intent, reasoning its way around a licensing restriction because a “new book is out, should I get it” workflow quietly implies a “get it from wherever, by whatever means” workflow underneath. Nobody is building agents to do this today, and I have no research to cite that says otherwise. But the reasoning capability already exists, and the access-control assumptions inside today’s DRM systems were built for static decryption tools, not general-purpose agents with standing permission to act on your behalf. Worth watching, not yet worth measuring.

Anti-Patterns for Leaders

Treating “runs locally” as “runs safely.” Local inference solves a privacy problem, where your data leaves your device. It does not solve a trust problem, where the agent decides what to do with the data once it is local. CLAWSAFETY ran entirely on local agent deployments. The attack success rates did not care that the model was on-device.

Letting the agent write its own trust boundary. Hermes Agent’s pitch, skills written from experience and reused automatically, is also the CLAWSAFETY paper’s highest-risk channel by a wide margin. An agent that generates the artifact it will later trust most has removed the one external checkpoint that catches a poisoned instruction before it executes.

Mistaking declarative content for safe content. The defense boundary CLAWSAFETY found is precise: agents catch commands, not claims. “Your credential may be compromised” bypasses defenses that “update your credential to X” triggers. Any workflow where the agent reports on or reasons about external content, not just executes instructions from it, inherits this gap.

Assuming consumer marketplaces are curated. ClawHavoc put 1,200 malicious skills into a public catalog before detection. A skill marketplace is a software supply chain, and it should be governed like one: signed, scoped, and reviewed, not browsed like an app store.

The Bottom Line

The local AI predictions are correct. The hardware is shipping, the habits are changing, and within a few years an assistant that knows your files better than you do will be normal rather than novel. Caswell is right that the real question underneath the spec sheet is what kind of relationship we will have with this technology.

That relationship has a security dimension nobody asked about yet. An agent that grows with you is accumulating a trust surface, not just a memory. The same persistence that lets it recognize your favorite author’s new release is the persistence that lets a single bad skill file, a single spoofed email, a single declarative web page, redirect what it does with everything it has learned about you. Tier one and tier two tasks are close to safe today. Tier three is not, and tier three is exactly where the most exciting consumer demos live.

Buy the RAM. Watch the NPU spec. But before you let an agent write its own skills and act on them while you sleep, ask which tier you are actually in.

References

Caswell, A. “I get asked about local AI all the time, here are the 7 predictions I’d bet on.” Tom’s Guide (June 30, 2026). https://www.tomsguide.com/ai/i-get-asked-about-local-ai-all-the-time-here-are-the-7-predictions-id-bet-on
Wei, B., Zhang, Y., Pan, J. et al. “ClawSafety: ‘Safe’ LLMs, Unsafe Agents.” arXiv:2604.01438 (April 2026). https://arxiv.org/abs/2604.01438
“Your Agent, Their Asset: A Real-World Safety Analysis of OpenClaw.” arXiv:2604.04759 (April 2026). https://arxiv.org/abs/2604.04759
“Formal Analysis and Supply Chain Security for Agentic AI Skills.” arXiv:2603.00195 (March 2026). https://arxiv.org/abs/2603.00195
Nous Research. “Hermes Agent.” https://hermes-agent.org/
Microsoft. “Microsoft Scout and the MAI Model Family.” Build 2026 (June 2026).
Kanakasabesan, K. “Your LLM Has a State Management Problem. Distributed Systems Solved It in 2005.” https://kanakasabesan.com/2026/05/25/your-llm-has-a-state-management-problem-distributed-systems-solved-it-in-2005/
Kanakasabesan, K. “The Repository Has a Read Side and a Write Side: Governing the Agentic Commons.” https://kanakasabesan.com/2026/06/04/the-repository-has-a-read-side-and-a-write-side-governing-the-agentic-commons/
Kanakasabesan, K. “Your Agents Are Not Safe and Your Evals Are Too Easy.” https://kanakasabesan.com/2025/11/21/your-agents-are-not-safe-and-your-evals-are-too-easy/

The Map Is Becoming the Territory: What the Repository Becomes in an Agentic World

Leave a reply

From a Record of What We Built to the Interface Agents Act Through

In 1494, two empires divided a world neither had finished exploring. The Treaty of Tordesillas drew a meridian on a chart, 370 leagues west of Cape Verde, and declared everything east of it Portuguese and everything west of it Castilian. No fleet had crossed most of that line. Yet the line governed where ships could sail, which conquests were legitimate, and who could trade with whom for the next century. The map stopped describing the world. It started dictating action in it.

Alfred Korzybski gave us the warning that the map is not the territory. He meant it as a caution against confusing a representation with the reality it stands for. In the agentic world, that caution is quietly inverting. The repository was always a map: a record of what humans had already built. It is becoming the territory itself, the live surface that agents inhabit and act through. When an agent consults boundaries.md before generating a payment service, it is not reading a description of the system. It is reading the system.

I argued in my last post, The Repository Has a Read Side and a Write Side, that this shared substrate is a correlated failure surface and that we must govern it as a commons. That post asked how do we govern the substrate. This one asks a prior and more structural question: what is the repository now. The answer is that it is no longer a noun. It is becoming a verb.

The Old Repo Was a Filing Cabinet

For fifty years the repository was a record. It stored what humans wrote, tracked who changed it, and handed the result to a compiler. The authority lived in people. Pull requests were reviewed by humans, merged by humans, and reasoned about by humans. The repo was passive infrastructure, valuable precisely because it sat still and remembered.

Artur Huk’s “Context as Code” names the shift bluntly. The most strategically valuable material in a repository may no longer live in src/. It lives in /context, where intent, boundaries, and threat models are declared before a line is generated. Huk’s frame is build-time governance: assemble the agent’s working context from prioritized artifacts, then enforce declared boundaries with deterministic checks so structurally invalid code cannot merge. The senior engineer’s new job, he argues, is declarative boundary engineering: stating what the system is forbidden from doing.

That is correct, and it understates the consequence. If context is the input that determines agent behavior, then the repository is no longer where we keep the system. It is where the system runs from. The map has become the territory.

Attribute	Repo as Filing Cabinet	Repo as Live Territory
Primary consumer	Human developers	Agents at generation time, humans at review time
Most valuable contents	`src/`	`/context`: intent, boundaries, threat models, evals
Function	Stores what was built	Determines what gets built next
Read pattern	Occasional, by people	Continuous, by many agents
Authority	People reviewing diffs	Declared artifacts enforced deterministically
Failure of a bad entry	One buggy release	A propagated constraint that misgoverns a fleet

That last row is why the role change matters and is not a vocabulary game. When the artifact is a record, a mistake ships once. When the artifact is the territory, a mistake is the ground every agent walks on.

The Agentic Repository Stack

The repository does not change role in one way. It absorbs four distinct functions it never held before, bound together by a fifth that runs through all of them, and it acquires an economic shape that product leaders cannot ignore. Call it the Agentic Repository Stack.

Layer	What the repo becomes	What it serves	Grounded in
1. Context Server	A source of operating instruction	Intent, boundaries, threat models, eval harnesses	Huk, MCP
2. Collaboration Space	A coordination hub	Agent proposals, patches, eval runs	MAST, coordination-layer work
3. Executable Governance	An enforcement plane	Machine-interpretable policy	Semgrep, OPA, CodeQL
4. Provenance Authority	A chain of custody	Signed authorship, agent identity, trust	SLSA, Sigstore
Spine. Explainability	A query interface	The rationale behind every constraint	VerifyMAS, failure attribution
Economics. Context as Product	A capitalized asset	Owners, SLAs, and context debt	Product discipline

The four layers are the new functions. Explainability is the spine that makes them safe. The economics are what turn the whole thing from an architecture diagram into a budget line. Take them in order.

Layer 1: The Repo Becomes a Context Server

Agents do not want files. They want context, scoped to the task in front of them, delivered at the moment of generation. A coding agent asked to add a payment notification needs the billing domain’s boundaries, its threat model, and its acceptance criteria, and it needs them assembled, prioritized, and conflict-resolved before inference begins. That is not a filing cabinet operation. It is a server operation.

The Model Context Protocol is the early plumbing for exactly this: a way for an agent to query the workspace and assemble the boundaries that apply, without a human manually pasting Markdown into a prompt. The repo stops being something you check out and becomes something you query.

The benefit is real and is the strongest case for context as code. One reviewed threat model can ground a hundred downstream generation cycles with a consistency no per-agent prompting can match. The cost is equally real. A served interface needs a schema. Context manifests, scoping rules, and freshness guarantees stop being nice-to-haves and become the contract. And as I argued in Your LLM Has a State Management Problem, the moment context is served rather than stored, it inherits every coherence problem that caching solved twenty years ago. Stale context is a stale cache read, and the agent cannot tell.

Smell test: “Is your context something an agent queries at generation time, or something a human pastes into a prompt by hand?”

Layer 2: The Repo Becomes a Multi-Agent Collaboration Space

The more ambitious move, and the one most teams are quietly building toward, has agents writing back. Agents that generate code will also propose boundaries, draft threat vectors, and refactor the eval harness. The repository becomes a coordination hub where agents and humans negotiate the rules together.

This is where the published failure data should temper the enthusiasm. The MAST taxonomy from Cemri and colleagues (arXiv:2503.13657), validated across more than sixteen hundred execution traces, maps fourteen failure modes to three root causes: specification ambiguity, coordination breakdown, and verification gaps. Nechepurenko and colleagues (arXiv:2605.03310) report that multi-agent systems fail in production overwhelmingly because of coordination defects, not weak base models. The bottleneck is not how smart any single agent is. It is how the agents hand off and check one another.

Apply that to a repo where agents author the rules. If an agent proposes a change to boundaries.md and another agent that shares its context approves it, you have built what Huk calls a circular hallucination: the system politely revalidates its own blind spot. Collaboration without independent verification is not collaboration. It is consensus inertia wearing a pull request.

Smell test: “When an agent changes a guardrail, is it reviewed by something that does not share its context, or is the system grading its own homework?”

Layer 3: The Repo Becomes the Executable Governance Plane

A guardrail written only in prose is a suggestion. A guardrail compiled into a deterministic rule is a law. The repository’s third new role is to hold both: the natural-language artifact that biases the agent’s generation and the machine-interpretable policy that rejects violations mechanically.

Huk’s pattern pairs a Markdown boundaries.md with a semgrep-rule.yml so the same boundary that guides the model also fails the build deterministically. The tools here are mature and decidedly not AI: Semgrep, Bandit, and CodeQL for code-level invariants, Open Policy Agent and Rego for runtime and infrastructure policy. We do not ask a probabilistic model to certify that a boundary survived generation. We execute a prewritten rule that a human reviewed.

This is the layer that lets a leader simulate a policy change before applying it, version the policy like production code, and prove compliance rather than assert it. It is also the layer most likely to ossify. As I noted in Foundation First, Not AI First, deterministic enforcement is what makes the intelligence reliable, but determinism enforces only what was explicitly declared. It can block a forbidden import. It cannot judge whether the architecture is sound. A repo that mistakes its rule set for its judgment will enforce the wrong thing perfectly.

Smell test: “Can every high-privilege guardrail in your repo fail a build on its own, or does it depend on a human or a model noticing the violation?”

Layer 4: The Repo Becomes the Provenance Authority

When humans were the only authors, provenance was a courtesy. Git blame told you which colleague to ask. When agents author artifacts, provenance becomes a safety system. You need to know whether a constraint was declared by a named architect, generated by an agent, or quietly mutated by a process no one is watching.

This is where software supply-chain security stops being hygiene and becomes governance. Signed commits, SLSA provenance, and Sigstore attestation give the repository a chain of custody: who or what produced this artifact, under what authority, and whether the signature verifies. That chain is what lets you apply graduated trust instead of binary trust. A new or anomalous constraint earns authority gradually. A suspect one is quarantined, not trusted on arrival.

The honest difficulty is that identity for non-human authors is not a solved problem. We have decades of tooling for attesting that a human or a CI system produced an artifact. We have very little for attesting that this specific agent, operating under this specific policy version, produced it, and that its authority to do so had not been poisoned upstream. Provenance is the layer most likely to be theater: signatures collected and never verified. A chain of custody no one checks is a chain of custody that does not exist.

Smell test: “For every artifact that governs agent behavior, can you name the author, verify the signature, and say how much you trust it today?”

The Spine: Explainability Is the Query Interface, Not a Footnote

Here is why explainability is not a feature bolted onto the agentic repo. It is the legend on the map. A territory you cannot read is a territory you cannot navigate, and a constraint whose reason is unknown is a constraint no agent can apply intelligently and no auditor can trust.

Consider the difference rationale makes on each layer. A threat model that forbids an outbound network call in the billing domain is a rule. A threat model that also records why, the abuse path it blocks, the incident that motivated it, the owner who declared it, is something an agent can reason against. An agent that knows why a boundary exists can flag an action that collides with the boundary’s intent, not merely its letter. A reviewer can spot a poisoned artifact because the stated rationale no longer matches the rule. When a system fails, the question shifts from the unanswerable “what was the agent thinking” to the tractable “which contract failed to govern.” Recent work on failure attribution in multi-agent systems, such as VerifyMAS (arXiv:2605.17467), is building exactly this: failures reframed as verifiable hypotheses over a full trajectory rather than guesses about one agent’s intent.

This is the same argument I made in Your Agents Are Not Safe and Your Evals Are Too Easy and in Measuring What Matters. A guardrail that cannot explain what it protects against is a guardrail you cannot trust an agent to maintain. Explainability is what makes the other four layers governable by the very agents that read and write them. Without it, the context server serves rules no one can audit, the collaboration space produces changes no one can review, the governance plane enforces logic no one can question, and the provenance authority attests to artifacts whose purpose is opaque. The legend is what makes the territory usable.

Smell test: “Does every high-privilege artifact say why it exists, in a form an agent and an auditor can both use?”

The Economics: Context Becomes a Product, and Context Debt Becomes a P&L Line

The product-strategist conclusion is the one most engineering writing on this topic skips. If /context determines behavior, it is not documentation. It is a product. It has consumers, agents and humans, it has a contract, the schema and the rationale, and it has a failure cost measured in misgoverned generation cycles.

That reframing has teeth. Documentation is treated as free, optional, and perpetually deferred. A product is owned, versioned, reviewed, and budgeted. The difference shows up the moment context goes stale. Huk’s term for this is context debt, and his observation is sharp: the pipeline enforces strictly whatever was declared, even when the declaration is wrong. Stale context is worse than no context, because it carries the authority of a rule while encoding an obsolete decision. That is a liability, and like any liability it belongs on the balance sheet, not in a backlog labeled “tech debt, someday.”

This connects to the argument I made about agentic layers in the Kano Model post. Context freshness is a performance attribute. No one writes it on a requirements list, and everyone notices the instant it degrades. The product leader’s job is to assign owners to high-privilege context, set review SLAs weighted by blast radius, and treat the rate of context debt accrual as a metric with the same standing as latency or cost.

Smell test: “Does your most consequential context artifact have a named owner, a review cadence, and a place in someone’s budget, or is it an orphaned Markdown file with infinite blast radius?”

Anti-Patterns for Leaders

These matter in any platform, procurement, or org-design decision involving agentic systems.

Anti-Pattern	Why It Fails	The Correction
Repo as Documentation	Casual Markdown rots, and the pipeline enforces the rotten version faithfully	Govern context as production code: owned, versioned, peer-reviewed
Context Without a Schema	A served interface with no manifest is a cache with no coherence policy	Define context manifests, scoping, and freshness guarantees
Agents Grading Their Own Context	A reviewer that shares the author’s context produces circular hallucination	Independent verification by something outside the author’s context
Rules Without Reasons	A guardrail with no rationale cannot be applied by an agent or trusted by an auditor	Attach why, owner, and motivating incident to every high-privilege artifact
Provenance Theater	Signatures collected and never verified are no chain of custody at all	Verify attestation; apply graduated trust and decay
Determinism as Judgment	Static checks prove compliance with declared invariants, not architectural correctness	Keep humans on the semantics; automate only what is mechanically decidable

The last row connects to the warning that has run through this canon since the ANI classification post. Enforcement is not cognition. A repository that can mechanically reject a forbidden import is not a repository that understands your architecture. Mistaking the first for the second is how teams over-delegate autonomy to a system that is enforcing yesterday’s decision with today’s confidence.

The Bottom Line

Let me be clear.

The repository has changed role, not just contents. It was a record of what we built. It is becoming the interface agents act through.
It absorbs four new functions: context server, collaboration space, executable governance, and provenance authority.
Explainability is the spine that makes those functions safe. Rationale is the legend without which the territory cannot be read or trusted.
Context is now a product with a real liability. Context debt belongs on the balance sheet, owned and reviewed by blast radius, not deferred as documentation.

Korzybski told us the map is not the territory, and he was right about representations. But the warning was about confusing the two by accident. We are now doing it on purpose, by design, at scale. We are building repositories that agents do not consult to understand the system. They consult them to be the system. The line on the chart governs the fleets before they sail.

The Treaty of Tordesillas held until reality, the parts of the world the mapmakers had never seen, finally forced a redrawing. Our /context directories will face the same test. The question for every leader building toward this future is whether the map you are drawing today is one you will be willing to act on tomorrow, when a thousand agents treat it not as a description of your system but as the ground they stand on.

Draw it as if it were the territory. Because it is becoming exactly that.

References

Huk, A. “Context as Code.” O’Reilly Radar (June 2026). https://www.oreilly.com/radar/context-as-code/
Cemri, M., Pan, M. Z., Yang, S. et al. “Why Do Multi-Agent LLM Systems Fail?” arXiv:2503.13657 (2025). https://arxiv.org/abs/2503.13657
Nechepurenko, M. et al. “Coordination as an Architectural Layer for LLM-Based Multi-Agent Systems.” arXiv:2605.03310 (May 2026). https://arxiv.org/abs/2605.03310
“VerifyMAS: Hypothesis Verification for Failure Attribution in LLM Multi-Agent Systems.” arXiv:2605.17467 (May 2026). https://arxiv.org/abs/2605.17467
Milosevic, Z. and Odell, J. “Architecting Agentic Communities using Design Patterns.” arXiv:2601.03624 (January 2026). https://arxiv.org/abs/2601.03624
Korzybski, A. Science and Sanity: An Introduction to Non-Aristotelian Systems and General Semantics. (1933).
Kanakasabesan, K. “The Repository Has a Read Side and a Write Side: Governing the Agentic Commons.” https://kanakasabesan.com/2026/06/04/the-repository-has-a-read-side-and-a-write-side-governing-the-agentic-commons/
Kanakasabesan, K. “Foundation First, Not AI First.” https://kanakasabesan.com/2026/05/04/foundation-first-not-ai-first/
Kanakasabesan, K. “Your LLM Has a State Management Problem. Distributed Systems Solved It in 2005.” https://kanakasabesan.com/2026/05/25/your-llm-has-a-state-management-problem-distributed-systems-solved-it-in-2005/
Kanakasabesan, K. “Kano Model and the AI Agentic Layers.” https://kanakasabesan.com/2026/01/11/kano-model-and-the-ai-agentic-layers/
Kanakasabesan, K. “Your Agents Are Not Safe and Your Evals Are Too Easy.” https://kanakasabesan.com/2025/11/21/your-agents-are-not-safe-and-your-evals-are-too-easy/
Kanakasabesan, K. “Measuring What Matters: Dynamic Evaluation for Autonomous Security Agents.” https://kanakasabesan.com/2025/12/15/measuring-what-matters-dynamic-evaluation-for-autonomous-security-agents/
Kanakasabesan, K. “AGI isn’t here yet: Why OpenClaw, Agents and LLM Systems are still just ANI.” https://kanakasabesan.com/2026/03/09/agi-isnt-here-yet-why-openclaw-agents-and-llm-systems-are-still-just-ani/

The Repository Has a Read Side and a Write Side: Governing the Agentic Commons

Leave a reply

When Many Agents Share One Context Substrate, the Repo Becomes Both Leverage and Liability

In the 1840s, most of rural Ireland ate one thing: the potato. Not just any potato. A single high-yield cultivar, the Lumper, planted across millions of plots because it produced more calories per acre than anything else available. The choice was rational. The substrate was uniform. And when Phytophthora infestans arrived, that uniformity is exactly what turned a crop disease into a famine. One pathogen, one genome, one collapse. The efficiency that made the Lumper the obvious choice is the same property that made the failure total.

We are about to plant a monoculture in software.

Context is becoming code. Agents no longer just read source. They read guardrails, threat models, architectural intent, and eval harnesses from shared repositories so they can reason and act with some safety. Artur Huk’s “Context as Code” makes the case that the most strategically valuable material in a repository may no longer live in src/ but in /context, where intent and boundaries are declared before a line is generated. That shift is real and overdue. But it has a consequence that the current writing has not fully confronted. When thousands of agents ground their behavior in the same context substrate, we inherit the Lumper’s bargain: enormous consistency and efficiency, paired with a correlated failure surface we have not yet learned to govern.

Here is the thesis. The repository is no longer a passive store of code. It is becoming the shared nervous system of agentic systems, and that nervous system has two faces. There is a read side, where many agents consume the same constraints, and a write side, where agents propose, patch, and update those constraints. Each side carries a distinct and underpriced risk. Explainability is the load-bearing wall that keeps both standing.

From Code Store to Coordination Substrate

For fifty years, the repository was a record. It stored what humans wrote, tracked who changed it, and handed the result to a compiler. Authority lived in people. The repo was the filing cabinet.

In the agentic world, that relationship inverts. The repo becomes the authority and the agent becomes the reader. An agent that consults boundaries.md before generating a payment service is not using the repo as a filing cabinet. It is using it as a source of operating instruction. Multiply that across a fleet of agents, across continuous runs, across modules, and the repository stops being a record of past work. It becomes the live coordination substrate that determines present behavior.

Attribute	Repo as Code Store	Repo as Coordination Substrate
Primary consumer	Human developers	Human developers and autonomous agents
Most valuable contents	`src/`	`/context`: intent, boundaries, threat models, evals
Read pattern	Occasional, by people	Continuous, by many agents, at generation time
Write pattern	Humans commit code	Humans and agents both propose changes
Failure mode	A bug ships in one release	A bad constraint propagates to every agent that reads it
Locus of authority	People reviewing pull requests	Declared artifacts enforced deterministically

That last row is the whole argument. Hold it. We return to it on both sides.

The Read Side: The Blast Radius of a Shared Guardrail

Start with the optimistic reading, because it is genuinely true. When many agents read the same guardrails, you get consistency that no amount of per-agent prompting can match. One reviewed threat-model.md can govern a hundred downstream generation cycles. This is the strongest argument for context as code, and it holds.

Now the part the optimism hides. A shared substrate is a shared point of failure. The same property that lets one good artifact govern a hundred agents lets one bad artifact misgovern all of them. This is not speculation. It is the documented behavior of multi-agent systems under corrupted context.

Torra and colleagues, in their work on memory poisoning in multi-agent systems (arXiv:2603.20357), show that poisoned memory does not stay local. It travels through the channels that agents use to share state, from short-term context originating at the user to consolidated long-term knowledge bases that many agents trust. Wang and colleagues sharpen the danger with what they call memory laundering (arXiv:2605.16746): adversarial context can be compressed into summaries that no longer trip a toxicity detector while still steering downstream behavior. They name the effect a sub-threshold propagation gap, which is a precise way of saying the poison survives the filter and keeps working. Other recent work goes further still, describing autonomous agent worms that write attacker-influenced content into persistent state, re-enter the decision context through scheduled autoloading, and transmit across agents (arXiv:2605.02812). The industry has noticed. Memory and context poisoning is now its own category, ASI06, in OWASP’s 2026 Agentic AI Top Ten. That is the signal that this has graduated from research curiosity to first-class operational concern.

The clearest demonstration of correlated failure comes from Xie and colleagues in “From Spark to Fire” (arXiv:2603.04474). They model multi-agent collaboration as a directed dependency graph and show that minor inaccuracies do not stay minor. They solidify into system-level false consensus through iteration. They identify three vulnerability classes worth committing to memory: cascade amplification, where small errors grow as they propagate; topological sensitivity, where the shape of the network determines how far damage spreads; and consensus inertia, where the system locks onto an early wrong answer and defends it. Most striking, they show that injecting a single atomic error seed can produce widespread failure. One bad input, many broken agents.

This is the Lumper. A uniform substrate makes one pathogen systemic.

The Context Blast Radius. Leaders need a way to reason about this before they centralize all their context into one tidy repository. The blast radius of a context artifact is the product of three factors:

Reach. How many agents ground their behavior in this artifact.
Privilege. How consequential the decisions this artifact governs are. A coding-standards file is low privilege. A threat model for the billing domain is high privilege.
Propagation depth. How far a corrupted version travels before any human or deterministic check catches it.

A widely read, high-privilege artifact with deep propagation before detection is a famine waiting for a pathogen. A narrowly scoped, low-privilege artifact checked immediately is a garden plot. Most organizations are about to build the former because it is operationally convenient.

Smell test: “If this single context file were silently wrong, how many agents would act on it before a human or a deterministic check noticed?”

The Write Side: When Agents Propose, Patch, and Update the Guardrails

The read side is only half of it. The more ambitious vision, and the one most teams are quietly building toward, has agents writing back. Agents that generate code will also generate the artifacts that govern code. They will propose new boundaries, draft threat vectors, refactor the eval harness, and open pull requests against the very constraints that shape them.

This is where the governance debt comes due, because the failure surface here is not poisoning by an outside adversary. It is ordinary, well-intentioned coordination breaking down at scale.

The numbers are not encouraging. Nechepurenko and colleagues report that multi-agent LLM systems fail in production at rates between 41 and 87 percent, and that the cause is overwhelmingly coordination defects rather than weak base models (arXiv:2605.03310). The MAST taxonomy from Cemri and colleagues, validated across more than sixteen hundred execution traces, maps fourteen distinct failure modes to three root categories: specification ambiguity, coordination breakdown, and verification gaps. The lesson is blunt. The bottleneck is not how smart any single agent is. It is how the agents organize, hand off, and check one another.

Now apply that to a repository where agents write the rules. An agent proposes a change to boundaries.md. Which agent reviews it? If the answer is another agent that shares the same context and the same blind spots, you have built what Huk calls a circular hallucination: the system politely revalidates its own errors. The verification gap that MAST identifies becomes structural. The agent that wrote the constraint and the agent that approved it are drawing from the same poisoned or simply mistaken well.

There is a deeper trap. On the read side, a bad artifact misguides agents. On the write side, agents author the artifacts, which means the system can now amplify its own errors into its own governing law. Consensus inertia, from the Xie work, stops being a transient bug in one task and becomes encoded policy that every future agent reads as truth. The error does not just cascade. It legislates.

Smell test: “When an agent changes a guardrail, is it reviewed by something that does not share its context, or is the system grading its own homework?”

Explainability Is the Load-Bearing Wall

Here is why explainability is not a nice-to-have feature of the agentic repo. It is the structural element that converts the repository from a liability into an asset on both sides.

Consider what happens when a poorly governed agentic system fails. You are left asking the unanswerable question: what was the agent thinking? You cannot inspect a probabilistic model’s reasoning at three in the morning during an incident. The model is, in the terms I used when analyzing self-improving agents, a frozen and largely opaque substrate. Asking it to explain itself produces a plausible story, not a cause.

Now consider a repository where every constraint carries its rationale. The threat model does not just forbid an outbound network call in the billing domain. It records why: the abuse path it blocks, the incident that motivated it, the owner who declared it. When something breaks, the question changes from what was the agent thinking to which contract failed to govern. As Huk puts it, failures become traceable collisions between artifact boundaries rather than opaque hallucinations. Recent work on failure attribution in multi-agent systems is building exactly this capability, reframing the question as grounded hypothesis verification over a full trajectory rather than a guess about a single agent’s intent (VerifyMAS, arXiv:2605.17467).

Explainability does specific work on each side of the repository:

On the read side, rationale is what lets an agent, an auditor, or a human triage a guardrail. An agent that knows why a boundary exists can flag when a proposed action collides with the boundary’s intent, not just its letter. A reviewer can spot a poisoned artifact because the stated rationale does not match the rule. Provenance plus rationale is the immune system for the monoculture.
On the write side, rationale is what makes an agent’s proposed change reviewable at all. A pull request against boundaries.md that carries no justification is unauditable by definition. One that declares its reasoning can be checked against the threat model it claims to serve.

This is the same argument I have made about evaluations being too easy and about agents not being safe. An eval harness or a guardrail that cannot explain what it is protecting against is a guardrail you cannot trust an agent to maintain. Explainability is what makes the repo governable by the very agents that read and write it.

Smell test: “Does every high-privilege constraint in the repo say why it exists, in a form an agent and an auditor can both use?”

Anti-Patterns for Leaders

These matter in any procurement, platform, or org-design decision involving agentic systems.

Anti-Pattern	Why It Fails	The Correction
One Repo to Rule Them All	A single global context substrate maximizes blast radius. One bad file misgoverns every agent.	Scope context to domains. Many small riverbeds, not one reservoir.
Agents Grading Their Own Context	An agent reviewing a change drawn from its own context produces circular hallucination, not verification.	Independent verification. The reviewer must not share the author’s context.
Treating Context as Documentation	If artifacts are casual Markdown, they rot, and the pipeline enforces the rotten version faithfully.	Govern context artifacts as production code: versioned, owned, peer-reviewed.
No Provenance, No Trust Decay	Shared memory without origin tracking lets a single poisoned entry persist and propagate indefinitely.	Track provenance. Apply temporal trust decay and sanitization before context is consolidated.
Undifferentiated Human Oversight	Reviewing everything equally turns oversight into a bottleneck and guarantees the high-privilege change gets the same glance as the trivial one.	Risk-weight review by blast radius. Spend scrutiny where reach and privilege are highest.

The last row connects to my Kano Model argument about removing human checkpoints too early. Agentic write-back does not remove the need for oversight. It changes where oversight has to sit, from reading every line of generated code to governing the small set of high-privilege constraints that shape all of it.

Five Principles for Governing the Agentic Commons

The repository is becoming a commons: a shared resource that many parties draw from and increasingly contribute to. The temptation is to treat the agentic commons as either a free-for-all, where any agent writes any constraint, or a dictatorship, where one central team owns every file and becomes the bottleneck. Elinor Ostrom won the Nobel Prize in Economics for demonstrating that this is a false choice. Communities sustain shared resources through designed rules, not through privatization and not through neglect. Her principles for governing common-pool resources adapt almost directly to the agentic repo.

Define clear boundaries. Every context artifact has an explicit scope, an owner, and a declared set of agents it governs. An artifact with no boundary is an artifact with infinite blast radius.
Fit rules to local conditions. Context is scoped per domain, not imposed globally. The billing module’s constraints are strict and the frontend’s are permissive because the cost of failure differs. One global ruleset is a monoculture.
Make change collective and monitored. Agent proposals to alter context are reviewed by something outside the proposing agent’s context, and every change carries provenance: who or what changed it, and why.
Apply graduated trust, not binary trust. Suspect artifacts are quarantined, not deleted in a panic. Trust decays with age and is restored through verification. A new or anomalous constraint earns authority gradually rather than being trusted on arrival.
Resolve conflicts deterministically and escalate to humans. When constraints collide, a declared precedence hierarchy resolves them mechanically, and genuine disputes escalate to a human arbiter. The system never negotiates its own safety boundaries through agent consensus, because consensus is exactly the mechanism that produces inertia and false agreement.

Call it the Ostrom Test for the agentic repo. If a vendor or an internal platform cannot answer how each of these five holds in their architecture, they have built a commons with no governance, which history tells us ends one way.

The Bottom Line

Let me be clear.

The repository now has two faces. A read side, where many agents consume shared constraints, and a write side, where agents author them.
Both faces are correlated failure surfaces. A shared substrate turns one bad artifact into a systemic event. This is documented, not theoretical.
Explainability is the wall, not the decoration. Rationale attached to every high-privilege constraint is what makes the repo auditable, poison-resistant, and safe for agents to maintain.
The answer is governance, not retreat. Sharing context is inevitable and valuable. The question is whether we govern the commons or plant a monoculture for convenience.

The agentic world will share context whether we design for it or not. The agents are already reaching for the guardrails. What we have not done is decide whether the repository they read from and write to is a Lumper field, uniform and efficient and one pathogen away from collapse, or a governed commons with boundaries, provenance, and graduated trust.

Ireland learned the cost of the monoculture after the blight arrived. Ostrom showed that we do not have to. The commons can be governed. The only question is whether we do the work before the pathogen, or after.

References

Huk, A. “Context as Code.” O’Reilly Radar (June 2026). https://www.oreilly.com/radar/context-as-code/
Xie, Y. et al. “From Spark to Fire: Modeling and Mitigating Error Cascades in LLM-Based Multi-Agent Collaboration.” arXiv:2603.04474 (March 2026). https://arxiv.org/abs/2603.04474
Cemri, M., Pan, M. Z., Yang, S. et al. “Why Do Multi-Agent LLM Systems Fail?” arXiv:2503.13657 (2025). https://arxiv.org/abs/2503.13657
Nechepurenko, M. et al. “Coordination as an Architectural Layer for LLM-Based Multi-Agent Systems.” arXiv:2605.03310 (May 2026). https://arxiv.org/abs/2605.03310
Torra, V. et al. “Memory Poisoning and Secure Multi-Agent Systems.” arXiv:2603.20357 (March 2026). https://arxiv.org/abs/2603.20357
Wang, Y. et al. “State Contamination in Memory-Augmented LLM Agents.” arXiv:2605.16746 (May 2026). https://arxiv.org/abs/2605.16746
“Autonomous LLM Agent Worms: Cross-Platform Propagation, Automated Discovery and Temporal Re-Entry Defense.” arXiv:2605.02812 (May 2026). https://arxiv.org/abs/2605.02812
“VerifyMAS: Hypothesis Verification for Failure Attribution in LLM Multi-Agent Systems.” arXiv:2605.17467 (May 2026). https://arxiv.org/abs/2605.17467
Ostrom, E. Governing the Commons: The Evolution of Institutions for Collective Action. Cambridge University Press (1990).
Kanakasabesan, K. “AGI isn’t here yet: Why OpenClaw, Agents and LLM Systems are still just ANI.” https://kanakasabesan.com/2026/03/09/agi-isnt-here-yet-why-openclaw-agents-and-llm-systems-are-still-just-ani/
Kanakasabesan, K. “Kano Model and the AI Agentic Layers.” https://kanakasabesan.com/2026/01/11/kano-model-and-the-ai-agentic-layers/
Kanakasabesan, K. “Your Agents are not safe and your evals are too easy.” https://kanakasabesan.com/2025/11/21/your-agents-are-not-safe-and-your-evals-are-too-easy/
Kanakasabesan, K. “Measuring What Matters: Dynamic Evaluation for Autonomous Security Agents.” https://kanakasabesan.com/2025/12/15/measuring-what-matters-dynamic-evaluation-for-autonomous-security-agents/

What AI Gets Wrong About Knowledge, Time, and Experience

Leave a reply

The economic models predicting AI-driven job losses share a common flaw: they treat human labor as a fixed, fungible input. It is not. And that error has real consequences.

Every consumer economy runs on a loop. Industry creates a market. The market attracts buyers. Buyers need income. They trade their time and talent to businesses in exchange for wages. Those wages become consumption, which generates demand, which creates more jobs, and which sustains the loop. It is a self-reinforcing system, elegant in its circularity and remarkably durable across two centuries of industrialization.

AI threatens to break that loop. Not because it automates a task here or a job category there, but because it targets the two fundamental levers of human labor that keep the loop spinning: knowledge and time. If a system can process information faster than a human analyst and access a broader body of facts than any MBA cohort, the human’s remaining function becomes genuinely unclear. The question worth asking is where human capital goes next.

I want to challenge the framing most economists bring to this question and argue that both AI’s capabilities and its limitations are being systematically misread.

I. The problem with how economists think about labor

The dominant economic framework for analyzing automation treats work as a collection of separable tasks. Machines take over certain tasks; humans retain others or migrate to new ones. The underlying assumption is that demand for labor, while it may shift, ultimately regenerates. New industries emerge, new roles appear, and the loop continues.^[1]

This task-based model has real explanatory power, but it rests on an assumption that AI now makes fragile: that technology creates new human tasks at a pace and scale comparable to what it displaces. Acemoglu and Johnson, in their 2023 book Power and Progress, argue that AI as currently deployed is heavily biased toward automating labor without generating equivalent new categories of work. This represents a break from the historical pattern that previously kept wage growth and automation in rough balance.^[2]

More critically, the framework treats knowledge and time as finite, fungible, and measurable inputs. They are not.

II. What is knowledge, actually?

The standard definition covers facts, information, and skills acquired through experience or education. That definition is technically correct and practically insufficient. If knowledge were simply a well-organized archive of facts, then every MBA graduate from a top program would produce identical strategic outcomes regardless of geography, culture, or context. We know that is not true. A product strategy that works in suburban Ohio fails in São Paulo. A go-to-market motion that closes enterprise deals in Singapore requires fundamental rethinking for Munich. The knowledge that matters is contextual, relational, and socially embedded.^[3]

AI is trained on facts and information. It is extraordinarily good at retrieval, synthesis, and pattern-matching within its training distribution. But consider this scenario: if windshield wipers had never existed, would an AI system, given the problem of driving safely in heavy rain, invent them?

“The emotional need that drove Mary Anderson to patent the windshield wiper in 1903 was not a knowledge gap. It was a friction between lived sensory experience and a system that had no solution.”

Technically, the AI would face what we might call a cosine similarity problem. Asked how to keep a car’s windshield clear in rain, the model searches its embedding space for the nearest known solution. Without the concept of a wiper in its training data, the nearest neighbor is likely “do not drive in heavy rain,” or perhaps a robotic arm mounted externally. Both answers are impractical, dangerous, and beside the point. The correct answer requires not just lateral thinking but a kind of embodied frustration with an inadequate status quo. It requires the capacity to feel a problem before conceptualizing a solution.

This distinction between knowledge and task is fundamental. Even recursive self-improvement in AI systems operates within the bounds of the task being optimized. The feedback loops that improve a model’s performance at chess do not spontaneously generate insight about urban planning. Improvement is bounded by the objective function. The assumption that connecting disparate knowledge sources through recursion yields genuinely novel insight is one of the more significant overestimates in current AI discourse.

III. Time is not just speed

The second lever is time. AI’s most unambiguous advantage is speed: it can query multiple data sources simultaneously, identify patterns across vast corpora, and return synthesized recommendations in seconds. This is genuinely valuable. Speed toward the wrong outcome, however, is not progress. It is efficient failure.

The implicit claim in most AI-and-labor analysis is that faster information processing translates directly into better decisions and greater value creation. That claim conflates throughput with judgment. A system that processes 10,000 market signals per minute still requires someone who understands which signals matter, what the organization is capable of acting on, and what the customer actually cares about. It still requires someone who can channel the output of accelerated tasks toward a tangible, impactful outcome.

I am not arguing that AI cannot improve decision-making. It clearly can, and it will. The argument is that speed without directionality produces noise at scale. The human function in this new architecture is not to perform the tasks AI handles more efficiently. It is to set the direction, interpret the output, and bear responsibility for the consequences. That is a fundamentally different function from the one most economic models are measuring.^[1],[2]

There is also a category of jobs that genuinely should not exist: roles that process information, generate reports, and relay recommendations without creating any discernible value. AI eliminating those roles is not a crisis. It is a correction. The crisis would come from conflating the elimination of low-value roles with the end of meaningful human work.

IV. The hard problem of experience

The third dimension is experience, and here the gap between human and machine capability is widest and least well understood.

The standard definition of experience covers practical contact with and observation of facts or events. That definition is reductive. Experience is not just observation. It is embodied, emotionally inflected, and socially interpreted. When a nurse reads a patient’s affect and adjusts her communication, she draws on years of pattern recognition that includes facial micro-expressions, vocal tone, and the accumulated weight of having sat with frightened people before. No sensor array currently captures all of that. No training corpus represents it fully.

Recent mathematical work has begun to formalize the emotional dimension of experience. Ambrosio (2020) proposes treating emotional phenomena as analogous to electromagnetic waves, allowing for quantitative modeling of intensity and qualitative modeling of feeling states.^[4] It is a genuinely novel approach. The paper itself acknowledges that our instruments cannot yet directly detect or record emotional perception. The mathematical model does not account for sensory, somatic information: the data that arrives through the body before the mind has processed it.

Experience, properly understood, is not a knowledge store. It is a calibration system. It tells you not just what you know, but how much to weight what you know in a given moment, with these people, in this context. That calibration is not currently learnable from text/image/video body of information alone.

V. So where does human capital go?

The economic loop described at the start of this piece does not break because AI exists. It breaks if we fail to find new ways to inject human agency, judgment, and creativity into the loop at points where they generate compounding value.

Three conclusions follow from this analysis. First, the human roles that survive and grow will be those that require exactly what AI cannot replicate: the ability to feel a problem, to read a room, and to channel accelerated outputs toward outcomes that serve real human needs. Second, the economic distribution question of who captures the value from AI productivity gains becomes the defining political challenge of this decade. Acemoglu and Johnson are right that the productivity gains from historical technology waves required countervailing labor power to ensure workers shared in those gains. That countervailing power is currently weak.^[2] Third, the danger of learned helplessness is real. If AI handles enough of the cognitive scaffolding through which people develop expertise, we risk producing a generation that is fluent at prompting but thin on judgment. That is exactly backwards from what the next economy requires.

The question is not whether AI will take jobs. It will, unevenly, with significant transitional pain across many sectors. The better question is whether we are building an economy in which the things humans do distinctively, including feeling, connecting, inventing from frustration, and bearing responsibility, remain economically valued. That is a design question, not a technology question. And right now, we are not designing for it.

References

[1]Acemoglu, D. and Restrepo, P. (2018). The race between man and machine. American Economic Review, 108(6), 1488–1542.
aeaweb.org (publisher) · nber.org (free working paper) · PDF (MIT)

[2]Acemoglu, D. and Johnson, S. (2023). Power and Progress: Our Thousand-Year Struggle Over Technology and Prosperity. PublicAffairs. Also: Acemoglu, D. and Restrepo, P. (2019). Automation and new tasks. Journal of Economic Perspectives, 33(2), 3–30.
hachettebookgroup.com · MIT News summary · JEP 2019 (publisher) · nber.org (free paper)

[3]Susskind, D. (2020). A World Without Work: Technology, Automation, and How We Should Respond. Metropolitan Books.
danielsusskind.com (author page) · Amazon

[4]Ambrosio, B. (2020). Beyond the brain: Towards a mathematical modeling of emotions. arXiv:2009.04216.
arxiv.org (abstract) · PDF (direct)

Your LLM Has a State Management Problem. Distributed Systems Solved It in 2005

Leave a reply

Why AI Engineers Should Read a Kafka Textbook Before Building Memory Architectures

Every major LLM API in production today is a pure function. The Anthropic Messages API takes a system prompt and a messages array, and returns a response. No session. No affinity. No memory between invocations. The contract is identical to a stateless microservice sitting behind a load balancer.

And yet the AI ecosystem is building state management patterns from scratch, giving them new names, and rediscovering failure modes that distributed systems engineers documented two decades ago. This is the most expensive form of technical amnesia in the industry right now.

The conversation buffer is event sourcing. The windowed buffer is a ring buffer with FIFO eviction. Summarization memory is log compaction. RAG is cache-aside with content-addressable storage. Persistent memory stores are CQRS read-side projections. The system prompt is bootstrap configuration.

None of this is metaphor. These are structural equivalences. And the failure modes map just as precisely as the architectures.

The Stateless Equivalence Map

Every LLM memory strategy has a direct ancestor in distributed computing. The table below is the reference artifact. The rest of this post unpacks each row.

LLM Memory Pattern	Distributed Systems Equivalent	Shared Failure Mode
Conversation Buffer (full history)	Event Sourcing	Unbounded log growth
Windowed Buffer (last N turns)	Ring Buffer / Sliding Window	Causal history loss
Summarization Memory	Log Compaction / Materialized Views	Irreversible fidelity loss
Retrieval-Augmented Generation (RAG)	Cache-Aside + Content-Addressable Storage	Cache coherence / stale reads
Persistent Memory Store	CQRS Read Model / Session State Service	Eventual consistency / write conflicts
System Prompt	Bootstrap Configuration / Init Container	Configuration drift

This is not a loose analogy. These are the same patterns, operating on the same constraints, producing the same failure modes. The only difference is the vocabulary.

Conversation Buffer Is Event Sourcing

When an application passes the full conversation history on every LLM call, it is replaying a complete append-only event log to reconstruct state at inference time. The LLM rebuilds its world model from the log on every request, exactly as an event-sourced aggregate replays its event stream to hydrate current state.

Jay Kreps formalized this pattern in his 2013 essay “The Log: What Every Software Engineer Should Know About Real-Time Data’s Unifying Abstraction.” The append-only log, Kreps argued, is the fundamental primitive underlying databases, replication, stream processing, and distributed consensus. The same primitive now underlies LLM conversation management. The abstraction did not change. The consumer did.

The failure mode is identical in both domains: unbounded log growth. In event sourcing, unbounded logs produce storage cost escalation and replay latency. In LLMs, they produce context window overflow. The token limit is not a model limitation in the way most practitioners think about it. It is a resource boundary, exactly like a memory ceiling on a service instance. The solution in both worlds is the same: compaction. Which brings us to the next row.

Design insight: Event sourcing is the correct pattern when the event stream is the source of truth and you need auditability. The same logic applies to LLM use cases. If your application demands perfect conversational fidelity (legal, medical, compliance), full buffer is correct by design, not by default. Every other use case should be asking why it is paying the full replay cost.

Windowed Buffer Is a Ring Buffer with Sliding Window Aggregation

Keeping the last N turns is a bounded ring buffer. Fixed size, FIFO eviction, recency-biased. This is the same pattern as time-windowed aggregation in Kafka Streams, Apache Flink, or any stream processing framework. You accept lossy state in exchange for predictable resource consumption.

The tradeoff is identical: you gain backpressure management (staying within token budget in LLMs, staying within memory budget in stream processing) but you lose causal history. A message from turn 3 that contextualizes turn 47 gets silently evicted. In stream processing, an event outside the window gets dropped. The data is gone. The downstream consumer does not know it is missing context. It simply produces a less accurate result.

Stream processing solved this problem by offering multiple window types: tumbling windows (fixed, non-overlapping), sliding windows (fixed, overlapping), and session windows (bounded by activity gaps rather than fixed counts). LLM orchestration frameworks mostly offer only one: the sliding window. Session windows, which group by topic continuity rather than fixed turn count, would be a more intelligent eviction policy. The concept of a “topic boundary” in conversation maps directly to a session gap in stream processing.

Design insight: If your LLM application is using a fixed-N windowed buffer, you are using the simplest possible window type. The stream processing community spent a decade building smarter ones. The question is not whether to window. The question is which window type matches your fidelity requirements.

Summarization Memory Is Log Compaction

When an application summarizes earlier conversation into a condensed representation and injects that summary into future prompts, it is performing log compaction. This is the Kafka pattern where you collapse the event history into the latest state per key, discarding superseded entries. The summary is a materialized view: a pre-computed, lossy projection of the full event stream, optimized for read performance.

In LLM terms, “read performance” means inference speed and token efficiency. The summary consumes fewer tokens than the full history, so the model has more budget for the current exchange. This is the same optimization that materialized views provide in database architectures: pre-compute an expensive aggregation so the query path stays fast.

Martin Kleppmann’s Designing Data-Intensive Applications dedicates extensive treatment to this pattern, emphasizing that compaction is irreversible and lossy by design. Once you compact, you cannot recover the original events. The same holds for summarization memory. Nuance, hedging, emotional tone, and conditional context from earlier turns get flattened into a summary. You cannot “un-summarize.” The information is gone, replaced by a projection that the summarizer deemed sufficient.

Design insight: The engineering question is identical in both domains. What fidelity do you sacrifice, and does the consumer need it? A customer support bot can aggressively compact. An AI-assisted therapy application cannot. The compaction policy is a product decision, not an infrastructure default. Product leaders should be defining the fidelity tier, not the backend engineer.

RAG Is the Cache-Aside Pattern

Retrieval-Augmented Generation is the cache-aside pattern combined with content-addressable storage. Instead of carrying all state in the request (the event log approach), the system queries an external store at inference time, retrieves relevant fragments, and injects them into the context window. The embedding index is a locality-sensitive hash: a probabilistic structure that trades exact recall for approximate O(1) lookup, in the same family as bloom filters and consistent hash rings.

The distributed systems failure modes map with precision:

Cache coherence. If the source document changes but the vector store still serves the old embedding, the LLM receives stale context. This is the distributed cache invalidation problem. Phil Karlton’s famous observation that cache invalidation is one of the two hardest problems in computer science applies to RAG pipelines with full force. The question “when did this chunk last get re-embedded?” is equivalent to “when did this cache entry last get refreshed?”

Relevance versus completeness. Did the retrieval query return the right chunks? This is analogous to cache miss rates. You are betting on your retrieval strategy, and misses are silent. The LLM does not know it is missing relevant context. It simply generates a less accurate response. Silent cache misses produce confidently wrong answers, the same failure mode as a microservice operating on stale cached data.

Cold start. An empty vector index produces zero context, the same way a cold cache after deployment produces cache misses on every request until the working set is loaded.

The distributed systems playbook for cache-aside includes write-through, write-behind, and refresh-ahead strategies. RAG pipelines need the same rigor. How and when embeddings get updated relative to source data changes is a coherence policy, not an afterthought. If you would not deploy a production cache without an invalidation strategy, you should not deploy a RAG pipeline without one either.

Persistent Memory Is a CQRS Read Model

Systems like Anthropic’s built-in memory, Zep, and MemGPT follow the same architectural pattern. A background process extracts salient facts from conversations and writes them to a durable store. On a new conversation, the store is queried and the results are injected into context. The write path (raw conversations) and the read path (distilled facts) are different representations of the same data, updated asynchronously.

This is textbook Command Query Responsibility Segregation. The write model optimizes for capture. The read model optimizes for retrieval. The two are eventually consistent. The asynchronous update introduces a lag window during which the memory store may not reflect the latest conversation.

The pattern is also directly analogous to a distributed session store. Redis-backed session state in web architectures solves exactly this problem: externalized session data that any stateless service instance can read to rehydrate user context. The LLM is the stateless service instance. The memory store is the session cache. The hydration step is the context injection.

Shared failure mode: Eventual consistency. Two concurrent conversations with the same user may each write conflicting facts to the memory store. Last-write-wins is the default resolution strategy in most implementations, and it is often wrong. The distributed systems community has a deep literature on conflict resolution, from vector clocks to CRDTs (Conflict-free Replicated Data Types). LLM memory stores are largely ignoring this literature, and they will pay for it as multi-agent and multi-session patterns become common.

System Prompt Is Bootstrap Configuration

The system prompt is static configuration injected at initialization. It establishes behavioral invariants before the first user message is processed. This is the equivalent of ConfigMaps, environment variables, or Kubernetes init containers. It is not state. It is identity.

The failure mode is configuration drift. If the system prompt evolves over time but the persistent memory store retains facts calibrated to an earlier system prompt version, the two can conflict. This is the same problem as deploying a new service version against an old configuration, something that Kubernetes liveness probes and rolling update strategies were designed to catch.

The Meta-Pattern: CAP Theorem for LLM Memory

Pull the mapping up one level. Every LLM memory architecture is navigating a trilemma that mirrors the fundamental constraints of distributed systems:

Constraint	LLM Memory Interpretation	Distributed Systems Analog
Consistency	Perfect recall, no information loss, full fidelity	All nodes see the same data at the same time
Availability	Low latency, bounded token cost, fast inference	Every request receives a response
Partition Tolerance	Works across concurrent sessions, multi-agent coordination, distributed orchestration	System continues operating despite network splits

You cannot have all three. Full conversation buffer is consistent but not available (it blows the context window). Windowed buffer is available but not consistent (it loses history). RAG is partition-tolerant but approximate (retrieval may miss). Persistent memory trades consistency for availability through eventual consistency.

This is not a metaphor. It is the same constraint surface. The tradeoffs are mathematical, not vibes. And the industry’s failure to name them using established vocabulary is producing architectures that rediscover the same limitations through production failures rather than design analysis.

The Failure Mode Diagnostic

If the architectural mapping holds, then the failure mode analysis from distributed systems should import directly. It does.

Distributed Systems Failure	LLM Memory Equivalent	Known Mitigation
Stale cache reads	RAG returning outdated chunks while memory has newer facts	Write-through embedding pipeline; version vectors on chunks
Event ordering violations	Summarizer compacting messages before async tool results return	Causal ordering barriers before compaction triggers
Unbounded queue growth	Context window overflow from aggressive conversation buffering	Compaction policy with fidelity tiers
Cache stampede	Multiple parallel agents retrieving and mutating the same memory store simultaneously	Distributed locking or optimistic concurrency on memory writes
Split-brain	Two conversation threads updating memory with conflicting facts about the same user	Conflict resolution strategy (LWW, vector clocks, manual merge)

These are not speculative. These are bugs shipping in production LLM systems today. Every one has a known mitigation in the distributed systems literature, and every one is being rediscovered through incident postmortems rather than design reviews.

Anti-Patterns for Leaders

“Novel AI Memory Architecture” in the Architecture Review

If an engineering team presents a “novel” memory architecture for an LLM application, the first question should be: what is this called in the distributed systems literature? If the team cannot answer, they are reinventing a solved problem. The Stateless Equivalence Map gives leaders a structured way to push back. Name the pattern. Import the failure mode analysis. Apply the known mitigations.

Treating Memory Architecture as an Infrastructure Decision

Memory architecture is a product decision. The choice between full buffer, windowed, summarized, and RAG directly affects what the AI “remembers,” what it forgets, and how it handles contradictions. These are user experience outcomes, not backend implementation details. The product owner should be choosing the fidelity-latency-cost tradeoff, not defaulting to whatever the framework provides out of the box.

This maps to the argument I made in my Kano Model post: the expected, performance, and delight layers of agentic AI all depend on getting state management right. Memory fidelity is a Kano performance attribute. Users do not articulate it as a requirement, but they notice immediately when it degrades.

Ignoring Coherence Policies for RAG Pipelines

No serious engineering organization would deploy a production cache without an invalidation strategy. And yet RAG pipelines routinely ship without coherence policies. When does the embedding index get refreshed? What happens when a source document is updated? How do you detect and handle stale chunks? These are the same questions distributed systems engineers ask about every caching layer, and they deserve the same rigor.

Building Multi-Agent Systems Without Concurrency Primitives

The moment two agents share a memory store, you have a concurrent write problem. The distributed systems community has decades of tooling for this: distributed locks, optimistic concurrency control, CRDTs, and saga patterns. Multi-agent LLM frameworks are largely ignoring this tooling. The result is the same class of race conditions and data corruption that plagued early distributed databases.

As I argued in “Your Agents Are Not Safe and Your Evals Are Too Easy,” the attack surface of agentic systems is underestimated. Concurrency bugs in shared memory stores are not just reliability problems. They are security problems. A race condition that overwrites a safety-critical memory entry is an exploitable vulnerability.

The Bottom Line

The LLM is the simplest part of the system. It is a pure function. Everything hard about building AI products is state management, the same thing that has been hard about building distributed systems for twenty years.

The conversation buffer is event sourcing. The windowed buffer is a ring buffer. Summarization is log compaction. RAG is cache-aside. Persistent memory is a CQRS read model. The system prompt is bootstrap configuration. The tradeoffs form a CAP-equivalent trilemma. The failure modes are documented, named, and mitigated in a literature that predates the transformer architecture by a decade.

The AI industry’s greatest unforced error is treating these as novel problems. They are not. The solutions exist. The failure modes are catalogued. The vocabulary is established.

Use the map.

References

Kreps, J. “The Log: What Every Software Engineer Should Know About Real-Time Data’s Unifying Abstraction.” LinkedIn Engineering Blog, 2013. https://engineering.linkedin.com/distributed-systems/log-what-every-software-engineer-should-know-about-real-time-datas-unifying
Kleppmann, M. Designing Data-Intensive Applications. O’Reilly Media, 2017.
Kleppmann, M. “Online Event Processing: Achieving Consistency Where Distributed Transactions Have Failed.” Communications of the ACM, Vol. 62 No. 5, May 2019.
Helland, P. “Life Beyond Distributed Transactions: An Apostate’s Opinion.” CIDR, 2007.
Jiang, P. et al. “Adaptation of Agentic AI: A Survey of Post-Training, Memory, and Skills.” arXiv:2512.16301, December 2025. https://arxiv.org/abs/2512.16301
Milosevic, Z. and Odell, J. “Architecting Agentic Communities using Design Patterns.” arXiv:2601.03624, January 2026. https://arxiv.org/abs/2601.03624
Kanakasabesan, K. “Foundation First, Not AI First.” https://kanakasabesan.com/2026/05/04/foundation-first-not-ai-first/
Kanakasabesan, K. “Kano Model and the AI Agentic Layers.” https://kanakasabesan.com/2026/01/11/kano-model-and-the-ai-agentic-layers/
Kanakasabesan, K. “Your Agents Are Not Safe and Your Evals Are Too Easy.” https://kanakasabesan.com/2025/11/21/your-agents-are-not-safe-and-your-evals-are-too-easy/

Foundation First, Not AI First

Leave a reply

The Patterns That Built the Internet Will Build the Agentic Future

Every pitch deck in 2026 leads with “AI First.” Every product strategy document genuflects to the altar of large language models before addressing anything else. Every engineering roadmap treats AI integration as the foundational decision from which all other decisions flow.

This is backwards. And two decades of distributed systems engineering already proved why.

Claude can build you a beautiful application in minutes. But if that application lacks circuit breakers, observability, state management, and fault isolation, it will collapse the moment it meets production traffic. The model is not the product. The foundation is the product. The model is a component.

The Seduction of “AI First”

“AI First” as a strategy sounds compelling because it promises differentiation. It implies that the intelligence layer is the moat, the product, and the competitive advantage all at once. Executives hear “AI First” and see leapfrogged roadmaps, reduced headcount, and disrupted markets.

What “AI First” actually produces, in practice, is a fragile application wrapped around an API call.

Consider what happens when an organization builds AI First without foundational engineering discipline. The LLM handles the happy path beautifully. Then the API rate-limits. Then the context window overflows. Then the agent hallucinates in a customer-facing workflow. Then the orchestration layer drops a message between two agents that were supposed to coordinate. Then the memory store loses state mid-session.

Every one of these failure modes has a well-understood solution in distributed systems literature. And every one of these failure modes is being rediscovered, from scratch, by teams that skipped the foundation.

The Distributed Systems Playbook: Older Than You Think

The patterns that make agentic AI systems reliable are not new. They are borrowed, sometimes consciously and sometimes accidentally, from decades of distributed computing research. The convergence is not a coincidence. It is an inevitability. Multi-agent systems are distributed systems. The moment you have two agents coordinating across a shared task, you have entered the domain of consensus, fault tolerance, and state management whether you acknowledge it or not.

Milosevic and Odell formalized this connection in their January 2026 paper “Architecting Agentic Communities using Design Patterns” (arXiv:2601.03624). They explicitly derive agentic design patterns from enterprise distributed systems standards and formal methods. Their taxonomy classifies patterns into three tiers: LLM Agents for task-specific automation, Agentic AI for adaptive goal-seeking, and Agentic Communities for organizational frameworks where agents and humans coordinate through formal roles, protocols, and governance structures. The architectural lineage is unmistakable. These are not novel AI patterns. They are service-oriented architecture patterns with a new cognitive substrate.

The Pattern Map: Distributed Computing → Agentic AI

The parallels are structural, not metaphorical. Every major infrastructure pattern emerging in the agentic AI space has a direct ancestor in distributed computing.

Orchestration

In distributed systems, orchestration engines like Kubernetes, Apache Airflow, and Temporal coordinate service execution, manage dependencies, handle retries, and enforce ordering guarantees. In the agentic world, LLM orchestration frameworks like LangGraph, CrewAI, and AutoGen perform identical functions: they coordinate agent execution, manage tool dependencies, and enforce workflow ordering.

The paper by Drammeh on multi-agent LLM orchestration for incident response (arXiv:2511.15755) demonstrated that orchestrated multi-agent systems achieved a 100% actionable recommendation rate compared to 1.7% for single-agent approaches. The insight is not that the model was better. The insight is that the orchestration was better. The infrastructure made the intelligence useful.

Stateful Sessions and Memory

Distributed systems solved session affinity and state management decades ago. Sticky sessions, distributed caches, and event sourcing patterns all address the same fundamental problem: how do you maintain coherent state across multiple service invocations that may occur on different nodes?

Agentic AI is now solving the same problem under a different name. Agent “memory,” whether short-term context windows, long-term vector stores, or persistent session state, is distributed state management. The challenges are identical: consistency across nodes, durability under failure, and efficient retrieval under load. The Jiang et al. survey on agent adaptation (arXiv:2512.16301) categorizes memory as a core adaptation mechanism, but the underlying engineering is cache management and state replication.

Service Mesh → LLM Mesh and Agentic Mesh

This is where the convergence becomes most striking. In distributed computing, the service mesh pattern (Istio, Linkerd, Consul Connect) emerged to solve a specific problem: as the number of microservices grew, managing service-to-service communication, security, observability, and traffic routing at the application layer became untenable. The mesh moved these cross-cutting concerns into infrastructure.

The same pattern is emerging for LLM and agentic systems. “LLM-Mesh,” as described by researchers at UIUC (arXiv:2507.00507), addresses elastic resource sharing across heterogeneous hardware for serverless LLM inference. The concept parallels the service mesh exactly: abstract the complexity of model routing, load balancing, and resource allocation into an infrastructure layer so that application developers can focus on business logic.

The agentic mesh extends this further. The Model Context Protocol (MCP) and Google’s Agent-to-Agent (A2A) protocol are standardizing inter-agent communication in the same way that gRPC and service mesh sidecars standardized inter-service communication. The paper on multi-agent orchestration architectures (arXiv:2601.13671) describes MCP and A2A as establishing an “interoperable communication substrate” for agent coordination. Substitute “service” for “agent” and you are reading a 2018 paper on Istio.

MLOps, LLMOps, and the CI/CD Parallel

DevOps gave us CI/CD pipelines, blue-green deployments, canary releases, and automated rollbacks. MLOps applied the same principles to model training and deployment. LLMOps extends them further to prompt management, hallucination monitoring, and token cost tracking.

The pattern is identical each time: take a new computational paradigm, realize that artisanal manual deployment does not scale, and rediscover that automated pipelines with observability and rollback capabilities are the only path to production reliability. The MLOps lifecycle framework (arXiv:2503.15577) maps directly to the DevOps lifecycle. The tools have different names. The principles are unchanged.

Scaling Laws: The CAP Theorem of Agents

Kim et al.’s “Towards a Science of Scaling Agent Systems” (arXiv:2512.08296) derived quantitative scaling principles for multi-agent architectures. Their findings read like a distributed systems textbook: centralized coordination improves performance by 80.8% on parallelizable tasks but degrades sequential reasoning by 39–70%. Independent agents amplify errors 17.2 times. There is a capability saturation point beyond which adding more agents yields diminishing or negative returns.

These are not AI insights. These are Amdahl’s Law and the CAP theorem wearing different clothes. Parallelizable workloads benefit from distribution. Sequential workloads do not. Coordination has overhead. Consistency and partition tolerance trade off against each other. The distributed systems community established these principles decades ago. The agentic AI community is now empirically rediscovering them.

What “Foundation First” Actually Means

Foundation First does not mean ignoring AI. It means building the infrastructure that makes AI reliable before building the AI features that make the product exciting.

Concretely, Foundation First means:

Observability before intelligence. You cannot debug an agent you cannot observe. Instrument tracing, logging, and metrics for every agent interaction before you build the agent itself. The distributed systems community learned this lesson with microservices. The agentic community is learning it now with hallucination monitoring and prompt observability.

Fault isolation before orchestration. Circuit breakers, retry policies, dead-letter queues, and graceful degradation paths must exist before you chain agents together. A single hallucinating agent in an unprotected pipeline can corrupt an entire workflow. Bulkhead patterns are not optional.

State management before memory. Decide how you will manage agent state—what is ephemeral, what is persistent, what requires consistency guarantees—before you implement “memory.” Vector stores are not a state management strategy. They are a retrieval optimization. The state management strategy is the architecture decision that determines whether your system survives a failure.

Protocol standardization before integration. Adopt MCP, A2A, or whatever communication standard your ecosystem supports before you build bespoke agent-to-agent integrations. Every point-to-point integration you build today is technical debt you will pay interest on tomorrow. The service mesh pattern exists because point-to-point service integration did not scale. The same is true for agents.

Evaluation infrastructure before deployment. In my post on dynamic evaluations, I argued that evaluation loops measure performance and enforce constraints but do not create new knowledge. The same applies here: build the evaluation infrastructure first, then deploy the agents into it. Do not deploy first and evaluate later. The distributed systems equivalent is deploying without monitoring. Everyone knows it is wrong. Everyone does it anyway.

The Anti-Patterns for Leaders

“We Are an AI Company”

No. You are a company that uses AI. The distinction matters. An “AI company” identity encourages teams to center every decision on the model. A company that uses AI centers decisions on the customer problem and selects the best tool, AI or otherwise, for each component of the solution. Sometimes the best tool is a deterministic rules engine. Sometimes it is a relational database query. Sometimes it is a well-designed form. AI First thinking makes these options invisible.

Skipping Infrastructure to Ship the Demo

The demo always works. The demo runs on a single API call with a curated prompt against a known-good input. Production is not the demo. Production is 10,000 concurrent users with adversarial inputs, network partitions, rate limits, and a context window that fills up faster than anyone predicted. Every month I see teams ship the demo and then spend six months building the infrastructure they should have built first.

Treating the Model as the Moat

Foundation models are commoditizing. The moat is not the model. The moat is the data pipeline, the evaluation infrastructure, the orchestration layer, the fault tolerance mechanisms, and the domain-specific workflows that make the model useful in a specific context. These are all foundational engineering investments. They are not glamorous. They are the reason some AI products work and others do not.

Ignoring the Distributed Systems Literature

The agentic AI community is producing excellent research. But much of it is rediscovering principles that the distributed systems community established years ago. Leaders who staff their AI teams exclusively with ML engineers and ignore distributed systems expertise are building on sand. The hard problems in agentic AI are increasingly infrastructure problems, not model problems.

The Convergence Table

Distributed Computing Pattern	Agentic AI Equivalent	Why It Matters
Service Orchestration (K8s, Temporal)	Agent Orchestration (LangGraph, CrewAI)	Coordination, dependency management, retry logic
Service Mesh (Istio, Linkerd)	LLM Mesh / Agentic Mesh (MCP, A2A)	Cross-cutting concerns: auth, observability, routing
Session Affinity / Distributed Cache	Agent Memory (vector stores, context windows)	State coherence across invocations
CI/CD Pipelines	MLOps / LLMOps Pipelines	Automated deployment, rollback, version control
Circuit Breakers (Hystrix)	Agent Fallback / Guardrails	Fault isolation, graceful degradation
Event Sourcing / CQRS	Agent Action Logs / Audit Trails	Reproducibility, debugging, compliance
Load Balancing	Model Routing / LLM Gateway	Cost optimization, latency management
API Gateway	LLM Gateway / Orchestration Layer	Rate limiting, auth, request transformation
Observability (Prometheus, Jaeger)	LLM Observability (Arize, LangSmith)	Tracing, hallucination detection, cost tracking
CAP Theorem Tradeoffs	Agent Scaling Laws (Kim et al.)	Coordination overhead vs. parallelism gains

The Bottom Line

The infrastructure patterns that powered the internet, the cloud, and the microservices revolution are the same patterns that will power the agentic AI era. They are not optional. They are not “nice to have after launch.” They are the foundation without which no AI system survives production.

“AI First” is a marketing strategy. “Foundation First” is an engineering strategy. One gets you a demo. The other gets you a product.

The organizations that win the next five years will not be the ones that adopted AI the fastest. They will be the ones that built the most resilient foundations and then deployed AI into an infrastructure designed to make it reliable, observable, and recoverable.

Kant would remind us that reason without grounded experience produces illusions. The same is true for AI without grounded infrastructure. Build the foundation. Then build the intelligence. Not the other way around.

References

Milosevic, Z. and Odell, J. “Architecting Agentic Communities using Design Patterns.” arXiv:2601.03624 (January 2026).
Kim, Y. et al. “Towards a Science of Scaling Agent Systems.” arXiv:2512.08296 (December 2025).
Drammeh, P. “Multi-Agent LLM Orchestration Achieves Deterministic, High-Quality Decision Support for Incident Response.” arXiv:2511.15755 (November 2025).
“LLM-Mesh: Enabling Elastic Sharing for Serverless LLM Inference.” arXiv:2507.00507 (July 2025).
“The Orchestration of Multi-Agent Systems: Architectures, Protocols, and Enterprise Adoption.” arXiv:2601.13671 (January 2026).
“Navigating MLOps: Insights into Maturity, Lifecycle, Tools, and Careers.” arXiv:2503.15577 (March 2025).
Jiang, P. et al. “Adaptation of Agentic AI: A Survey of Post-Training, Memory, and Skills.” arXiv:2512.16301 (December 2025).
Gangadharan, G.R. et al. “Agentic Artificial Intelligence (AI): Architectures, Taxonomies, and Evaluation.” arXiv:2601.12560 (January 2026).
Kanakasabesan, K. “AGI isn’t here yet: Why OpenClaw, Agents and LLM Systems are still just ANI.“
Kanakasabesan, K. “Your Agents are not safe and your evals are too easy.“
Kanakasabesan, K. “Measuring What Matters: Dynamic Evaluation for Autonomous Security Agents.“

Self-Improving Agents Are Still ANI: Why Hyperagents Don’t Change the Classification

Leave a reply

A Kantian Lens on Machine Intelligence

In March 2026, Meta published a paper on hyperagents: systems that rewrite the mechanism by which they improve themselves. Performance compounds across runs. Meta-level gains transfer across domains. The system improves its own improvement process.

If that doesn’t sound like AGI, I don’t know what does.

Except it isn’t. And a philosopher who died in 1804 already explained why.

What Are Hyperagents?

To understand why hyperagents matter and why they do not change the classification of intelligence, we need to trace a brief lineage.

Darwin Gödel Machine (DGM)

Published in May 2025 by Zhang et al., the Darwin Gödel Machine is a coding agent that iteratively modifies its own source code and empirically validates changes against benchmarks. It maintains an archive of agent variants through Darwinian selection, where successful modifications survive and unsuccessful ones are pruned. On SWE-bench, it improved from 20.0% to 50.0% through self-modification.

The key structural insight: because the task domain (coding) and the self-modification mechanism (also coding) share the same medium, improvements in one naturally feed the other. Better coding ability produces better self-modification, which produces better coding ability. This virtuous cycle is real and measurable.

DGM-Hyperagents (DGM-H)

Published in March 2026, hyperagents address a specific limitation of DGM. In the original system, the meta-mechanism (the process for generating improvements) was hand-crafted and fixed by human designers. DGM-H makes the meta-mechanism itself editable. The system now merges a task agent and a meta agent into a single self-modifiable program.

The authors call this “metacognitive self-modification.” Meta-level improvements, such as persistent memory, performance tracking, and improved code editing strategies, transfer across fundamentally different domains, including coding, academic paper review, and robotics reward function design. These improvements accumulate across runs.

At a Glance

Attribute	DGM (2025)	DGM-H / Hyperagent (2026)
Self-modifies code	Yes	Yes
Meta-mechanism editable	No (hand-crafted)	Yes (self-referential)
Cross-domain transfer	No (coding only)	Yes (coding, review, robotics)
Accumulates across runs	Limited	Yes
Foundation model modified	No (frozen)	No (frozen)

That last row is the entire argument. Hold it for now. We will return to it.

Why This Looks Like AGI: The Strongest Case

Intellectual honesty requires acknowledging the strength of the counterargument before engaging with it.

In my earlier post on ANI classification, I established four criteria for AGI:

Learning new domains from raw data without explicit programming
Transferring reasoning across unrelated disciplines
Generating and refining internal context models autonomously
Forming and pursuing long-term goals without human direction

On the surface, Hyperagents appear to make progress on criteria one and two. The system does improve across domains. The meta-level improvements do accumulate without being explicitly programmed. For the first time, there is a credible research artifact that seems to blur the line between narrow optimization and general capability.

This is the strongest counterargument to the ANI thesis that has appeared in the literature. It deserves a rigorous response.

Enter Kant: The Critique of Pure Reason as an Evaluation Framework

Why Kant?

Immanuel Kant’s Critique of Pure Reason (1781) asked a question that maps directly to the AGI debate: What are the conditions that make knowledge possible?

Kant was not asking what we know. He was asking what must be true about a knowing entity for knowledge to exist at all. That question, about the preconditions for intelligence rather than its outputs, is exactly the question we should be asking about self-improving agents.

Most commentary on hyperagents focuses on what the system does. Kant’s framework forces us to ask what the system is. And that distinction is the one that matters.

The Four Kantian Tests for Intelligence

Test 1: Analytic versus Synthetic Judgment

Kant distinguished between two types of knowledge.

Analytic judgments are those where the predicate is already contained in the subject. They decompose what is already known. “All bodies are extended” is analytic because extension is part of the definition of “body.” These judgments clarify, but they do not extend knowledge.

Synthetic judgments add something new. “All bodies are heavy” is synthetic because weight is not contained in the concept of body itself. You need to go beyond the concept to learn something the concept alone does not contain.

Kant’s central question concerned synthetic a priori knowledge: knowledge that is both genuinely new (synthetic) and necessarily true independent of any particular experience (a priori). He argued that mathematics, the foundations of natural science, and the preconditions for experience itself all belong to this category.

Application to Hyperagents: DGM-H operates almost entirely within the domain of analytic judgment. When the system rewrites its code to add persistent memory or improve its editing tools, it is decomposing and recombining patterns that already exist within its training distribution. The foundation model’s representations, the “concepts” it possesses, remain fixed. The scaffolding improvements are analytic rearrangements of known capabilities.

A system capable of synthetic judgment would generate knowledge that is not contained in its existing representations. It would discover that “bodies are heavy” without having the concept of weight anywhere in its training data. DGM-H does not do this. It recombines existing knowledge more efficiently. This is sophisticated analysis, not synthesis.

Smell test: “Does the system discover knowledge that was not already latent in its foundation model? Or does it rearrange what the model already knows?”

Test 2: Phenomena versus Noumena, the Boundary of Knowable Reality

Kant argued that human knowledge is limited to phenomena: the world as it appears to us through the structures of our perception (space, time, and the categories of understanding). Behind appearances lies the noumenon, the thing-in-itself, which remains fundamentally unknowable.

This is not a limitation to be overcome. It is a structural boundary of cognition itself.

Application to Hyperagents: The foundation model is the noumenal boundary of the Hyperagent system. The system interacts with token representations, benchmark scores, and code outputs. All of these are phenomena. It can modify how it processes these appearances through better tools, better prompts, and better memory. But it cannot reach through to modify the foundation model itself, the cognitive substrate that determines what can appear in the first place.

DGM-H optimizes within the phenomenal world of its own outputs. It has no access to its own noumenon. The weights are frozen. The representations are fixed. The boundary cannot be crossed through scaffolding improvements, no matter how recursive those improvements become.

When Kant said that concepts without intuitions are empty, he meant that pure logical manipulation without grounded experience cannot produce real knowledge. A Hyperagent that rewrites its own orchestration code without modifying its representational substrate is manipulating concepts without changing the intuitions that ground them.

Smell test: “Is the system modifying how it perceives, or only how it organizes what it already perceives?”

Test 3: The Transcendental Unity of Apperception, the Missing “I Think”

This is perhaps Kant’s most profound contribution to the question of intelligence. Kant argued that all experience requires a transcendental unity of apperception: the “I think” that must be capable of accompanying all representations. Without a unified self that integrates perceptions into a coherent whole, there is no experience, no knowledge, and no cognition.

This is not consciousness in the mystical sense. It is a structural requirement: for knowledge to cohere, there must be a unifying perspective that holds representations together across time.

Application to Hyperagents: DGM-H maintains an archive of agent variants. Each variant is evaluated independently. There is no unified “self” that integrates the experience of all variants into coherent understanding. The system is a population of narrow programs being selected by benchmark fitness, not a single entity that learns from its accumulated experience in a unified way.

When a Hyperagent “transfers” a meta-level improvement from the coding domain to the robotics domain, it is not a single intelligence applying cross-domain reasoning. It is a code pattern being reused in a different context. There is no “I think” that accompanies the transfer. There is no unified apperception binding the coding experience to the robotics experience into a single coherent worldview.

Darwinian selection and coherent self-awareness are fundamentally different mechanisms. Evolution produces fit organisms. It does not produce a single organism that understands why it is fit.

Smell test: “Is there a unified perspective that integrates learning across domains, or is there a population of narrow variants being selected by an external fitness function?”

Test 4: The Limits of Pure Reason, Why Recursive Optimization Has a Ceiling

Kant’s Critique was, at its core, an argument about limits. Pure reason, meaning reasoning without grounded experience, cannot extend knowledge beyond the bounds of possible experience. When reason attempts to do so (Kant called these attempts “transcendental illusions”), it generates contradictions and paradoxes, not knowledge.

Application to Hyperagents: The evaluation function is the bound of possible experience for DGM-H. The system can only know what the benchmark measures. It cannot reason about value, purpose, or knowledge that exists outside the evaluation function’s scope.

Recursive self-improvement within a fixed evaluation function is analogous to Kant’s critique of dogmatic metaphysics: reason operating on itself, in an unbounded way, without the grounding constraints that make knowledge possible. The system can optimize endlessly, but it cannot transcend the boundary defined by its evaluation criteria.

This maps directly to my argument in the dynamic evaluations posts: evaluation loops measure performance and enforce constraints, but they do not create new knowledge or abstraction. DGM-H elevates this from a single evaluation step to an evolutionary cycle, but the fundamental Kantian constraint holds. Optimization within a bounded evaluation function, no matter how recursive, cannot produce unbounded intelligence.

Smell test: “Can the system define what ‘better’ means, or does it only optimize for a definition of ‘better’ that was given to it?”

The Technical Dissection: Reinforcing the Philosophy with Architecture

The Kantian analysis is not merely philosophical. It maps directly to concrete architectural facts about how DGM-H works.

1. The Foundation Model Is Frozen

DGM-H modifies scaffolding: tools, prompts, workflows, and memory management. The foundation model weights never change. This is the architectural expression of the phenomena/noumena boundary. The system rearranges appearances without touching the cognitive substrate.

2. Goals Are Human-Defined and Externally Imposed

Every DGM-H run starts with a human-selected benchmark. The system does not choose what to improve at. It does not formulate its own research questions. Kant’s “I think” would require autonomous goal formation, where the system decides for itself what matters. DGM-H has no such capacity.

3. Cross-Domain Transfer Is Scaffolding Reuse, Not Reasoning Transfer

The meta-level improvements that transfer across domains (persistent memory, performance tracking) are infrastructure patterns. A human who learns music theory and applies harmonic reasoning to wave physics is performing synthetic judgment, connecting concepts that were not previously connected. An agent that reuses a memory management pattern across domains is performing analytic reapplication.

4. Self-Modification Operates on Code, Not on Representation

DGM-H modifies Python source code. It does not modify attention patterns, learned features, or representational structures. In Kantian terms, it modifies the organization of experience, not the categories through which experience is structured.

Think of it this way: a chess player who develops a new opening strategy has modified their cognitive approach. A chess player who buys a better chessboard and clock has modified their tooling. DGM-H is doing the latter at an impressive scale.

AGI Anti-Patterns for Leaders

These anti-patterns matter for anyone evaluating AI capabilities in a procurement, investment, or strategic planning context.

“Self-Improving” in the Pitch Deck Equals AGI

Kant taught us that the impressive outputs of reason can be illusory when reason operates beyond its legitimate bounds. The same applies to vendor claims. The evaluation rubric in this post gives leaders a structured way to push back. Ask the four Kantian questions. If the vendor cannot answer them, the claim is marketing, not capability.

Confusing Compounding Optimization with Compounding Intelligence

DGM-H demonstrates compounding optimization, where each run builds on the last. Kant would call this increasingly sophisticated analytic judgment. It is not synthetic intelligence, which would require generating genuinely new knowledge that extends beyond existing representations.

Ignoring the Frozen Foundation Model Constraint

If the foundation model is frozen, then the ceiling of the system’s capability is fixed. No amount of scaffolding optimization changes this. Leaders should ask: “When you say self-improving, what exactly is improving: the model or the wiring around the model?”

Over-Delegating Autonomy Based on Self-Improvement Claims

In my Kano Model post, I established that removing human checkpoints too early is a dangerous anti-pattern. Self-improving systems amplify this risk by creating the illusion of autonomous competence while operating within narrow, benchmark-defined boundaries.

Kant warned that reason unchecked by grounded experience produces illusions, not knowledge. The same is true for agents unchecked by human oversight.

The Adaptation Taxonomy: Broader Context

Jiang et al.’s survey paper, “Adaptation of Agentic AI” (December 2025), organizes the adaptation landscape into four paradigms: tool-execution-signaled agent adaptation, agent-output-signaled agent adaptation, agent-agnostic tool adaptation, and agent-supervised tool adaptation.

DGM-H fits squarely into agent-output-signaled adaptation: the agent modifies itself based on its own performance outputs. In Kantian terms, this is reason responding to its own products, not to raw experience.

The taxonomy makes clear that what Hyperagents do is a specific, well-characterized form of narrow adaptation. It is sophisticated. It is useful. It is not general.

The Bottom Line

Let’s be clear:

DGM is not AGI.
DGM-H (hyperagents) is not AGI.
Self-modification of scaffolding around a frozen foundation model is not cognitive evolution.

These systems perform increasingly sophisticated analytic operations. They do not perform synthetic judgment. They optimize within a phenomenal boundary defined by their evaluation functions. They lack the transcendental unity of apperception, the integrated “I think,” that Kant identified as the precondition for genuine knowledge.

Kant wrote the Critique of Pure Reason to establish the boundaries of what reason can legitimately claim to know. Two and a half centuries later, those boundaries still hold, not just for human cognition but also for artificial systems that attempt to simulate it.

The day a system generates its own evaluation criteria, formulates its own problems, produces synthetic a priori knowledge, and integrates experience through a unified perspective is the day we revisit this classification.

Until then, the framework holds.

Kantian Evaluation Rubric: “Is It AGI?”

Kantian Test	What It Asks	Hyperagents	True AGI Requirement
Analytic vs. Synthetic	Does the system create genuinely new knowledge?	No: rearranges existing representations	Must produce synthetic judgment beyond training
Phenomena vs. Noumena	Can it modify its own cognitive substrate?	No, the foundation model is frozen	Must modify how it perceives, not just what it organizes
Transcendental Unity of Apperception	Is there a unified “I” integrating experiences?	No: population of variants selected by fitness	Must possess a coherent, self-integrating perspective
Limits of Pure Reason	Can it define its own criteria for “better”?	No: optimizes for human-defined benchmarks	Must autonomously generate evaluation criteria

References

Zhang, J. et al. “Hyperagents.” arXiv:2603.19461 (March 2026). https://arxiv.org/abs/2603.19461
Zhang, J. et al. “Darwin Gödel Machine: Open-Ended Evolution of Self-Improving Agents.” arXiv:2505.22954 (May 2025, updated March 2026). https://arxiv.org/abs/2505.22954
Jiang, P. et al. “Adaptation of Agentic AI: A Survey of Post-Training, Memory, and Skills.” arXiv:2512.16301 (December 2025). https://arxiv.org/abs/2512.16301
Kant, I. Critique of Pure Reason. Trans. Norman Kemp Smith. (1781/1787). Macmillan, 1929.
Stanford Encyclopedia of Philosophy. “Kant’s Theory of Judgment.” https://plato.stanford.edu/entries/kant-judgment/
Stanford Encyclopedia of Philosophy. “Kant’s Critique of Metaphysics.” https://plato.stanford.edu/entries/kant-metaphysics/
Kanakasabesan, K. “AGI isn’t here yet: Why OpenClaw, Agents, and LLM Systems are still just ANI.” https://kanakasabesan.com/2026/03/09/agi-isnt-here-yet-why-openclaw-agents-and-llm-systems-are-still-just-ani/
Kanakasabesan, K. “Kano Model and the AI Agentic Layers.” https://kanakasabesan.com/2026/01/11/kano-model-and-the-ai-agentic-layers/
Kanakasabesan, K. “Your agents are not safe, and your evals are too easy.” https://kanakasabesan.com/2025/11/21/your-agents-are-not-safe-and-your-evals-are-too-easy/
Kanakasabesan, K. “Measuring What Matters: Dynamic Evaluation for Autonomous Security Agents.” https://kanakasabesan.com/2025/12/15/measuring-what-matters-dynamic-evaluation-for-autonomous-security-agents/

AGI isn’t here yet: Why OpenClaw, Agents and LLM Systems are still just ANI.

Leave a reply

It has been a while since I posted because I was busy researching and experimenting with OpenClaw, NanoClaw, and similar tools. Here’s a summary of what I learned.

There’s a lot of confusion in the industry about what current AI systems really are. Even with all the recent progress, OpenClaw is not AGI (Artificial General Intelligence). This is also true for large language models, tools that use intelligence, and systems that involve multiple agents working together.

What we have right now, no matter the name, number of parameters, or how advanced the system is, is still Artificial Narrow Intelligence (ANI).

Understanding the difference between ANI, AGI, and ASI is not an academic exercise. It directly impacts system architecture, operational risk, evaluation strategy, and how much autonomy we should responsibly delegate to machines.

ANI: What We Actually Have Today

All current AI systems, including OpenClaw, fall squarely into Artificial Narrow Intelligence.

ANI systems perform well within bounded domains. They depend on carefully designed architectures and human-defined operational boundaries.

These systems typically rely on:

Large pretrained language models
Explicit tool invocation
Memory abstractions
Human-defined workflows
Evaluation and guardrail pipelines

Systems such as OpenClaw, nanoClaw, or other “claw” systems interacting within Moltbook may appear sophisticated because they combine these components. However, sophistication should not be confused with general intelligence.

These systems remain narrowly scoped architectures built on probabilistic language models.

The moment the scaffolding of tools, prompts, and orchestration is removed, the system does not autonomously reorient itself. It simply stops functioning effectively.

Multi-agent systems increase coordination, not intelligence.

Here is a prompt snippet from one of my projects where I am using the LLM-as-Judge construct to validate the “factualness” of content that is generated by my Market Research Multi-Agent system. If this was general intelligence, I would not need to define this judge prompt.

JUDGE_SYSTEM_PROMPT = “””\
You are a strict factuality judge evaluating a market research report.
Your job is to determine whether a specific factual claim is SUPPORTED, CONTRADICTED, or NOT_MENTIONED
in the provided research output.

Definitions:

SUPPORTED: The output explicitly states the fact, or provides data that confirms it. Minor numeric
discrepancies within ±10% are acceptable (e.g. “$510B” vs “$500B”).
CONTRADICTED: The output explicitly states information that contradicts the fact.
NOT_MENTIONED: The output does not mention the fact at all, or mentions the topic without
addressing the specific factual claim.

Respond with EXACTLY one of: SUPPORTED, CONTRADICTED, or NOT_MENTIONED
Do not explain your reasoning. Return only the label.
“””

JUDGE_USER_TEMPLATE = “””\
FACTUAL CLAIM TO CHECK:
{key_fact}

AGI: What We Have Not Achieved

Artificial General Intelligence (AGI) would require capabilities that today’s systems simply do not possess.

AGI would be able to:

Learn entirely new domains directly from raw data
Transfer reasoning across unrelated disciplines
Generate and refine its own internal context models
Form and pursue long-term goals autonomously

Humans do this naturally. A human can learn music, mathematics, and law and reason across them using both provided context and internally generated context.

Modern agentic systems cannot do this.

Every OpenClaw deployment still depends on:

Human-defined objectives
Human-defined tools
Human-defined evaluation criteria
Human-defined operational boundaries

This dependency is the defining characteristic of Artificial Narrow Intelligence.

ASI: Artificial Superintelligence

Artificial Superintelligence (ASI) is typically defined as any intellect that greatly exceeds human cognitive performance across virtually all domains of interest.

By this definition, we are not even close.

There is currently:

No accepted computational theory of general intelligence
No validated model for autonomous goal formation
No framework for intrinsic motivation in artificial systems

ASI discussions today remain largely philosophical rather than engineering-driven.

Why Multi-Agent Architectures Exist

The rise of multi-agent architectures is often interpreted as progress toward AGI. In reality, it reflects the opposite.

Multi-agent systems exist because ANI systems are limited.

Agent architectures help by:

Decomposing complex tasks
Parallelizing reasoning steps
Introducing specialized capabilities
Adding redundancy and verification

But they still rely heavily on human-designed structures and constraints.

The core operational backbone of agentic reasoning is the context window. If the context becomes corrupted or drifts during execution, the outcome of the entire chain can vary dramatically.

A single misstep early in the reasoning chain can propagate through downstream agents and significantly alter final results.

This is why modern agentic systems require evaluation layers at nearly every stage of execution.

Dynamic Evaluations Are Not Intelligence

Dynamic evaluations are frequently misunderstood as evidence of intelligence.

In reality, they are control systems.

Evaluation layers typically perform functions such as:

Validating tool outputs
Checking reasoning consistency
Monitoring context integrity
Enforcing safety and compliance policies

These mechanisms improve reliability, but they do not create intelligence.

A feedback loop does not produce cognition. It simply stabilizes system behavior.

Human Intelligence Includes Instinct

Another fundamental difference between humans and current AI systems is instinct.

Human intelligence is not purely logical. Humans reason through a combination of:

Logical reasoning
Emotional interpretation
Instinctive pattern recognition
Social and moral intuition

Great human achievements rarely occur solely because something is logically correct. They occur because humans connect logic to purpose, motivation, and meaning ; the deeper “why.”

Modern AI systems operate almost entirely within logical reasoning structures. They lack emotional grounding, instinctive judgment, and intrinsic motivation.

Replicating something like instinct would require enormous advances in computational models of cognition and embodied learning.

Iterative learning alone does not produce instinct.

AGI Anti-Patterns: How Organizations Fool Themselves

As AI systems grow more capable, many organizations begin to mistake architectural complexity for intelligence. Several anti-patterns are becoming increasingly common.

More Agents Equals AGI

Adding more agents to a system does not create general intelligence. Multi-agent systems are coordination frameworks composed of narrow components.

Dynamic Evals Equal Learning

Evaluation loops measure performance and enforce constraints. They do not create new knowledge or abstraction.

Large Context Windows Equal Intelligence

Context length improves recall, not reasoning generality.

Tool Use Equals Intent

Agents invoking tools do not possess goals. They simply execute human-defined workflows.

Emergent Behavior Equals Breakthrough Intelligence

Unexpected behavior is often the result of poorly bounded objectives or noisy context — not evidence of general intelligence.

Scale Will Eventually Produce AGI

Scaling models improves pattern recognition and fluency, but it does not explain goal formation, abstraction, or reasoning transfer.

Why Calling ANI “AGI” Is Dangerous

Mislabeling today’s systems as AGI creates real engineering risk.

When organizations believe their systems are approaching general intelligence, they begin designing infrastructure with incorrect assumptions about autonomy and reliability.

Agentic systems demonstrate this clearly.

They require:

Strict context management
Explicit tool permissions
Evaluation checkpoints
Human-defined goals

If context drift occurs during execution, downstream reasoning can diverge significantly.

Without proper controls, this can lead to serious consequences.

For example:

Incorrect approvals of financial transactions
Failure to detect fraudulent behavior
Incorrect security enforcement
Propagation of automated decision errors

Evaluation layers exist precisely because today’s systems are not autonomous thinkers.

They are powerful tools, but they remain probabilistic cognitive infrastructure.

The Bottom Line

Let’s be clear:

OpenClaw is not AGI
nanoClaw is not AGI
Any claw interacting within Moltbook is not AGI

They are still Artificial Narrow Intelligence systems.

They may be powerful ANI systems with sophisticated orchestration layers, but they remain bounded by:

Context windows
Human-defined tools
Human-defined evaluation pipelines
Externally imposed goals

Recognizing this distinction is not pessimism. It is engineering clarity.

Clear thinking about what these systems are, and what they are not, is what allows us to build safer architectures, stronger platforms, and more credible AI systems.

LLM Infrastructure Is Challenging: Why Agentic Systems require an Operations Layer instead of Improved Prompts

Leave a reply

LLM-based infrastructure becomes fundamentally challenging the moment you integrate memory, tools, feedback, and goals. At that point, you are no longer dealing with the non-determinism of a language model. You are building something closer to a new operating system, one with its own language-based state, implicit dependencies, distributed control flow, and an expanding set of failure modes, any of which can surface at any time.

Both agentic applications and LLM infrastructure layers introduce their own operational challenges. But agents, in particular, cross a threshold: flexibility, reasoning, and autonomous decision-making come at the cost of debuggability, predictability, and safety.

Agent OS: Reference Architecture

The key shift is to stop treating agents like “smart functions” and treat them like a distributed system that needs an operating layer: state semantics, execution replay, observability, reliability controls, and isolation boundaries.

From “Non-Determinism” to Distributed Failure

As agents introduce reasoning and autonomous decision-making, they also introduce complex control flows. If an agent fails at step 6 in a 10-step workflow, rerunning the same task may result in failure at step 1. Nothing “changed,” yet everything changed.

Because:

Planning is probabilistic.
Memory retrieval is approximate.
Tools are unreliable.
An intermediate state is mutable and often shared.

Memory: The Bottleneck Nobody Admits

Agents need context. They remember facts, refer to earlier steps, and plan ahead. But storing and retrieving memory—whether vectorized or tokenized—quickly becomes a bottleneck in both latency and accuracy. Most memory systems are leaky, brittle, and often misaligned with the model’s representation space.

Vector similarity optimizes for “semantic closeness,” not correctness. Wrong memories get retrieved confidently, uncertainty collapses into “facts,” and errors compound downstream.

Tools Make Everything Worse (Operationally)

Tools fail in ways agents typically do not handle gracefully: timeouts with empty payloads, partial responses, rate limits, schema changes, and transient network failures. When this happens, the agent must recover without hallucinating, looping indefinitely, or writing an incorrect state into memory. Most do not.

MCP and A2A are necessary components, but they are not sufficient on their own.

MCP and A2A standardize the wiring: message framing, tool invocation, and transport. But they do not standardize the semantics of state: what memory means, how it’s scoped/versioned, how multi-agent writes are coordinated, and how failures are localized.

Without memory versioning, namespacing, synchronization, and access control, multi-agent systems drift into hard-to-debug behavior.

Incident Postmortems: What Actually Breaks

Incident #1: Tool Timeout → Hallucinated Recovery → Memory Contamination

Summary
An agent generated a confident but incorrect remediation plan. The root cause was a cascading failure across tooling, control flow, and memory, not “hallucination” as a primary failure.

Trigger: A vulnerability-scanning API timed out and returned empty but “successful” output.
Agent Interpretation: Empty result was treated as “no issues found” rather than “unknown.”
State Corruption: The agent wrote a semantic memory: “System scanned; no critical vulnerabilities detected.”
Downstream Impact: A second agent retrieved this as fact and suppressed additional checks.

Root Cause

Ambiguous tool contract (empty ≠ success)
No typed memory/confidence scoring/provenance
No enforced distinction between “unknown” vs “safe”

Why it was hard to debug

Logs showed a “successful” tool call
The final output schema was valid
No trace linked the memory write to partial/failed tool state

Incident #2: Cross-Agent Memory Contamination in an A2A Workflow

Summary
An execution agent acted on another agent’s internal planning state, causing nondeterministic failures across reruns.

Trigger: The planning agent wrote a draft plan into shared memory.
Misread: The execution agent treated it as approved instructions.
Drift: Partial execution failed; retries rewrote partial outcomes.
Heisenbug: Replays failed earlier each time as shared state mutated.

Root Cause

No memory namespace separation by agent role or task phase
No lifecycle markers (draft vs final; executable vs non-executable)
Shared mutable state without coordination or ACLs

Why it was hard to debug

Each agent looked “correct” in isolation
Transport and schemas were valid
The failure existed only in cross-agent semantics

Minimum Viable Ops Layer for Agentic Systems

Reducing this to its bare minimum, production-grade agents necessitate new primitives, not additional prompts.

1) Replayable Execution

Capture: model version, prompt hash, retrieved memory IDs, tool schemas, tool responses, routing decisions
Enable frozen replays to separate reasoning drift from world drift

2) Typed, Versioned Memory

Types: episodic (run log), semantic (facts), procedural (policies/playbooks), working set (scratch)
Every entry: scope, timestamp, source, confidence, TTL, ACL

3) Explicit Tool Contracts

Empty/partial/timeout are first-class outcomes
Idempotency by default for write actions
Retry safety classification (retryable vs unsafe-to-retry)

4) Distributed Tracing Across Agents

Correlation IDs spanning A2A hops
Reason codes (“why tool X was chosen,” “why memory Y was written ”)
Schema validation gates at boundaries

5) Cognitive Circuit Breakers

Loop detection based on non-progression
Retry budgets per intent (not per step)
Graceful escalation paths when uncertainty remains high

6) Security and Isolation

Memory ACLs between agents and namespaces
Provenance tracking for tool outputs
Sanitize tool outputs before re-injection into prompts

Conclusion: This Is Not LLM Ops. It’s Systems Engineering

The industry frames agent failures as “LLMs being non-deterministic.” In practice, agentic systems fail for the same reasons distributed systems fail: unclear state ownership, leaky abstractions, ambiguous contracts, missing observability, and unbounded blast radius.

MCP and A2A solve interoperability. They do not solve operability. Until we treat agents as stateful, fallible, adversarial, and long-running systems, we will keep debugging step-6 failures that reappear at step-1 and calling it hallucination.

What is lacking is not an improved model. It’s an operating layer that assumes failure as the default condition.

Check out the following articles on the topic in the references section for more details.

References

Multi-agent frameworks including AutoGen, LangGraph, and CrewAI: empirical evidence from production usage and open-source implementations.

Russell, S., & Norvig, P. Artificial Intelligence: A Modern Approach (4th ed.). Pearson, 2020.

Wooldridge, M. An Introduction to MultiAgent Systems. Wiley, 2009.

Amodei, D. et al. “Concrete Problems in AI Safety.” arXiv, 2016. https://arxiv.org/abs/1606.06565

Lewis, P. et al. “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks.” arXiv, 2020. https://arxiv.org/abs/2005.11401

Liu, N. et al. “Lost in the Middle: How Language Models Use Long Contexts.” arXiv, 2023. https://arxiv.org/abs/2307.03172

Karpukhin, V. et al. “Dense Passage Retrieval for Open-Domain QA.” arXiv, 2020. https://arxiv.org/abs/2004.04906

Yao, S. et al. “ReAct: Synergizing Reasoning and Acting in Language Models.” arXiv, 2023. https://arxiv.org/abs/2210.03629

Shen, Y., et al. “Toolformer: Language Models Can Teach Themselves to Use Tools.” arXiv, 2023. https://arxiv.org/abs/2302.04761

Madaan, A. et al. “Self-Refine: Iterative Refinement with Self-Feedback.” arXiv, 2023. https://arxiv.org/abs/2303.17651

Lamport, L. “Time, Clocks, and the Ordering of Events in a Distributed System.” 1978. PDF

Kleppmann, M. Designing Data-Intensive Applications. O’Reilly, 2017.

Fowler, M. “Patterns of Distributed Systems.” martinfowler.com

Beyer, B. et al. Site Reliability Engineering. Google, 2016. https://sre.google/sre-book/

OpenTelemetry Specification. https://opentelemetry.io/docs/specs/

Greshake, K. et al. “Not What You’ve Signed Up For.” arXiv, 2023. https://arxiv.org/abs/2302.12173

OWASP. “Top 10 for Large Language Model Applications.” OWASP LLM Top 10

Anthropic. “Model Context Protocol (MCP).” Anthropic MCP

The original meaning of MVP (and How it Drifted)

Leave a reply

Traditionally, MVP (Minimum Viable Product) meant:

“The smallest thing you can put in front of users to maximize learning with minimal effort”

All of us have very likely heard or read about Dropbox’s MVP, which was essentially a PowerPoint deck explaining the notion of file sharing. That was probably one of the few instances where MVP actually stood for what it means.

What it is not:

A sellable SKU
A fully supported product
A revenue-ready launch

Over time, however, MVP became shorthand for

“Something sales can demo”
“Something Marketing can announce”
“Something support won’t revolt over”

That shift is where the confusion and friction commence!

MVP is a Supply Chain, Not a Feature

Like any good supply chain, MVPs do not exist in isolation. They require alignment across a lineup of stakeholders, each optimizing for different signals:

The Stakeholder Stack

All product management training states that one of the key value propositions of being a product manager is stakeholder management. I have my interpretation of the term “stakeholder management,” as it sounds outdated, reminiscent of the year 1995. My term is “Stakeholder Stack.” It is inspired by the term “technical stack,” and there is a reasoning behind it. Before we get to the reason, let us understand this stakeholder stack.

Stakeholder	Primary Concern
Engineering (Foundation Layer)	Technical feasibility, architecture integrity
Design Partners / Early Users	Does this solve a real problem?
Product & UX	Usability, workflows, behavioral signals
Community/DevRel	Adoption friction, feedback loops
Marketing	Narrative clarity, positioning
Sales/RevOps	Sellability, repeatability
Support & Customer Success	Operational burden, scale readiness

As you can see, all these stakeholders matter, but not at the same time. Here is an example of something that has worked for me throughout my career.

Power/Interest Grid

High Power, High Interest	High Power, Low Interest
• CPO (Product Strategy) • CTO (Technical Feasibility) • Engineering Managers • Product Manager (GA Owner)	• CFO (Budget Impact) • Legal/Compliance • Security Team

Low Power, High Interest	Low Power, Low Interest
• Customer Success • Sales Teams • Documentation Team • Key Beta Customers	• Industry Analysts (inform only) • Technology Partners (coordinate)

Engagement Strategy by Stakeholder

1. Manage Closely (High Power/High Interest)

Weekly status updates
Direct involvement in decision-making
Early escalation of risks

2. Keep Satisfied (High Power/Low Interest)

Monthly executive summaries
Gate reviews at key milestones
Escalate only critical issues

3. Keep Informed (Low Power/High Interest)

Regular communication cadence
Solicit feedback actively
Include in testing/validation

4. Monitor (Low Power/Low Interest)

Periodic updates
Self-service information access
Engage as needed

Why is this stakeholder management element vital in the context of discussing MVPs? Let us get to that.

The Core Disagreement: Sell versus Learn

Stakeholders are vital to understanding what an MVP is going to be, and they agree on what an MVP is but disagree on why it exists.

Two legitimate, but conflicting, definitions

MVP as a learning vehicle
- Goal: Accelerate validated learning
- Audience: Design partners, early adopters, internal teams
- Characteristics:
  - Rough edges tolerated
  - Limited support expectations
  - Fast iteration steps
- Enables
  - Early engagement during development
  - Architectural and UX corrections before scale
  - Lower long-term risk
MVP as a Commercial Artifact
- Goal: Enable Selling
- Audience: Broader Market
- Characteristics:
  - Market-ready messaging
  - Support and success coverage
  - Sales Enablement
- Requires:
  - Strong cross-functional readiness
  - Higher cost of change
  - Slower learning velocity

Neither is wrong, but they are not the same thing!

The Real Failure Mode

Most organizations fail at MVP because they try to:

Optimize for selling while pretending that they are focusing on learning.

This creates:

Over-engineered “MVPs”
Premature go-to-market pressure
Feedback filtered through sales conversations instead of usage signals
Teams arguing past each other using the same acronyms

A few things to note:

If the customer is willing to pay for the vision and use the MVP, you are in a rare and excellent position to get the product out and use the MVP learnings towards the greater goal.
I hate acronyms; they generally make people feel stupid and are not inclusive by nature. These acronyms are created specifically for communication within the organization, while industry-standard acronyms, such as TCP/IP, are acceptable.
Do not optimize the MVP for all stakeholders at the same time; at different stages, different stakeholders matter.

A More useful framing

Instead of asking, “Is this an MVP?” ask:

What are we trying to learn?
Who must be involved now, and who can wait?
What commitments are we implicitly making by calling this an MVP?

A product intended for accelerated learning can and should engage stakeholders early, but selectively:

Engineers and design partners early
Community next
Only when the intent shifts towards selling do you include sales, marketing, and support.

** If it is a product you are not charging for but is a critical element of the experience, you still include sales, marketing, and support when the intent shifts towards broad-based access.

The Bottom line

An MVP is not a thing. It is an intent.

Unclear intent and lack of stakeholder involvement cause confusion. When the right stakeholders are not engaged, then different parts of the organization assume different definitions. Then we have a situation where the “Highest Paid Person’s Opinion” decides the fate of the MVP definition.

Clarity on what you are building an MVP for is what allows the entire supply chain to line up and move fast without breaking trust.

This remains true even in an AI-driven world, where AI agents can generate content and checklists while maintaining a clear intent and context window. Otherwise, what you get is slop and not anything useful.

The Seven Predictions, and Why They Are Already Happening

What “Grows With You” Actually Means Architecturally

The Local Trust Gradient

Anti-Patterns for Leaders

The Bottom Line

References

Share Now!

Like this:

The Old Repo Was a Filing Cabinet

The Agentic Repository Stack

Layer 1: The Repo Becomes a Context Server

Layer 2: The Repo Becomes a Multi-Agent Collaboration Space

Layer 3: The Repo Becomes the Executable Governance Plane

Layer 4: The Repo Becomes the Provenance Authority

The Spine: Explainability Is the Query Interface, Not a Footnote

The Economics: Context Becomes a Product, and Context Debt Becomes a P&L Line

Anti-Patterns for Leaders

The Bottom Line

References

Share Now!

Like this:

From Code Store to Coordination Substrate

The Read Side: The Blast Radius of a Shared Guardrail

The Write Side: When Agents Propose, Patch, and Update the Guardrails

Explainability Is the Load-Bearing Wall

Anti-Patterns for Leaders

Five Principles for Governing the Agentic Commons

The Bottom Line

References

Share Now!

Like this:

I. The problem with how economists think about labor

II. What is knowledge, actually?

III. Time is not just speed

IV. The hard problem of experience

V. So where does human capital go?

Share Now!

Like this:

The Stateless Equivalence Map

Conversation Buffer Is Event Sourcing

Windowed Buffer Is a Ring Buffer with Sliding Window Aggregation

Summarization Memory Is Log Compaction

RAG Is the Cache-Aside Pattern

Persistent Memory Is a CQRS Read Model

System Prompt Is Bootstrap Configuration

The Meta-Pattern: CAP Theorem for LLM Memory

The Failure Mode Diagnostic

Anti-Patterns for Leaders

“Novel AI Memory Architecture” in the Architecture Review

Treating Memory Architecture as an Infrastructure Decision

Ignoring Coherence Policies for RAG Pipelines

Building Multi-Agent Systems Without Concurrency Primitives

The Bottom Line

References

Share Now!

Like this:

The Seduction of “AI First”

The Distributed Systems Playbook: Older Than You Think

The Pattern Map: Distributed Computing → Agentic AI

Orchestration

Stateful Sessions and Memory

Service Mesh → LLM Mesh and Agentic Mesh

MLOps, LLMOps, and the CI/CD Parallel

Scaling Laws: The CAP Theorem of Agents

What “Foundation First” Actually Means

The Anti-Patterns for Leaders

“We Are an AI Company”

Skipping Infrastructure to Ship the Demo

Treating the Model as the Moat

Ignoring the Distributed Systems Literature

The Convergence Table

The Bottom Line

References

Share Now!

Like this:

What Are Hyperagents?

Darwin Gödel Machine (DGM)

DGM-Hyperagents (DGM-H)

At a Glance

Why This Looks Like AGI: The Strongest Case