Something is wrong with how we’re building agent systems.
Not at the model layer; the models are extraordinary. Not at the tool-use layer; function calling works. The problem is underneath all of that, at the layer nobody wants to talk about because it isn’t as exciting as benchmarks: the infrastructure layer.
The current generation of agent frameworks treats infrastructure as a solved problem. It isn’t. What we have is a collection of workarounds that happen to function in demos and break badly in production.
Let me be specific.
Context windows are not memory
An agent that “remembers” by stuffing prior conversation into a context window does not have memory. It has a buffer. The distinction matters.
Memory implies persistence: the ability to recall facts across sessions, across tasks, across time. Memory implies structure: the ability to distinguish what you know from what you believe from what you’ve been told. Memory implies forgetting: the ability to let irrelevant information decay without manual pruning.
A context window has none of these properties. It is a fixed-size text field prepended to every call. When it fills up, you summarize, which is a euphemism for “lossy compression applied to everything your agent has ever learned.” The summarization has no semantic model of what matters. It cannot distinguish a validated fact from a hallucinated intermediate step that happened to appear in a prior response.
Every production agent system hits this wall. The usual response is “use a vector database for long-term memory.” That is not a solution. It is a different shape of the same problem.
A vector store gives you similarity retrieval. It does not give you structured knowledge. It cannot tell you whether a fact is current or stale, who asserted it, what evidence justified the assertion, or whether the agent that wrote it had the authority to do so. It is a bag of embeddings with no provenance, no governance, and no epistemological structure.
API keys are not identity
Here is something common in agent deployments that should alarm anyone who has thought about security for more than five minutes: agents authenticate to external services with shared API keys stored in environment variables, or worse, in configuration files that ship with the container image.
That is not an identity model. It is a shared secret with no principal binding, no capability scoping, no delegation chain, and no audit trail. Every agent instance in the cluster authenticates as the same identity, because there is no identity. There is only a token.
What does a real identity model look like? Every actor in the system (human, agent, infrastructure node, external service) is a cryptographic principal. Identity is proof of key possession, not presentation of a shared secret. Principals hold capabilities: fine-grained, composable permissions that say exactly what an agent may do and in what scope. Capabilities are delegatable. A principal can grant a subset of its own capabilities to a subordinate, creating an auditable chain of authorization.
None of this is novel cryptography. The X.509 certificate chain you rely on every time you open a browser tab implements a delegation model more sophisticated than what most agent frameworks provide. We just haven’t applied these ideas to agents.
Secrets in the container filesystem
This one is worth dwelling on, because it shows how far the gap has opened between what agent systems need and what agent frameworks provide.
On a recent community call in the agent infrastructure space, there was a serious discussion about how to manage secrets for agent runtimes. The proposals included environment variables, mounted config files, and, I wish I were exaggerating, writing secrets to the container’s local filesystem and reading them at startup.
Every one of these was state of the art in application deployment around 2015. Kubernetes added Secrets resources the following year. Dedicated secrets managers went further, with dynamic secret generation, transit encryption, and lease-based access. The question of how to give a running process credentials without hardcoding them has been answered, thoroughly, for a decade.
And yet here we are in 2026, watching the agent infrastructure community rediscover the problem from scratch.
The right shape is not complicated. Key material stays off disk and off the network: a small local service alongside the agent, reachable only on the machine, caches what the active session needs, defers to a secrets manager as the root of trust, and wipes that material when the session ends. The agent’s application code doesn’t change at all.
This is a boring, well-understood, completely solved problem.
The real problem is epistemic
The individual failures (no real memory, no real identity, no real secrets management) are symptoms. The disease is that agent frameworks have no epistemic model.
By “epistemic model” I mean a principled answer to the question: what does this system know, and why does it believe it?
In a system with no epistemic model, every fact is equally trustworthy. The output of a hallucination-prone model and the output of a deterministic database query live in the same flat namespace. A fact retrieved from a vector store three months ago has the same standing as a fact validated against a source of truth five seconds ago. There is no way to tell speculative working knowledge from canonical truth.
This is not a theoretical concern. It is the reason agent systems cannot be trusted with real work. If you cannot answer “why does the agent believe X?” for an arbitrary X, you cannot deploy that agent anywhere trust matters, which is to say anywhere that matters at all.
What an operating system looks like
An operating system provides the abstractions applications need so they don’t solve the same low-level problems over and over: process isolation, memory management, access control, a filesystem, device drivers.
Agent systems need the same thing. They need a layer that provides identity, memory, governance, and provenance as infrastructure, not as libraries each application reimplements.
That layer has to distinguish fast memory (mutable, ephemeral, speculative) from slow memory (immutable, audited, canonical), and it needs a formal process for elevating working knowledge to canonical truth. It needs cryptographic principals with delegatable capabilities. And it needs an access control engine that evaluates every operation against a semantic policy, not a configuration file.
None of this is research. All of it is engineering. The hard part was never designing these systems; it was recognizing that they were necessary.
We recognized it, and built Pharos Fabric around it.