Agent Context Layer
6/13/2026
Recently, as I’ve been using various agent tools to complete tasks, or creating skills for my team, I’ve kept running into a few problems:
- CLI agent sessions are opaque to users, making them hard to track and manage unless you dig through the root directory
- A single agent struggles to extract useful context from past history
- There is no effective context-sharing mechanism between multiple agents
- Skill and MCP configurations are messy and scattered across global and project-level files
- According to Claude’s best practices, the most important part of a skill is the gotchas. But after a skill is created, how does a team continuously add to these gotchas together? For a code repository, you can put skills inside the project and manage them with git, but for general-purpose skills—like a pptx skill or a D2C skill—how do you manage those?
- Skill versioning and updates
Using multiple agents at once is friction most developers are already enduring. Each agent has its own skill paths, MCP configurations, and so on; reminders given in Codex are unknown to Claude, so you have to repeat them; Claude’s plan might be manually copied over to Codex for review.
Once collaboration enters the picture, the cost of inconsistent context escalates from “annoying” to “ungovernable”: which project can use a skill, who can modify it, who can add skills; whether a rule is a team consensus or just someone’s preference.
I once reposted on X about Linear’s new project docs feature and commented: “Linear is becoming the agent’s context layer.” In fact, besides Linear, many tools are doing similar things, but each only covers part of it:
| Tool / Technology | Function |
|---|---|
| Linear, Multica | Turning plans and project docs into agent context |
| tape.systems / Bub | Abstracting history into append-only fact logs, supporting on-demand assembly |
| CC Switch, aghub | Unified management of skills and MCP configurations |
| Raft (formerly Slock) | Context sharing between multiple agents / humans |
I’m increasingly sensing the presence of something: context, including sessions, plans, memory, skills, and MCPs (not necessarily all distinct things), should be managed as a unified whole.
By “context layer,” I don’t mean a specific product, but an infrastructure layer independent of any agent. Whether it’s Claude Code, Cursor, or other agent tools, they can all work on top of this layer.
In the past we treated these as configuration problems for each tool, managing them with their own dotfiles. But I’m increasingly convinced they need to be pulled out of individual agents and made into an independent layer. First, extracting them from the agent prevents vendor lock-in; second, it keeps an appropriate distance from the codebase.
So the full chain is: harness -> context layer -> project / codebase
Where is the boundary between the context layer and the harness?
context layer = the part that persists across sessions; harness = temporary orchestration within a single session.
My ideal context layer, or context-layer management tool, would look like this:
- A unified context management platform that integrates sessions, plans, rules, skills, and MCP configurations
- Context as a collaborative space, where members can collaborate, manage permissions, and share context
- Tools for managing and searching historical conversations, so agents can easily view and search past dialogue
- Unified management of skills and MCP configurations, including versioning and permission management
- Session / plan blame, so an agent can retrieve the detailed conversation and reasoning behind a code change
- Ability to periodically extract reusable patterns from sessions as skills and memories, which managers can review and add to the skills list
- Context should also be managed with version-control tools like git
This layer is both the input for future sessions and the savings from past sessions. The harness lives inside a single session, responsible for how to use this context. The context layer is the persistent, shareable infrastructure for the context in between.
The context layer can be further divided into three categories. How each is used depends on token cost:
| Type | What it is | How it is consumed | Why |
|---|---|---|---|
| Capability | skills, MCPs | MCP tools pushed into context at session start; skill metadata pushed / body pulled | Small and almost always relevant, preload |
| Rules | rules, CLAUDE.md, AGENTS.md | Pushed into context at session start | Same as above, constrains “how things should be done” |
| Records | sessions, plans | Pulled on demand via tools (blame / search) | Massive and only occasionally relevant, fetch a slice from the repository |
Putting these three categories in the same layer matters not only for team collaboration, but also because they transform into one another, and transformation requires them to be together. For example: periodically extracting patterns from sessions to turn into skills = records → capabilities
As mentioned earlier with session blame, if you want to know why a piece of code was changed a certain way, you need to look at the conversation at the time (records), the corresponding code, and the rules the agent was relying on. Git blame can already locate a line to a commit; the missing piece is commit → session. But this mapping does not happen automatically.
A session’s changes may be manually edited before committing, or split into several commits, so there is no natural one-to-one relationship between commits and sessions. To make this link reliable, you need to explicitly pin a session anchor to the commit: a commit trailer (the kind of key-value pair appended to a commit message, like Co-authored-by: Claude Code). If the agent appends a Session-id: line when committing, blame on that commit can stably link back to the original session.
Once the anchor exists, the agent can understand the reasoning behind a code change. Yet this feature is almost nowhere to be seen today, because sessions are not stored in a place that can be queried by code. They live inside each person’s local harness; even if a session id is pinned, there is no unified, persistent, shared repository where that id can retrieve the full conversation.
So session blame cannot work in isolation; it requires a context layer for this kind of feature to exist.
What will this context-layer tool ultimately look like? I’m not sure. It could be an MCP, a CLI, a desktop app, or a web app plus daemon. Any of them are possible. I don’t know what Linear / Multica / Raft will eventually evolve into.