Tag Archives: agentic AI

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

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/

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

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/

Vital Cog

My thoughts on Product Management, Technology, and Philosophy.

Tag Archives: agentic AI

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

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

Like this:

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

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

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:

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: