Subramanya N

Context Engineering: Why Prompt Engineering Was Never Enough

Thu, 23 Apr 2026 00:00:00 +0000

For a while, “prompt engineering” was the name we gave to the craft of getting good results from large language models. It made sense in the early days. Most people were using one-shot interactions, and the main lever really did feel like wording: ask more clearly, add an example, constrain the format, and the model behaved better.

That framing is now too small for the real problem.

When an AI system fails in production, the issue is usually not that the model needed one more clever sentence in the system prompt. The issue is that the model did not see the right information, saw too much irrelevant information, saw the right information in the wrong format, or could not carry the right state forward from one step to the next. In other words, the problem was not just the prompt. The problem was the entire context pipeline.

That is why the term context engineering has caught on. The phrase entered mainstream AI discussion in mid-2025, when Tobi Lütke and Andrej Karpathy argued that “prompt engineering” undersold the real work involved in building reliable LLM systems.[1] But the underlying discipline is older than the name. If you have built RAG, tool calling, memory systems, summarization, or evaluation loops, you have already done pieces of context engineering. What changed is that we finally have a name that describes the whole job.

A Simple Mental Model

If you want the simplest possible picture, context engineering is the layer between the outside world and the model’s working memory.

flowchart TD
    U["User request"] --> CE["Context engine"]

    I["Instructions and policies"] --> CE
    R["Retrieved knowledge"] --> CE
    M["Memory and saved state"] --> CE
    T["Tool definitions and results"] --> CE
    H["Recent conversation history"] --> CE

    CE --> W["Model context window"]
    W --> L["LLM reasons and acts"]
    L --> O["Answer or tool call"]
    O --> S["New memory, logs, and state"]
    S --> CE

That is the whole game.

The model is the reasoning engine. The context engine decides what the model gets to reason over.

The Name Is New. The Job Is Not.

One reason the term resonates is that it ties together several threads that had been evolving separately.

Retrieval-Augmented Generation, or RAG, taught us that models need access to external knowledge at inference time.[2] ReAct taught us that reasoning and acting work better when models can call tools, observe results, and continue from there.[3] Memory research taught us that long-running assistants need indexing, retrieval, and reading strategies rather than endless transcript accumulation.[4] Long-context evaluation showed that simply stuffing more tokens into a model is not the same thing as giving it better working memory.[5][6][7]

Seen this way, context engineering is not a replacement for those ideas. It is the umbrella above them.

That umbrella matters because modern AI systems are no longer isolated prompts. They are dynamic systems that assemble instructions, documents, structured data, tool outputs, and prior state into a temporary context window for the next step. LangChain described this well when it defined context engineering as the work of providing the right information and tools in the right format so the LLM can plausibly complete the task.[8]

The phrase “plausibly complete the task” is doing a lot of work there. It is the right test.

If an agent fails, the first question should not be, “How do I make the prompt smarter?”

The first question should be, “Did I actually give the model what it needed to succeed?”

Why Prompt Engineering Became Too Small

Prompt engineering still matters. It just became a subset of a larger discipline.

The old mental model was:

Prompt engineering	Context engineering
Write better instructions	Build the full information environment
Focus on a single request	Focus on multi-step systems
Mostly static	Dynamic and stateful
Optimize wording	Optimize selection, structure, memory, and tools
Improve a single model call	Improve the whole loop

This distinction becomes obvious the moment you build an agent.

Suppose you are building a support agent for enterprise software. The user asks, “Why are our API requests timing out?”

If you think only in prompt terms, you might improve the wording:

Ask the model to be concise
Ask it to cite evidence
Ask it to think step by step

Those are fine improvements. But they are not enough.

The real system questions are harder:

Does the agent have access to the incident runbooks?
Can it see the latest logs and status pages?
Does it know which customer tier this account belongs to?
Does it remember earlier turns in the conversation?
Can it query the ticket system?
Can it distinguish stale documents from current ones?
If it gets too much context, what gets trimmed?

That is context engineering.

The prompt is one line item inside it.

What Counts as Context

In practice, context includes everything the model sees at inference time, not just the visible prompt.[8][9]

That usually means:

System instructions
The current user request
Retrieved documents
Structured data like JSON, tables, schemas, and records
Tool definitions
Tool outputs
Recent conversation history
Long-term memory or saved notes
Security, policy, and formatting constraints
Environment state such as files, tabs, tickets, or working directories

This is why the phrase “filling the context window” has become so central. The context window is not just a place where text goes. It is the model’s temporary working memory. Everything that enters it competes for attention.

And competition is the key word.

Every extra token is not merely additional information. It is also additional distraction.

Why Bigger Context Windows Did Not Solve the Problem

One of the most common misconceptions in the current AI market is that larger context windows made context engineering less important.

The research points in the opposite direction.

Lost in the Middle showed that models often use long contexts unevenly, performing better when relevant information appears near the beginning or end and worse when important information sits in the middle.[5] Databricks’ long-context RAG study found that while adding more retrieved documents can help, only a small number of state-of-the-art models maintained strong performance above 64k tokens.[6] Chroma’s Context Rot report went even further: even simple tasks become less reliable as input length grows, especially when ambiguity and distractors are introduced.[7]

This is the part many teams learn the hard way.

Bigger windows do not eliminate the need to choose. They make the cost of bad choices less obvious at first and more painful later.

A long prompt can fail in at least four different ways:

Context poisoning: a bad fact, hallucination, or outdated result gets carried forward.
Context distraction: too much relevant-but-not-critical detail overwhelms the core task.
Context confusion: different pieces of context contradict each other.
Context waste: useful tokens are buried under redundant or low-value material.

This is why context engineering is not about maximizing tokens. It is about maximizing signal density inside the context window.

This is where one of the best recent ideas enters the picture.

Jason Liu argued that the next step after classic chunk-based RAG is to stop thinking only about “the most similar passages” and start thinking about the shape of the search space.[10] His framing is especially useful because it maps out a progression that many teams are already moving through:

Minimal chunks
Chunks with source metadata
Better handling for multimodal and structured content
Facets and query refinement

The first three are improvements in what gets retrieved.

The fourth is more interesting. It improves what the agent learns about the corpus itself.

Facets give the model something like peripheral vision. Instead of returning only the top few chunks, the system can also return aggregated metadata:

Which document types dominate the result set
Which teams or owners appear most often
Which dates cluster together
Which categories are present but underrepresented in the top results

That matters because similarity search is biased toward what is easiest to match, not necessarily what is most important to inspect.[10] A retrieval system may over-surface well-documented resolved incidents and under-surface sparse, still-open incidents. A legal search may over-surface signed contracts and hide the unsigned ones that actually need attention. Facets help the agent see not just “what matched,” but “what else exists nearby.”

This is a major conceptual shift.

RAG was mostly about retrieval.

Context engineering is increasingly about navigation.

The Six Jobs of Context Engineering

The easiest way to make context engineering concrete is to break it into the actual jobs it performs.

1. Selection

The first job is deciding what deserves to enter the window at all.

This includes retrieval, ranking, filtering, source choice, and freshness checks. It sounds obvious, but it is still where a huge amount of quality is won or lost. Benchmarks like BRIGHT show that realistic retrieval is much harder than surface-level semantic matching suggests.[11] If your retrieval quality is weak, no amount of downstream prompt polishing will fully save the result.

Selection is not just “find relevant chunks.” It is:

choose the right source
choose the right granularity
choose the right amount
choose the right ordering

Good systems often retrieve less than naive systems, but retrieve it more intentionally.

2. Structure

The second job is deciding how the chosen context is represented.

The same information can be helpful or useless depending on formatting. Anthropic’s tool-use guidance is explicit about this: tool descriptions and interfaces strongly shape model behavior.[9] Long-context prompting guidance makes similar recommendations for XML tagging, source labeling, and clearly separated document sections.[12]

In practice, structure means:

label sources
separate instructions from data
wrap complex documents in consistent markup
preserve tables as tables when they matter
return citations and metadata with evidence

A short, well-labeled result often outperforms a giant JSON blob.

3. Compression

The third job is reducing context without destroying what matters.

This is where a lot of agent systems either get much better or much worse.

Compression can mean:

summarizing earlier turns
trimming stale history
keeping only the last few user turns verbatim
extracting durable facts from long threads
caching stable prefixes to reduce cost and latency

OpenAI’s prompt caching documentation shows that prompt order matters economically as well as cognitively: static shared prefixes are cheaper and faster when placed up front because cache hits depend on exact prefix reuse.[13] OpenAI’s newer Responses API work on compaction pushes the same idea further by treating long-running agent history as something that should be compressed into a more token-efficient representation before the window fills up.[14]

Compression is not optional. The only question is whether you do it deliberately or let the context window degrade on its own.

4. Memory

The fourth job is deciding what should persist beyond the current turn.

This is where many teams make the same mistake: they confuse memory with transcript retention.

But good memory is not “keep everything forever.” LongMemEval frames long-term memory as a three-stage problem: indexing, retrieval, and reading.[4] That is the right way to think about it. A memory system should help the model recover the right prior fact at the right moment, not drown it in the complete past.

This leads to a useful distinction:

Working memory: the short-term context needed for the current task
Reference memory: externalized facts, summaries, notes, or artifacts that can be reloaded later

If everything stays in working memory, the model gets distracted. If everything gets pushed out, the model loses continuity.

Context engineering decides what belongs in each layer.

5. Tool and Interface Design

The fifth job is making tools legible to the model.

This is an underappreciated part of the discipline. A tool surface is not just software API design. It is also context design.

The model needs to understand:

what the tool does
when to use it
what each parameter means
what the output implies
what to do next after seeing the result

This is why tool descriptions matter so much.[9] It is also why Jason Liu’s emphasis on tool results is important.[10] The output of a tool does not merely answer the current query. It teaches the agent how to think about the next query.

When the tool surface becomes standardized through a protocol like MCP, this becomes even more important. MCP makes it easier to connect tools, resources, and prompts to LLM applications, but it does not decide what information should be surfaced, how it should be filtered, or how much of it should be injected into the next model call.[15] The protocol is the plumbing. Context engineering is still the craft.

6. Isolation and Orchestration

The sixth job is deciding when not to share context.

This is one of the biggest differences between toy demos and production agents.

Sometimes the right answer is not a larger shared prompt. It is multiple smaller prompts with isolated scopes.

Anthropic’s multi-agent research system is a strong example.[16] Their subagents run in parallel with separate context windows, which helps them explore different branches of a problem without contaminating each other with every intermediate detail. LangChain describes a similar pattern under “isolate”: sometimes the best way to improve agent reliability is to split contexts rather than accumulate them.[17]

This matters because shared context has a hidden cost. It creates path dependence. A single bad branch can influence the next step, and the next, and the next.

Isolation is a way to limit blast radius.

What Changed in 2026

In 2025, context engineering was mostly a useful name for a problem people already felt. In 2026, it is starting to harden into an architecture.

The first big shift is that builders are moving durable state outside the raw context window. Anthropic’s context editing and memory tool explicitly separate what stays live in the working window from what should persist across sessions.[18] OpenAI’s January 2026 cookbook on personalization makes the same move in a different form: structured state objects that persist across runs and are deliberately injected back into working memory at the start of each run.[19] OpenAI’s Responses API then pushes this one step further with native compaction, so long-running agent loops do not require every team to build a custom summarization subsystem from scratch.[14]

Anthropic’s Managed Agents makes the underlying pattern unusually explicit: the session is not the model’s context window.[20] That is a critical 2026 idea. The window is transient working memory. The session log is the durable object. The harness decides how to slice, compact, and rehydrate that durable context back into the next model call.

The second shift is that retrieval is becoming more just in time and more interface-native. Instead of front-loading every possibly relevant token, teams are giving agents retrieval surfaces they already know how to operate. Mintlify’s ChromaFs is a good example: rather than booting a full sandbox for documentation retrieval, it presents docs as a virtual filesystem navigable with ls, cat, and grep, cutting p90 session creation from about 46 seconds to about 100 milliseconds.[21] Turso’s AgentFS pushes the same intuition toward general agent execution: a copy-on-write filesystem abstraction with portable single-file storage and built-in auditing.[22]

The third shift is that context graphs are becoming an implementation direction, not just a metaphor. Foundation Capital’s thesis made the term visible, but the stronger claim is architectural: when agents sit in the execution path, they can capture decision traces as durable artifacts, not just emit final outputs.[26][27] Open-source systems like Graphiti and commercial platforms like Zep operationalize this as temporal context graphs with validity windows, provenance episodes, and hybrid retrieval across semantics, keywords, and graph structure.[23] TrustGraph takes a related approach by treating context as a versioned artifact: graph, embeddings, evidence, and policies bundled into portable “context cores” that can be promoted or rolled back like build outputs.[24][25]

The fourth shift is that context engineering is now visible in real software practice, not just platform blogs. The 2026 MSR paper on context engineering in open-source software studied 466 repositories and found that AI context files such as AGENTS.md are spreading, but with no stable content structure yet.[28] That matters because it marks a move from theory to operational artifacts. Context is no longer just something inferred at runtime. It is being authored, versioned, reviewed, and mined as part of the software lifecycle.

If you want the 2026 mental model in one picture, it looks like this:

flowchart LR
    E["Session log / events"] --> A["Context assembler"]
    F["Files, docs, and tools"] --> A
    G["Context graph / memory"] --> A
    P["Policies and AGENTS.md"] --> A

    A --> W["Working context window"]
    W --> X["Agent action"]

    X --> E
    X --> G

That is a very different architecture from “prompt + vector search.”

Where Context Graphs Actually Fit

One reason this conversation gets muddy is that people use context engineering and context graph as if they mean the same thing. They do not.

Context engineering is the broader discipline. It is the work of deciding what goes into the next context window, what stays out, what gets compressed, and what gets retrieved on demand.

A context graph is one possible long-term memory substrate inside that larger system.

That distinction matters because not every useful agent needs a context graph. A documentation assistant over mostly static content may need good retrieval, tool design, and compaction, but not a graph. A coding agent may get surprisingly far with repository instructions, a durable session log, and a filesystem abstraction.[20][21][22][28]

Context graphs become compelling when the problem has four characteristics:

Temporal truth matters. You need to know not just what is true now, but what was true at decision time.[23]
Provenance matters. You need to trace facts back to the episode, document, or interaction that produced them.[23][24]
Precedent matters. The task depends on how similar cases were handled before, including exceptions and approvals.[26][27]
Cross-entity reasoning matters. The useful memory is not a flat note, but a network of people, policies, incidents, accounts, tickets, and outcomes.[23][25]

This is why the best definition of a context graph, in my view, is not “a graph database for AI.” It is a durable representation of precedent.

That is also why decision traces matter so much. Foundation Capital’s framing is useful here: rules tell the agent what should happen in general; decision traces tell it what happened in a specific case, under real constraints, with real exceptions.[26] Once those traces are linked across entities and time, you get something much more valuable than generic memory. You get searchable judgment.

How I Would Build It in 2026

If I were building a serious context-engineering stack today, I would not start with the graph. I would start with the interfaces and promotion rules.

1. Build a durable session layer first

Every action, tool result, observation, and important intermediate artifact should land in an append-only session log or event store. This is your recoverable context object.[14][20]

Do not confuse the active context window with the source of truth.

The window is for reasoning. The session is for recovery, replay, debugging, and selective rehydration.

2. Treat the context assembler as a product surface

The assembler should explicitly manage:

token budgets
source priority
freshness
compaction thresholds
history trimming
citation formatting
cache-aware ordering

This is the layer that decides what the model sees now. It should be observable, testable, and cheap to change.[18][19][14]

3. Prefer just-in-time retrieval over eager stuffing

Give the model lightweight handles first: file paths, object IDs, URLs, query templates, ticket IDs, incident IDs. Then let it pull detail only when needed.[9][18][21]

This is where filesystems, MCP tools, search APIs, and structured queries become more valuable than giant top-K dumps.

4. Promote only high-value state into long-term memory

Not everything should become memory.

I would promote four classes of artifacts:

stable user or account preferences
durable facts with provenance
important intermediate summaries
decision traces and exceptions

Everything else should stay in the session log until it proves it deserves promotion.

5. Build the context graph as a promoted memory layer

This is the part many teams invert.

The graph should not be your raw transcript in graph form. It should be the curated layer that sits above sessions and below real-time assembly:

entities
relationships
time validity
source episodes
approvals
exceptions
outcomes

If you skip the promotion step, the graph becomes a dumping ground. If you get promotion right, the graph becomes the memory of how the organization actually reasons.[23][26]

6. Package context like code

By 2026, one of the most promising ideas is to treat context as a versioned artifact. In software projects this shows up as AGENTS.md and other repository-specific context files.[28] In graph-native systems it shows up as context cores: portable bundles of ontology, graph structure, embeddings, provenance, and retrieval policy.[24][25]

This matters because context changes need the same operational discipline as code changes:

review
versioning
rollback
environment promotion
evaluation

Once context becomes an artifact, it becomes governable.

7. Separate observability from intelligence

You need both:

observability of the agent run
observability of the context system

Those are not the same thing.

I want to know:

what the model saw
what it did not see
what got compacted
what was retrieved just in time
what got promoted into memory
what graph neighborhood was traversed
which precedent actually influenced the action

If you cannot answer those questions, you are still debugging prompts in the dark.

A Practical Maturity Model

If you are trying to evaluate where your own system stands, this maturity model is more useful than abstract definitions.

Level 0: Prompt-Only

You have a system prompt, a user message, and maybe a couple of examples.

This can work surprisingly well for narrow tasks. It breaks quickly when the task requires fresh knowledge, persistence, or tools.

Level 1: Retrieval-Enhanced

You add documents at runtime.

This is where many teams stop. It is also where many teams start seeing the limitations of naive chunking, ranking, and context bloat.

Level 2: Agent-Aware

You now manage history, tool results, memory, and formatting intentionally.

This is the first level where “context engineering” becomes a useful term, because the system is no longer just prompt plus retrieval. It is assembling multiple forms of context dynamically.

Level 3: Adaptive

The system changes how it builds context based on the task.

It may:

choose among sources
compress older history
reload memory selectively
route work to specialized tools
isolate subproblems into separate contexts

At this point, context construction is part of the application’s core logic.

Level 4: Context-Native

The system treats context as a first-class engineering surface.

It has:

explicit context budgets
retrieval and generation evals
metadata and facet-aware navigation
memory policies
observability around failure modes
cost-aware prompt assembly

This is where the strongest production systems are heading.

What Good Context Engineering Looks Like in Practice

If I had to reduce the whole discipline to a checklist, it would look like this:

Start with the task, not the prompt. Define what success looks like first.
Enumerate the context sources the model might need. Instructions, docs, tools, memory, state, policies.
Separate working memory from reference memory. Not everything should live in the active window.
Retrieve with intent. More chunks is not the same as better recall.
Structure context so the model can parse it quickly. Labels, sources, tables, and boundaries matter.
Design tools as if they are part of the prompt, because they are.
Trim aggressively. If you would not ask a human to reread it, do not force the model to reread it.
Measure retrieval and generation separately. Otherwise you will diagnose the wrong problem.
Use isolated contexts when tasks branch or can run in parallel.
Promote durable facts and decision traces intentionally. Not every transcript belongs in long-term memory.
Package critical context like code. Instructions, policies, and graph artifacts should be versioned.
Treat context bugs like software bugs. They should be observable, reproducible, and fixable.

None of this is glamorous. That is exactly why it matters.

Prompt engineering became popular because it sounded like a shortcut.

Context engineering matters because it describes the actual work.

The Real Takeaway

The center of gravity in AI is moving.

The frontier question used to be: How smart is the model?

The applied question is increasingly: What does the model get to see before it has to act?

That is a different engineering problem. It is less about single prompts and more about systems design. Less about phrasing and more about information flow. Less about one-shot output quality and more about whether an agent can stay reliable over time.

This is why context engineering is going to keep growing as a discipline. The better models get, the more the remaining failures look like context failures. Missing state. Wrong tool. Bad retrieval. Bloated history. Poor formatting. Conflicting evidence. Weak memory. Unbounded loops.

The irony is that this makes AI systems feel more like classical software, not less. We are back to building pipelines, interfaces, state machines, memory hierarchies, caches, and observability layers. The novelty is that all of those pieces now exist in service of a probabilistic reasoning engine.

The name may be new. The direction is not.

Reliable AI systems will be built by teams that treat context as a first-class product surface.

Everyone else will keep calling the model flaky.

References:

[1] Simon Willison. (2025, June 27). Context engineering.

[2] Lewis, P. et al. (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks.

[3] Yao, S. et al. (2023). ReAct: Synergizing Reasoning and Acting in Language Models.

[4] Wu, D. et al. (2025). LongMemEval: Benchmarking Chat Assistants on Long-Term Interactive Memory.

[5] Liu, N. F. et al. (2023). Lost in the Middle: How Language Models Use Long Contexts.

[6] Leng, Q. et al. (2024). Long Context RAG Performance of Large Language Models.

[7] Hong, K., Troynikov, A., and Huber, J. (2025, July 14). Context Rot: How Increasing Input Tokens Impacts LLM Performance.

[8] LangChain. (2025, June 23). The rise of “context engineering”.

[9] Anthropic. How to implement tool use.

[10] Jason Liu. (2025, August 27). Beyond Chunks: Why Context Engineering is the Future of RAG.

[11] Su, H. et al. (2025). BRIGHT: A Realistic and Challenging Benchmark for Reasoning-Intensive Retrieval.

[12] Anthropic. Long context prompting tips.

[13] OpenAI. Prompt caching.

[14] OpenAI. (2026, March 19). From model to agent: Equipping the Responses API with a computer environment.

[15] Model Context Protocol. What is the Model Context Protocol (MCP)?

[16] Anthropic. (2025, June 13). How we built our multi-agent research system.

[17] LangChain. (2025, July 2). Context Engineering.

[18] Anthropic. (2025, September 29). Managing context on the Claude Developer Platform.

[19] Okcular, E. (2026, January 5). Context Engineering for Personalization - State Management with Long-Term Memory Notes using OpenAI Agents SDK.

[20] Anthropic. Scaling Managed Agents: Decoupling the brain from the hands.

[21] Mintlify. (2026, March 24). How we built a virtual filesystem for our Assistant.

[22] Turso. AgentFS.

[23] Zep. Graphiti: Build Real-Time Knowledge Graphs for AI Agents.

[24] TrustGraph. The context development platform.

[25] TrustGraph. Working with Context Cores.

[26] Gupta, J., and Garg, A. (2025, December 22). AI’s trillion-dollar opportunity: Context graphs.

[27] Garg, A. (2026, January 16). Why context graphs are the missing layer for AI.

[28] Mohsenimofidi, S., Galster, M., Treude, C., and Baltes, S. (2026). Context Engineering for AI Agents in Open-Source Software.

The Filesystem Is the Database: Why Agents Need a New Storage Primitive

Mon, 13 Apr 2026 00:00:00 +0000

Something interesting is happening in the agentic infrastructure space, and it is not what most people expected. For the past two years, the dominant paradigm for giving agents access to knowledge has been Retrieval-Augmented Generation: embed your documents, store them in a vector database, and let the model query them at inference time. RAG worked. It was good enough. But “good enough” has a shelf life, and in 2026, that shelf life is expiring.

A new pattern is emerging across the industry, and it is converging from multiple directions at once. Mintlify replaced its entire RAG pipeline with a virtual filesystem and saw session creation drop from 46 seconds to 100 milliseconds [1]. Turso built AgentFS, a SQLite-backed filesystem that gives every agent its own copy-on-write sandbox [2]. Box, the enterprise content giant, announced that it is repositioning its entire platform as a virtual filesystem layer for AI agents [3]. And ByteDance open-sourced OpenViking, a context database that organizes all agent memory, resources, and skills as a hierarchical filesystem [4].

These are not niche experiments. They are signals of a fundamental shift. The filesystem is becoming the universal interface for agent cognition, and the database is quietly becoming its substrate.

Why RAG Hit a Wall

RAG was the right answer for 2023. You had a pile of documents, a model with a limited context window, and you needed a way to surface relevant chunks at query time. Vector embeddings and similarity search solved that problem elegantly.

But agents are not chatbots. An agent does not ask one question and leave. It explores. It reads a file, discovers a reference, follows it, reads another file, runs a command, writes an output. This is not a retrieval problem. It is a navigation problem.

RAG pipelines struggle with this for three reasons. First, they are stateless by design. Every query is independent; there is no concept of “I was just looking at this directory, now show me the adjacent file.” Second, they flatten structure. A documentation site with a clear hierarchy of sections, pages, and code examples gets shredded into anonymous 512-token chunks that lose their organizational context. Third, they are expensive at scale. Embedding computation, vector index maintenance, and re-ranking all add latency and cost that compound as the corpus grows.

The filesystem solves all three. It is inherently stateful (the agent has a working directory). It preserves structure (directories, subdirectories, files). And it is fast because the operations are simple: ls, cat, grep, find. These are not novel abstractions. They are the most battle-tested interface in computing.

The Convergence: Four Approaches, One Pattern

What makes this moment significant is that the filesystem pattern is emerging independently across very different contexts.

Mintlify’s ChromaFs is perhaps the most instructive example. Mintlify powers documentation assistants for thousands of companies. Their original architecture was textbook RAG: chunk the docs, embed them, retrieve at query time. When they replaced it with ChromaFs, a virtual filesystem that intercepts UNIX commands and translates them into Chroma database queries, the results were dramatic. Session creation went from 46 seconds to 100 milliseconds, a 460x improvement. Marginal cost per conversation dropped from $0.0137 to effectively zero [1]. The key insight: the agent already knows how to navigate a filesystem. Teaching it to use cat /auth/oauth.mdx is trivial compared to teaching it to formulate the right vector query.

Turso’s AgentFS attacks a different problem: agent isolation and auditability. Every agent gets its own SQLite-backed filesystem with copy-on-write semantics. The host filesystem is a read-only base layer; the agent writes to a SQLite delta layer. Every file operation, tool call, and state change is recorded. The entire agent runtime, files, state, history, fits in a single portable SQLite file [2]. This is not just a filesystem. It is an auditable, reproducible execution environment.

Box’s enterprise VFS is the most strategically significant. Box CEO Aaron Levie has been explicit: agents need a filesystem to do knowledge work in the enterprise [3]. But Box is not pitching a literal filesystem. They are pitching a “dynamic data delivery contract” that can be backed by object storage, relational databases, or their own content platform. The filesystem is the interface; the backing store is whatever makes sense for the data. What makes Box’s play interesting is the governance layer: permissions, audit trails, and compliance boundaries that carry over automatically from the content platform to the agent.

ByteDance’s OpenViking takes the pattern furthest. It organizes all agent context, memories, resources, skills, knowledge, under a viking:// protocol using standard filesystem semantics. Agents navigate with ls and find. But the clever part is the tiered access model: every piece of context is processed into three layers. L0 is a one-sentence summary for quick retrieval. L1 is an overview with core information for planning. L2 is the full content for deep reading [4]. The agent starts with L0, drills into L1 when it needs more, and only loads L2 when it is doing detailed work. On the LoCoMo benchmark, this reduced token consumption from 24.6 million to 4.2 million while increasing task completion rates to 52% [4].

Filesystem as Interface, Database as Substrate

The pattern that connects all four is what I would call the VFS duality: the filesystem wins as the interface, and the database wins as the substrate. This is not an either-or choice. It is a layered architecture.

Why the filesystem wins as the interface is straightforward. LLMs are trained on the internet, and the internet is built by developers who think in terms of files, directories, paths, and command-line tools. Models are unusually competent with these primitives because they have seen billions of examples of developers navigating codebases, reading files, and running shell commands. When you give an agent a filesystem, you are meeting it where its training data lives.

Why the database wins as the substrate is equally clear. The moment agent memory needs to be shared, audited, queried by multiple agents, or made reliable under concurrency, you need database guarantees. ACID transactions, access control, semantic search, version history: these are hard problems that databases have spent decades solving. Reimplementing them on top of a literal filesystem is a path to pain.

The VFS pattern gives you both. The agent sees files and directories. The system sees tables, indexes, and access control lists. ChromaFs stores everything in Chroma but exposes it as files. AgentFS stores everything in SQLite but exposes it as a POSIX filesystem. OpenViking uses its own storage engine but exposes it as viking:// paths. Box uses its enterprise content platform but exposes it as a navigable tree.

But Can a VFS Actually Beat the Native Filesystem?

The natural objection to all of this is: why not just use the real filesystem? POSIX is right there. Every operating system ships with it. Why add an abstraction layer?

I wanted to answer this question empirically, so I built markdownfs, a from-scratch virtual filesystem in Rust designed specifically for agent workloads [6]. It supports the full set of UNIX-like commands (ls, cat, grep, find, chmod, chown), Git-style versioning with content-addressable storage, multi-user permissioning, and exposes three access methods: a CLI/REPL, an HTTP/REST API, and an MCP server that agents like Claude and Cursor can connect to directly.

The architecture is simple: an in-memory inode table backed by a content-addressable blob store using SHA-256 hashing, with tokio::RwLock for safe concurrent access. Files are deduplicated automatically. Version control uses the same commit/revert model as Git, but at the filesystem level. Persistence is handled through atomic bincode snapshots.

When I benchmarked markdownfs against the native filesystem across the standard agent operations (file creation, reads, writes, directory listing, grep, find, move, copy, deletion), markdownfs averaged roughly 130x faster across the board. The reasons are structural, not incidental. In-memory operations eliminate disk I/O entirely. Content-addressable storage means duplicate files are stored once. Zero-copy reads mean the agent gets data without serialization overhead. And because the entire filesystem state lives in a single process, there are no system call boundaries to cross.

The comparison is particularly stark for the operations agents perform most frequently:

Operation	Why VFS Wins
Repeated reads (agent re-reading context)	In-memory, zero-copy. No disk seeks, no page cache misses.
grep across files (agent searching for patterns)	All content is in-memory. No directory traversal, no file handle management.
Rapid file creation (agent producing work artifacts)	No filesystem journaling, no inode allocation on disk, no fsync.
Directory listing (agent exploring structure)	BTreeMap lookup vs. readdir syscalls.

But performance is not the real argument. The real argument is what the native filesystem cannot do. A POSIX filesystem has no concept of semantic search. It has no built-in versioning (you need Git for that). It has no tiered access model (you get the whole file or nothing). It has no content deduplication. It has no audit trail of agent operations. And critically, it has no MCP interface, which means agents cannot access it through the standard protocol that the ecosystem is converging on.

The VFS is not just faster. It is a richer primitive. It gives you the familiar interface of ls and cat while adding the capabilities that agents actually need: versioning, permissions, search, deduplication, and protocol-native access via MCP or HTTP.

What This Means for RAG

To be clear, RAG is not dead. Vector search remains valuable for fuzzy, semantic queries where the agent genuinely does not know what it is looking for. But the honest assessment is that RAG has been over-applied. Many of the use cases where teams deployed RAG pipelines, documentation retrieval, codebase navigation, enterprise knowledge management, are better served by a filesystem interface.

The evidence is striking. Mintlify’s 460x speedup came from replacing RAG with a filesystem, not augmenting it [1]. Research from Letta shows that agents using simple filesystem operations achieve 74% accuracy on memory benchmarks, competitive with specialized retrieval tools. And agentic keyword search approaches can achieve over 90% of RAG performance without vector databases at all [5].

The future is likely hybrid. RAG for open-ended semantic search. Filesystem for structured navigation and task execution. But the center of gravity is shifting toward the filesystem, and the strategic implications are significant.

The Strategic Imperative

If you are building agentic infrastructure, you need a VFS strategy. Here is why.

For SaaS companies: the lesson from Box is that the filesystem is becoming the integration surface for agents. If your platform’s content is not navigable as a filesystem, agents will bypass you. The SaaS companies that expose their data through filesystem-like interfaces will become part of the agentic workflow. Those that do not will become invisible to agents, which means invisible to users.

For infrastructure vendors: the database is not going away. It is moving underneath the filesystem. This is actually good news for database companies. Turso understood this and built AgentFS on top of SQLite. Every agent that spins up creates a new database. The more agents the world runs, the more databases the world needs. But the database needs to disappear behind a filesystem abstraction.

For enterprises: the governance story is what matters. Box’s pitch is not really about filesystems. It is about the fact that their permission model, audit trail, and compliance infrastructure automatically extends to agents when content is accessed through the VFS layer [3]. This is the answer to the question every CISO is asking: “How do we let agents access our content without creating a security nightmare?”

The Unifying Layer

The agentic infrastructure stack has been evolving in clear phases: tools (MCP), skills, and context graphs. The virtual filesystem fits into this arc as the delivery mechanism for all three. MCP tools are invoked through the filesystem. Skills are stored as files. Context graphs are navigated as directory trees. The filesystem does not replace these layers. It unifies them behind a single, familiar interface.

This is the real insight. The filesystem is not a new idea. It is the oldest abstraction in computing. But that is exactly why it works for agents. In a world where we are inventing new paradigms every quarter, the most powerful move might be reaching back to the most proven interface we have and putting a modern database behind it.

The companies that understand this, Mintlify, Turso, Box, ByteDance, are not building something new. They are recognizing something old and giving it a new job.

References:

[1] Mintlify. (2026, April 2). How we built a virtual filesystem for our Assistant. Mintlify Blog.

[2] Turso. (2026). The Missing Abstraction for AI Agents: The Agent Filesystem. Turso Blog.

[3] Blocks and Files. (2026, March 9). Box pitches ‘virtual filesystem’ layer for AI agents. Blocks and Files.

[4] Volcengine. (2026). OpenViking: An open-source context database for AI Agents. GitHub.

[5] Signals. (2026, February). Keyword Search is All You Need: Achieving RAG-Level Performance Without Vector Databases Using Agentic Tool Use. Signals.

[6] Subramanya N. (2026). markdownfs: A high-performance, concurrent markdown database built in Rust. GitHub.

The SaaSpocalypse: A Survival Guide

Mon, 23 Feb 2026 00:00:00 +0000

It started with a single press release. On January 30, 2026, AI startup Anthropic announced 11 specialized plugins for its Claude Cowork agent, empowering it to handle complex workflows in sales, finance, legal, and HR [1]. Wall Street’s reaction was not just negative; it was apocalyptic. In the week that followed, nearly $1 trillion in value was wiped from software and services stocks in a sell-off so brutal, Jefferies traders coined a new term for it: the “SaaSpocalypse” [2, 3].

Thomson Reuters suffered its biggest single-day drop on record (-15.8%), LegalZoom plunged nearly 20%, and established giants like Atlassian and Intuit saw their valuations crumble by 50% and 34% respectively since the start of the year [4, 5]. The panic was clear: if an AI agent can do the job of your software, why would anyone pay for your software?

This is more than a market correction. It’s a referendum on the entire Software-as-a-Service model. But is it truly an apocalypse, or is it a long-overdue reckoning? And for the thousands of founders, employees, and investors in the SaaS ecosystem, a more urgent question looms: how do you survive?

The Great Divide: Two Competing Realities

The market is now split into two warring camps, each with a compelling narrative.

Camp 1: The End Is Nigh

This camp believes the threat is existential. The core of their argument is the death of the per-seat pricing model. As Morningstar analysts bluntly put it, “if one person can now do the work of two, seat counts fall” [5]. Why pay for 500 Salesforce seats when 450 employees and an AI agent can do the same work? This isn’t a hypothetical; Salesforce CEO Marc Benioff has already stated the company won’t be hiring more engineers, customer service agents, or lawyers precisely because of AI’s capabilities [4].

Anthropic CEO Dario Amodei predicts AI could displace half of all entry-level white-collar jobs in the next five years, and OpenAI CEO Sam Altman has warned that AI will be “quite harmful” to some traditional software companies [4, 6]. For this camp, the math is simple: fewer employees and more capable AI means less revenue for traditional SaaS.

Camp 2: The Panic Is Illogical

On the other side, a powerful contingent of tech leaders argues the panic is a massive overreaction. Nvidia CEO Jensen Huang called the notion that AI will replace the software industry “the most illogical thing in the world,” while Arm Holdings CEO Rene Haas dismissed the sell-off as “micro-hysteria” [7].

Their argument, articulated well by Bernard Golden, CEO of Navica, is threefold [8]:

Enterprise DIY Will Fail: Building real software requires far more than just code. It demands deep domain expertise, regulatory knowledge, global support, and legal indemnification—things AI can’t replicate.
Incumbents Have Moats: Established players have network effects, scale, and deep, custom integrations that startups can’t easily displace.
Jevons Paradox: As AI makes software cheaper and easier to create, the demand for it won’t shrink—it will explode. Cheaper software will lead to vastly more software, not less.

The Survival Playbook

So, who is right? The truth, as analyzed by firms like Bain & Company and The Guardian, lies in the middle. Disruption is mandatory, but obsolescence is not [5, 9]. Survival depends on a clear-eyed assessment of your company’s position and a swift, decisive pivot. Here is the emerging survival guide.

1. Defend Your Moat

The companies weathering the storm are not the ones fighting AI, but the ones with unique, defensible assets that AI can’t easily replicate. The four critical moats are:

Moat Type	Description	Example
Proprietary Data	Data that is unique to your customers and not publicly available. AI models are trained on public data; they can’t access your private, firewalled customer information.	A vertical SaaS for pharmaceutical research with years of private clinical trial data.
Complex Systems	Deeply embedded, mission-critical workflows that are core to a business’s operations. The cost and risk of ripping out these systems are too high.	Oracle’s ERP systems, ServiceNow’s IT service management platform.
Network Effects	Platforms where the value increases as more users join. The classic example is a marketplace, but it also applies to collaborative software.	A procurement platform that connects thousands of buyers and suppliers.
Deep Integration	Software that is intricately woven into a customer’s tech stack, with numerous custom APIs and data connections.	A manufacturing execution system tied into a factory’s physical hardware.

If your product relies solely on analyzing public data or performing a task that can be replicated by a generic AI agent, you are in the kill zone.

2. Embrace the New Pricing Model: The Outcome Economy

The per-seat license is dying. The future is outcome-based pricing. Your customers no longer want to pay for access to your tool; they want to pay for the result it delivers. As a recent BVP report notes, AI-native companies are abandoning seat-based pricing almost entirely [10].

The Old Model: $150 per user per month.
The New Model: $0.99 per resolved customer issue, $5 per generated lead, or 1% of the cost savings achieved.

This is not theoretical. Intercom’s AI agent, Fin, is already at a $100M+ revenue run rate by charging per resolution. This model aligns your success directly with your customer’s success. It’s a harder model to build, but a far more defensible one.

3. Become the Trusted Incumbent

Here lies the greatest advantage for existing SaaS companies. In a world of black-box AIs, trust is the scarcest resource. A Bain & Company survey found that customers would prefer to buy AI-enabled solutions from their incumbent vendors [9]. They trust their security, their reliability, and their longevity.

The challenge is that most incumbents have been slow to deliver compelling AI offerings. The opportunity is massive for those who can integrate AI deeply into their existing, trusted products. Don’t just add an AI chatbot in the corner; use AI to supercharge your core workflow and deliver a 10x better outcome.

The SaaSpocalypse is not an extinction-level event for everyone. It is a cleansing fire. The companies that will be wiped out are the ones selling undifferentiated, easily-replicated features. The companies that survive—and thrive—will be the ones with deep moats, customer trust, and a business model built for the new outcome-based economy.

References:

[1] Anthropic’s new AI tool sends shudders through software stocks

[2] Selloff wipes out nearly $1 trillion from software and services stocks

[3] ‘Get me out’: Traders dump software stocks as AI fears erupt

[4] AI fears pummel software stocks: Is it ‘illogical’ panic or a SaaS apocalypse?

[5] Is the share market headed toward a ‘SaaS-pocalypse’?

[6] AI to change nature of software industry; will be bad for some companies: Sam Altman

[7] AI fears pummel software stocks: Is it ‘illogical’ panic or a SaaS apocalypse?

[8] The AI software freakout is a massive overreaction. Here’s why.

[9] Why SaaS Stocks Have Dropped—and What It Signals for Software’s Next Chapter

[10] The AI pricing and monetization playbook

2026: The Year SaaS Disappeared Into the Conversation

Thu, 19 Feb 2026 00:00:00 +0000

What if the best user interface was no interface at all? For decades, we have been trained to navigate a labyrinth of menus, buttons, and settings screens. We learned the language of software. In 2026, that paradigm is finally flipping. Software is learning to speak our language.

This is not just about adding a chatbot to a dashboard. A quiet revolution is underway: Software as a Service (SaaS) is no longer a destination and is becoming a capability accessed through natural language. The primary interface for getting work done is shifting from graphical (GUI) to conversational (CUI) and, increasingly, to voice. As a recent analysis in Harvard Business Review noted, the goal is no longer to automate the past but to orchestrate a new, more dynamic future where intelligent agents assemble novel workflows in real time, unconstrained by human org charts [1].

Meet Your New Coworker: The Personalized AI Agent

At the heart of this transformation is the move from generic, one-size-fits-all tools to deeply personalized AI agents that act as expert coworkers. These agents do not just access public data; they understand your world. As Goldman Sachs CIO Marco Argenti declared in January 2026, “Context is the new frontier,” signaling the rise of personal agents that know your context and can act on your behalf [2].

This trend has accelerated across the enterprise landscape in just the first two months of the year:

Glean launched its latest AI Assistant on February 17, positioning it as an “expert agentic coworker” powered by a “Personal Graph” that understands an employee’s role, projects, and collaborators to move from insight to execution [3].
Microsoft announced on January 30 that M365 Copilot can reference a user’s “memory” in voice chats, using stored personalization settings for more relevant responses [4].
Slack, on January 29, relaunched Slackbot as a “personal, context-aware AI agent for work,” designed to be the teammate that was “in the meeting with you,” saving users at least 90 minutes per day by internal estimates [5].
Atlassian followed on January 30, declaring that “teammate agents are what’s hot in 2026” and showcasing Rovo AI, which pulls context from project trackers, code repositories, and third-party apps to act as a core member of the team [6].
Google introduced “Personal Intelligence” for Search on January 22, connecting AI with private Gmail and Photos data to deliver tailored recommendations and turn a public utility into a personal concierge [7].

This shift is significant enough to create a new software category. The viral open-source project OpenClaw showcased a personal AI that could run locally and control user apps, eventually leading to its creator being hired by OpenAI [8]. It hints at the end of app sprawl: why juggle a dozen tools when one intelligent agent can coordinate calendars, tasks, and research?

The Rise of Voice: Don’t Type, Just Speak

The conversational interface reaches its strongest expression through voice. As Forbes argued, voice is becoming the defining UI of the AI era [9]. Tools like Wispr Flow are advancing this concept with a universal voice input layer that works across applications and turns speech into polished text at up to 220 words per minute [10]. It is not an app you switch into; it is a layer that sits on top of everything.

This is not a niche behavior. A 2026 Voices.com report found that 55% of consumers now use voice to interact with AI, while only 29% of companies have deployed voice AI, exposing a clear gap between user behavior and enterprise adoption [11]. VentureBeat described this transition as a move from “chatbots that speak” to “empathetic interfaces” that understand nuance and intent [12]. That is why every major SaaS player is moving quickly to add voice.

The graphical interface is not disappearing. Complex visualization, creative design, and exploratory analysis still benefit from visual canvases. The future is a hybrid model where voice and conversation handle routine tasks while GUI surfaces are used for specialized work, potentially generated on the fly by AI for each specific need.

The “SaaSpocalypse” and the New Business Model

This shift is fueling what some call a “SaaSpocalypse.” A February 2026 Fortune report noted that $2 trillion had been wiped from software stocks as AI pressures traditional SaaS models [13]. The conventional per-seat, per-month model is weakening. As Goldman Sachs noted, we are entering an “agent-as-a-service economy” where organizations deploy fleets of agents and pay by token consumption rather than human time [2].

In its place, a new model is emerging: outcome-based pricing. Intercom’s AI agent Fin is a strong example. Customers pay for results ($0.99 per resolved issue), not software access. Fin now handles over 80% of support volume and has grown past $100M ARR, demonstrating the economic power of this model [14].

Welcome to the Post-App Era

The pieces are now in place. Personalized, agentic AI and voice-first interfaces are dissolving the traditional SaaS model. The center of gravity is shifting from features to outcomes and from clicks to conversations.

The key question is no longer “Which app should I use?” but “What do I want to accomplish?” In 2026, for the first time, software is ready to answer directly.

References:

[1] Harvard Business Review. (2026, February). A Blueprint for Enterprise-Wide Agentic AI Transformation.

[2] Goldman Sachs. (2026). What to Expect From AI in 2026: Personal Agents, Mega Alliances.

[3] Glean. (2026, February 17). Glean’s Latest AI Assistant Moves Every Employee from Insight to Execution.

[4] Microsoft Tech Community. (2026, January). What’s New in Microsoft 365 Copilot.

[5] Slack. (2026, January). Introducing Slackbot, Your Context-Aware AI Agent for Work.

[6] Atlassian. (2026, January). AI Takes a Seat on the Team.

[7] Google. (2026, January). Google Brings Personal Intelligence to AI Mode in Search.

[8] TechCrunch. (2026, February 15). OpenClaw Creator Peter Steinberger Joins OpenAI.

[9] Forbes. (2026, February). Is Voice Becoming the UI of the AI Era?.

[10] Wispr Flow. (2026). Effortless Voice Dictation.

[11] Voices.com. (2026). Amplified 2026: The State of Voice and the Trends Shaping the Industry.

[12] VentureBeat. (2026). Everything in Voice AI Just Changed.

[13] Fortune. (2026, February 13). SaaSpocalypse: Why $2 Trillion Got Wiped From Software Stocks.

[14] GTM Now. (2026). How Intercom Built a $100M AI Agent with Outcome Pricing.

OpenClaw and the Rise of User-Built Intelligence: A Wake-Up Call for SaaS

Sun, 01 Feb 2026 00:00:00 +0000

In the last few weeks, the AI community has been captivated by a project that is not a new model, but a new paradigm. OpenClaw, an open-source personal AI assistant, has exploded in popularity, amassing over 114,000 GitHub stars in just two months [1]. Andrej Karpathy, one of the most respected voices in AI, described it as “genuinely the most incredible sci-fi takeoff-adjacent thing I have seen recently” [2].

This is not just another AI tool. OpenClaw represents a fundamental shift in how users interact with software, and it is a direct challenge to the traditional SaaS model. While SaaS platforms have spent a decade becoming the systems of record for business data, users are now building their own intelligence layers on top, turning incumbent platforms into dumb data pipes. This is the wake-up call for every SaaS company.

You know what's crazy about @openclaw... It will actually be the thing that nukes a ton of startups, not ChatGPT as people meme about... The fact that it's hackable (and more importantly, self-hackable) and hostable on-prem will make sure tech like this DOMINATES conventional SaaS imo
— Max Rovensky (@MaxRovensky) January 2026

The Ambient AI Revelation

What makes OpenClaw so significant? It’s not the technology itself, which is a clever combination of existing tools. As one analyst put it, OpenClaw’s innovation was to give an AI model “its own computer and told it to act like a personal assistant” [4].

The real breakthrough is the validation of a new form factor for AI: ambient, proactive intelligence. Unlike every major AI tool today - ChatGPT, Copilot, even your own internal copilots - which require a human in the loop, OpenClaw is designed to act autonomously. It runs 24/7, even when you’re asleep, watching for things that matter and taking action on your behalf. As one writer noted, “Claude Code knows your codebase. OpenClaw knows your life” [4].

This flips the current SaaS paradigm on its head. SaaS platforms are systems of record, but they are blind to the process of the business. They capture the nouns, but not the verbs. This is the “System of Record Trap.” Your CRM knows your customer data, but it doesn’t know the informal follow-up sequence your top salesperson uses. Your project management tool knows your deadlines, but it doesn’t know the complex triage process your team uses to handle incoming requests. This is the value that is being left on the table, and it’s the value that tools like OpenClaw are now capturing.

More Than a Toy: What Users Are Actually Building

If you think this is just a developer toy, you are mistaken. The community around OpenClaw is building and sharing thousands of “skills” that give their agents real-world capabilities. As chronicled by Simon Willison, users are already using OpenClaw to [1]:

Buy a car by negotiating with multiple dealers over email.
Remotely control an Android phone to scroll through TikTok or use Google Maps.
Monitor a server for security threats, detecting failed SSH login attempts and exposed ports.
Transcribe voice messages by finding an API key and using it to call the Whisper API.

These are not simple automations. They are complex, multi-step workflows that are being built and executed outside of any traditional SaaS platform. The value being unlocked is so compelling that users are willing to accept significant security risks, a phenomenon Simon Willison calls the “Normalization of Deviance” [1]. People are buying dedicated Mac Minis just to run OpenClaw in a sandboxed environment, a clear signal of the demand for this new paradigm.

The SaaS Dilemma: Build or Be Bypassed

This is the existential threat to SaaS. Every workflow built in OpenClaw is a workflow that is not being captured by the underlying SaaS platform. Every decision made by a personal AI agent is a decision that the SaaS vendor has no visibility into. The SaaS platform becomes a commodity data layer, a “dumb data pipe,” while the intelligence, the context, and the customer relationship move to the agentic layer.

The only durable defense is to build a native intelligence layer that allows users to automate their workflows directly within the platform. This journey from reactive software to proactive intelligence unfolds in three stages.

Stage	Description	User Experience
1. User-Built Automation	Users can describe their goals in natural language, and the platform builds and runs the automation workflow natively.	“When a new maintenance request comes in, check if it’s urgent. If so, text the on-call vendor.”
2. Pattern Learning	The platform analyzes workflow usage across its user base to identify common patterns and best practices.	The platform notices that responding to requests within 4 hours boosts tenant retention by 40% and suggests this workflow to other users.
3. Proactive Delivery	The platform learns individual user patterns and proactively delivers personalized automation, anticipating needs before the user even asks.	A property manager logs in to find the weekend’s maintenance requests already triaged, assigned, and with draft notifications ready for approval.

This evolution transforms a SaaS product from a passive tool into an active partner, creating a powerful moat built on compounded knowledge of user behavior. The more users automate, the smarter the platform becomes, and the harder it is for competitors to replicate.

The Time to Act is Now

The path forward for SaaS leaders is clear, and the timeline is short. The technological pillars are now in place: reliable function-calling models, long context windows, and universal standards like the Model Context Protocol (MCP) are mature and widely adopted. The enterprise demand has been validated by the explosive growth of platforms like Salesforce Agentforce, which generated $900 million in revenue in its first six months.

The choice for SaaS vendors is stark: either build a native intelligence layer or risk becoming a commoditized backend for your users’ personal AI agents. The era of passive, reactive software is over. The agentic workspace is the new strategic imperative, and the time to build it is now.

References:

[1] Willison, S. (2026, January 30). Moltbook is the most interesting place on the internet right now. Simon Willison’s Weblog.

[2] Karpathy, A. (2026, January 30). Tweet on X.

[3] Rovensky, M. (2026, January 12). Tweet on X.

[4] Hwang, J. (2026, January 31). The Ambient AI Era: Clawdbot (OpenClaw)’s Ripple Effects. Nextword.

The Agentic Workspace: A Strategic Imperative for the Next Era of SaaS

Mon, 19 Jan 2026 00:00:00 +0000

The SaaS landscape is at a critical inflection point. The traditional, human-driven application model is giving way to a new paradigm: the agentic workspace. This is not a distant trend, but a strategic imperative for today. We propose that the next evolution for every successful SaaS company is to become a platform that orchestrates intelligent agents to achieve user outcomes. This transition is complex and fraught with challenges, but for those who navigate it successfully, the rewards will be immense. Those who fail to adapt risk being left behind.

The convergence of SaaS and AI agents is reshaping the enterprise software landscape

The Decline of Seat-Based SaaS Dominance

The traditional SaaS model, built on per-user licensing and incremental feature updates, is facing unprecedented pressure. The rise of powerful, autonomous AI agents is beginning to render this model insufficient. As one industry analyst put it, “In three years, any routine, rules-based digital task could move from ‘human plus app’ to ‘AI agent plus API’” [2]. This fundamental change has exposed the vulnerabilities of the old guard and paved the way for a new generation of AI-native startups.

These startups, unburdened by legacy systems, are operating with unprecedented efficiency. As highlighted in recent analysis [5], AI-native firms are averaging $3.48 million in revenue per employee—a staggering 5.7 times more than their traditional SaaS counterparts. This efficiency gap is a clear signal of a major market shift.

AI-native startups are averaging $3.48M revenue per employee — 5.7x more than traditional SaaS companies

Six Pressures Reshaping the SaaS Model

Drawing inspiration from analysis by Cloud.Substack [5], the decline of the traditional model can be attributed to six interconnected pressures:

Pressure Point	Description & Example
Seat Expansion Stall	The primary growth engine for SaaS has sputtered. For example, Zoom, once a paragon of high NRR, saw its enterprise NRR fall to 98% as customers no longer needed to add seats at the same pace [5].
Price Increases Consuming Budget	SaaS inflation is running at nearly 5x the market rate, with price hikes consuming a significant portion of incremental IT budgets. This leaves little room for new investments and creates a cycle of vendor consolidation [5].
The Shift to AI Budgets	Enterprise spending is decisively moving towards AI. With leaders expecting a 75% growth in their LLM budgets, if a product isn’t tapping into this new pool of capital, it’s competing for a shrinking one [5].
The Speed of Innovation	The pace of development has accelerated dramatically. AI-native startups are shipping new features weekly, while traditional SaaS companies are often stuck in quarterly release cycles. This speed differential is a critical competitive advantage.
Single-Product Plateau	The multi-product suite strategy is losing its effectiveness. Customers increasingly prefer best-in-class point solutions, and are less willing to accept a suite of mediocre products from a single vendor [5].
The Value-Add Test	Many early AI features have been underwhelming. The bar for AI integration is now genuine productivity gains, not incremental improvements. Features must deliver measurable, tangible value to justify their cost and complexity [5].

Acknowledging the Obstacles on the Path to Autonomy

While the promise of agentic AI is immense, the path to full autonomy is not without significant challenges. Acknowledging these hurdles is crucial for a credible strategy.

Reliability and Trust: Agentic systems still struggle with reliability. Hallucinations, where an AI generates false information, remain a key concern. According to a recent McKinsey report, 80% of organizations have already encountered risky behaviors from AI agents, including improper data exposure and unauthorized system access [7]. Building robust validation and human-in-the-loop systems is essential.
The Incumbent’s Moat: Large SaaS players like Salesforce and Microsoft have powerful distribution channels and are actively acquiring promising agent startups. Their deep enterprise integrations and existing customer relationships provide a significant defensive moat that shouldn’t be underestimated.
The Economics of AI: Many AI-native startups are currently operating with a high burn rate, spending heavily on tokens and compute power with an unclear path to profitability. Industry estimates suggest that inference costs can consume 30-50% of gross margins for agent-heavy applications, and the long-term economic viability of these models is still being tested.

The New Moat: Capturing the ‘Why’ with Context Graphs

Despite the challenges, the strategic advantage of becoming an agentic platform is undeniable. The new competitive moat is the Context Graph: a living record of decision traces that explains not just what happened, but why it was allowed to happen [6].

Agents don’t just need rules. They need access to the decision traces that show how rules were applied in the past, where exceptions were granted, how conflicts were resolved, who approved what, and which precedents actually govern reality. [6]

While traditional systems of record store data about objects (like customers or invoices), context graphs create a system of record for decisions. They capture the exceptions, overrides, and precedents that currently live in siloed communications.

Context graphs capture the decision traces that explain not just what happened, but why

This creates a powerful feedback loop. The companies that provide the agentic execution layer are the only ones who can capture these decision traces. As their context graphs grow, their agents become smarter and more reliable, creating a defensible advantage that is nearly impossible for competitors to replicate.

Evolving Business Models for the Agentic Era

This transformation requires a radical rethinking of business models. The seat-based license is being replaced by new models that align price with the value AI agents deliver.

Pricing Model	Description & Example
Usage-Based: Resources	Customers pay for the compute and token resources they consume. Example: A developer platform charges based on the number of API calls and GPU hours used by its agents.
Agent-Based	Customers purchase or subscribe to individual AI agents with specific skills. Example: An e-commerce platform sells a “Pricing Optimization Agent” for a monthly fee.
Usage-Based: Interactions	Customers are charged per discrete interaction or completed task. Example: A customer service platform charges per successfully resolved support ticket.
Outcome-Based: Jobs Completed	Payment is tied to the successful execution of a predefined job. Example: A sales automation platform charges a fee for each qualified lead its agents generate.
Outcome-Based: Financial Pricing	The most advanced model, where payment is a percentage of the financial value created. Example: A marketing automation platform takes a share of the revenue generated from campaigns run by its agents.

What Winners Will Look Like

Beyond the tech giants, a new class of winners is emerging. These companies are not just building features; they are building agentic workspaces. Glean is creating enterprise search agents that can query across dozens of enterprise tools to answer complex questions autonomously—replacing hours of manual research with seconds of agent-driven synthesis. Adept AI is building general-purpose agents that can learn to use any software application through observation and interaction. Meanwhile, Sierra is pioneering conversational AI agents for customer experience that can resolve issues end-to-end without human handoff. These pioneers are demonstrating the power of focusing on autonomous, outcome-driven workflows rather than incremental feature additions.

The Strategic Imperative to Act Now

The evidence is clear. The convergence of market pressures, from stalled seat expansion to the rise of hyper-efficient AI-native competitors, points to a single conclusion: the future of SaaS is the agentic workspace. This is no longer a question of ‘if,’ but ‘when.’ The companies that act now—that begin the work of transforming their platforms into orchestrators of intelligent agents and capturing the invaluable context graphs that power them—will be the leaders of the next decade.

Where to start? Audit your core workflows for agentic potential: identify the repetitive, rules-based processes where human judgment is minimal but human time is maximal. Then pilot context capture in one high-value process—every decision trace you record today becomes training data for tomorrow’s autonomous agents.

The choice is simple: build the future, or be relegated to the past. The time to build your agentic workspace is now.

References:

[1] Deloitte. (2025, November 18). SaaS meets AI agents: Transforming budgets, customer experience, and workforce dynamics. Deloitte Insights.

[2] Bain & Company. (2025, September 23). Will Agentic AI Disrupt SaaS? Bain & Company.

[3] Forbes. (2026, January 15). Are SaaS Moats Real Or AI Mirage? The Great Enterprise Software Debate. Forbes.

[4] BCG. (2025, August 13). Rethinking B2B Software Pricing in the Era of AI. BCG.

[5] Cloud.Substack. (2026, January 17). The 6 Threat Vectors Killing Traditional B2B Software in 2026 (And How to Fight Back). Cloud.Substack.

[6] Foundation Capital. (2025, December 22). AI’s trillion-dollar opportunity: Context graphs. Foundation Capital.

[7] McKinsey & Company. (2025, October 16). Deploying agentic AI with safety and security: A playbook for technology leaders. McKinsey & Company.

Context Graphs Are a Trillion-Dollar Opportunity. But Who Actually Captures It?

Wed, 14 Jan 2026 00:00:00 +0000

The concept of Context Graphs, first articulated by Jaya Gupta of Foundation Capital, has rapidly captured the industry’s imagination [1]. The thesis is that the next trillion-dollar enterprise platforms will not be systems of record for data, but systems of record for decisions. For the underlying definition, see my explainer on what are context graphs.

The thesis is compelling. But the most pressing question remains: who actually captures this trillion-dollar opportunity?

The answer, I believe, is hiding in plain sight. It is not in the data warehouses or the CRMs. It is in the agentic tools that are already operating in the wild, in the execution path, generating decision traces every second. And the most advanced and widely discussed of these tools, Anthropic’s Claude Code and the newly released Claude Cowork, provide a fascinating, real-world case study of both the immense potential and the critical, missing piece.

The Agents in the Arena: Claude Code and Cowork

On January 12, 2026, Anthropic launched Claude Cowork, a desktop agent that extends the power of its developer-focused Claude Code tool to non-technical users [2]. This was not just another feature release. It was a statement. While the industry has been debating the future of agentic workflows, Anthropic has been shipping them.

What makes Claude Code and Cowork so different is that they are not just chatbots; they are doers. They operate within a designated folder on your computer, with the ability to read, write, and create files. They can take a messy folder of receipts and turn it into a structured expense report. They can take scattered notes and draft a coherent document. They are, in short, executing complex, multi-step tasks that generate a rich history of decisions.

Perhaps the most stunning demonstration of this was the revelation that Claude Cowork itself was built almost entirely by Claude Code in about a week and a half. Think about that. An AI agent planned and executed the creation of a new software product. This is not a theoretical exercise; it is a real-world, complex decision trace of immense value.

The Irony: Generating Traces, But Not Capturing Them

Every time a developer uses Claude Code to refactor a codebase, or a project manager uses Claude Cowork to organize a project folder, a decision trace is generated. The agent is walking the graph of the user’s intent, pulling context from different files, making decisions, and executing actions. It is creating the raw material of a context graph.

But where does that raw material go? It evaporates. It is ephemeral, living for a moment in the agent’s context window or the user’s chat history, but it is not persisted as a structured, queryable artifact. The why is lost, leaving only the what.

This is the central irony of the current agentic landscape. The most advanced agentic tools are the perfect instruments for creating context graphs, yet they are not being used for that purpose. They are generating a constant stream of valuable decision data that is simply being discarded.

The Ephemeral Nature of Decision Traces in Today’s Agents

Why Incumbents Can’t Just Add This Feature

Incumbents are structurally disadvantaged from capturing this opportunity. They are simply in the wrong place architecturally.

Systems of Record (Salesforce, Workday): These platforms are built to store the current state of an object. They know the deal is closed-won, but they do not have a record of the dozen steps, approvals, and exceptions that led to that outcome. They are in the wrong architectural layer.
Data Warehouses (Snowflake, Databricks): These platforms are in the read path, not the write path. They receive data via ETL after the decisions have been made and the context has been lost. They can tell you what happened, but they cannot tell you why.

Trying to retrofit decision trace capture onto these systems is like trying to understand a chess game by only looking at the final board position. You have lost the move-by-move history that contains all the strategic insight.

The Real Race: Who Builds the “Event Clock” for Agents?

So, who are the real contenders?

Contender	Strengths	Weaknesses
Anthropic (The Agent Provider)	Owns the agent and the execution path. In the pole position to build persistence directly into their products.	Not their core business. May see it as a feature, not a platform. Risks vendor lock-in for customers.
Orchestration Startups	Focused on the cross-system workflow layer where context is richest. Can be vendor-neutral, orchestrating agents from multiple providers.	Need to convince customers to adopt a new layer in their stack. Dependent on agent providers for core capabilities.

This brings us to a critical distinction. The goal is not to simply monitor agents. Agent observability and telemetry tools are useful for capturing the what—metrics, logs, and traces of execution. They can tell you an agent made 10 API calls and wrote 3 files. But they cannot tell you why.

A decision trace captures the reasoning, the context, and the precedents that led to an action. This is a fundamentally different and more valuable asset than telemetry. The trillion-dollar prize will go to whoever successfully builds the event clock for the agentic era—the system that captures the decision traces of every agent, human, and automated process in the enterprise. My bet is on a new category of company to emerge: one that is purpose-built to be this system of record for decisions.

From “Code” and “Cowork” to “Context”

Jaya Gupta was right. The opportunity is massive. But the winner will not be a better database or a smarter CRM. The winner will be the company that recognizes that the actions of agents like Claude Code and Cowork are not just outputs; they are assets. They are the building blocks of the enterprise’s collective intelligence.

For Anthropic, the path seems clear. The next logical product in their suite is not just a new skill or a new integration. It is Claude Context: a platform that captures, stores, and makes sense of every decision trace their agents generate. It would transform their tools from powerful productivity aids into an indispensable system of record for the modern enterprise.

Whether Anthropic seizes this opportunity or leaves the door open for a new wave of startups remains to be seen. But one thing is certain: the race to build the context graph is on, and the companies that are in the execution path of agentic work are the ones with the head start.

References:

[1] Gupta, J. (2025, December 22). AI’s trillion-dollar opportunity: Context graphs. Foundation Capital.

[2] Nuñez, M. (2026, January 12). Anthropic launches Cowork, a Claude Desktop agent that works in your files — no coding required. VentureBeat.

A Year with Cursor: How My Workflow Evolved from Agent to Architect

Sun, 04 Jan 2026 00:00:00 +0000

It’s been over a year since I made Cursor my primary IDE, and it’s hard to overstate the impact it’s had on my work. As a machine learning engineer building conversational AI platforms at Dylog and experimenting with agentic infrastructure on my personal projects, I’ve lived through the evolution of AI-native development. My journey with Cursor mirrors the maturation of the tool itself: from a simple agent to a sophisticated architectural partner.

This post is a reflection on that journey, detailing how my workflow evolved and how I’ve come to rely on a powerful combination of Plan Mode, custom commands, and context engineering to build faster, smarter, and with more clarity.

Phase 1: The Agent Takes the Wheel

When I first started, my usage was simple. I treated Cursor like a supercharged autocomplete. I’d write a comment, hit Cmd+K, and let the agent generate the code. It was magical, but it was also a black box. I was a passenger, and the agent was driving.

Then came the @ mentions. This was my first taste of giving the agent real context. Instead of hoping it understood my codebase, I could explicitly tell it what to look at:

@file to reference a specific file
@folder to include an entire directory
@codebase to let it search across the whole project
@web to pull in external documentation
@docs to reference official docs for libraries

This was a huge leap. Suddenly, the agent wasn’t guessing; it was working with the same context I had. I could say “refactor this function to match the pattern in @file:utils/helpers.ts” and it would actually understand.

The @ mention dropdown in Cursor, showing context options like @file, @folder, @codebase, @web, and @docs that allow explicit context control

But even with better context, I’d often find myself in a loop of generating, debugging, and regenerating. The agent lacked the architectural vision for larger tasks.

Phase 2: MCP Changes Everything

The introduction of Model Context Protocol (MCP) was when things got serious. MCP allowed me to connect Cursor to external tools and data sources, turning the agent from a code generator into a true assistant with access to my entire workflow.

I started integrating MCPs for:

GitHub for pulling issues and PRs directly into context
Linear for task management integration
Slack for team communication context
Custom MCPs for internal APIs and databases

With MCP, I could say “implement the feature described in Linear issue #234” and the agent would fetch the issue, understand the requirements, and start building. It was no longer just about code; it was about connecting the dots across my entire development ecosystem.

MCP configuration panel showing connected integrations like GitHub, Linear, Slack, and custom servers that extend Cursor’s capabilities across the development ecosystem

Phase 3: The Rise of the Planner

The introduction of Plan Mode was the next game-changer. It was the first time I felt like I was collaborating with the AI, not just delegating to it. Inspired by workflows from developers like Ray Fernando, I started using a two-step process:

Plan with Opus: I’d use a powerful model like Claude Opus to generate a detailed, step-by-step implementation plan. I’d give it the high-level goal, and it would break it down into a series of concrete tasks, complete with file names, function signatures, and logic.
Execute with Sonnet/GPT: I’d then hand that plan to a faster, cheaper model like Sonnet or GPT-5.2 to execute each step. The cheaper model didn’t need to be a brilliant architect; it just needed to be a diligent builder.

This workflow was a massive improvement. It separated the “what” from the “how,” and it gave me a reviewable artifact—the plan—that I could edit and approve before any code was written. It also saved a ton of money on tokens.

A split view showing a detailed implementation plan in a .cursor/plans/ file on the left, and the corresponding generated code on the right, demonstrating the separation of architecture from execution

Phase 4: The Architect Emerges (Commands + Planning)

This is where I live today. While Plan Mode is still central to my workflow, I’ve layered on a set of custom commands and rules to fine-tune the process and bake my architectural principles directly into the IDE.

My Current Setup

Rules (.cursorrules): I have a set of rules that define my coding standards, preferred patterns, and architectural constraints. The agent reads these before every task, ensuring consistency across the codebase.

Custom Commands: I’ve built commands that wrap my most common workflows:

/plan - Generates a detailed implementation plan using Opus
/refactor - Takes a file and refactors it based on instructions
/test - Generates a test suite for a given function
/review - Reviews code against my rules and suggests improvements

Queued Messages: I use Ctrl+Enter to queue follow-up instructions while the agent is working. This lets me think ahead and keep the momentum going without interrupting the current task.

The Cursor command palette showing custom commands like /plan, /refactor, /test, and /review, alongside a .cursorrules file that defines coding standards and architectural constraints

The Evolution at a Glance

Phase	Key Feature	What Changed
1	Agent Mode + @ Mentions	Context became explicit, not guessed
2	MCP Integration	External tools and data became accessible
3	Plan Mode	Architecture separated from execution
4	Commands + Rules	Workflows became repeatable and personalized

Why This Matters

This evolution from agent to architect is more than just a personal productivity hack. It’s a glimpse into the future of software development. We’re moving from a world where we write code to a world where we describe systems. Our job is to be the architect, to define the blueprint, and to let the agents do the building.

Cursor, more than any other tool I’ve used, understands this shift. It’s not just about generating code; it’s about managing complexity, maintaining context, and giving developers the leverage to build at a scale that was previously unimaginable.

If you’re still using AI as a simple code generator, I encourage you to explore @ mentions, MCP, Plan Mode, and custom commands. It’s a journey that will transform you from a developer who uses AI to an architect who directs it.

What Are Context Graphs, Really?

Thu, 01 Jan 2026 00:00:00 +0000

Last week, I wrote about my reaction to Jaya Gupta’s viral post on Context Graphs [1]. The idea of a “system of record for decisions” resonated deeply, framing the evolution of agentic infrastructure from tools to skills to memory. But since then, the conversation has exploded, and it has become clear that the term “context graph” itself is a bit of a Rorschach test. Everyone sees something different.

Animesh Koratana, founder of PlayerZero, has written a series of follow up posts that cut through the noise and get to the heart of what a context graph actually is, and why it is so structurally hard to build [2] [3]. His insights are critical for anyone serious about building agentic AI in the enterprise. This is not about “adding memory to your agent” or wiring up a graph database. It is about rethinking our assumptions about data, time, and the nature of organizational knowledge.

The Two Clocks Problem: Why We Are Missing Half of Time

Koratana’s most powerful insight is what he calls the Two Clocks Problem. We have built trillion dollar infrastructure for the state clock: what is true right now. Your CRM stores the final deal value. Your ticketing system stores “resolved.” Your codebase stores the current state.

But we have almost no infrastructure for the event clock: what happened, in what order, and with what reasoning. The git blame shows who changed the timeout from 5s to 30s, but the why is gone. The CRM says “closed lost,” but it does not say you were the second choice and the winner had one feature you are shipping next quarter. As Koratana puts it:

“We’ve built trillion-dollar infrastructure for what’s true now. Almost nothing for why it became true.”

This is the core of the problem. We are asking agents to exercise judgment without access to precedent. We are training lawyers on verdicts without case law. The context graph is the infrastructure for the event clock. It is the case law of the enterprise.

The Five Coordinate Systems Problem: Why This Is Not a Database Problem

So why can’t we just build a better database? Because a context graph requires joins across five different coordinate systems that do not share keys:

Events: What happened?
Timeline: When did it happen?
Semantics: What does it mean?
Attribution: Who owned it?
Outcome: What did it cause?

Each of these has a different geometry. Timelines are linear. Events are sequential. Semantics live in vector space. Attribution is graph structured. Outcomes are causal DAGs. And the keys are fluid. “Jaya Gupta” in an email, “J. Gupta” in a contract, and “@JayaGup10” in Slack are the same entity with no shared identifier.

Traditional databases are built for joins on stable keys within a single coordinate system. Context graphs require probabilistic joins across all five simultaneously. This is not a database problem; it is a representation problem.

Agents as Informed Walkers: How We Solve the Representation Problem

If the ontology of every organization is different and constantly changing, how can we ever hope to model it? Koratana’s answer is that we do not have to. The agents do it for us.

When an agent works through a problem, its trajectory is a trace through the state space of the organization. It is an implicit map of the ontology, discovered through use rather than specified upfront. This is the key insight from graph representation learning (node2vec): you do not need to know the structure of a graph to learn representations of it. You just need to walk it.

Agents are informed walkers. Their trajectories are not random; they are problem directed. By accumulating enough of these trajectories, we can learn embeddings that encode the structure of the organization. We can learn that two engineers who never interact are structurally equivalent because they play the same role in different subgraphs. We can learn that a certain sequence of events is a precursor to churn, even if those events have never been explicitly linked.

What This Actually Means for Builders

So, what is a context graph, really? It is not a graph database. It is not a vector store. It is a learned representation of organizational reasoning, derived from the trajectories of agents solving problems.

This has profound implications for how we build agentic systems:

The agents are not building the context graph; they are solving problems worth solving. The context graph is an emergent property of their work. The focus should be on deploying agents into real workflows, not on building a perfect ontology upfront.
The value is in the trajectories, not the state. We need to shift our focus from storing the final state to capturing the full, replayable history of how that state was reached.
This is a machine learning problem, not a data engineering problem. The goal is not to build a perfect data model, but to learn a representation that is useful for reasoning.

Building a context graph is not about buying a new piece of software. It is about a fundamental shift in how we think about data, time, and the nature of work in the agentic era. It is about recognizing that the most valuable asset we have is not our data, but the accumulated wisdom of the decisions we make every day. And it is about building the infrastructure to finally capture that wisdom and put it to work.

References:

[1] Gupta, J. (2025, December 23). AI’s trillion-dollar opportunity: Context graphs. X.

[2] Koratana, A. (2026, January 1). Why context graphs are rare in the wild. LinkedIn.

[3] Koratana, A. (2025, December 28). How to build a context graph. LinkedIn.

Context Graphs: My Thoughts on the Trillion Dollar Evolution of Agentic Infrastructure

Fri, 26 Dec 2025 00:00:00 +0000

After reading Jaya Gupta’s post about Context Graphs, I have not been able to stop thinking about it [1]. For me, it did something personal: it gave a name to the architectural pattern I have been circling around in the agentic infrastructure discussions on this blog for the past year. I later wrote a more direct explainer on what are context graphs and why the term means more than agent memory.

Gupta’s thesis is simple but profound. The last generation of enterprise software (Salesforce, Workday, SAP) created trillion dollar companies by becoming systems of record. Own the canonical data, own the workflow, own the lock in. The question now is whether those systems survive the shift to agents. Gupta argues they will, but that a new layer will emerge on top of them: a system of record for decisions.

I agree. And I think this is the missing piece that connects everything I have been writing about.

The Missing Layer: Decision Traces

What resonated most with me was Gupta’s articulation of the decision trace. This is the context that currently lives in Slack threads, deal desk conversations, escalation calls, and people’s heads. It is the exception logic that says, “We always give healthcare companies an extra 10% because their procurement cycles are brutal.” It is the precedent from past decisions that says, “We structured a similar deal for Company X last quarter, we should be consistent.”

None of this is captured in our systems of record. The CRM shows the final price, but not who approved the deviation or why. The support ticket says “escalated to Tier 3,” but not the cross system synthesis that led to that decision. As Gupta puts it:

“The reasoning connecting data to action was never treated as data in the first place.”

This is the wall that every enterprise hits when they try to scale agents. The wall is not missing data. It is missing decision traces.

From Tools to Skills to Context: The Evolution I Have Been Documenting

Reading Gupta’s post, I realized that the evolution I have been documenting on this blog (from MCP to Agent Skills to governance) is really a story about building the infrastructure for context graphs. Let me explain.

Phase 1 was about tools. The Model Context Protocol (MCP) gave agents the ability to interact with external systems. It was the plumbing that connected agents to databases, APIs, and the outside world. But we quickly learned that tool access alone is not enough. An agent with a hammer is not a carpenter.

Phase 2 was about skills. Anthropic’s Agent Skills standard gave us a way to codify procedural knowledge, the “how to” guides that teach agents to use tools effectively. Skills are the brain of the agent. They turn tribal knowledge into portable, composable assets. But even skills are not enough. An agent with a hammer and a carpentry manual is still not a master carpenter.

Phase 3 is about context. This is where context graphs come in. A context graph is the accumulated record of every decision, every exception, and every outcome. It answers the question, “What happened last time?” It turns exceptions into precedents and tribal knowledge into institutional knowledge.

Phase	Primitive	What It Provides	My Analogy
Phase 1	Tools (MCP)	Capability	The agent has a hammer.
Phase 2	Skills (Agent Skills)	Expertise	The agent has a carpentry manual.
Phase 3	Context (Context Graphs)	Experience	The agent has access to the record of every house it has ever built.

Why This Matters for the Governance Stack

The governance stack I have been advocating for (agent registries, tool registries, skill registries, policy engines) is the infrastructure that makes context graphs possible. The agent registry provides the identity of the agent making the decision. The tool registry (MCP) provides the capabilities available to that agent. The skill registry provides the expertise that guides the agent’s actions. And the orchestration layer is where the decision trace is captured and persisted.

Without this infrastructure, decision traces are ephemeral. They exist for a moment in the agent’s context window and then disappear. With this infrastructure, every decision becomes a durable artifact that can be audited, learned from, and used as precedent.

My Takeaway

Gupta is right that agent first startups have a structural advantage here. They sit in the execution path. They see the full context at decision time. Incumbents, built on current state storage, simply cannot capture this.

But the bigger insight for me is this: we are not just building agents. We are building the decision record of the enterprise. The context graph is not a feature; it is the foundation of a new kind of system of record. The enterprises that win in the agentic era will be those that recognize this and invest in the infrastructure to capture, store, and leverage their decision traces.

We started by giving agents tools. Then we taught them skills. Now, we must give them context. That is the trillion dollar evolution.

References:

[1] Gupta, J. (2025, December 23). AI’s trillion dollar opportunity: Context graphs. X.

2025: The Year Agentic AI Got Real (What Comes Next)

Tue, 23 Dec 2025 00:00:00 +0000

If 2024 was the year of AI experimentation, 2025 was the year of industrialization. The speculative boom around generative AI has rapidly matured into the fastest-scaling software category in history, with autonomous agents moving from the lab to the core of enterprise operations. As we close out the year, it’s clear that the agentic AI landscape has been fundamentally reshaped by massive investment, critical standardization, and a clear-eyed focus on solving the hard problems of production readiness.

But this wasn’t just a story of adoption. 2025 was the year the industry confronted the architectural limitations of monolithic agents and began a decisive shift toward a more specialized, scalable, and governable future.

The $37 Billion Build-Out: From Experiment to Enterprise Imperative

The most telling sign of this shift is the sheer volume of capital deployed. According to a December 2025 report from Menlo Ventures, enterprise spending on generative AI skyrocketed to $37 billion in 2025, a stunning 3.2x increase from the previous year [1]. This surge now accounts for over 6% of the entire global software market.

Crucially, over half of this spending ($19 billion) flowed directly into the application layer, demonstrating a clear enterprise priority for immediate productivity gains over long-term infrastructure bets. This investment is validated by strong adoption metrics, with a recent PwC survey finding that 79% of companies are already adopting AI agents [2].

Source: Menlo Ventures, 2025: The State of Generative AI in the Enterprise [1]

Solving the Interoperability Crisis: The Standardization of 2025

While the spending boom captured headlines, a quieter, more profound revolution was taking place in the infrastructure layer. The primary challenge addressed in 2025 was the interoperability crisis. The early agentic ecosystem was a chaotic landscape of proprietary APIs and fragmented toolsets, making it nearly impossible to build robust, cross-platform applications. This year, two key developments brought order to that chaos.

1. The Maturation of MCP

The Model Context Protocol (MCP), introduced in late 2024, became the de facto standard for agent-to-tool communication. Its first anniversary in November 2025 was marked by a major spec release that introduced critical enterprise features like asynchronous operations, server identity, and a formal extensions framework, directly addressing early complaints about its production readiness [3].

This culminated in the December 9th announcement that Anthropic, along with Block and OpenAI, was donating MCP to the newly formed Agentic AI Foundation (AAIF) under the Linux Foundation [4]. With over 10,000 active public MCP servers and 97 million monthly SDK downloads, MCP’s transition to a neutral, community-driven standard solidifies its role as the foundational protocol for the agentic economy.

The shift from fragmented, proprietary APIs to a unified, MCP-based approach simplifies agent-tool integration.

2. The Dawn of Portable Skills

Following the same playbook, Anthropic made another pivotal move on December 18th, opening up its Agent Skills specification [5]. This provides a standardized, portable way to equip agents with procedural knowledge, moving beyond simple tool-use to more complex, multi-step task execution. By making the specification and SDK available to all, the industry is fostering an ecosystem where skills can be developed, shared, and deployed across any compliant AI platform, preventing vendor lock-in.

The Next Frontier: The Rise of the Agent Workforce

These standardization efforts have unlocked the next major architectural shift: the move away from monolithic, general-purpose agents toward collections of specialized skills that function like a human team. No company hires a single “super-employee” to be a marketer, an engineer, and a financial analyst. They hire specialists who excel at their roles and collaborate to achieve a larger goal. The future of enterprise AI is the same.

This “multi-agent” or “skill-based” architecture is not just a theoretical concept. Anthropic’s own research showed that a multi-agent system—with a lead agent coordinating specialized sub-agents—outperformed a single, more powerful agent by over 90% on complex research tasks [6]. The reason is simple: specialization allows for greater accuracy, and parallelism allows for greater scale.

We are already seeing the first wave of companies built on this philosophy. YC-backed Getden.io, for example, provides a platform for non-engineers to build and collaborate with agents that can be composed of various skills and integrations [7]. This approach democratizes agent creation, allowing domain experts—not just developers—to build the specialized “digital employees” they need.

The Challenges of 2026: From Adoption to Governance

While 2025 solved the problem of connection, 2026 will be about solving the challenges of control and coordination at scale. As enterprises move from deploying dozens of agents to thousands of skills, a new set of problems comes into focus:

Governance at Scale: How do you manage access control, cost, and versioning for thousands of interconnected skills? The risk of “skill sprawl” and shadow AI is immense, demanding a new generation of governance platforms.
Reliability and Predictability: The non-deterministic nature of LLMs remains a major barrier to enterprise trust. For agents to run mission-critical processes, we need robust testing frameworks, better observability tools, and architectural patterns that ensure predictable outcomes.
Multi-Agent Orchestration: As skill-based systems become the norm, the primary challenge shifts from tool-use to agent coordination. How do you manage dependencies, resolve conflicts, and ensure a team of agents can reliably collaborate to complete a complex workflow? This is a frontier problem that will define the next generation of agentic platforms.
Security in a Composable World: A world of interoperable skills creates new attack surfaces. How do you secure the supply chain for third-party skills? How do you prevent a compromised agent from triggering a cascade of failures across a complex workflow? The security model for agentic AI is still in its infancy.

The groundwork laid in 2025 was monumental. It moved us from a world of isolated, experimental bots to the brink of a true agentic economy. But the journey is far from over. The companies that will win in 2026 and beyond will be those that master the art of building, managing, and securing not just agents, but entire workforces of specialized, collaborative skills.

References:

[1] Menlo Ventures. (2025, December 9). 2025: The State of Generative AI in the Enterprise. Menlo Ventures.

[2] PwC. (2025, May 16). PwC’s AI Agent Survey. PwC.

[3] Model Context Protocol. (2025, November 25). One Year of MCP: November 2025 Spec Release. Model Context Protocol Blog.

[4] Anthropic. (2025, December 9). Donating the Model Context Protocol and establishing the Agentic AI Foundation. Anthropic.

[5] VentureBeat. (2025, December 18). Anthropic launches enterprise ‘Agent Skills’ and opens the standard. VentureBeat.

[6] Anthropic. (2025, June 13). How we built our multi-agent research system. Anthropic Engineering.

[7] Y Combinator. (2025). Den: Cursor for knowledge workers. Y Combinator.

Agent Skills: The Missing Piece of the Enterprise AI Puzzle

Thu, 18 Dec 2025 00:00:00 +0000

The enterprise AI landscape is at a critical juncture. We have powerful general-purpose models and a growing ecosystem of tools. But we are missing a crucial piece of the puzzle: a standardized, portable way to equip agents with the procedural knowledge and organizational context they need to perform real work. On December 18, 2025, Anthropic took a major step towards solving this problem by releasing Agent Skills as an open standard [1]. This move, following the same playbook that made the Model Context Protocol (MCP) an industry-wide success, is not just another feature release—it is a fundamental shift in how we will build and manage agentic workforces.

The Problem: General Intelligence Isn’t Enough

General-purpose agents like Claude are incredibly capable, but they lack the specialized expertise required for most enterprise tasks. As Anthropic puts it, “real work requires procedural knowledge and organizational context” [2]. An agent might know what a pull request is, but it doesn’t know your company’s specific code review process. It might understand financial concepts, but it doesn’t know your team’s quarterly reporting workflow. This gap between general intelligence and specialized execution is the primary barrier to scaling agentic AI in the enterprise.

Until now, the solution has been to build fragmented, custom-designed agents for each use case. This creates a landscape of “shadow AI”—siloed, unmanageable, and impossible to govern. What we need is a way to make expertise composable, portable, and discoverable. This is exactly what Agent Skills are designed to do.

The Solution: Codified Expertise as a Standard

At its core, an Agent Skill is a directory containing a SKILL.md file and optional subdirectories for scripts, references, and assets. It is, as Anthropic describes it, “an onboarding guide for a new hire” [2]. The SKILL.md file contains instructions, examples, and best practices that teach an agent how to perform a specific task. The key innovation is progressive disclosure, a three-level system for managing context efficiently:

Metadata: At startup, the agent loads only the name and description of each installed skill. This provides just enough information for the agent to know when a skill might be relevant, without flooding its context window.
Instructions: When a skill is triggered, the agent loads the full SKILL.md body. This gives the agent the core instructions it needs to perform the task.
Resources: If the task requires more detail, the agent can dynamically load additional files from the skill’s scripts/, references/, or assets/ directories. This allows skills to contain a virtually unbounded amount of context, loaded only as needed.

This architecture is both simple and profound. It allows us to package complex procedural knowledge into a standardized, shareable format. It solves the context window problem by making context dynamic and on-demand. And by making it an open standard, Anthropic is ensuring that this expertise is portable across any compliant agent platform.

Component	Purpose	Context Usage
Metadata (`name`, `description`)	Skill discovery	Minimal (loaded at startup)
Instructions (`SKILL.md` body)	Core task guidance	On-demand (loaded when skill is activated)
Resources (`scripts/`, `references/`)	Detailed context and tools	On-demand (loaded as needed)

Skills vs. MCP: The Brain and the Plumbing

It is crucial to understand how Agent Skills relate to the Model Context Protocol (MCP). They are not competing standards; they are complementary layers of the agentic stack. As Simon Willison aptly puts it, “MCP provides the ‘plumbing’ for tool access, while agent skills provide the ‘brain’ or procedural memory for how to use those tools effectively” [3].

MCP tells an agent what tools are available. It is the API that connects agents to databases, APIs, and other external systems.
Agent Skills teach an agent how to use those tools. They provide the procedural knowledge, best practices, and organizational context required to perform complex, multi-step tasks.

For example, MCP might give an agent access to a git tool. An Agent Skill would teach that agent your team’s specific git branching strategy, pull request template, and code review checklist. One provides the capability; the other provides the expertise. You need both to build a truly effective agentic workforce.

Why an Open Standard Matters for the Enterprise

By releasing Agent Skills as an open standard, Anthropic is making a strategic bet on interoperability and ecosystem growth. This move has several critical implications for the enterprise:

It Prevents Vendor Lock-In: An open standard for skills means that the expertise you codify is not tied to a single agent platform. You can build a library of skills for your organization and deploy them across any compliant agent, whether it’s from Anthropic, OpenAI, or an open-source provider.
It Creates a Marketplace for Expertise: We will see the emergence of a marketplace for pre-built skills, both open-source and commercial. This will allow organizations to acquire specialized capabilities without having to build them from scratch.
It Accelerates Adoption: A standardized format for skills makes it easier for developers to get started and for organizations to share best practices. This will accelerate the adoption of agentic AI and drive the development of more sophisticated, multi-agent workflows.

The Road Ahead: Governance and the Ecosystem

The Agent Skills specification is, as Simon Willison notes, “deliciously tiny” and “quite heavily under-specified” [3]. This is a feature, not a bug. It provides a flexible foundation that the community can build upon. We can expect to see the specification evolve as it is adopted by more platforms and as best practices emerge.

However, the power of skills—especially their ability to execute code—also introduces new governance challenges. Organizations will need to establish clear processes for auditing, testing, and deploying skills from trusted sources. We will need skill registries to manage the discovery and distribution of skills, and policy engines to control which agents can use which skills in which contexts. These are the next frontiers in agentic infrastructure.

Agent Skills are not just a new feature; they are a new architectural primitive for the agentic era. They provide the missing link between general intelligence and specialized execution. By making expertise composable, portable, and standardized, Agent Skills will unlock the next wave of innovation in enterprise AI. The race is no longer just about building the most powerful models; it is about building the most capable and knowledgeable agentic workforce.

References:

[1] Anthropic. (2025, December 18). Agent Skills. Agent Skills.

[2] Anthropic. (2025, October 16). Equipping agents for the real world with Agent Skills. Anthropic Blog.

[3] Willison, S. (2025, December 19). Agent Skills. Simon Willison’s Weblog.

From Boom to Build-Out: The State of Enterprise AI in 2026

Wed, 10 Dec 2025 00:00:00 +0000

The era of AI experimentation is over. What began as a speculative boom has rapidly industrialized into the fastest-scaling software category in history. According to a new report from Menlo Ventures, enterprise spending on generative AI skyrocketed to $37 billion in 2025, a stunning 3.2x increase from the previous year [3]. This isn’t just hype; it’s a fundamental market shift. AI now commands 6% of the entire global SaaS market—a milestone reached in just three years [3].

This explosive growth signals a new phase of enterprise adoption. The conversation has moved beyond simple chatbots and one-off tasks to focus on building durable, agentic infrastructure. Reports from OpenAI, Anthropic, and Menlo Ventures all point to the same conclusion: the battleground for competitive advantage has shifted from model performance to platform execution.

The Money Flows to Applications, and Enterprises are Buying

So, where is this money going? Over half of all enterprise AI spend $19 billion is flowing directly into the application layer [3]. This indicates a clear preference for immediate productivity gains over long-term, in-house infrastructure projects. The “buy vs. build” debate has decisively tilted towards buying, with 76% of AI use cases now being purchased from vendors, a dramatic reversal from 2024 when the split was nearly even [3].

This trend is fueled by two factors: AI solutions are converting at nearly double the rate of traditional SaaS (47% vs. 25%), and product-led growth (PLG) is driving adoption at 4x the rate of traditional software [3]. Individual employees and teams are adopting AI tools, proving their value, and creating a powerful bottom-up flywheel that short-circuits legacy procurement cycles.

The Architectural Shift: From Queries to Agentic Workflows

This rapid adoption is not just about doing old tasks faster; it’s about enabling entirely new ways of working. The data shows a clear architectural shift from simple, conversational queries to structured, agentic workflows that are deeply embedded in core business processes.

Anthropic’s 2026 survey reveals that 57% of organizations are already deploying agents for multi-stage processes, with 81% planning to tackle even more complex, cross-functional workflows in the coming year [1]. This transition from single-turn interactions to persistent, multi-step agents is where true business transformation is happening.

OpenAI’s 2025 report highlights a 19x year-to-date increase in the use of structured workflows like Custom GPTs and Projects, with 20% of all enterprise messages now being processed through these repeatable systems [2]. The impact is tangible, with 80% of organizations reporting measurable ROI on their agent investments and workers saving an average of 40-60 minutes per day [1, 2].

Perhaps most striking is that 75% of workers report being able to complete tasks they previously could not perform, including programming support, spreadsheet analysis, and technical tool development [2]. This democratization of technical capabilities is fundamentally reshaping how work gets done.

Coding Leads the Charge

Nearly all organizations (90%) now use AI to assist with development, and 86% deploy agents for production code [1]. The adoption is so pervasive that coding-related messages have increased by 36% even among non-technical workers [2].

Organizations report time savings across the entire development lifecycle: planning and ideation (58%), code generation (59%), documentation (59%), and code review and testing (59%) [1]. This systematic integration across the full software development lifecycle is accelerating delivery timelines and freeing developers to focus on higher-value architectural and problem-solving work.

The New Frontier: Platform-Level Execution

As AI becomes an essential, intelligent layer of the enterprise tech stack, the primary barriers to scaling are no longer model capabilities but organizational and architectural readiness. The top challenges cited by leaders are integration with existing systems (46%), data access and quality (42%), and change management (39%) [1]. These are not model problems; they are platform problems.

This new reality is creating a widening performance gap. OpenAI’s data shows that “frontier firms” that treat AI as integrated infrastructure see 2x more engagement per seat, and their workers are 6x more active than the median [2]. Technology, healthcare, and manufacturing are seeing the fastest growth (11x, 8x, and 7x respectively), while professional services and finance operate at the largest scale [2].

The state of enterprise AI in 2026 is clear: the gold rush is over, and the era of building the railroads has begun. Success is no longer defined by having the best model, but by having the best platform to deploy, manage, and secure intelligence at scale.

References:

[1] Anthropic. (2025). The 2026 State of AI Agents Report. Anthropic.

[2] OpenAI. (2025). The state of enterprise AI 2025 report. OpenAI.

[3] Menlo Ventures. (2025, December 9). 2025: The State of Generative AI in the Enterprise. Menlo Ventures.

The Three-Platform Problem in Enterprise AI

Sun, 07 Dec 2025 00:00:00 +0000

Enterprise AI has a platform problem. The tools to build AI-powered applications exist, but they’re scattered across three disconnected ecosystems—each solving part of the puzzle, none providing a complete solution.

This isn’t a “too many choices” problem. It’s an architectural one. Gartner tracks these ecosystems in separate Magic Quadrants because they serve fundamentally different users with different needs. But building production AI applications requires capabilities from all three.

Three Ecosystems, Zero Integration

1. Low-Code Platforms (The Citizen Developer)

Platforms like Microsoft Power Apps, Mendix, and OutSystems let business users build applications quickly without writing code. They excel at UI, rapid prototyping, and workflow automation.

Gartner Magic Quadrant for Enterprise Low-Code Application Platforms

What they do well: Speed to prototype, accessibility for non-developers, business process automation.

What they lack: Infrastructure control, enterprise governance at scale, and the flexibility professional developers need.

2. DevOps Platforms (The Professional Developer)

GitLab, Microsoft Azure DevOps, and Atlassian provide CI/CD pipelines, source control, and deployment infrastructure. They answer the “how do we ship and operate this reliably?” question.

Gartner Magic Quadrant for DevOps Platforms

What they do well: Security, governance, testing, deployment automation, operational excellence.

What they lack: They don’t help you build faster—they help you ship what you’ve already built.

3. AI/ML Platforms (The AI Specialist)

Cloud providers (AWS, GCP, Azure) and specialized vendors offer models, MLOps tooling, and inference infrastructure. They provide the intelligence layer.

Gartner Magic Quadrant for AI Code Assistants

What they do well: Model access, training infrastructure, inference at scale.

What they lack: An opinion on how you actually build and deploy applications around those models.

The Cost of Fragmentation

When your AI strategy requires stitching together leaders from three separate ecosystems, you pay an integration tax:

Workflow disconnects. A business user prototypes an AI workflow in a low-code tool. A developer rebuilds it from scratch to meet security requirements. The prototype and production system share nothing but a spec document.

Observability gaps. Tracing a user request through a low-code UI, into a DevOps pipeline, through an AI model call, and back is nearly impossible without custom instrumentation.

Governance drift. Security policies enforced in your DevOps platform don’t automatically apply to your low-code environment. Compliance becomes a manual audit.

Your most capable engineers end up writing glue code instead of building products.

A Different Architecture: API-First Unification

The solution isn’t better integrations—it’s platforms built on a different architecture.

Replit offers a useful case study. They’ve grown from $10M to $100M ARR in under six months by building a platform where:

The same infrastructure serves both citizen developers and professionals. A business user building through natural language (“create a customer feedback dashboard”) and a developer writing code are using the same underlying APIs, the same deployment system, the same security model.
AI is native, not bolted on. Their Agent can build, test, and deploy complete applications autonomously—but it’s using the same environment a professional developer would use. No “export to production” step.
Governance applies universally. Database access, API key management, and deployment policies are platform-level concerns. They apply whether you’re prompting an AI agent or writing TypeScript.

This is the “headless-first” pattern that companies like Stripe and Twilio proved out: build the API, make it excellent, then layer interfaces on top. The UI for non-developers and the API for developers are just different clients to the same system.

What This Means for Platform Strategy

If you’re evaluating AI platforms, the question isn’t “which low-code tool, which DevOps platform, and which AI vendor?”

The better question: Does this platform unify these concerns, or will we be writing integration code for the next three years?

Look for:

API-first architecture. Can professional developers access everything through APIs? Is the UI built on those same APIs?
Built-in deployment and operations. Does prototyping in the platform give you production-ready infrastructure, or does it give you an export button and a prayer?
Platform-level governance. Are security, compliance, and cost controls configured once and inherited everywhere, or are they per-tool?

The platforms winning in this space aren’t the ones with the longest feature lists. They’re the ones that recognized the three-ecosystem problem and architected around it from day one.

The Platform Convergence: Why the Future of AI SaaS is Headless-First

Tue, 02 Dec 2025 00:00:00 +0000

The AI agent market is experiencing its own big bang—but this rapid expansion is creating fundamental fragmentation. Enterprises deploying agents at scale are caught between two incomplete solutions: Agent Builders and AI Gateways.

Agent Builders democratize creation through no-code interfaces. AI Gateways provide enterprise governance over costs, security, and compliance. Both are critical, but in their current separate forms, they force a false choice: speed or control? The reality is, you need both.

We’ve seen this movie before. The most successful developer platforms—Stripe, Twilio, Shopify—aren’t just slick UIs or robust infrastructure. They are headless-first platforms that masterfully combine both.

The Headless-First Model

Stripe didn’t win payments by offering a payment form. Twilio didn’t win communications by providing a dashboard. They won by providing a powerful, programmable foundation with APIs as the primary interface. Their UIs are built on the same public APIs their customers use. Everything is composable, programmable, and extensible.

Principle	Benefit
API-First Design	Platform’s own UI uses public APIs, ensuring completeness
Progressive Complexity	Start with no-code UI, graduate to API without migration
Composability	Every capability is a building block for higher-level abstractions
Extensibility	Third parties build on the platform, creating ecosystem effects

This is the blueprint for AI platforms: not just a UI for building agents, nor just a gateway for traffic—but a comprehensive, programmable platform for building, running, and governing AI at every layer.

The Two Incomplete Categories

Agent Builders (Microsoft Copilot Studio, Google Agent Builder) empower non-technical users to create agents in minutes. The problem arises at scale: Who manages API keys? Who tracks costs? Who ensures compliance? This democratization often creates ungoverned “shadow IT”—business units spinning up agents independently, each with its own credentials and error handling. Platform teams discover the proliferation only when something breaks.

AI Gateways (Kong, Apigee) solve the governance problem with centralized security, cost monitoring, and compliance. But a gateway is just plumbing—it doesn’t accelerate creation. Business users wait in IT queues while engineers build what they need. Innovation slows to a crawl.

Integrating both categories creates its own integration tax: two authentication systems, two deployment processes, broken observability across disconnected logs, and policy enforcement gaps where builder retry logic conflicts with gateway rate limits.

The Platform Convergence

The solution is a unified, headless-first platform with four integrated layers:

Layer 1: UI Layer — Intuitive no-code agent builder for business users, built on top of the platform’s own APIs. Natural language definition, visual workflow design, one-click deployment with inherited governance.

Layer 2: Runtime Layer — Enterprise-grade gateway that every agent runs through automatically. Centralized auth (OAuth, OIDC, SAML), real-time policy enforcement, distributed tracing, cost tracking, anomaly detection.

Layer 3: Platform Layer — Comprehensive APIs and SDKs for developers. REST/GraphQL endpoints, language-specific SDKs, agent lifecycle management, webhook system for event-driven architectures.

Layer 4: Ecosystem Layer — Marketplace for discovering and sharing agents, tools, and integrations. Internal registry, reusable components, version control, usage analytics.

Speed AND Control

The difference between fragmented and unified approaches:

Capability	Fragmented Tools	Unified Platform
Agent Creation	Separate builder	Integrated no-code + API/SDK
Infrastructure	Separate gateway	Built-in gateway with inherited policies
Observability	Disconnected logs	End-to-end unified tracing
Policy Management	Manual coordination	Single policy engine
Developer Experience	High friction	Single, cohesive API surface
Audit & Compliance	Cross-system correlation	Native audit trails

With a unified platform: business user creates agent in UI → platform applies policies automatically → agent deploys with full observability → platform team monitors centrally → developer extends via API without migration.

What This Unlocks

Self-Service AI: HR builds a resume screening agent in 20 minutes. It inherits security policies automatically. Cost allocates to HR’s budget. Compliance trail generates without extra work.

AI-Powered Products: Engineers embed agent capabilities into customer-facing apps using platform APIs. Multi-tenant isolation, usage-based billing, and governance come built-in.

Internal Marketplace: Marketing’s “competitive intelligence” agent gets discovered by Sales. One-click deployment. Usage metrics show ROI across the organization.

Conclusion

The debate over agent builder vs. AI gateway is a red herring—a false choice leading to fragmented, expensive solutions. The real question: point solution or true platform?

In payments, Stripe won by unifying developer APIs with merchant tools. In communications, Twilio won by combining carrier control with developer speed. The AI platform market is at the same inflection point.

The future isn’t about stitching tools together; it’s about building on a unified, programmable foundation. The organizations that invest in platform-first infrastructure—rather than cobbling together point solutions—will move faster, govern more effectively, and build more sophisticated agentic systems.

The convergence is coming. The question is whether you’ll be ahead of it or behind it.

MCP Enterprise Readiness: How the 2025-11-25 Spec Closes the Production Gap

Mon, 01 Dec 2025 00:00:00 +0000

Just over a week ago, the Model Context Protocol celebrated its first anniversary with the release of the 2025-11-25 specification [1]. The announcement was rightly triumphant—MCP has evolved from an experimental open-source project to a foundational standard backed by GitHub, OpenAI, Microsoft, and Block, with thousands of active servers in production [1]. For readers comparing the protocol to Anthropic’s procedural customization layer, I cover Claude Skills vs MCP separately.

But beneath the celebration lies a more interesting story: this spec release is not just an evolution; it’s a strategic pivot toward enterprise readiness. For the past year, MCP has succeeded as a developer tool—a convenient way to connect AI models to data and capabilities during experimentation. The 2025-11-25 spec is different. It introduces features explicitly designed to solve the operational, security, and governance challenges that prevent organizations from deploying agent-tool ecosystems at enterprise scale.

This article examines three key features from the new spec and analyzes how they close what I call the “production gap”—the distance between experimental agent prototypes and enterprise-grade agentic infrastructure.

The Production Gap: Why Experimental Agents Don’t Scale

Before diving into the technical features, we need to understand the problem they’re solving. Organizations have been experimenting with MCP-powered agents for months, often with impressive results in controlled environments. Yet most of these projects remain trapped in pilot purgatory, unable to progress to production deployments. The barriers are not technical whimsy; they are fundamental operational requirements:

Requirement	Why It Matters	What’s Been Missing
Asynchronous Operations	Real-world tasks like report generation, data analysis, and workflow automation can take minutes or hours, not milliseconds.	MCP connections are synchronous. Long-running tasks force clients to hold connections open or build custom polling systems.
Enterprise Authentication	Organizations need centralized control over which users, agents, and services can access sensitive tools and data.	The original OAuth flow assumed a consumer app model. It lacked support for machine-to-machine auth and didn’t integrate with enterprise Identity Providers.
Extensibility	Different industries and use cases require custom capabilities without fragmenting the core protocol.	There was no formal mechanism to standardize extensions, leading to proprietary, incompatible implementations.

These aren’t edge cases; they are the table stakes for production systems. The 2025-11-25 spec directly addresses each one.

Feature 1: Asynchronous Tasks — Making Long-Running Workflows Production-Ready

Perhaps the most transformative addition is the new Tasks primitive [2]. While still marked as experimental, it fundamentally changes how agents interact with MCP servers for long-running operations.

The Problem: Synchronous Request-Response Doesn’t Match Real Work

Traditional MCP follows the classic RPC pattern: the client sends a request, the server processes it, and the server returns a response—all within a single connection. This works beautifully for quick operations like reading a database row or checking a weather API. But it breaks down for realistic enterprise workflows:

Data Analytics Agent: “Generate a quarterly financial report by analyzing three years of transaction data” → 15 minutes of processing.
Compliance Agent: “Scan all customer contracts for non-standard clauses” → 2 hours across 10,000 documents.
DevOps Agent: “Deploy this service to production and run integration tests” → 30 minutes with orchestration dependencies.

Organizations have been forced to build custom workarounds: job queues, polling systems, callback webhooks—all non-standard, all increasing complexity and reducing interoperability.

The Solution: A Unified Async Model

The new Tasks feature introduces a standard “call-now, fetch-later” pattern:

The client sends a request to an MCP server with a task hint.
The server immediately acknowledges the request and returns a unique taskId.
The client periodically checks the task status (working, completed, failed) using standard Task operations.
When complete, the client retrieves the final result using the taskId.

This is more than syntactic sugar. It provides a uniform abstraction for asynchronous work across the entire MCP ecosystem. An agent framework doesn’t need to know whether it’s calling a data pipeline, a deployment system, or a document processor—the async pattern is the same.

Enterprise Impact: Agents That Don’t Block

In production environments, this changes everything. An AI assistant orchestrating a complex workflow can:

Kick off multiple long-running tasks in parallel (e.g., “analyze sales data,” “generate customer insights,” “create visualizations”).
Continue planning and reasoning while tasks are in progress.
Provide real-time status updates to users without blocking.
Handle failures gracefully with retries and fallback strategies.

This is how real autonomous agents operate. The Tasks primitive makes it possible within a standard, interoperable protocol.

Feature 2: Enterprise-Grade OAuth with CIMD and Extensions

The original MCP spec included OAuth 2.0 support, but it was modeled on consumer app patterns (think “Log in with GitHub”). That model doesn’t work for enterprise use cases, where organizations need centralized identity management, audit trails, and policy-based access control. The 2025-11-25 spec introduces two critical updates to close this gap.

CIMD: Decentralized Trust Without Dynamic Client Registration

The first change is replacing Dynamic Client Registration (DCR) with Client ID Metadata Documents (CIMD) [3]. In the old model, every MCP client had to register with every authorization server it wanted to use—a scalability nightmare in federated enterprise environments.

With CIMD, the client_id is now a URL that the client controls (e.g., https://agents.mycompany.com/sales-assistant). When an authorization server needs information about this client, it fetches a JSON metadata document from that URL. This document includes:

Client name and description
Valid redirect URIs
Supported grant types
Public keys for token verification

This approach creates a decentralized trust model anchored in DNS and HTTPS. The authorization server doesn’t need a pre-existing relationship with the client; it trusts the metadata published at the URL. For large organizations with dozens of agent applications and multiple MCP providers, this dramatically reduces operational overhead.

Extension 1: Machine-to-Machine OAuth (SEP-1046)

The second critical addition is support for the OAuth 2.0 client_credentials flow via the M2M OAuth extension. This enables machine-to-machine authentication—allowing agents and services to authenticate directly with MCP servers without a human user in the loop.

Why does this matter? Consider these enterprise scenarios:

Scheduled Agent Jobs: A nightly data ingestion agent that pulls information from multiple MCP sources to update a data warehouse.
Service-to-Service Communication: A monitoring agent that periodically checks the health of deployed systems by querying infrastructure management tools.
Headless Automation: An agent that processes incoming support tickets and takes automated actions based on predefined rules.

None of these involve an interactive user. They are autonomous services that need persistent, secure credentials to access tools on behalf of the organization. The client_credentials flow is the standard OAuth mechanism for exactly this use case, and its inclusion in MCP makes headless agentic systems viable.

Extension 2: Cross App Access (XAA) (SEP-990)

Perhaps the most strategically significant feature for large enterprises is the Cross App Access (XAA) extension. This solves a governance problem that has plagued the consumerization of enterprise AI: uncontrolled tool sprawl.

In the standard OAuth flow, a user grants consent directly to an AI application to access a tool. The enterprise Identity Provider (IdP) sees only that “Alice logged in to the AI app,” not that “Alice’s AI agent is now accessing the payroll system.” This creates a governance black hole.

XAA changes the authorization flow to insert the enterprise IdP as a central policy enforcement point. Now, when an agent attempts to access an MCP server:

The agent requests authorization from the enterprise IdP.
The IdP evaluates organizational policies: Is this agent approved for production use? Does Alice have permission to delegate payroll access to this agent? Is this access compliant with our data governance policies?
Only if all policies are satisfied does the IdP issue tokens to the agent.

This provides centralized visibility and control over the entire agent-tool ecosystem. Security teams can monitor which agents are accessing which tools, set organization-wide policies (e.g., “no agents can access PII without human review”), and audit all delegated access. It eliminates shadow AI and provides the compliance story that regulated industries demand.

Enterprise Impact: From Shadow AI to Governed Infrastructure

Together, these OAuth enhancements transform MCP from a developer convenience into a governed, auditable integration layer. Organizations can:

Enforce Identity Standards: All agents authenticate using the corporate IdP, with the same rigor as human employees.
Enable Zero-Trust Architecture: Every tool access is explicitly authorized based on policy, not implicit trust.
Provide Audit Trails: Every delegation, token issuance, and access event is logged for compliance and forensic analysis.
Scale Securely: Decentralized trust via CIMD means new agents and tools can be onboarded without central bottlenecks, while XAA ensures control is never lost.

Feature 3: Formal Extensions Framework — Enabling Innovation Without Fragmentation

The third major addition is the introduction of a formal Extensions framework [3]. This is a governance mechanism for the protocol itself, allowing the community to develop new capabilities without fragmenting the ecosystem.

The Innovation-Standardization Tension

Every successful protocol faces this dilemma: enable innovation fast enough to keep up with evolving use cases, but standardize carefully enough to maintain interoperability. Move too slowly, and the community builds proprietary extensions that fragment the ecosystem. Move too quickly, and the core protocol becomes bloated with niche features that most implementations don’t need.

MCP’s solution is a structured extension process. New capabilities are proposed as Specification Enhancement Proposals (SEPs), which undergo community review and can be adopted incrementally. Extensions are namespaced and clearly marked, so implementations can selectively support them without breaking compatibility.

Enterprise Impact: Customization Without Vendor Lock-In

For enterprises, this is critical. Different industries have unique requirements:

Healthcare: Extensions for HIPAA-compliant audit logging and patient consent management.
Financial Services: Extensions for transaction integrity, regulatory reporting, and fraud detection hooks.
Manufacturing: Extensions for real-time sensor data streaming and factory floor integrations.

The formal extensions framework allows organizations to develop these capabilities as standard, interoperable extensions rather than proprietary forks. This preserves the core value proposition of MCP—a universal protocol for agent-tool communication—while enabling the customization required for production use.

The Multiplier Effect: Sampling with Tools (SEP-1577)

One more feature deserves mention: Sampling with Tools [3]. This allows MCP servers themselves to act as agentic systems, capable of multi-step reasoning and tool use. A server can now request the client to invoke an LLM on its behalf, enabling server-side agents.

Why is this powerful? It enables compositional agent architectures. A high-level agent can delegate to specialized MCP servers, which themselves use agentic reasoning to fulfill complex requests. For example:

A “Financial Analysis Agent” delegates to an “ERP Data Server,” which uses its own reasoning to determine which tables to query, how to join data, and how to format results.
A “Compliance Agent” delegates to a “Legal Document Server,” which autonomously searches case law, extracts relevant clauses, and generates a summary.

This nested, hierarchical approach is how real autonomous systems will scale. By making it a standard protocol feature rather than a custom implementation, MCP provides the foundation for a rich ecosystem of specialized, composable agents.

Closing the Production Gap: A New Maturity Threshold

The 2025-11-25 MCP specification is not a radical redesign; it’s a targeted set of enhancements that directly address the barriers preventing enterprise adoption. By introducing:

Asynchronous Tasks for long-running workflows,
Enterprise OAuth with CIMD, M2M, and XAA for governed, auditable authentication,
Formal Extensions for standardized innovation,
Sampling with Tools for compositional agent architectures,

the spec closes the production gap—the distance between experimental prototypes and scalable, secure, enterprise-grade systems.

This is the moment when MCP transitions from a promising developer tool to a foundational piece of enterprise infrastructure. Organizations that have been waiting for “production readiness” signals now have them. The features are there. The governance mechanisms are there. The security model is there.

The next phase of agentic AI will be defined not by flashy demos, but by the quiet, reliable, at-scale operation of autonomous systems integrated deeply into enterprise workflows. The 2025-11-25 MCP spec is the technical foundation that makes this future possible.

For technology leaders evaluating whether to invest in MCP-based infrastructure, the calculus has changed. This is no longer an experimental protocol; it’s a production standard. The organizations that adopt it now, build their agent ecosystems on it, and contribute to its continued evolution will define the next decade of enterprise AI.

References:

[1] MCP Core Maintainers. (2025, November 25). One Year of MCP: November 2025 Spec Release. Model Context Protocol.

[2] Model Context Protocol. (2025, November 25). Tasks. Model Context Protocol Specification.

[3] Pakiti, Maria. (2025, November 26). MCP 2025-11-25 is here: async Tasks, better OAuth, extensions, and a smoother agentic future. WorkOS Blog.

[4] Subramanya, N. (2025, November 20). The Governance Stack: Operationalizing AI Agent Governance at Enterprise Scale. subramanya.ai.

[5] Subramanya, N. (2025, November 17). Why Private Registries are the Future of Enterprise Agentic Infrastructure. subramanya.ai.

The Governance Stack: Operationalizing AI Agent Governance at Enterprise Scale

Thu, 20 Nov 2025 00:00:00 +0000

Enterprise adoption of AI agents has reached a tipping point. According to McKinsey’s 2025 global survey, 88% of organizations now report regular use of AI agents in at least one business function, with 62% actively experimenting with agentic systems [1]. Yet this rapid adoption has created a critical disconnect: while organizations understand the importance of governance, they struggle with the implementation of it. The same survey reveals that 40% of technology executives believe their current governance programs are insufficient for the scale and complexity of their agentic workforce [1, 2].

The problem is not a lack of frameworks. Numerous organizations have published comprehensive governance principles—from Databricks’ AI Governance Framework to the EU AI Act’s regulatory requirements [2]. The problem is that governance has remained largely conceptual, living in policy documents and compliance checklists rather than in the operational infrastructure where agents actually execute.

This article presents the technical foundation required to operationalize governance at scale: the Governance Stack. This is the integrated set of platforms, protocols, and enforcement mechanisms that transform governance from aspiration into automated reality across the entire agentic workforce lifecycle.

The Governance Gap: From Principle to Practice

Traditional enterprise governance models were designed for static systems and predictable workflows. An application goes through a review process, gets deployed, and then operates within well-defined boundaries. Governance checkpoints are discrete events: code reviews, security scans, compliance audits.

Agentic AI shatters this model. Agents are dynamic, adaptive systems that make autonomous decisions, spawn sub-agents, and interact with constantly evolving toolsets. They don’t follow predetermined paths; they reason, plan, and execute based on context. As one industry analysis puts it, the governance question shifts from “did the code do what we programmed?” to “did the agent make the right decision given the circumstances?” [3].

This creates four fundamental challenges that traditional governance infrastructure cannot address:

Challenge	Traditional Governance	Agentic Reality
Decision-Making	Predetermined logic paths, testable and auditable	Context-dependent reasoning, emergent behavior
Delegation	Single service boundary, clear ownership	Recursive agent chains, distributed responsibility
Policy Enforcement	Deployment-time checks, periodic audits	Real-time enforcement at the moment of action
Auditability	Static code and logs	Dynamic decision traces across multiple agents and tools

The governance gap is the distance between what existing frameworks prescribe and what existing infrastructure can enforce. Closing this gap requires purpose-built technology.

The Five Layers of the Governance Stack

Drawing on the foundational pillars outlined in frameworks like Databricks’ AI Governance model [2], we can define a technical architecture—a Governance Stack—that provides the infrastructure necessary to operationalize these principles. This stack has five integrated layers, each addressing a specific aspect of agent lifecycle management.

Layer 1: Identity and Attestation Foundation

Before governance can be enforced, we must know who (or what) is making a request. This requires a robust identity layer specifically designed for autonomous agents, not just human users.

As discussed in previous work on OIDC-A (OpenID Connect for Agents), this layer provides [4]:

Verifiable Agent Identities: Every agent receives a cryptographically verifiable identity, issued by a trusted authority (the AI provider or enterprise identity system).
Delegation Chains: Clear, auditable records of which user or system authorized the agent, and what permissions were delegated.
Attestation Mechanisms: Proof that the agent is running the expected code, on approved infrastructure, with the intended configuration.

This identity foundation is the prerequisite for all subsequent layers. Without it, governance policies have no subject to act upon.

Layer 2: Agent and Tool Registries

Governance requires visibility. The second layer of the stack is a comprehensive registry system that provides a single source of truth for:

Agent Registry: A catalog of every agent deployed in the enterprise, including its capabilities, business owner, data access, and lifecycle status [5]. This is not just a static directory; it’s a dynamic system that tracks agent versions, configurations, and runtime behavior.
MCP/Tool Registry: A curated, approved set of tools and MCP servers that agents are authorized to access. This registry enforces pre-deployment security reviews, manages versions, tracks usage, and provides cost visibility [5].

As explored in our previous article on private registries, this layer transforms governance from a manual audit process into an automated, enforceable function of the infrastructure itself [5]. Agents that aren’t registered can’t deploy. Tools that haven’t been vetted can’t be accessed.

Layer 3: Policy Engine and Gateway

The third layer is where governance rules are codified and enforced in real-time. This includes:

Agent Firewalls and MCP Gateways: Acting as intermediaries between agents and their tools, these gateways inspect every request, enforce security policies, and block unauthorized actions before they occur [6]. They provide:

Prompt injection detection and filtering
Real-time policy evaluation (e.g., “can this agent access PII?”)
Dynamic rate limiting and cost controls
Anomaly detection for suspicious behavior patterns

Automated Policy Enforcement: Instead of relying on manual reviews, the policy engine automatically validates agents against organizational standards at every lifecycle stage. For example, an agent cannot be promoted to production without:

A completed data classification assessment
Approval from the designated business owner
A passed security scan
Documented human oversight procedures for high-stakes decisions

This layer is the operational heart of the governance stack. It is where abstract policies become concrete actions that prevent harm in real-time.

Layer 4: Observability and Monitoring Platform

Governance is not a one-time gate; it requires continuous oversight. The fourth layer provides real-time visibility into the behavior of the entire agentic workforce:

Performance Dashboards: Track accuracy, decision quality, latency, and resource consumption across all agents.
Drift Detection: Monitor agents for behavioral changes that might indicate model degradation, prompt injection, or unauthorized modifications.
Audit Trails: Capture every agent action, tool invocation, and delegation event with sufficient context to enable forensic analysis and compliance reporting [3].
Anomaly Alerting: Trigger automated responses when agents deviate from expected patterns, such as accessing unusual data sources or making an abnormal volume of API calls.

This layer transforms governance from reactive (responding to incidents after they occur) to proactive (detecting and preventing issues before they cause harm).

Layer 5: Human-in-the-Loop Orchestration

The final layer recognizes that not all decisions can or should be fully automated. For high-stakes scenarios, governance requires explicit human oversight:

Escalation Workflows: Agents can request human approval before executing sensitive actions, such as modifying production systems or processing large financial transactions.
Override Mechanisms: Authorized personnel can intervene to pause, redirect, or terminate agent operations when necessary.
Explainability Interfaces: When agents make consequential decisions, stakeholders need to understand the reasoning. This layer provides tools to inspect the decision chain, view the data that influenced the agent, and audit the tool usage.

This is not about replacing human judgment; it’s about augmenting it with the right information at the right time.

Operationalizing the Framework: Governance Across the Agent Lifecycle

The power of the Governance Stack becomes clear when we map it to the complete agent lifecycle. Governance is not a single checkpoint; it is a continuous process embedded at every stage.

Lifecycle Stage	Governance Stack in Action
Planning & Design	Identity layer establishes agent ownership. Policy engine validates business case against organizational risk appetite.
Data Preparation	Registries enforce data classification and lineage tracking. Policy engine blocks access to non-compliant datasets.
Development & Training	Observability platform tracks experiments and model performance. Registries version all agent configurations.
Testing & Validation	Agent firewall tests for adversarial inputs and prompt injections. Policy engine validates against security and ethical standards.
Deployment	Gateway enforces real-time authorization for all tool access. Observability platform begins continuous monitoring.
Operations	Monitoring platform detects drift and anomalies. Human-in-the-loop mechanisms escalate high-stakes decisions.
Retirement	Registries archive agent configurations. Identity layer revokes all permissions. Audit trails are retained for compliance.

This lifecycle-aware approach ensures that governance is not an afterthought, but an integrated function of how agents are built, deployed, and managed.

The ROI of Governance Infrastructure

Implementing a comprehensive Governance Stack is a significant investment. Organizations rightfully ask: what is the return?

The answer lies in four measurable outcomes:

Risk Mitigation: As demonstrated by the recent AI-orchestrated cyber espionage campaign disrupted by Anthropic [6], uncontrolled agent access to powerful tools is not a theoretical threat. A governance stack with identity attestation, gateways, and real-time policy enforcement would have prevented that attack at multiple layers.

Regulatory Compliance: With regulations like the EU AI Act imposing strict requirements on high-risk AI systems, the ability to demonstrate comprehensive lifecycle governance, auditability, and human oversight is not optional—it’s mandatory [2]. The Governance Stack provides the automated evidence generation required for compliance.

Operational Efficiency: Without centralized registries and monitoring, organizations waste time debugging agent failures, tracking down tool dependencies, and investigating cost overruns. The stack provides the visibility and control to operate an agentic workforce at scale.

Trust and Adoption: The ultimate ROI is internal and external trust. Employees, customers, and regulators need confidence that autonomous agents are operating safely, ethically, and in alignment with organizational values. The Governance Stack makes that confidence possible.

Building vs. Buying: The Emerging Vendor Landscape

Organizations face a critical decision: build this governance infrastructure in-house or adopt emerging platforms that provide it as a service. Early movers are choosing different paths:

Enterprise Platforms: Companies like Collibra, Databricks, and TrueFoundry are extending their data governance and MLOps platforms to include agent registries and observability tools [2, 5, 7].
Purpose-Built Solutions: Startups like Agentic Trust are building end-to-end governance platforms specifically designed for agentic AI, providing integrated registries, gateways, and policy engines [5].
Protocol-Level Standards: Open standards like OIDC-A and MCP are enabling interoperability, allowing organizations to build custom stacks from best-of-breed components [4].

The optimal path depends on organizational maturity, existing infrastructure, and the scale of agentic deployment. However, the underlying message is universal: governance at scale requires dedicated infrastructure.

Conclusion: Governance as the Enabler of Scale

The era of experimental agentic AI pilots is ending. Organizations are now operationalizing agentic workforces across critical business functions, and the governance gap is the primary barrier to scaling these deployments safely and responsibly.

The Governance Stack is not a constraint on innovation; it is the foundation that makes innovation sustainable. By providing identity, visibility, policy enforcement, continuous monitoring, and human oversight, this technical infrastructure transforms governance from a compliance burden into a strategic enabler.

The organizations that invest in this stack today will be the ones that confidently deploy autonomous agents at enterprise scale tomorrow. They will move faster, operate more safely, and earn the trust of stakeholders who demand accountability in the age of autonomous AI.

For technology leaders navigating this landscape, the path is clear: governance is not a policy problem—it is an engineering challenge. And like all engineering challenges, it requires purpose-built infrastructure to solve. The Governance Stack is that infrastructure.

References:

[1] McKinsey & Company. (2025, November 5). The State of AI in 2025: A global survey. McKinsey.

[2] Databricks. (2025, July 1). Introducing the Databricks AI Governance Framework. Databricks.

[3] DZone. (2025, May 21). Securing the Future: Best Practices for Privacy and Data Governance in LLMOps. DZone.

[4] Subramanya, N. (2025, April 28). OpenID Connect for Agents (OIDC-A) 1.0 Proposal. subramanya.ai.

[5] Subramanya, N. (2025, November 17). Why Private Registries are the Future of Enterprise Agentic Infrastructure. subramanya.ai.

[6] Subramanya, N. (2025, November 14). From Espionage to Identity: Securing the Future of Agentic AI. subramanya.ai.

[7] TrueFoundry. (2025, September 10). What is AI Agent Registry. TrueFoundry.

Why Private Registries are the Future of Enterprise Agentic Infrastructure

Mon, 17 Nov 2025 00:00:00 +0000

The age of agentic AI is no longer on the horizon; it’s in our datacenters, cloud environments, and business units. A recent PwC report highlights that a staggering 79% of companies are already adopting AI agents in some capacity [1]. As these autonomous systems proliferate, executing tasks and making decisions on behalf of the enterprise, a critical governance gap has emerged. Without a robust management framework, organizations risk a chaotic landscape of “shadow AI,” creating significant security vulnerabilities, compliance nightmares, and operational inefficiencies.

The solution lies in a new class of enterprise software: the Private Agent and MCP Registry. This is not just a catalog, but a command center for agentic infrastructure, providing the visibility, governance, and security necessary to scale AI responsibly. Let’s explore the core pillars of this trend, using the “Agentic Trust” platform as a blueprint for building a better, more secure agentic future.

Pillar 1: A Centralized Directory for Every Agent

The first step to managing agentic chaos is to establish a single source of truth. You cannot govern what you cannot see. A private agent registry provides a comprehensive, real-time inventory of every agent operating within the enterprise, whether built in-house or sourced from a third-party vendor.

A centralized agent directory, as shown in the Agentic Trust platform, provides a complete inventory for governance and oversight.

As the screenshot of the Agentic Trust directory illustrates, this is more than just a list. A mature registry tracks critical metadata for each agent, including:

Unique Identity: A verifiable ID for every agent, forming the foundation for authentication and authorization.
Capabilities: A clear declaration of what the agent is designed to do, including the tools, resources, and prompts it can access.
Lifecycle Status: Tracking whether an agent is in development, production, or retired.
Ownership and Lineage: Connecting each agent to a business owner, use case, and the data it interacts with.
Activity Monitoring: Recording when agents were last used and their registration dates.

This centralized view eliminates blind spots and provides the traceability required for compliance and security audits. Organizations can quickly answer critical questions: How many agents do we have? Who owns them? What are they authorized to do?

Pillar 2: A Curated Marketplace for Agent Tools (MCPs)

Autonomous agents are only as powerful as the tools they can access. The Model Context Protocol (MCP) has become a standard for providing agents with these tools, but an uncontrolled proliferation of MCP servers creates another layer of risk. A private registry addresses this by functioning as a curated, internal “app store” or marketplace for MCPs.

An MCP Registry, like this one from Agentic Trust, allows enterprises to create a governed marketplace of approved tools for their AI agents.

Instead of allowing agents to connect to any public MCP, the enterprise can define a catalog of approved, vetted, and secure tools. As shown in the Agentic Trust MCP Registry, this allows organizations to:

Enforce Security Standards: Ensure that all available tools meet enterprise security and compliance requirements before they’re made available to agents.
Manage Versions and Dependencies: Control which versions of tools are used, preventing unexpected breaking changes that could disrupt agent operations.
Control Costs: Monitor the usage of paid APIs and tools, preventing runaway costs from autonomous agents making thousands of requests.
Improve Developer Productivity: Provide a central place for developers to discover and reuse existing tools, accelerating agent development and reducing duplication.
Categorize and Organize: Group tools by function (productivity, collaboration, payments, development, monitoring) to make discovery easier.

The registry shows connection status for each MCP server, making it immediately visible which integrations are active and which require attention. This operational visibility is critical for maintaining a healthy agentic ecosystem.

Pillar 3: End-to-End Governance and Policy Enforcement

A private registry is the enforcement point for enterprise AI policy. It moves governance from a manual, after-the-fact process to an automated, built-in function of the agentic infrastructure. Drawing on best practices from platforms like Collibra and Microsoft Azure’s private registry implementations, this includes [1, 2]:

Mandatory Metadata and Documentation: Before an agent or MCP can be registered, developers must provide essential information such as data classification, business owner, purpose, and criticality. This ensures that every component in the agentic ecosystem is properly documented and understood.

Lifecycle Policy Alignment: The registry can embed automated policy checks at each stage of an agent’s lifecycle. For example, an agent cannot be promoted to production without a completed security review, ethical bias assessment, and approval from the designated business owner. This creates natural checkpoints that enforce organizational standards.

Access Control and Permissions: Using Role-Based Access Control (RBAC), integrated with enterprise identity systems like Entra ID or Okta, the registry defines who can create, manage, and consume agents and their tools. Different teams might have different levels of access based on their role and the sensitivity of the agents they’re working with.

Audit Trails and Compliance: Every action in the registry—agent registration, tool connection, permission changes—is logged and auditable. This creates a complete forensic trail that satisfies regulatory requirements and enables rapid incident response when issues arise.

Pillar 4: Solving Real Enterprise Challenges

The value of a private registry becomes clear when we examine the specific problems it solves. Consider these common enterprise scenarios:

Challenge: Shadow AI and Uncontrolled Tool Adoption

Development teams are rapidly adopting AI tools and MCP servers without central oversight. This creates security blind spots, compliance risks, and operational fragmentation across the organization. A private registry provides centralized discovery of approved tools and usage visibility, allowing security teams to monitor what tools are being used and by whom [2].

Challenge: Regulatory Compliance and Data Sovereignty

Organizations in regulated industries (financial services, healthcare, government) need to maintain strict control over data flows and ensure AI tools meet compliance requirements. The registry enables data classification tagging for MCP servers, geographic controls for region-specific availability, comprehensive audit trails, and pre-configured compliance templates [2].

Challenge: Cost Control and Resource Optimization

Without visibility into agent and tool usage, organizations face unpredictable costs as autonomous agents make API calls and consume resources. A private registry provides usage analytics, cost allocation by team or project, budget alerts, and the ability to deprecate underutilized or expensive tools [2].

Challenge: Developer Productivity and Tool Discovery

Developers waste time rebuilding integrations that already exist elsewhere in the organization or struggle to find the right tools for their agents. The registry solves this with searchable catalogs, reusable components, standardized integration patterns, and clear documentation for each available tool [3].

The Architecture That Enables Scale

Behind the user interface of platforms like Agentic Trust lies a sophisticated architecture that makes enterprise-scale agent management possible. The key components include [3, 4]:

Component	Purpose
Central Registry API	Provides standardized endpoints for agent and MCP registration, discovery, and management
Metadata Database	Stores agent cards, capability declarations, and relationship data
Policy Engine	Enforces governance rules, access controls, and compliance checks
Discovery Service	Enables capability-based search and intelligent agent-to-tool matching
Health Monitor	Tracks agent and MCP server availability through heartbeats and health checks
Integration Layer	Connects to enterprise identity systems, monitoring tools, and DevOps pipelines

This architecture mirrors patterns from successful enterprise software registries, such as container registries, API management platforms, and model registries. The lesson is clear: as a technology becomes critical to enterprise operations, it requires industrial-grade management infrastructure.

The Path Forward

The trend toward private registries for agentic infrastructure is not a passing fad; it is a necessary evolution in response to the rapid adoption of autonomous AI systems. As the Model Context Protocol ecosystem continues to grow, with the official MCP Registry serving as a public catalog [4], forward-thinking enterprises are building their own private implementations to maintain control, security, and governance.

Platforms like Agentic Trust demonstrate what this future looks like: a unified command center where every agent is visible, every tool is vetted, and every action is governed by policy. This is how organizations move from the chaos of unmanaged AI to the strategic advantage of a well-orchestrated agentic ecosystem.

For enterprises embarking on this journey, the message is clear: you cannot scale what you cannot see, and you cannot govern what you cannot control. A private registry is the foundation upon which responsible, secure, and effective agentic AI is built.

References:

[1] Collibra. (2025, October 6). Collibra AI agent registry: Governing autonomous AI agents. Collibra.

[2] Bajada, AJ. (2025, August 14). DevOps and AI Series: Azure Private MCP Registry. azurewithaj.com.

[3] TrueFoundry. (2025, September 10). What is AI Agent Registry. TrueFoundry.

[4] Model Context Protocol. (2025, September 8). Introducing the MCP Registry. Model Context Protocol.

From Espionage to Identity: Securing the Future of Agentic AI

Fri, 14 Nov 2025 00:00:00 +0000

Anthropic has detailed its disruption of the first publicly reported cyber espionage campaign orchestrated by a sophisticated AI agent [1]. The incident, attributed to a state-sponsored group designated GTG-1002, is more than just a security bulletin; it is a clear signal that the age of autonomous, agentic AI threats is here. It also serves as a critical case study, validating the urgent need for a new generation of identity and access management protocols specifically designed for AI.

This post will dissect the anatomy of the attack, connect it to the foundational security challenges facing agentic AI, and explore how emerging standards like OpenID Connect for Agents (OIDC-A) provide a necessary path forward [2, 3].

Anatomy of an AI-Orchestrated Attack

Anthropic’s investigation revealed a campaign of unprecedented automation. The attackers turned Anthropic’s own Claude Code model into an autonomous weapon, targeting approximately thirty global organizations across technology, finance, and government. The AI was not merely an assistant; it was the operator, executing 80-90% of the tactical work with human intervention only required at a few key authorization gates [1].

The technical sophistication of the attack did not lie in novel malware, but in orchestration. The threat actor built a custom framework around a series of Model Context Protocol (MCP) servers. These servers acted as a bridge, giving the AI agent access to a toolkit of standard, open-source penetration testing utilities—network scanners, password crackers, and database exploitation tools.

By decomposing the attack into seemingly benign sub-tasks, the attackers tricked the AI into executing a complex intrusion campaign. The AI agent, operating with a persona of a legitimate security tester, autonomously performed reconnaissance, vulnerability analysis, and data exfiltration at a machine-speed that no human team could match.

The MCP Paradox: Extensibility vs. Security

The Anthropic report explicitly states that the attackers leveraged the Model Context Protocol (MCP) to arm their AI agent [1]. This highlights a central paradox in agentic AI architecture: the very protocols designed for extensibility and power, like MCP, can become the most potent attack vectors.

As the “Identity Management for Agentic AI” whitepaper notes, MCP is a leading framework for connecting AI to external tools, but it also presents significant security challenges [3]. When an AI can dynamically access powerful tools without robust oversight, it creates a direct and dangerous path for misuse. The GTG-1002 campaign is a textbook example of this risk realized.

This forces a critical re-evaluation of how we architect agentic systems. We can no longer afford to treat the connection between an AI agent and its tools as a trusted channel. This is where the concept of an MCP Gateway or Proxy becomes not just a good idea, but an absolute necessity.

The Solution: Identity, Delegation, and Zero Trust for Agents

The security gaps exploited in the Anthropic incident are precisely what emerging standards like OIDC-A (OpenID Connect for Agents) are designed to close [2, 3]. The core problem is one of identity and authority. The AI agent in the attack acted with borrowed, indistinct authority, effectively impersonating a legitimate user or process. True security requires a shift to a model of explicit, verifiable delegation.

The OIDC-A proposal introduces a framework for establishing the identity of an AI agent and managing its authorization through cryptographic delegation chains. This means an agent is no longer just a proxy for a user; it is a distinct entity with its own identity, operating on behalf of a user with a clearly defined and constrained set of permissions.

Here’s how this new model, enforced by an MCP Gateway, would have mitigated the Anthropic attack:

Security Layer	Description
Agent Identity & Attestation	The AI agent would have a verifiable identity, attested by its provider. An MCP Gateway could immediately block any requests from unattested or untrusted agents.
Tool-Level Delegation	Instead of broad permissions, the agent would receive narrowly-scoped, delegated authority for specific tools. The OIDC-A `delegation_chain` ensures that the agent’s permissions are a strict subset of the delegating user’s permissions [2]. An agent designed for code analysis could never be granted access to a password cracker.
Policy Enforcement & Anomaly Detection	The MCP Gateway would act as a policy enforcement point, monitoring all tool requests. It could detect anomalous behavior, such as an agent attempting to use a tool outside its delegated scope or a sudden spike in high-risk tool usage, and automatically terminate the agent’s session.
Auditing and Forensics	Every tool request and delegation would be cryptographically signed and logged, creating an immutable audit trail. This would provide immediate, granular visibility into the agent’s actions, dramatically accelerating incident response.

Building Enterprise-Grade Security for Agentic AI

The Anthropic report is a watershed moment. It proves that the threats posed by agentic AI are no longer theoretical. As the “Identity Management for Agentic AI” paper argues, we must move beyond traditional, human-centric security models and build a new foundation for AI identity [3].

Today, most MCP servers being developed are experimental tools designed for individual developers and small-scale applications. They lack the enterprise-grade security controls that organizations require to deploy them in production environments. For enterprises to confidently adopt agentic AI systems built on protocols like MCP, we need to fundamentally rethink how we approach security.

The path forward requires building robust delegation frameworks, implementing proper identity management for AI agents, and creating enterprise-grade security controls like gateways and policy enforcement points. We need solutions that provide:

Cryptographic delegation chains that clearly define and constrain agent permissions
Real-time policy enforcement that can detect and prevent anomalous behavior
Comprehensive audit trails that enable forensic analysis and compliance
Zero-trust architectures where every agent action is verified and authorized

We cannot afford to let the open, extensible nature of protocols like MCP become a permanent backdoor for malicious actors. The future of agentic AI depends on our ability to build security into these systems from the ground up, making enterprise adoption not just possible, but secure and responsible.

References:

[1] Anthropic. (2025, November). Disrupting the first reported AI-orchestrated cyber espionage campaign. Anthropic.

[2] Subramanya, N. (2025, April 28). OpenID Connect for Agents (OIDC-A) 1.0 Proposal. subramanya.ai.

[3] South, T. (Ed.). (2025, October). Identity Management for Agentic AI: The new frontier of authorization, authentication, and security for an AI agent world. arXiv.

Claude Skills vs. MCP: A Tale of Two AI Customization Philosophies

Thu, 30 Oct 2025 00:00:00 +0000

In the rapidly evolving landscape of artificial intelligence, the ability to customize and extend the capabilities of large language models (LLMs) has become a critical frontier. Anthropic, a leading AI research company, has introduced two powerful but distinct approaches to this challenge: Claude Skills and the Model Context Protocol (MCP). While both aim to make AI more useful and integrated into our workflows, they operate on fundamentally different principles. This post delves into a detailed comparison of Claude Skills and MCP, explores whether they can or should be merged, and discusses the exciting future of AI customization they represent.

What are Claude Skills? The Power of Procedural Knowledge

Claude Skills, also known as Agent Skills, are a revolutionary way to teach Claude how to perform specific tasks in a repeatable and customized manner. At its core, a Skill is a folder containing a SKILL.md file, which includes instructions, resources, and even executable code. Think of Skills as a set of standard operating procedures for the AI. For example, a Skill could instruct Claude on how to format a weekly report, adhere to a company’s brand guidelines, or analyze data using a specific methodology.

The genius of Claude Skills lies in their architecture, which is built on a principle called progressive disclosure. This three-tiered system ensures that Claude’s context window isn’t overwhelmed with information:

Level 1: Metadata: When a session starts, Claude loads only the name and description of each available Skill. This is a very lightweight process, consuming only a few tokens per Skill.
Level 2: The SKILL.md file: If Claude determines that a Skill is relevant to the user’s request, it then loads the full content of the SKILL.md file.
Level 3 and beyond: Additional resources: If the SKILL.md file references other documents or scripts within the Skill’s folder, Claude will load them only when needed.

This efficient, just-in-time loading mechanism allows for a vast library of Skills to be available without sacrificing performance. Skills are also portable, working across Claude.ai, Claude Code, and the API, and can even include executable code for deterministic and reliable operations.

What is the Model Context Protocol (MCP)? The Universal Connector

The Model Context Protocol (MCP) is an open-source standard designed to connect AI applications to external systems. If Claude Skills are about teaching the AI how to do something, MCP is about giving it access to what it needs to do it. MCP acts as a universal connector, similar to a USB-C port for AI, allowing models like Claude to interact with a wide range of data sources, tools, and workflows.

MCP operates on a client-server architecture:

MCP Host: The AI application (e.g., Claude) that manages connections to various external systems.
MCP Client: A component within the host that maintains a one-to-one connection with an MCP server.
MCP Server: A program that exposes tools, resources, and prompts from an external system to the AI.

This architecture allows an AI to connect to multiple external systems simultaneously, from local files and databases to remote services like GitHub, Slack, or a company’s internal APIs. MCP is built on a two-layer architecture, with a data layer based on JSON-RPC 2.0 and a transport layer that supports both local and remote connections.

The Core Difference: Methodology vs. Connectivity

The fundamental distinction between Claude Skills and MCP can be summarized as methodology versus connectivity. MCP provides the AI with access to tools and data, while Skills provide the instructions on how to use them effectively. According to Anthropic’s own documentation:

“MCP connects Claude to external services and data sources. Skills provide procedural knowledge—instructions for how to complete specific tasks or workflows. You can use both together: MCP connections give Claude access to tools, while Skills teach Claude how to use those tools effectively.”

This highlights that Skills and MCP are not competing technologies but are, in fact, complementary. An apt analogy is that of a master chef. MCP provides the chef with a fully stocked pantry of ingredients and a set of high-end kitchen appliances (the what). Skills, on the other hand, are the chef’s personal recipe book and techniques, guiding them on how to combine the ingredients and use the appliances to create a culinary masterpiece.

Feature	Claude Skills	Model Context Protocol (MCP)
Primary Purpose	Procedural knowledge and methodology	Connectivity to external systems
Architecture	Filesystem-based with progressive disclosure	Client-server with JSON-RPC 2.0
Core Concept	Teaching the AI how to do something	Giving the AI access to what it needs
Dependency	Requires a code execution environment	A client and a server implementation
Token Efficiency	Very high due to progressive disclosure	Moderate, with tool descriptions in context
Portability	Across Claude interfaces	Open standard for any LLM

Can a Claude Skill be an MCP? And Should They Be Merged?

Given that both are Anthropic’s creations, a natural question arises: could a Claude Skill be implemented as an MCP, or should the two be merged into a single, unified system? While technically possible to create an MCP server that exposes Skills, it would be architecturally inefficient and would defeat the purpose of both systems.

Exposing Skills through MCP would negate the benefits of progressive disclosure, as it would introduce the overhead of the MCP protocol for what should be a simple filesystem read. It would also create a redundant abstraction layer, as Skills already require a local code execution environment. The two systems are designed for different purposes and have different optimization goals: Skills for context efficiency within Claude, and MCP for standardized integration across different AI systems.

Therefore, Claude Skills and MCP should be treated as independent, complementary technologies. The most powerful workflows will come from using them in synergy.

The Power of Synergy: Using Skills and MCP Together

The true potential of these technologies is unlocked when they are used in concert. Here are a few integration patterns that showcase their combined power:

Skills as MCP Orchestrators: A Skill can contain a complex workflow that orchestrates calls to multiple MCP servers. For example, a “Deploy and Notify” Skill could contain a deployment checklist, notification templates, and rollback procedures. It would then use MCP to access GitHub for code, a CI/CD server for deployment, and Slack for notifications.
Skills for MCP Configuration: An organization can create Skills that teach Claude its specific standards for using MCP tools. For example, a “GitHub Workflow Standards” Skill could contain instructions on branch naming conventions, pull request review checklists, and commit message templates, ensuring that Claude uses the GitHub MCP server in a way that aligns with the company’s best practices.
Hybrid Skills: A Skill can contain embedded code that makes calls to an MCP server. This is useful for self-contained workflows that need to fetch external data.

The Future: A Marketplace for Skills and an Ecosystem for MCP

The future of AI customization will likely see the development of a vibrant Skills Marketplace. Similar to the app stores for our smartphones or the extension marketplaces for our code editors, a Skills Marketplace would allow developers to publish, share, and even sell Skills. This could create a new economy around AI expertise, with a wide range of Skills available, from free, community-contributed Skills to premium, industry-specific Skill packages for domains like law, medicine, or finance.

Simultaneously, the MCP ecosystem will continue to grow, with more and more tools and services exposing their functionality through MCP servers. This will create a virtuous cycle: as more tools become available through MCP, the demand for Skills that can effectively use those tools will increase.

Conclusion

Claude Skills and the Model Context Protocol represent two distinct but complementary philosophies of AI customization. MCP is the universal connector, providing the what—the access to tools and data. Skills are the procedural knowledge, providing the how—the instructions and methodology. They are not competitors but partners in the quest to create more powerful, personalized, and integrated AI assistants. The future of AI workflows will not be about choosing between Skills or MCP, but about leveraging the power of Skills and MCP to create intelligent systems that are truly tailored to our needs.

References:

[1] Anthropic. (2025, October 16). Claude Skills: Customize AI for your workflows. Anthropic.

[2] Anthropic. (2025, October 16). Equipping agents for the real world with Agent Skills. Anthropic.

[3] Model Context Protocol. (n.d.). What is the Model Context Protocol (MCP)? Model Context Protocol.

[4] Model Context Protocol. (n.d.). Architecture overview. Model Context Protocol.

[5] Willison, S. (2025, October 16). Claude Skills are awesome, maybe a bigger deal than MCP. Simon Willison’s Weblog.

[6] Claude Help Center. (n.d.). What are Skills? Claude Help Center.

[7] IntuitionLabs. (2025, October 27). Claude Skills vs. MCP: A Technical Comparison for AI Workflows. IntuitionLabs.

Navigating UMass Amherst: A Handbook for International Students

Mon, 08 May 2023 00:00:00 +0000

Subramanya N

Context Engineering: Why Prompt Engineering Was Never Enough

A Simple Mental Model

The Name Is New. The Job Is Not.

Why Prompt Engineering Became Too Small

What Counts as Context

Why Bigger Context Windows Did Not Solve the Problem

From Retrieval to Navigation

The Six Jobs of Context Engineering

1. Selection

2. Structure

3. Compression

4. Memory

5. Tool and Interface Design

6. Isolation and Orchestration

What Changed in 2026

Where Context Graphs Actually Fit

How I Would Build It in 2026

1. Build a durable session layer first

2. Treat the context assembler as a product surface

3. Prefer just-in-time retrieval over eager stuffing

4. Promote only high-value state into long-term memory

5. Build the context graph as a promoted memory layer

6. Package context like code

7. Separate observability from intelligence

A Practical Maturity Model

Level 0: Prompt-Only

Level 1: Retrieval-Enhanced

Level 2: Agent-Aware

Level 3: Adaptive

Level 4: Context-Native

What Good Context Engineering Looks Like in Practice

The Real Takeaway

The Filesystem Is the Database: Why Agents Need a New Storage Primitive

Why RAG Hit a Wall

The Convergence: Four Approaches, One Pattern

Filesystem as Interface, Database as Substrate

But Can a VFS Actually Beat the Native Filesystem?

What This Means for RAG

The Strategic Imperative

The Unifying Layer

The SaaSpocalypse: A Survival Guide

The Great Divide: Two Competing Realities

Camp 1: The End Is Nigh

Camp 2: The Panic Is Illogical

The Survival Playbook

1. Defend Your Moat

2. Embrace the New Pricing Model: The Outcome Economy

3. Become the Trusted Incumbent

2026: The Year SaaS Disappeared Into the Conversation

Meet Your New Coworker: The Personalized AI Agent

The Rise of Voice: Don’t Type, Just Speak

The “SaaSpocalypse” and the New Business Model

Welcome to the Post-App Era

OpenClaw and the Rise of User-Built Intelligence: A Wake-Up Call for SaaS

The Ambient AI Revelation

More Than a Toy: What Users Are Actually Building

The SaaS Dilemma: Build or Be Bypassed

The Time to Act is Now

The Agentic Workspace: A Strategic Imperative for the Next Era of SaaS

The Decline of Seat-Based SaaS Dominance

Six Pressures Reshaping the SaaS Model

Acknowledging the Obstacles on the Path to Autonomy

The New Moat: Capturing the ‘Why’ with Context Graphs

Evolving Business Models for the Agentic Era

What Winners Will Look Like

The Strategic Imperative to Act Now

Context Graphs Are a Trillion-Dollar Opportunity. But Who Actually Captures It?

The Agents in the Arena: Claude Code and Cowork

The Irony: Generating Traces, But Not Capturing Them

Why Incumbents Can’t Just Add This Feature

The Real Race: Who Builds the “Event Clock” for Agents?

From “Code” and “Cowork” to “Context”

A Year with Cursor: How My Workflow Evolved from Agent to Architect

Phase 1: The Agent Takes the Wheel

Phase 2: MCP Changes Everything

Phase 3: The Rise of the Planner

Phase 4: The Architect Emerges (Commands + Planning)

My Current Setup

The Evolution at a Glance