The problem
Coding agents (Claude Code, Codex, Cursor) each have their own way to persist context —CLAUDE.md, .cursorrules, local memory files. But these mechanisms have two limits:
-
They don’t scale in size. Local files like
CLAUDE.mdare injected into the system prompt, which means they eat into the context window. The more rules you add, the less room the agent has to work. The Context Graph stores knowledge externally and the agent queries only what it needs viarecallandget_context. - They’re siloed per engineer. When one engineer defines coding rules in their agent, the rest of the team never sees them. Scale that to 10 engineers running parallel agents, and you get 10 diverging sets of conventions. Each agent “remembers,” but none of them share.
How the Context Graph fixes this
The Context Graph gives your coding agents persistent, structured memory. Instead of re-explaining your conventions every session, you store them once in the graph. Every agent session reads from the same source of truth. The graph stores your engineering standards as entities and relations:- Naming conventions —
camelCasefor variables,PascalCasefor components,UPPER_SNAKE_CASEfor constants - Architectural patterns — where to put hooks, how to structure API routes, which state management to use
- Design system rules — approved components, spacing tokens, color usage
- Error handling policies — how to handle API failures, logging standards, retry strategies
recall and get_context. No copy-pasting. No “remember to add this to the system prompt.”
Supported coding agents
Theconnect command generates configs for:
| Agent | Config file | Format |
|---|---|---|
| Claude Code | .mcp.json | JSON — mcpServers object |
| Cursor | .mcp.json | JSON — same file, same format |
| Codex | .codex/config.toml | TOML — [mcp_servers] table |