Contexo in the wild — six real scenarios, start to finish

“Contexo is GitHub for AI context” is a fine one-liner, but it doesn’t tell you when you’d reach for it — or how it actually works once you do. So here are six situations teams hit with AI coding agents, each walked through step by step. Every step maps to something Contexo does today.

1. Your agent forgets everything between sessions

The problem. Every fresh session starts at zero. You re-explain the auth flow, re-describe the architecture, re-warn about the same gotcha — then you get to work. That’s the context tax, paid daily.

How Contexo solves it, step by step:

1. One-time setup. In your project, run ctx init (scaffolds .contexo/ and writes the MCP config) and ctx hooks install (wires Contexo into Claude Code’s Stop hook).
2. You just work. After each turn, the Stop hook appends a compact record to a local session buffer at .contexo/raw/sessions/_pending/<session-id>.jsonl. No action from you.
3. You push. When you (or the agent) run a push and there’s a recent session plus new concept/analysis pages, Contexo pauses the push and asks the agent to capture the reasoning first.
4. The agent distills. Over MCP, it reads the session buffer (ctx_capture_session) and writes a source page (ctx_write_page) — the decision, the why, the rejected alternatives, the dead-ends — then re-pushes. Each push is a real git commit.
5. Tomorrow. A fresh session connects over MCP, calls ctx_pull, and reads the always-loaded project index (ctx://index) before doing anything else.

What you get. Every session starts already knowing the project — and the reasoning survives, not just the what.

2. Your team’s agents don’t share a brain

The problem. You spent a week teaching your agent the payments module. Your teammate’s agent has no idea any of it happened. Same repo, separate silos, duplicated effort.

How Contexo solves it, step by step:

1. You push your context to the shared repo — it’s a real commit on the server.
2. You invite a teammate. Mint an invite key and send it over.
3. They join and pull. One command joins the repo; the next pulls every page into their local .contexo/.
4. Their agent is now current — it reads the same index and pages yours does.
5. You manage the roster with ctx members (and ctx members remove <email> as owner).

What you get. One push and the whole team’s agents are current. Everyone’s AI works from a single source of truth instead of five private, drifting copies.

3. Onboarding burns your senior engineers’ time

The problem. Every new hire — and their AI — relearns the codebase by interrupting whoever has been here longest. The same questions, answered again.

How Contexo solves it, step by step:

1. Day one, they connect. The new hire installs the CLI, runs ctx login, and ctx join <invite-key>.
2. They pull the knowledge base. ctx pull brings down every distilled page the team has built.
3. Their agent reads the index (ctx://index) and searches for the area they’re starting in (ctx://search?q=billing).
4. It answers from the team’s context — the same decisions, gotchas, and reasoning everyone else’s agent uses — instead of asking a human.

What you get. New people and their agents ramp from the team’s accumulated context on day one, not month two, without taxing your seniors.

4. Your context is trapped in one tool

The problem. Your hard-won context lives in one tool’s chat history. Switch from Claude Code to Cursor — or run both — and you start from scratch.

How Contexo solves it, step by step:

1. Contexo runs as an MCP server (ctx mcp) over stdio — the open standard for connecting agents to tools.
2. ctx init registers it for Claude Code in .mcp.json. For Cursor (or any MCP client), add the same ctx mcp command to that tool’s MCP config.
3. Every tool pulls the same repo. Whichever agent you open calls ctx_pull and reads the identical context.
4. Contexo records who pulled. It reads the MCP client name on connect, so the activity feed shows whether Claude Code or Cursor fetched.

What you get. Your context is yours, not your editor’s. Switch tools, mix tools, or adopt a new one next year — the knowledge comes with it.

5. Your agent is quietly working from stale context

The problem. A teammate updated a context page an hour ago. Your agent is still acting on last week’s copy — and doesn’t know it.

How Contexo solves it, step by step:

1. A teammate pushes a change to a page; the server’s version of it moves ahead of your last pull.
2. Your agent opens that page over MCP (ctx://wiki/<slug>).
3. Contexo compares your last-pulled revision against the server’s current one.
4. If they differ, it prepends a drift notice to the page before the agent reads the body — so the agent knows the copy is stale (roughly):

<DRIFT_NOTICE> This page changed on the server since your last pull.
Consider pulling before you rely on it. </DRIFT_NOTICE>

5. ctx status flags it too, listing drifted pages so you can ctx pull before acting.

What you get. Your agent acts on current context — or knows to refresh first. No silent staleness steering decisions.

6. Two people edited the same page — and nobody wants a clobber

The problem. You and a teammate both refined the same context page. Whoever pushes last usually wins, and the other’s work quietly disappears.

How Contexo solves it, step by step:

1. You both pull the page, then edit it independently.
2. Your teammate pushes first. The server’s version moves ahead.
3. You push — the server rejects it as a conflict (HTTP 409).
4. Contexo hands your agent a merge directive with the common ancestor, your version, the server’s version, and a section-by-section map of what each side changed (roughly):

<MERGE_REQUIRED> page: payments-webhooks
  conflicting section:  ## Retry policy   (changed by both)
  auto-kept section:     ## Idempotency keys   (only you changed)
</MERGE_REQUIRED>

5. Your agent reconciles the conflicting section, writes the merged page (ctx_write_page), and re-pushes. Contexo advances your local sync state so the re-push lands cleanly.
6. Everything is reviewable. Because each push is a git commit, ctx diff, ctx history, and ctx evolution show exactly what changed — section by section, with blame.

What you get. Nothing is silently lost, and you review changes to your context the way you review code, not as a black box.

Here’s a real diff from a Contexo page. Notice it diffs frontmatter fields and whole sections — not raw lines:

Frontmatter is diffed field by field — here reasoning_summary was sharpened and three related links were added.

Added sections are shown whole, with a per-section line count (+6, +18).

And a removed section (−14 lines), so you can see exactly what context went away — and why.

The thread through all six

Different problems, one shape of fix: a single, versioned, MCP-native place your agents read from and write to. That’s the whole idea — give the context your agents run on the same discipline your code already has.

If any of these sound like your week, point Contexo at a project:

ctx init

…and let your agents start remembering. It’s open source and free to start — sign up at contexo.live, or star the repo on GitHub to follow along.