Skip to main content

​
The problem at scale

Each coding agent has its own local memory — but none of them talk to each other. When multiple agents run in parallel across your organization, Engineer A’s agent enforces one set of conventions while Engineer B’s enforces another. The context is there, it’s just siloed.

​
The --read-only flag

When you connect with --read-only, the agent can read from the graph but cannot write to it: 
npx rippletide-mcp@latest connect --agent-id <agent_id> --read-only
This is what makes team-wide governance possible:
  • A team lead or platform engineer maintains the canonical Context Graph with all conventions, patterns, and policies
  • Individual engineers connect to it in read-only mode
  • Every agent session inherits the same standards without anyone being able to accidentally overwrite them
With --read-only, the generated .mcp.json includes the flag in the URL: 
{
  "mcpServers": {
    "rippletide-kg": {
      "type": "http",
      "url": "https://mcp.rippletide.com/mcp?agentId=<agent_id>&read_only=true"
    }
  }
}

​
Centralized policy, distributed agents

The Context Graph acts as shared engineering memory. The workflow:
1

Define your standards

A team lead stores conventions in a Context Graph — naming rules, component patterns, architectural decisions. This can be done through any MCP-connected client (Cursor, Claude Code) or the dashboard.
2

Connect every engineer

Each engineer runs the connect command in read-only mode in their project:
npx rippletide-mcp@latest connect --agent-id <shared_agent_id> --read-only
Their coding agent now has access to the full set of team standards.
3

Update once, propagate everywhere

When a convention changes (e.g., “we’re switching from REST to tRPC”), the team lead updates the graph. Every active agent session picks up the change on the next recall or get_context call. No PRs to update linting configs. No Slack messages hoping everyone reads them.

​
What this looks like in practice

New engineer onboarding: Instead of reading a 40-page style guide, their coding agent already knows the conventions. They start writing code that matches the team’s patterns from day one. Cross-repo consistency: The same Context Graph can be shared across multiple repositories. Frontend, backend, infrastructure — same naming rules, same error handling, same patterns. Audit trail: Every rule stored in the graph is an entity with a history. You can see what was added, when, and by whom through the dashboard.

​
Example: team setup

# 1. Team lead creates the shared graph (read-write)
npx rippletide-mcp@latest connect --agent-id team-standards-agent

# 2. Team lead defines conventions via their coding agent
#    e.g. "From now on, use camelCase for all variables"
#    The agent stores this in the Context Graph automatically

# 3. Every engineer connects in read-only
npx rippletide-mcp@latest connect --agent-id team-standards-agent --read-only

# 4. Every agent session now enforces the same conventions

​
Connecting to a teammate’s graph

You’re not limited to a single shared team graph. You can connect to any colleague’s Context Graph if they share their agent ID: 
npx rippletide-mcp@latest connect --agent-id <colleague_agent_id> --read-only
This is useful for pair programming scenarios or when ramping up on a codebase that one person knows well.