Context Composition for Agentic Systems
What this idea is really proposing
Your proposal is best read as a repository-native context operating model for agents: one place where volatile fetched material lives, where scratch-code can mature into reusable code, where episodic investigation notes can mature into curated knowledge, and where both code and knowledge can be imported from other contexts through a manifest and presented as one navigable surface. What is distinctive is not any single ingredient on its own, but the fact that the repo becomes the unit of ownership, quality control, promotion, reuse, and composition. Today’s ecosystem already contains many of these ingredients separately—repo-local instructions, project memory, versioned skills, MCP resources, long-term stores, registries, subagents, and durable workflows—but I did not find a mainstream framework that exposes your exact dual-promotion model as a first-class primitive. Instead, the market is converging on adjacent pieces. citeturn19view0turn26view0turn28view0turn38search1turn41view0turn40view1
Seen through that lens, your proposed ladders map neatly onto the agent-memory vocabulary that is now standard in both practice and research. The .cache and scratch areas resemble working memory / session state / transient artefacts; your Git-persisted “memory” resembles episodic memory; the curated knowledge_base resembles semantic memory; and reusable scripts or promoted “skills” resemble procedural memory. LangChain’s current memory guidance explicitly frames agent memory in semantic, episodic, and procedural terms; Google ADK distinguishes a session “scratchpad” from more persistent state scopes; Anthropic separates project instructions from auto-memory files; and recent research increasingly treats the path from trace to memory to skill to rule as one continuous compression pipeline rather than separate concerns. citeturn34search0turn36view0turn19view0turn33view1
That is why the idea matters. It is not just “better RAG” or “more files in context”. It is closer to context engineering plus memory lifecycle management plus skill packaging plus compositional interoperability. Anthropic’s engineering guidance explicitly argues that strong agents often need a hybrid of pre-computed context and just-in-time exploration, and that simply waiting for larger context windows will not solve relevance, staleness, or context pollution. OpenAI’s own roadmap now includes conversation state, prompt caching, compaction, tool search, MCP, and versioned skills—features that all point toward structured context management, not naïve prompt stuffing. citeturn19view3turn20view1turn20view2turn37view0turn38search1
The current agentic framework landscape
The framework market in mid-2026 is easiest to understand in three broad families. The first family is managed agent runtimes: OpenAI’s Responses API and Agents SDK, Anthropic’s Claude Code plus Agent SDK, Google’s ADK plus Gemini Enterprise Agent Platform, and Microsoft’s Agent Framework plus Copilot Studio. These systems focus on model access, tool execution, orchestration, guardrails, observability, and some combination of state, memory, and approvals. citeturn20view0turn19view2turn21view0turn29search11turn23view0turn23view2
The second family is open-source orchestration and memory frameworks. LangGraph positions itself as an orchestration runtime with durable execution, human-in-the-loop control, persistence, and long-term stores; LlamaIndex offers agent workflows and memory customisation; CrewAI focuses on collaborative multi-agent systems with flows, memory, and observability; and Hugging Face’s smolagents keeps the abstractions deliberately small, centring multi-step code- or JSON-based tool use. These are closer to “agent operating systems” than to thin API wrappers. citeturn16search4turn28view1turn16search3turn16search11turn16search1turn16search13turn16search2turn16search6
The third family is coding-agent workbenches and capability systems. Claude Code, OpenCode, Codex/OpenAI Skills, and Pydantic AI Harness all expose agent behaviour through project-native files: CLAUDE.md, AGENTS.md, command directories, capability libraries, plugins, MCP servers, and bundled skills. This family is especially relevant to your proposal because it already treats the repository as a live boundary for instructions, tools, and reusable behaviours—even if it usually stops short of full knowledge lifecycle management and cross-repo flattening. citeturn19view0turn26view0turn26view1turn35view0turn27view1turn27view3turn38search1turn38search6
A striking market-wide pattern is the move away from “put everything in the prompt” toward selective loading. OpenAI now supports tool search to defer tool definitions until needed; Pydantic AI introduced on-demand capabilities and explicitly warns that large visible toolsets degrade model behaviour; Anthropic’s subagents preserve context by pushing exploration into a separate window; and OpenCode includes automatic compaction and optional pruning when context is full. Any serious implementation of context composition should therefore distinguish between a logical unified surface and the much smaller active working set shown to the model at any given turn. citeturn37view0turn27view1turn19view1turn35view0
How the leading vendors are approaching the problem
OpenAI is currently the clearest example of an API-first agent stack. Its Responses API is positioned as the main primitive for stateful, tool-using workflows; the Conversations API persists long-lived state; the Agents SDK adds reusable agents, handoffs, tracing, sessions, guardrails, and approval flows; MCP support is first-class; and OpenAI’s tools stack includes file search, tool search, shell, computer use, and versioned skills. In practical terms, OpenAI is solving context composition through platform-managed state, deferred tool loading, reusable skill bundles, and protocol adapters, not through a repo-native memory model. citeturn20view0turn20view1turn20view3turn37view0turn38search1turn38search4
Anthropic is solving the same problem from a context-engineering and coding-agent perspective. Claude Code gives each project an auto-memory directory with a MEMORY.md index and topic files, while CLAUDE.md remains the repo-local instruction surface. Subagents get separate execution windows for context savings, and Anthropic’s published guidance is unusually explicit that the best long-horizon agents mix up-front context with runtime exploration rather than relying on huge windows alone. The limitation, relative to your idea, is that Claude’s auto-memory is machine-local rather than Git-native, so it is durable for the agent but not inherently versioned or shareable as a repository artefact. citeturn19view0turn19view1turn19view3
Google has perhaps the most complete “context infrastructure” story. ADK is an open-source, multi-language agent framework; session.state is explicitly described as the session’s scratchpad; Memory Bank provides a managed persistent memory layer; Agent Registry provides an organisational catalogue for agents, MCP servers, and tools; the platform exposes MCP server support; and A2A, originally developed by Google and now under the Linux Foundation, targets agent-to-agent interoperability across frameworks and vendors. Conceptually, Google is closest to your proposal on the axes of scratchpad vs persistent memory, governed registries, and cross-agent composition—though again as managed services rather than as a Git-centred repository abstraction. citeturn21view0turn36view0turn21view1turn41view0turn29search2turn39search1turn21view3
Meta is notably more model- and API-centric. The Meta Model API / Llama API documentation advertises tool calling, reasoning controls, files, structured output, moderation, fine-tuning, and OpenAI compatibility. That is enough to support capable agentic applications, but it is less obviously a complete first-party agent platform in the way Google, Microsoft, OpenAI, and Anthropic now present theirs. For your idea, Meta currently looks like the least opinionated vendor: strong building blocks for tool-using agents, but fewer visibly integrated primitives for lifecycle memory, repo-native curation, or inter-agent governance. citeturn30search1turn30search2turn8search9turn30search0
Microsoft is taking an enterprise orchestration route. The new Agent Framework is described as the direct successor to AutoGen and Semantic Kernel, combining AutoGen’s agent abstractions with Semantic Kernel’s enterprise features such as session-based state, type safety, middleware, and telemetry, while adding graph-based workflows. Copilot Studio’s generative orchestration and connected-agent patterns go further into modular delegation, knowledge selection, and governance, including explicit warnings about data handoff, privilege boundaries, and auditability when one agent calls another. This lines up strongly with your “owning entity” and “quality gate” intuition: Microsoft’s view is that modularity only works if governance and descriptive metadata are first-class. citeturn23view0turn23view1turn23view2turn23view3
The open platforms closest to your idea
Pydantic AI is one of the best conceptual matches for the “composition” half of your idea. It is model-agnostic, type-safe, and explicitly designed for production workflows. More importantly, it treats a capability as a reusable, composable unit of agent behaviour that can bundle tools, lifecycle hooks, instructions, and model settings. It also supports on-demand capability loading when toolsets get too large, graph-based state machines for complex multi-agent flows, durable execution integrations, and MCP both as a client and as a server. If your proposal became a library rather than a product, Pydantic AI is probably the closest existing substrate for expressing “context modules” as typed capabilities with explicit loading semantics. citeturn27view0turn27view1turn27view2turn27view3turn27view4
OpenCode is one of the best matches for the repository-native half. It already supports Git-committed AGENTS.md instructions, markdown-defined per-project commands in .opencode/commands/, custom tools, specialised agents, MCP server configuration, reference directories that can point at external locations or Git repositories, and a layered configuration model spanning organisational defaults, user preferences, project config, and .opencode directories. It also exposes instruction globs, context compaction, permissions, plugins, and snapshots. In other words, OpenCode already behaves like a lightweight context repository for code-agent work—even though its focus remains coding workflows rather than a full promotion ladder from fetched evidence to shared knowledge base. citeturn26view0turn26view1turn26view2turn26view3turn35view0turn35view1
A useful reference point alongside those two is LangGraph / LangChain memory. LangGraph separates short-term thread state from long-term stores; long-term memories are JSON documents organised by namespace and key; and the conceptual guide explicitly distinguishes semantic, episodic, and procedural memory, including organisation-level memory and few-shot style episodic recall. This is not the same as your repo model, but it shows that the field is already comfortable with hierarchical memory namespaces, read/write memory tools, and shared policy-like memory. citeturn28view1turn28view0turn34search0turn34search2
Taken together, Pydantic AI and OpenCode strongly suggest that your proposal is not fighting the grain of the ecosystem. The missing piece is the single abstraction that unifies repo structure, memory lifecycle, skill promotion, and cross-context imports. Today, OpenCode gives you a repo-native shell for instructions and commands, while Pydantic AI gives you a strong abstraction for composable typed behaviours. Your idea would sit almost exactly at their intersection. citeturn26view0turn35view0turn27view1turn27view3
The scientific state of the art behind context composition
The modern agent literature starts from tool use and action loops. ReAct showed that interleaving reasoning and acting improves performance and interpretability for tasks that require both planning and external information access. Toolformer showed that models can learn when and how to call tools via self-supervision. These two works anchor most current agent frameworks, even when product documentation no longer references them directly. citeturn11search1turn11search2
The next important layer is memory and reflection. Generative Agents introduced the now-familiar observation–reflection–planning pattern with an explicit memory stream. Reflexion explored verbal reinforcement and self-critique. Voyager added an ever-growing skill library of executable code and showed how a skill repository can compound capabilities over time. MemGPT then reframed long-horizon work as virtual context management with memory tiers, directly analogous to paging between fast context and slower external storage. Your proposal’s “promotion ladders” are unusually well aligned with this trajectory, especially the move from raw traces to reusable skills. citeturn12search0turn12search1turn12search2turn11search3
The retrieval literature has also moved beyond flat chunking. RAPTOR builds hierarchical summaries for tree-organised retrieval; GraphRAG argues for graph-structured organisation of private corpora; HippoRAG uses a knowledge-graph memory inspired by hippocampal indexing and HippoRAG 2 explicitly tries to bridge the gap between factual memory and more associative “sense-making” retrieval. These systems matter for your idea because they show that knowledge-base structure is now a first-order design choice, not a trivial implementation detail. A composed context surface will probably need more than one substrate: raw files, hierarchical summaries, and graph-style relational views are all useful for different retrieval tasks. citeturn14search0turn12search3turn14search1turn14search7
Recent surveys make the same point more abstractly. One 2026 survey formalises memory evolution as Storage, Reflection, and Experience; another frames the field through forms, functions, and dynamics; a broader 2025 survey on LLM agents unifies architectural foundations, collaboration mechanisms, and evolution; and the planning survey shows that decomposition, plan selection, external modules, reflection, and memory are deeply coupled rather than separable concerns. The academic direction is clear: long-horizon agents are being understood less as “LLM + prompt” and more as systems that accumulate, compress, revise, and operationalise experience. citeturn31search3turn31search4turn31search6turn31search2
Several 2026 papers are especially close to your specific design. Infini Memory argues that persistent memory should be maintained as topic-structured documents rather than isolated records or fragments, with staged writes and periodic consolidation. Experience Compression Spectrum explicitly unifies memory, skills, and rules as points on a continuum of increasing compression, and argues that current systems lack a principled lifecycle that moves information across levels. MemOS goes further and argues that memory should be treated as an explicit, schedulable, governable resource with structured representations, unified interfaces, version control, and access governance. These are not yet settled engineering standards, but they are strikingly aligned with your notion of cache → memory → knowledge base → skills/rules under an owned repository boundary. citeturn33view0turn33view1turn33view2
The empirical story is also sobering. LoCoMo shows that even with long contexts and RAG, current systems still lag humans on very long conversational memory. LongMemEval reports substantial accuracy drops on sustained interactive memory tasks, and LongMemEval-V2 shows that environment-specific “experienced colleague” memory for web agents remains difficult, with strong systems still trading accuracy against latency and cost. So the scientific background supports your instinct that this is a practical systems problem—but it also shows why it is worth treating as a research problem in its own right. citeturn14search2turn25search0turn25search1
Where this is likely to go next
The strongest near-term trend is toward lazy, selective context composition. Anthropic explicitly recommends hybrid designs that mix pre-computed context with autonomous exploration; OpenAI’s tool search dynamically loads tools only when needed; Pydantic AI’s on-demand capabilities exist precisely because monolithic visible toolsets are expensive and error-prone; and OpenCode and OpenAI both now treat compaction as ordinary infrastructure for long-running sessions. The implication for your design is important: a flattened composed surface should be navigable by the agent, but only a small active slice should usually be materialised into the live prompt. citeturn19view3turn37view0turn27view1turn35view0turn32search0
The second trend is toward promotion from traces into more compressed artefacts. Research is increasingly converging on the idea that raw histories are too expensive and too noisy to remain the main unit of reuse. Memory, skills, and rules are being treated as progressively more compact representations of the same underlying experience, and platforms are already exposing the engineering equivalents: OpenAI skills are reusable, versioned bundles; Voyager demonstrated an ever-growing skill library from traces; and Infini Memory argues for buffered writes and periodic consolidation into topic documents. This is the scientific justification for your two ladders: one for code maturity, one for knowledge maturity. citeturn33view1turn38search1turn12search2turn33view0
The third trend is protocol-driven interoperability. MCP has become the main open protocol for exposing resources, prompts, and tools, with resources identified by URIs and designed for listing, reading, templating, and change notifications. A2A targets agent-to-agent communication, discovery, skills, and task exchange across frameworks and vendors. Google’s Agent Registry adds the organisational catalogue layer on top. If context composition becomes a real category, I would expect it to succeed fastest when it can be compiled outward into MCP resources/tools and A2A-discoverable agent capabilities, rather than remaining a purely local file convention. citeturn40view1turn40view0turn39search1turn39search8turn41view0
The fourth trend is governance and security. The more durable and composable memory becomes, the more it becomes a target. MCP’s specification emphasises user consent, data privacy, and tool safety; OpenAI recommends approval by default and explicit logging for MCP tool calls; Microsoft warns that connected agents can bypass privilege boundaries if poorly governed; and the newest memory-security literature shows that poisoned long-term memory can bias retrieval, tool selection, and control flow across tasks. Your emphasis on an “owning entity” and curated promotion is therefore not just a product-management preference; it is likely to be a security requirement. citeturn40view1turn20view3turn23view3turn25search2turn25search5turn25search19turn25search16
The bottom line is that context composition is a plausible next abstraction layer. The field already has the pieces: repo-local instruction files, scratchpads, durable memory stores, typed capabilities, skill bundles, MCP resources, A2A discovery, compaction, and governed registries. What is still mostly missing is a coherent abstraction that says: this repository is the quality-gated unit of knowledge, skills, memory, and experiments; these artefacts can be promoted across lifecycle tiers; and these repositories can compose into a logical context surface without collapsing into prompt chaos. In that sense, your idea is well aligned with where both industry practice and the research literature appear to be heading. citeturn19view0turn26view0turn27view1turn28view0turn38search1turn40view1turn39search1turn33view1