For teams running agent fleetsOpen source

Context management for software factories.

Your agents can reach everything and can't tell what's true. ctxpipe turns it into one organised, current, inspectable repo that the whole fleet reads over MCP.

Request early access
Book a demo

Pick the repos and tools each Workspace reads. Scope changes by pull request.

Connectors

Connectors

Connect external tools and choose what content ctxpipe should ingest.

  • GitHubSyncing
    Used in
    Payments · 1 team
    Account
    acme
    Scope
    .ctxpipe/sources.yaml · teams: [PAY]
  • LinearSyncing
    Used in
    Payments · 1 team
    Account
    Acme
    Scope
    .ctxpipe/sources.yaml · teams: [PAY]
  • NotionSyncing
    Used in
    Payments · 1 team
    Account
    Acme HQ
    Scope
    .ctxpipe/sources.yaml · teams: [PAY]
  • ConfluenceSyncing
    Used in
    Payments · 1 team
    Account
    acme.atlassian.net
    Scope
    .ctxpipe/sources.yaml · teams: [PAY]
  • SlackSyncing
    Used in
    Payments · 1 team
    Account
    Acme
    Scope
    .ctxpipe/sources.yaml · teams: [PAY]
  • PagerDutySyncing
    Used in
    Payments · 1 team
    Account
    acme
    Scope
    .ctxpipe/sources.yaml · teams: [PAY]
Linear synced. 14 files committed to acme/payments-knowledge.
The problem

Your agents can reach everything. That's the problem.

Every repo, ticket, doc, incident and Slack thread is one MCP call away. So agents read too much, trust the wrong parts, and you can't see why. More context hasn't made the fleet better. It's made it noisier.

  • Too muchThousands of files, tickets and threads. The context window fills with reading, not work.
  • Too noisyStale runbooks, duplicate docs and contradicting decisions all look equally true.
  • UnorganisedSpread across Linear, Notion, Slack and dozens of repos, with nothing linking a decision to its code.
  • OpaqueWhen an agent gets it wrong, you can't see what it read or why it believed it.
Example: one agent query returns 47 results from six tools. Most are stale, duplicated, contradicting or unlinked, one is current, and there is no record of which the agent trusted.
agent-3 · context for one taskExample
“What's our retry policy for payment capture?”47 results · 6 tools · 212k tokens
stale 9duplicate 14contradicts 6unlinked 17current 1
  • confluencePayments retries (2021)stale
  • notionRetry guidelines (draft copy)duplicate
  • slack#payments-oncall: “just bump retries to 5?”contradicts
  • linearPAY-212 Retry storm on captureunlinked
  • codecapture/retry.ts before #418contradicts
  • githubPR #391 Retry capture 3x (reverted)stale
  • confluenceRetry policy v2 (copy)duplicate
  • adrADR-019 Idempotency keys for capturecurrent
  • + 39 more
Which of these did the agent trust?no record
Solution

Write it down once. Keep it current. Serve it to every agent.

How ctxpipe works, in four steps.

  1. 01 · Connect

    Agents read your decisions, not just your code.

    Link your repos and pull in engineering context from Linear, Notion, PagerDuty and more. ctxpipe writes it to one git repo as Markdown, linked back to the code.

    • Code, tickets, docs, incidents
    • Markdown in your git
    • A Workspace per team or product
    capture-retries.md
    capture-retries.md
    ---
    kind: Pattern
    claims:
      - to: ../services/payments-service.md
        predicate: PART_OF
        confidence: 0.85
        valid_from: 2026-10-13
      - to: ../decisions/adr-019-idempotency-keys.md
        predicate: LINKS_TO
    ---
     
    # Payment capture retries
     
    Capture retries twice with an idempotency key
    (ADR-019, shipped in PR #418).
     
    Before Oct 13: 3 attempts, exponential backoff.
    The 2021 runbook (5 fixed attempts) is stale.
  2. 02 · Keep current

    Agents stop acting on stale docs.

    Every push to a linked repo is re-read. Each fact links back to where it came from, and expires when the code stops backing it. Every change is a commit you can revert.

    • One job, one commit
    • Contradiction flags
    Graph

    Nodes 348 · Edges 579 · Updated Oct 13

  3. 03 · Curate

    Fix what's wrong the way you fix code.

    Ask Workspace chat to correct or add knowledge. It works in its own sandbox, on its own branch, and nothing reaches main until you merge the pull request. It's your repo, so your own agents can edit it too.

    • A sandbox per conversation
    • Changes by pull request
    • Plain git
    Refund retrieschat/1

    Refunds should reuse the same idempotency middleware.

    Write that down for refunds and mark the runbook as superseded.

    2 changed files+12−1Open diff
    • knowledge/services/refunds.md
    • knowledge/decisions/adr-019-idempotency-keys.md

    ctxpipe pushed 2 files to ctxpipe/chat/refund-retries/1 and opened PR #57

    Continue the conversation…

  4. 04 · Serve

    Every agent starts from the same facts.

    Claude Code, Cursor, Codex and OpenCode search the same Workspace over MCP: knowledge, code and graph. ctxpipe returns sources, not answers. Your agent reasons with its own model and cites them.

    • npx ctxpipe init
    • 7 read-only tools
    • Any MCP client
    • Claude Code
    • Cursor
    • Codex
    • VS Code
    • OpenCode
    Refund retrieschat/1

    We're adding retries to refunds. What's our pattern for payment capture, and is the runbook still right?

    Read 4 files2 searches

    • Searchcapture retry
    • Read fileknowledge/patterns/capture-retries.md
    • Read fileknowledge/decisions/adr-019-idempotency-keys.md
    • Searchrunbook retries 2021
    • Read filegithub/pulls/acme/payments-service/418.md
    • Read filepayments-service/src/capture/retry.ts

    Capture retries twice with an idempotency key. That's ADR-019, shipped in PR #418 on Oct 13.

    The 2021 runbook says 5 fixed attempts. The code no longer does that, so treat it as stale.

    Refunds should reuse the same idempotency middleware.

    Source: knowledge/patterns/capture-retries.md

    Continue the conversation…

    ✻ Claude Code~/acme/payments-servicectxpipe

    >

    parallel

    ⏺ ctxpipe - search_knowledge (MCP)

    capture-retries.md L12–18

    adr-019-idempotency-keys.md L1–9

    ⏺ ctxpipe - search_code (MCP)

    ledger · post.ts :88

    checkout-web · capture.ts :41

    ⏺ ctxpipe - read_file (MCP)

    7 lines · main @ a41f9c2

    ⏺ ctxpipe - get_related (MCP)

    ADR-019 decided it · PR #418 shipped it · 2021 runbook superseded

    ⏺

    ↳ cites capture-retries.md:12 · adr-019 · ledger/src/post.ts:88

Your software factory

Your factory changes fast. Your sources are a mess. Context is the layer in between.

Building is cheap now, and harnesses get replaced every quarter. What carries over is what your org knows. ctxpipe keeps it organised and current from your code, tickets and docs, and serves it to whatever factory you run this year.

ProductYour product, prototypes, internal tools, new bets
Cheap to build
builds
FactoryAgent harnesses, central or per team: Claude Code, Cursor, Codex, your own agents, on any model
Changes fast
serves
ContextctxpipeOrganised, current, inspectable. In your git.
Stays current
reads
SourcesCode, tickets, docs, incidents, threads: agent-written, legacy, noisy
Different speeds

Swap the harness or the model. The context stays.

Designed for transparency

Nothing your agents read is hidden from you.

It's open source

The core is MIT licensed, including every job that writes to your Workspace. Read it, run it or fork it.

ctxpipe-ai/ctxpipe
public
licence
MIT
language
TypeScript
self-host
Docker Compose · Terraform · AWS CDK
View on GitHubStar on GitHub

Context is files in a repo

Every fact your agents read is a Markdown file in a git repo you own. Open it in any editor or point any tool at it.

knowledge/patterns/capture-retries.md
---
kind: Pattern
claims:
  - to: ../decisions/adr-019-idempotency-keys.md
    predicate: LINKS_TO
    valid_from: 2026-10-13
---
# Payment capture retries

History is git

Every change is a commit you can read, blame or revert. Jobs commit small and often; chat edits arrive as pull requests.

acme/payments-knowledgeexample
  • botctxpipe - Knowledge update of payments-service from extract_ingesta41f9c2
  • botctxpipe - Knowledge update of payments-knowledge from claims_upgradeb30d7c4
  • botctxpipe - Knowledge update of github from PR #4189f4e21b
  • botctxpipe - Knowledge update of slack from #payments-oncalle7c0d3a
FAQ

What your team will ask.

Getting started
How do we deploy it?
Two ways. Hosted: we run it for you (early access). Self-hosted: the MIT core runs on Docker Compose to evaluate, and Terraform or AWS CDK for production, with any OpenAI-compatible model provider, including Azure and Bedrock. When you self-host, ctxpipe's own servers are not in the data path. Self-hosting docs
What does early access involve?
We host ctxpipe for your team before general availability. You get priority onboarding (we help you set up your first Workspace, connect GitHub and your tools, and point your agents at it) and a direct line to the people building it. Your feedback shapes what we ship next.
Do we need GitHub?
Writable Workspaces need GitHub today. Any other git URL works as a read-only Workspace, with search, chat and the graph.
Why join the community?
The Discord is where you talk to the team directly: get help self-hosting, see what's shipping next, and argue for what should come after. It's also where other teams share how they structure their Workspaces.
How it compares
How is this different from Graphify and other code-graph tools?

Graphify maps one folder of code into a graph you regenerate. ctxpipe keeps a team's knowledge across many repos, plus the tickets, docs, incidents and PRs behind it, as Markdown in a git repo you own. It updates on every push, every change is a commit you can review, and the graph is a view you can rebuild, not the source of truth. Cross-repo and connectors are in the MIT core, not a paid tier.

Hosted context engines answer from an index you can't read, diff or take with you. With ctxpipe you keep the corpus itself. Where code-graph tools are stronger: symbol-level navigation (callers, references) and a one-command local setup.

How is this different from RAG over our docs?
RAG stitches an answer together from raw chunks on every question. ctxpipe writes your sources down as linked Markdown first and keeps those files current, so agents read knowledge that's already been extracted, linked, versioned and revertable.
Do we still need AGENTS.md files?
Keep them. ctxpipe reads the AGENTS.md files, skills and ADRs in your linked repos as knowledge, and gives each Workspace its own AGENTS.md so any agent knows how it's organised.
Control
Does ctxpipe write to our code repos?
No. It reads your code repos and writes only to the Workspace's own knowledge repo. Background jobs commit there directly, one job per commit and fast-forward only, so every change can be reverted. Edits from Workspace chat go through a pull request you merge.
Do you train on our code?
No. Hosted ctxpipe sends model calls only to zero-data-retention endpoints, so providers don't store or train on your prompts. SOC 2 is on the roadmap, not done. Self-host to keep everything, model calls included, inside your network. Data processing
Does ctxpipe call a model when our agents query it?
No. Over MCP, ctxpipe returns sources, not answers: knowledge sections, code and related context, each with a ref and line range. Your agent does the reasoning on its own model. Access is read-only and limited to the organisations you approve.
What happens if we stop using ctxpipe?
The Workspace repo stays where it is, with its full history. You lose the background upkeep and the index, not the knowledge. Point any agent or editor at the repo and carry on.

Give every agent the same context.

Hosted ctxpipe is in early access, with onboarding from the team that builds it.

Request early access
or self-host from GitHub