AI Agents10 min read·

What Is an AI Context Repo for Agents?

What an AI context repository is, what belongs inside it, and how Context Repo gives humans and agents one home for prompts, documents, and collections across every AI tool.

By Context Repo Team

We built Context Repo because every AI tool stores context differently and none of them talk to each other. The perfect prompt you wrote in Cursor on Monday is sitting in a closed project tab by Wednesday. The research document you uploaded to Claude is gone when the session ends. The system prompt you tuned in ChatGPT is locked inside that one chat. The category we needed didn't exist yet, so we named it: 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. Versioned templates with ${variable} placeholder syntax. Each prompt keeps a full version history with diffs and one-click restore, so you can change the template every day without losing a previous iteration.
  • 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. Collections scope search (only retrieve from the client-x-research collection) and scope MCP access (give the Cursor IDE running on this laptop access to the dev-prompts collection only).

On top of those primitives Context Repo exposes:

  • A 28-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 29-operation REST API under /v1 with the same authentication modes, documented in OpenAPI 3.1 at /openapi.json.
  • A Chrome extension for one-click capture of any webpage straight into a collection.
  • A ChatGPT App for native ChatGPT integration via the Apps SDK.
  • 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. Every edit to a prompt or document creates a new version with a diff and a restore point. Metadata edits do not, so the history stays meaningful.
  • 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} syntax, full search across the prompt body, and atomic restore to any prior version.
  • Collections. Curated bundles that scope what an agent or a client sees.
  • OAuth-scoped sharing. Per-user API keys (the gm_* keys, stored as a bcrypt hash rather than plaintext, the same one-way hashing standard that protects passwords) with explicit read or write scopes.
  • 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 stores its own history in its own format and loses everything else. The good answer ChatGPT gave you last Tuesday is buried in a conversation you cannot search across. The system prompt you tuned in Claude Projects does not exist in Cursor. The reference PDF you uploaded to one chat is gone when the next one starts.

Three patterns sharpen the problem:

  • Prompts live where you wrote them. Cursor projects, ChatGPT custom GPTs, Claude Projects, and the system-prompt fields of a dozen other tools each have their own storage. None of them sync.
  • Documents live where you uploaded them. A spec PDF dropped into Claude is gone when the conversation closes. The same PDF re-uploaded to ChatGPT is now two copies of the same artifact in two opaque vaults.
  • Knowledge accumulates faster than you can re-find it. Even the tools that keep history make it hard to search across.

The reflexive solution ("just keep everything in Notion") fails because Notion does not speak MCP. The AI client you are talking to right now cannot reach into your Notion workspace and pull the prompt template you saved last week without an integration layer.

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. Every primitive in Context Repo has an MCP tool with a clear description, an inputSchema with typed properties, and a readOnlyHint or destructiveHint annotation so the calling agent knows whether the operation is safe to retry. All 28 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. find_items is the only tool that surfaces prompts in semantic results, so when an agent asks "what prompts do I have about onboarding," it reaches for find_items, not deep_search.
  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 and reference material.
  • Scraped webpages and product specs.
  • Saved conversations curated as documents (not raw chat logs).
  • Collections that scope what an agent can see.

What doesn't:

  • Live conversation history (the chat tool's job).
  • High-volume time-series telemetry (a real database's job).
  • Production application data (your app's database).
  • Secrets, credentials, or PII (a secrets manager's job).

Context Repo accounts are single-user today. There is no team workspace, no shared collection, no role-based access control beyond per-user API keys with scoped permissions. We made that call deliberately. The product earns its keep solving the cross-tool context problem for an individual practitioner first. Team features can come once the single-user version is sharp.

Is Context Repo open source?

Partly. The MCP server is open source. The hosted product is not, but it talks to you through open protocols, so you are never locked in.

  • 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 real-time backend and database that powers reactive subscriptions, so when you edit a prompt in the dashboard, the MCP server connected to your Cursor IDE sees the change instantly without polling) and Clerk (the auth and billing provider that handles OAuth 2.1 with PKCE for MCP).
  • Vectors are 1536-dimensional using OpenAI's text-embedding-3-small model. Rate limits use sliding windows through Upstash Redis: 10 scrapes per minute, 100 API calls per minute, 120 read-only calls per minute, with fail-open behavior if Redis is unreachable.

Everything else (the 28 MCP tools, the 29 REST endpoints, 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 do not need this. The product is overkill for an individual chatting with ChatGPT once a week, and we will tell you that on the pricing page before you sign up.