Skip to content

feat(agents): declarative spawn policy for Custom Agents (PR 1/6, agent-oriented workflow) - #107

Open
tournierjc wants to merge 1 commit into
mainfrom
feat/agent-spawn-policy
Open

tournierjc wants to merge 1 commit into
mainfrom
feat/agent-spawn-policy

Conversation

@tournierjc

Copy link
Copy Markdown
Collaborator

Part 1/6 of the agent-oriented workflow redefinition (spawn policy; follow-ups: model chain, session defaults, knowledge autoUpdate flag, containment, relationship panel).

What

Gives every Custom Agent a declarative spawn policy in its canonical agent.md:

x-mavis:
  spawnMode: master-only        # subagent-only | master-only | both (default)
  canSpawn: [orchestrator, mavis]  # stable names allowed to spawn this agent

How

  • Parsing: x-mavis.spawnMode/canSpawn in canonical-agent-config.ts (KNOWN_MAVIS_FIELDS, strict validation with diagnostics, round-trip serialization).
  • Domain gate (V2): service/agent/domain/spawn-policy.ts — evaluateAgentSpawnGate + LocalAgentService.getSpawnPolicy.
  • Task-spawn enforcement (V1 runners): one shared evaluateLocalTaskSpawnGate in local-task-runner.ts, called by both foreground and background runners after name resolution and before the task row — a denied spawn reads like Unknown agent with the policy reason. Parent identity is resolved to the stable owner name; canSpawn fails closed on an explicit restriction with unresolvable parent. Port plumbing via LocalAgentSpawnPolicyPort (fail-open when unbound).
  • User-create enforcement (V2): SessionLifecycleApplication.assertUserCreatableAgent rejects subagent-only targets with 403 AGENT_SPAWN_MODE_FORBIDDEN (TUI/CLI/HTTP POST /sessions).
  • Discovery: AgentDetail.spawnMode/canSpawn on the management listAgents response → available to mavis agent list and remote clients (feeds the future relationship panel, PR 6).

Composition / compatibility

  • Composes with, never replaces: features.delegation gate and canonical role tool ceilings decide capability; this decides permission between named Agents. Built-ins carry no Custom-file policy.
  • Absent policy = byte-for-byte today's behavior (fail open on missing policy/port/file).

Verification (run on this commit)

  • tsc (programmatic, standalone paths): 0 errors in touched files
  • run-vitest-suite.mjs capability: 231 files / 5630 passed (incl. 2 new suites registered in test/vitest-suites.json: gate table + canonical parsing/round-trip + master/subagent-only/canSpawn/fail-closed cases)
  • policy 142 passed, status-contract 9 passed
  • check:source + check:tsconfig pass; public-source.json regenerated (only the 4 added files)
  • Docs: docs/tui-capabilities.md § 'Agent spawn policy' (Kinetick-only section)

Co-Authored-By: Hermes noreply@nousresearch.com

Add x-mavis.spawnMode (subagent-only | master-only | both) and
x-mavis.canSpawn to the canonical agent.md, evaluated by a single
gate per entry point:

- task spawns (foreground + background runners) deny master-only
  targets from task children and enforce the canSpawn parent
  allowlist, failing closed on an explicit restriction;
- user-facing Session create (lifecycle application) denies
  subagent-only targets;
- the policy rides out through the management listAgents response
  (spawnMode/canSpawn on AgentDetail) for client-side graph UIs.

Agents without a declared policy behave exactly as before: the gate
fails open on missing policy, missing port, and unreadable files.
Built-in Agents keep the runtime-owned feature policy untouched.

Kinetick-only behavior, documented in docs/tui-capabilities.md.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants