Your agent now knows Runpod
better than anyone

Every product requirement, tech spec, service dependency, and architecture decision. All queryable by any AI agent via MCP or HTTP.

🗒

Knowledge is scattered

Requirements live in Notion. Specs live in Google Docs. Architecture lives in people's heads. Decisions live in Slack threads that scroll away.

🤖

Agents work in silos

Each repo has its own CLAUDE.md. Each agent gets a different slice of truth. Skills and prompts aren't shared. One team's agent doesn't know what another team's knows.

🚫

Context dies with the session

When your agent conversation ends, everything it learned is gone. The same gotcha gets re-discovered by different people every week.

🔍

Nobody can answer "what are we building?"

Without asking 3 people and checking 4 tools. There's no single place to see all products, their status, and what's blocking launch.

Context is a single, version-controlled database that holds all of Runpod's product intelligence. Humans browse it through the Explorer. AI agents query it through MCP or HTTP. Learnings persist across sessions. The same source of truth serves everyone.

For everyone

Search requirements, specs, and architecture across all products. No GitHub access needed — just a browser.

For agents

Any AI tool (Claude Code, Cursor, Codex) can query the full product context via MCP. Your agent knows what Runpod is building before you write a line of code.

For the org

Learnings, patterns, and gotchas are stored permanently. Institutional knowledge doesn't quit when people change teams.

  1. Browse the Explorer

    Open the Explorer and log in with Okta. No setup needed — see every product, requirement, and spec right now.

  2. Connect your agent

    Create a token, then run the one-liner below to connect Claude Code, Cursor, or any MCP client.

  3. You're connected

    Your agent can query requirements, architecture, and learnings. Humans and agents share the same source of truth.

claude mcp add --transport http context "http://dev-context.runpod.dev/mcp?token=ctx_YOUR_TOKEN"
Run in your terminal
claude mcp add --transport http context "http://dev-context.runpod.dev/mcp?token=ctx_YOUR_TOKEN"
Or add to ~/.mcp.json
{ "mcpServers": { "context": { "type": "http", "url": "http://dev-context.runpod.dev/mcp?token=ctx_YOUR_TOKEN" } } }
Add to .cursor/mcp.json
{ "mcpServers": { "context": { "url": "http://dev-context.runpod.dev/mcp?token=ctx_YOUR_TOKEN" } } }
Command Palette > MCP: Add Server
1. Open Command Palette Cmd+Shift+P 2. Run "MCP: Add Server" > select "HTTP" 3. Enter URL: http://dev-context.runpod.dev/mcp?token=ctx_YOUR_TOKEN
Run in your terminal
codex mcp add context --url "http://dev-context.runpod.dev/mcp?token=ctx_YOUR_TOKEN"
/ship

Tell your agent what to build. It handles the full lifecycle: requirements, specs, codebase exploration, implementation, review against acceptance criteria, and syncing back to the database.

/context

Query product requirements and architecture directly.

/prd-authoring

Create PRDs with domains and requirements.

/spec-authoring

Write technical specs with failure modes and rollout plans.

/pre-implement

Compile a brief from requirements, specs, and architecture.

All skills are auto-discovered via load_skill. No extra setup.

You talk to your agent. It queries Context behind the scenes and comes back with real, structured answers.

Claude Code

Markdown files, Notion pages, and CLAUDE.md work until they don't. Here's why structured data wins.

Scattered files
Different agents see different things

Each repo's CLAUDE.md has a partial picture. Agent in repo A doesn't know what repo B's agent knows.

Stale within weeks

Docs drift from reality. Nobody updates the Notion page after the design changes. The CLAUDE.md references a function that was renamed.

Can't query, only read

"Show me all P0 requirements blocking launch" requires opening 12 files. There's no way to filter, sort, or join across documents.

No relationships

A requirement mentions a service by name. But there's no link — rename the service and nothing updates. No way to trace intent to code.

Context dies with the session

Agent discovers a gotcha, works around it, conversation ends. Next person hits the same wall.

Structured database
One source, every agent

Every agent in every repo queries the same database. Same requirements, same architecture, same learnings.

Version-controlled like code

Every change is a commit. You can diff, branch, review, and roll back. The database is the audit trail.

SQL — filter, sort, join, search

"Show me all P0 requirements blocking launch" is one query. Cross-reference requirements with services, specs, and learnings instantly.

Typed edges, enforced links

Requirements link to services via edges. Specs link to requirements. Merge gates enforce completeness — no orphans allowed.

Learnings persist forever

Agent saves a gotcha. It surfaces automatically the next time anyone touches that service. Institutional memory that doesn't quit.

Product requirements

PRDs, requirements, acceptance criteria, and specs. Queryable via SQL.

Tech stack & architecture

Every service, dependency, and ownership boundary in one graph.

Full-text search

Search across every PRD, requirement, spec, and service.

Learnings

Gotchas and patterns discovered during implementation, shared across the team.

Inspired by DO-178C (aerospace) and ISO 26262 (automotive) — industries where you must trace every requirement from business intent to running code. Context enforces the same chain for Runpod: no orphaned specs, no unlinked requirements, no surprises.

PRD
What product are we building?
e.g. "Pods", "Serverless", "Billing"
Domain
What area of the product?
e.g. "Pod Lifecycle", "Billing Events"
Requirement
What must it do?
e.g. "Users can stop a running pod"
Acceptance Criteria
How do we verify it?
e.g. "Pod status is 'stopped' within 30s"
Tech Spec
How do we build it?
API design, failure modes, rollout plan
Service
Where does the code live?
e.g. runpod/pods-api, runpod/billing

Every link in this chain is a queryable edge in the database. You can trace any requirement back to the business intent that created it, or forward to the service that implements it. Merge gates enforce completeness — you can't land a spec without linking it to requirements.

Your agent sends SQL queries. The database answers instantly.

context query