Agents & Cognition · 06.02
Affordance Matching: Routing by Capability, Never by Name
Every workspace agent is ranked ready, offline-capable, enablable, or incapable against a node's declared requirements — never a hardcoded agent name.
Six affordances, four categories
| Affordance | Category | What it grants |
|---|---|---|
browser | runtime | Controls a live Chromium/browser runtime through the harness. |
computerUse | runtime | Controls desktop applications through the host computer. |
fileSystem | workspace | Reads or writes workspace files through the runtime. |
codebaseIndex | workspace | Uses a harness-provided semantic code index. |
terminal | control | Runs shell commands or scripts through the runtime. |
nativeMcp | protocol | Calls Agentis MCP tools directly from the harness. |
Known even while offline
configuredAffordances() mirrors what a runtime would advertise given its stored config, without needing a live connection — so the canvas, readiness checks, and routing can reason about an agent's powers even while it's asleep. This mirror has to be kept in sync by hand with each adapter's own capabilities().affordances; it's a deliberate duplication in service of not needing to wake every agent just to ask "what can you even do."
potentialAffordances() goes further, answering what a runtime could satisfy after some setup step — the difference between "can't" and "can't yet." Prefer a workflow's own browser node for ordinary web automation instead of demanding native browser control on an agent; reserve the affordance match for when the task genuinely needs the harness's own capability.
Continue
How AdapterManager drives Claude Code, Codex, Cursor, Hermes, Antigravity, and HTTP runtimes through one normalized task/result contract.
How each task is classified and routed to the cheapest sufficient model tier, unless an explicit pin or override wins.