While using different agent tools and creating skills for my team, I keep encountering the same problems:
- CLI agent sessions are opaque. Unless users inspect local directories, sessions are difficult to track and manage.
- A single agent has limited access to useful context from previous sessions.
- Multiple agents lack a stable mechanism for sharing context.
- Skill and MCP configurations are distributed across global and project-level files.
- Teams lack a shared process for adding gotchas after a skill is created.
- General-purpose skills have no natural place for versioning and updates.
Repository-specific skills can live with the project and be managed through Git. General-purpose skills, such as PPTX or D2C skills, do not belong to one repository and therefore lack a clear owner.
Using several agents already creates persistent friction. Skill paths and MCP configurations differ between tools. A constraint explained to Codex remains unknown to Claude. A plan produced by Claude may need to be copied into Codex for review.
When several people collaborate, inconsistent context becomes a governance problem: which projects may use a skill, who may change it, and whether a rule is team policy or an individual preference.
I once reposted Linear's project documentation feature on X and wrote, “Linear is becoming the agent's context layer.” Several tools address parts of the same problem:
| Tool / Technology | Function |
|---|---|
| Linear, Multica | Turn plans and project documents into agent context |
| tape.systems / Bub | Store history as append-only fact logs and assemble it on demand |
| CC Switch, aghub | Manage skills and MCP configurations |
| Raft (formerly Slock) | Share context between agents and humans |
These problems point to the same conclusion: sessions, plans, memory, skills, and MCP should not remain separate categories of configuration. They should be managed as one system.
By context layer, I do not mean a specific product. I mean an infrastructure layer independent of any individual agent. Claude Code, Cursor, and other agent tools should be able to work on top of it.
These resources are usually treated as tool-specific configuration and managed through separate dotfiles. They need to be extracted from the agent itself: partly to reduce vendor lock-in, and partly to keep an appropriate distance from the codebase.
The full relationship is:
Harness → Context Layer → Project / Codebase
The boundary between the context layer and the harness is:
The context layer stores what persists across sessions. The harness orchestrates work within one session.
A complete context-layer management tool should provide:
- Unified management for sessions, plans, rules, skills, and MCP configurations
- A collaborative context space with permissions and sharing
- Search and management for historical sessions
- Version and permission management for skills and MCP configurations
- Session / plan blame, allowing agents to retrieve the conversations and reasoning behind code changes
- Periodic extraction of reusable patterns from sessions into reviewable skills or memory
- Version control for context, using a system such as Git
This layer is both input for future sessions and an archive of previous ones. The harness determines how context is used during a session. The context layer makes that context persistent, searchable, and shareable.
Based on token cost, the context layer can be divided into three categories:
| Type | Contents | Consumption model | Reason |
|---|---|---|---|
| Capability | Skills, MCP | Push MCP tools at session start; push skill metadata and pull the body when needed | Small and usually relevant |
| Rules | Rules, CLAUDE.md, AGENTS.md | Push at session start | Small and needed to constrain how work is performed |
| Records | Sessions, plans | Pull slices on demand through blame or search | Large and only occasionally relevant |
Keeping these categories together is not only useful for collaboration. They also transform into one another. Extracting a recurring pattern from a session and turning it into a skill is a conversion from record to capability.
Session blame is another example. To understand why code was changed, an agent needs the conversation at the time, the corresponding code, and the rules under which the agent worked.
Git blame can locate a line in a commit, but sessions and commits do not have a natural one-to-one relationship. Agent-generated changes may be edited before commit or split across several commits. A reliable link requires an explicit session anchor in the commit, such as a Session-id commit trailer. This allows the commit to refer back to its source session.
The anchor alone is insufficient. If sessions remain inside each person's local harness, a session ID still has no unified, persistent, and shared store from which to retrieve the conversation.
Session blame therefore cannot exist as an isolated feature. It depends on a context layer.
The final form of that layer is still unclear. It may be an MCP server, a CLI, a desktop application, or a web application paired with a daemon. Linear, Multica, and Raft may also continue moving in this direction.