New: Ask reason for a cited answer
Context Repo

What Is an AI Context Repo for Agents?

What an AI context repository is, what belongs inside it, and how humans and connected agents retrieve shared prompts, documents, and collections.

Context Repo Team

10 min read

We built Context Repo because AI tools store context differently and do not share one portable repository by default. The prompt you wrote in Cursor on Monday may still be sitting in a project tab by Wednesday. Research uploaded to one Claude conversation and a system prompt tuned in ChatGPT remain attached to those products unless you deliberately save them somewhere shared. We call that shared layer an AI Context Repo for agents.

This article is the long-form answer to "what is that, exactly?"

What is an AI context repository?

A repository, in software, is a versioned store of artifacts plus the tooling that makes those artifacts useful: branches, history, diffs, search, access control. An AI context repository takes the same idea and applies it to the things AI agents actually consume.

In Context Repo, that means three primitives:

  • Prompts. Templates with ${variable} placeholder syntax. The original content is version 0, later content edits add snapshots that the dashboard can compare, and restore copies an earlier snapshot into a new current version.
  • Documents. Text artifacts processed through 75+ file formats via LlamaIndex Cloud. The source can be a PDF, a Word doc, a Markdown file, a code file, or a scraped webpage. Each document is embedded into a 1536-dimension vector space (a numerical fingerprint of meaning, so search finds ideas, not just keywords) and chunked for hierarchical navigation.
  • Collections. Named groups of prompts and documents. Read their members directly, or pass collectionId to deep_search or reason to restrict document-only retrieval. Collections and tags organize context; they are not credential boundaries.

On top of those primitives Context Repo exposes:

  • A 29-tool MCP server at https://contextrepo.com/mcp over streamable HTTP transport, the modern way Model Context Protocol travels over a normal web connection. It speaks JSON-RPC (the small shared message format AI tools already understand) and covers CRUD for prompts, documents, and collections, plus find_items, deep_search, deep_read, deep_expand, and version-history tools. Authentication runs over OAuth 2.1 with PKCE (the OAuth flow that lets you log in safely without a shared secret in the URL) or per-user API keys.
  • A 35-operation REST API under /v1 with the same authentication modes, documented in OpenAPI 3.1 at /openapi.json.
  • A Chrome extension that saves the visible ChatGPT or Claude conversation, captures a public page by URL through Firecrawl, or saves selected page content as a document. You can organize that document into a collection afterward.
  • A ChatGPT App for native ChatGPT integration. The hosted MCP server exposes the OpenAI Apps SDK Company Knowledge tools search and fetch.
  • Plain-text agent surfaces at /llms.txt, /llms-full.txt, /index.md, and /pricing.md for clients that prefer markdown grounding over HTML.

That is the shape of the repository: primitives in the middle, transports on the outside, the dashboard at contextrepo.com/dashboard for humans to manage everything in one place.

How is a context repository different from a vector database?

A vector database is a low-level index for similarity search. It stores embeddings (numerical fingerprints of meaning) and returns nearest neighbors. That is useful, and Context Repo sits on top of one (a 1536-dimensional vector space using OpenAI's text-embedding-3-small model). What the repository adds on top is everything you would otherwise have to build yourself:

  • Version history. Prompt content edits create prompt versions. Any changed canonical document field creates one document revision, while an exact unchanged document update is a no-op.
  • Document hierarchy. Long documents are chunked at three levels (document, section, paragraph). Agents can walk the structure with deep_search, deep_read, and deep_expand instead of dumping a 200-page PDF into context.
  • Prompt templating. Reusable templates with ${variable} placeholders stored verbatim, caller-managed substitution, literal or semantic prompt-body search through find_items, and non-destructive restore to a prior snapshot.
  • Collections. Curated bundles for organizing prompts and documents, with optional document-only retrieval through deep_search and reason.
  • Resource-scoped credentials. Per-user API keys (the gm_* keys, stored as a bcrypt hash rather than plaintext) with prompt or document read/write scopes. Collections share the document scopes; keys cannot be limited to one collection ID.
  • An MCP transport. The agent asks for context by intent ("find prompts about onboarding") instead of by raw embedding.

If you only need similarity search, you do not need this. If you need every other thing on the list, you do.

Why do we need this if ChatGPT, Claude, and Cursor already store history?

Each tool keeps its own history in its own format. A useful answer from ChatGPT can be buried in one conversation. A system prompt in Claude Projects does not automatically appear in Cursor. A reference PDF uploaded to one chat may need to be uploaded again elsewhere.

Three patterns sharpen the problem:

  • Prompts live where you wrote them. Cursor projects, ChatGPT custom GPTs, Claude Projects, and other system-prompt fields each have their own storage. They do not form one cross-vendor repository.
  • Documents live where you uploaded them. A spec PDF dropped into one client is not automatically available in another. Re-uploading it creates another client-specific copy.
  • Knowledge accumulates faster than you can re-find it. Even the tools that keep history make it hard to search across.

Keeping everything in a general notes app solves storage, but not universal agent access. An AI client still needs an integration layer and the right authorization to retrieve a template from that workspace.

A context repository is the integration layer.

What does Context Repo expose to agents and humans?

One repository, many ways in and out. Humans curate from the dashboard. Agents read and write through MCP or REST. The same prompts, documents, and collections are reachable from every surface.

Rendering diagram

We deliberately did not name this a prompt manager, a vector DB front end, or a team knowledge base. Those names exist and the category is saturated. The thing that was not built yet was a repository whose primary user is an AI agent acting on behalf of a human.

That shifts the design in three places:

  1. The wire format is agent-first. MCP isn't a UI library. It's a typed JSON-RPC contract (the small shared message format AI tools already speak) for tool calls. Context Repo tools have clear descriptions, typed input schemas, and readOnlyHint, destructiveHint, and idempotentHint annotations that help hosts reason about side effects and retries. All 29 hosted tools follow this contract.
  2. The retrieval primitives are agent-friendly. Agents do not want to dump a 200-page PDF into context. We expose deep_search for hierarchical chunk retrieval and deep_expand for navigating up to a parent, down to children, or sideways to siblings of a chunk. The agent walks the document tree the way a human walks the table of contents. Both find_items and the Company Knowledge search compatibility tool can surface prompts in semantic results; deep_search operates on document chunks.
  3. The discovery surfaces are agent-readable. /llms.txt, /llms-full.txt, /.well-known/mcp.json, /.well-known/agent-card.json, /.well-known/oauth-authorization-server (the OAuth metadata standard from RFC 8414), /.well-known/oauth-protected-resource (the protected-resource metadata standard from RFC 9728), and the OpenAPI spec at /openapi.json all exist so an agent encountering Context Repo for the first time can describe what it does and how to use it without a human in the loop.

The pattern generalizes. Anyone building a product that AI agents will consume on a user's behalf is building a context repository at some level. We just made the layer reusable.

What belongs in a context repository (and what doesn't)?

A few honest boundaries are useful.

What belongs:

  • Prompt templates you want to reuse across tools.
  • Research documents, product specs, and reference material.
  • Web pages worth keeping, saved by URL and refreshed later to stay current.
  • Conversations, decisions, and session handoffs saved from ChatGPT, Claude, or another agent.
  • Collections that group related prompts and documents.

What doesn't:

  • Bulk application data or your own embedding pipeline (your app's database).
  • Secrets, credentials, or PII (a secrets manager's job).

Context Repo accounts belong to one person today; there are no shared org workspaces, member seats, or org-level roles. Within one account, every tool and agent you connect works from the same context, each with its own API key scoped to prompts, documents, or both. Document edits made through MCP must name the revision they are based on, so one agent cannot silently overwrite another's edit. Documents that several agents edit at once can also require a lease through the REST API. To share with people, publish a prompt or document as a read-only public link from the dashboard.

Is Context Repo open source?

Partly. The MCP server is open source. The hosted product is not, but it exposes documented MCP and REST interfaces that you can use to read your stored resources.

  • The MCP server package is published as context-repo-mcp on npm. Source lives on GitHub at github.com/Gitmaxd/context-repo-mcp.
  • The hosted platform runs on Convex (the backend and database that powers reactive dashboard subscriptions) and Clerk (the auth and billing provider that handles OAuth for MCP). Each MCP read retrieves the current stored state.
  • Vectors are 1536-dimensional using OpenAI's text-embedding-3-small model. Rate limits use sliding windows: 10 scrape-family calls per minute, 100 API-family calls per minute, and 120 read-only calls per minute.

Everything else (the 29 hosted MCP tools, the 35 REST operations, the OpenAPI spec, the agent.json manifests) is a thin surface on top of those primitives.

When should you reach for a context repository?

The shape of people who get value here is fairly specific:

  • You use three or more AI clients in a given week (Claude, Cursor, ChatGPT, VS Code, Windsurf, Factory, Amp).
  • You have prompts you actually reuse (onboarding prompts, research prompts, code-review prompts).
  • You upload the same documents to multiple chat tools and lose track of which version is current.
  • You want a single audit trail of how a prompt changed over time.

If your AI use is occasional and single-tool, you may not need this yet.

Updated

Your questions, answered.

  • An AI context repository is a single store for the prompts, documents, and collections an AI agent needs to do its work. Prompts and documents carry version history; collections organize those items. Compatible tools can reach the same repository through the Model Context Protocol (MCP) or a REST API.

More articles