The Attention Name System is Copass’s unified addressing layer. Anything an AI system attends to — a sandbox, a data source, an agent, a context window, a compute session — gets a stable, human-readable address inside one namespace. DNS gave hosts a single address space. ANS does the same for attention.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 address scheme
Every piece of your sandbox in Copass has an address of the form:o://— the scheme. Recognizable, distinct fromhttps://.<handle>— the owner’s Copass ID, e.g.alice. Handles are globally unique.<resource_type>—sandbox,agent,datasource,project,compute-session, etc. The taxonomy is open.<id>— the stable identifier within the resource type’s namespace.- Optional sub-paths — for nested resources (a data source lives inside a sandbox, a project inside a sandbox, etc.).
Why this matters
One namespace, three Routers
AgentRouter, ContextRouter, and ComputeRouter all resolve through ANS. Same address shape, same resolution semantics, same audit trail.
Stable references across providers
An agent’s address (
o://alice/agent/support) is stable whether the agent runs on Anthropic, Google, or self-hosted Hermes. Provider portability has a real addressing layer behind it.Cross-Router composition
o://alice/sandbox/sb_abc is what an AgentRouter call passes to ContextRouter for retrieval and to ComputeRouter for sandbox isolation. Three Routers, one address.The lock-in is the namespace
Switching providers within Copass is a flag. Switching out of Copass means rewriting every address your application holds. The namespace is the moat.
How it shows up in your code
You usually don’t construct addresses by hand — the SDK and CLI do it for you, and you receive them when you create resources:What ANS does that you don’t see
ANS is not just the address format — it’s the resolution layer that decides what a given address points to right now:- Provider portability — when AgentRouter swaps from Anthropic to Google, the agent’s address (
o://alice/agent/support) doesn’t change. ANS resolves it to the right backend per call. - Compute attachment — when an agent runs, ANS resolves which compute session is current for
(user, sandbox). Move the workload to a different ComputeRouter provider; the address stays the same. - Context Window lifecycle — context windows get addresses too. ANS knows which window is active for a session and routes retrieval reads accordingly.
Comparison to DNS
| DNS | ANS | |
|---|---|---|
| Names | hosts (copass.id) | attention targets (o://alice/agent/support) |
| Resolves to | IP addresses | resource backends — Anthropic for an agent, Daytona for compute, etc. |
| Stability | DNS records change rarely | Backends behind an address can change every call (provider routing) |
| Authority | global (ICANN) | scoped to Copass (the platform is the registry) |
| Public scheme | https://, ssh://, etc. | o:// |
Why we built it
The fragmentation problem: an AI system that wants to use Claude one day, GPT the next, Gemini the day after, while keeping the same memory, the same integrations, and the same end-user identity, has nowhere to put a stable reference. Provider SDKs give you IDs in their namespace. Vendor lock-in starts at the address layer. ANS gives every piece — across context, agents, and compute — a single stable address that survives provider swaps. Once your application holdso://alice/agent/support, that reference is yours forever. The Routers handle the swap; the address doesn’t move.
This is what makes Portable Context work in practice. The decoupling thesis isn’t a marketing claim — it’s an addressing-layer choice.
Next steps
- Context Router — Sandboxes — the most common ANS-addressable thing.
- AgentRouter overview — how an agent’s ANS address resolves to a provider runtime.
- ComputeRouter overview — how a compute session attaches to an ANS address.
- Portable Context — the principle ANS makes practical.

