Scope, realm, and rescope
Project global capabilities into a safe runtime world for each agent
global defaults + agent-local shadowingHow can two agents see different tools, personas, and working directories in one process?
Companies in one building share elevators and fire systems but keep separate access, offices, and equipment. A realm bounds service publication; a scope is the access card you currently hold.
Mechanism
createScope/scopeOf/scopeTarget provide zero-dependency scope primitives. Registries and event dispatch resolve the current agent target at call time.
Agent creation mounts presets and local contributions inside agent.ctx. Local names shadow global defaults and unwind with the agent.
Declare defaults
Deployment-level providers and tools live in the root world.
What extensions must preserve
- Agent-local capabilities must not publish into the root service realm
- Scope filtering occurs in the authoritative dispatch path
- Scoped registration identity must be protected
The tempting wrong turns
- ×Treating cwd as a complete isolation boundary
- ×Manually filtering a global array by agentId
- ×Allowing user presets to publish services to the root realm
Do not trust the conclusion—verify it
These anchors are pinned to official deepseek-harness@47f9438; account for later breaking changes when reading current upstream.
Pause for ten seconds before revealing
Why do tool restrictions not filter tools registered inside the agent scope?
Scope solves runtime isolation; profiles, bundles, and patches solve boot-time product composition.