agent_registry_spec - mark-ik/graphshell GitHub Wiki
Doc role: Canonical registry spec for agent_registry.
Status: Active / canonical
Kind: Atomic registry
Related docs:
- ../2026-02-22_registry_layer_plan.md (registry ecosystem and ownership model)
- SYSTEM_REGISTER.md (register hub and routing boundary)
Policy authority: This file is the canonical policy authority for agent_registry semantics and boundaries.
Policy in this file should be distilled from canonical specs and accepted research conclusions.
- Supervised-agent policy: Agent execution must run through supervised runtime coordination, not unmanaged threads.
- Boundary-ingress policy: Agent outcomes cross into app state via explicit intents/signals.
- Backpressure policy: Scheduling/load failures and throttling are explicit and diagnosable.
- Capability-declaration policy: Agent capabilities and side-effect classes must be declared and testable.
Defines background/autonomous tasks and their scheduling contracts.
In scope:
- agent registration
- spawn and schedule contracts
- agent capability metadata
Out of scope:
- control panel worker supervision itself
- core reducer semantics
- command surface UI
This registry is a named capability surface within the Register. It should expose stable lookup and capability contracts, keep failures explicit, and avoid hidden fallback semantics.
Canonical interfaces:
spawn(context)schedule(cron)describe_agent(id) -> AgentCapability
- Agents are explicit background capabilities, not hidden threads.
- Agent work crosses into app state through supervised intents.
- Failures and backpressure surface through diagnostics.
- policy-driven scheduling classes
- resource budgeting and pausing
- user-authored agents
- cross-mod coordination policies
- Registration, lookup, and fallback behavior are covered by registry contract tests.
- At least one harness or scenario path exercises the registry through real app behavior.
- Diagnostics channels emitted by this registry follow the Register diagnostics contract.
- Registry ownership remains explicit and does not collapse into widget-local or ad hoc fallback logic.