Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.copass.com/llms.txt

Use this file to discover all available pages before exploring further.

The ContextRouter is the what they know layer of Copass’s three-Router architecture. Your sandbox holds the data, the integrations, the memory, and the end users — separate from whichever agent runtime is reading from it. This is the data half of the decoupling. AgentRouter is who runs; ComputeRouter is where they run; ContextRouter is what they know.

​
What you can do

  • Spin up sandboxes — your tenancy boundary, free to create per app, environment, customer, or experiment.
  • Connect 3,000+ integrations via Pipedream, or register custom data sources you push to directly.
  • Ingest content into a sandbox so agents and retrieval have material to work with.
  • Group sources into projects for retrieval-scoped collaboration.
  • Query the knowledge graph through the discover / interpret / search retrieval gradient.

​
What you get with Context Router

ThingWhat it is
SandboxesTenancy boundary. Holds the vault prefix, encryption key, quotas. Starts empty.
ProjectsSandbox-scoped logical grouping. Retrieval scopes by project.
Data SourcesThe unit of attribution. Slack, GitHub, custom firehoses, your own MCP server.
IntegrationsOAuth’d apps from Pipedream’s 3,000+ catalog.
WebhooksInbound event push from your own systems.
IngestionThe activation step — pulling content through a source into the sandbox.
Retrievaldiscover / interpret / search over the knowledge graph.

​
Three paths

“What sandboxes do I have?” “Ingest this folder of docs.” “Connect my Slack workspace and add it to the support project.”

​
Via the CLI

copass setup                              # bootstrap a sandbox
copass ingest ./docs                      # fill it
copass integrations connect slack         # OAuth
copass discover "checkout flakiness"      # query

​
Via the SDK

import { CopassClient } from '@copass/core';

const client = new CopassClient({ auth: { type: 'api-key', key: process.env.COPASS_API_KEY! } });

const sandbox = await client.sandboxes.create({ name: 'my-app' });
const source = await client.sources.register(sandbox.id, { provider: 'custom', name: 'docs' });
await client.sources.ingest(sandbox.id, source.id, { text: '...', source_type: 'document' });

const menu = await client.matrix.discover({ query: 'checkout flakiness', sandbox_id: sandbox.id });

​
How ContextRouter powers agents

Every AgentRouter call is scoped to a ContextRouter sandbox. When an agent runs:
  • Tools come from the sandbox’s data sources — OAuth’d integrations and custom MCP servers light up automatically.
  • Retrieval (discover / interpret / search) reads from the sandbox’s knowledge graph.
  • Memory (the Context Window) lives in the sandbox.
  • End users are isolated inside the sandbox via endUserId — one sandbox, many humans, no cross-talk.
Switch agent providers (Anthropic ↔ Google ↔ Hermes) and the sandbox stays put. Everything the agent reads stays in ContextRouter; only the runtime moves.

​
Common patterns

One sandbox per app

Most apps need exactly one sandbox. Multiple end users live inside via endUserId. See Multi-tenancy.

Projects for team scoping

Share a sandbox with teammates but scope each grant to a project so they only see their slice. See Projects.

Custom MCP for internal tools

Your internal API as an MCP server, registered as a data source. Agents call it like any OAuth’d integration. See Custom MCP.

Webhook intake from your systems

Push events from CI, monitors, or internal services into a custom data source. See Webhooks.

​
Next steps

  • Sandboxes — start here; the foundation.
  • Ingestion — the activation step.
  • Retrieval — what you get back from the knowledge graph.
  • AgentRouter — the runtime that reads from your ContextRouter sandbox.
  • Portable Context — why the runtime can change without touching the sandbox.