← All posts

What is missing from AI agents?

Ask Google, OpenAI, Anthropic, CrewAI or LangChain what parts an agent has and they all say: a model, the instructions it follows, the tools it can call, and (usually) memory.

They don’t say anything about what the agent may see, what it takes when it leaves, what survives when it crashes, or what you can prove later about what it did.

A regulated enterprise needs all four. There’s a couple of startups around that will fill each gap for you. The problem is these four gaps are really one thing.

If you buy one each from separate startups, then only you own all four. Then an auditor asks, what did your agent see and do? You have four answers and no record.

Five days apart

Consider a real-world example, an agentic mortgage processing app.

On the first day a customer agent opens a mortgage application and starts the underwriting run. Underwriting needs the applicant’s credit file, and the applicant has consented to the pull. The credit agent asks the bureau, the consent is on file, and the report comes over. The run’s memory keeps the report, which is what memory is for.

On the sixth day the applicant withdraws consent, which is their right. The bureau refuses now, correctly. The memory holds the report anyway. Nothing told it otherwise, and memory has no permissions to check.

On the fourteenth day, the funding day, the run crashes. The durable executor does exactly what it promises and replays the run from its journal. Calls to the outside are not made a second time. Their recorded answers are used instead.

The report nobody may see any more is handed over again, on purpose, by the component whose job is correctness.

Every vendor behaved correctly; and yet you have a disclosure and a lot of explaining to do.

The problem is structural, not a shortfall of effort: the executor must replay recorded outcomes or it is not durable, and the bureau cannot reach into another company’s journal to revoke what it once returned.

This is the general case and not a quirk of the example.

A durable executor must hold every external call outside its replay boundary because it owns neither the data nor the permissions on the data, so the thing it can faithfully reproduce is the answer it was once handed rather than the decision that produced the answer.

An executor that could enclose the reads and their entitlements would have to be the memory and the governance as well, at which point it has stopped being one of four procurements.

The failure lands in the seam between them, and a seam is the one thing nobody sells.

The run and the audit trail it leaves are worked, query by query, in the Research Notes.

Consensus or blindspot?

So when the industry tells us an agent is these parts, we should be concerned. It’s a good list, but it’s incomplete.

Google’s Agent Development Kit defines an agent as “a self-contained execution unit designed to act autonomously to achieve specific goals,” assembled from three basic components: an AI model, task instructions, and optionally a set of tools.

OpenAI’s Agents SDK is almost the same sentence: “an agent is a large language model (LLM) configured with instructions, tools, and optional runtime behavior such as handoffs, guardrails, and structured outputs.”

Anthropic describes the augmented LLM, “an LLM enhanced with augmentations such as retrieval, tools, and memory.”

A CrewAI agent takes a role, a goal, a backstory, an LLM, tools, memory, and knowledge sources.

LangChain declines to enumerate at all and defines by behavior instead: “an AI agent is a system that uses an LLM to decide the control flow of an application.”

YK’s widely read map of agents on Google Cloud gathers the whole convergence into one sentence: “Strip away the frameworks and every agent is the same five parts: a model that reasons, tools it can call, memory so it isn’t goldfish-brained, a runtime loop that ties them together until the task is done, and increasingly connections to other agents.”

These were written by parties who compete with one another, so the agreement between them is worth something. This is not one vendor’s slide. It is what the field believes an agent is made of.

The list everyone gives, and the four questions it does not answer. THE LIST EVERYONE GIVES model tools instructions memory agent-to-agent = recall AND NO ANSWER TO ANY OF THESE What may this agent see? What survives a crash? What may it keep when it leaves? What can you prove later? Everyone draws the parts. Nobody draws what they stand on.

What the list leaves out

Google’s definition and OpenAI’s do not mention memory at all. The thinness is not the interesting part, though. What is interesting is that the same four things are missing from every version of the list: entitlement, retention, durability, and proof.

None has a box for durability. None has a box for entitlement. Read the ADK and the OpenAI agent documentation for what happens when a run fails partway through and you find nothing on the subject.

Memory, where it appears, means recall: the property of not being goldfish-brained. Recall is not the same requirement as surviving a failure, and it is not the same requirement as knowing what the agent was permitted to read in the first place. One word covers one of the three and is quietly assumed to cover all three.

The industry has noticed, one box at a time

The omissions have not gone unremarked. What is striking is the form the remarks take.

In February, 2026, Temporal raised $300 million at $5 billion valuation, on the thesis that durable execution is what turns agentic AI into something that survives contact with production. Entitlement became a product category of its own in the same way. Glean sells permission-aware retrieval as the property that makes enterprise search safe at all: “Glean enforces the existing permissions of your data sources in results, so users only see what they are allowed to access.”

So the field does know the boxes are missing. Its response is to sell each missing box separately. An enterprise that wants an agent to work on its own data now assembles that agent out of four purchases: a model, a retrieval layer that respects permissions, a memory service, and a durable executor. Each one is competently built. Each one is bought from a different company.

What the parts stand on

The corrected picture is not the old list with two more boxes bolted onto it. Two more boxes would repeat the error, since the point is that these cannot be bought separately. What the list is missing is not a part. It is the thing the parts stand on.

The same parts, standing on one governed record. THE SAME PARTS, ON ONE SUBSTRATE model tools loop agent-to-agent you bring these every read, every call ONE GOVERNED RECORD ENTITLEMENT permits RETENTION keeps DURABILITY survives PROOF proves append-only · two clocks · capability-scoped · replay with the reads inside WunderOS Every part can be correct. Only the record can answer for them.

This is why WunderOS is built as an operating system rather than as a component. Memory is a service of the operating system rather than something held inside the agent, so a visiting agent does not own its memory of your data; the enclave does. Every read and every tool call crosses one governed boundary, and each traces through a bounded capability to the person who authorized it. The record is append-only and keeps two clocks, so what was true and when the system learned it stay separate facts rather than one overwritten field. Governed decisions are deterministic and replay the same way any durable executor does. What differs is where the boundary of the replay falls. The reads and the entitlements are inside it, so replaying a visit re-reaches the verdicts instead of reciting answers recorded by a system that owns neither. Because the boundary, the memory, and the record are one system, the fourteenth-day question has somewhere to be answered: what was read, under whose authority, and what the agent is still permitted to hold.

Which boxes WunderOS fills

An honest accounting is owed, since the argument above is a claim about the shape of a stack and not only about other people’s diagrams.

In the consensus diagram WunderOS
Model Not ours, and not planned. Bring your own.
Tools The agent brings them. WunderOS governs every call.
Runtime loop The agent brings it. WunderOS hosts it and bounds it.
Connections to other agents Governed at the boundary each agent crosses.
Memory Ours. A service of the operating system, not a store inside the agent.
Durability (no box in the list) Ours. Append-only record, two clocks, deterministic replay with the reads inside the boundary, reversible actions.
Entitlement (no box in the list) Ours. Every access traces through a capability to the person who authorized it.

We do not sell the model and do not intend to. We do not sell the loop either, and an agent is welcome to arrive in whichever framework it was written in. The last two rows are the two the list has no name for, and they are really one row, kept apart in the table only because the industry buys them apart.

If you only remember one thing

An agent’s permissions, its memory, and its record of what it did are three views of one fact. A system can account only for what it owns, and a stack assembled from four vendors owns that fact nowhere.

The first enterprise use case built on this is the Agentic Data Enclave, a sovereign space where you host someone else’s agents to work on your data, prove what they saw, and curate what their memory keeps before they leave. The mechanism is at how it works, and the guarantees behind it are worked out in the Research Notes.