Skip to content

Smithers integration

Smithers is the constraint-convergence orchestrator. It does not present itself as a chat surface — it presents as a workbench around an issue. The agent-platform integration is at the harness layer: Smithers spawns agency-profile sessions through agencyInvoke and records iterations against HarnessRun.

Mounts and surfaces

From projects/matrix-3/packages/smithers/matrix.json:

ComponentMountSurface
SmithersSupervisorsmithersheadless (with browser companions)
ConstraintGraphchild of supervisorheadless
GitHubAdapterchild of supervisorheadless
ContainerManagerchild of supervisorheadless

The webapp at /apps/smithers/ (declared via webapp in matrix.json) is the workbench shell.

How Smithers uses system.agents

The supervisor's loop, as it relates to the agent platform:

  1. smithers.start arrives with { issueNumber }.
  2. ConstraintGraph is loaded for that issue.
  3. For each ready constraint, the supervisor calls agencyInvoke to spawn a propose session targeting the constraint's TargetRef.
  4. Activity frames stream back; ContainerManager may have spawned a Claude Code or Codex worker container if the profile's runtime preference required it.
  5. After the propose session completes, an evaluate session runs against the same target with the constraint's check set.
  6. The supervisor calls recordHarnessIteration with the propose+eval pair.
  7. Convergence is reached when all constraints are green; otherwise the supervisor decides whether to ratchet or escalate.

Why system.agents and not direct inference

Smithers's actor accept set (in its manifest) does NOT include $prompt — it isn't a chat surface. But its coding agent (coding-agent/CodingAgent.ts) imports @open-matrix/inference-catalog and uses nativeToolOracle directly for some cognitive steps. There is a documented goal to consolidate the cognitive substrate behind system.agents (P1.6 cognitive-stack workstream); today some Smithers paths bypass it.

Capabilities Smithers brings

SmithersSupervisor.matrix.json declares:

  • permissions: { network: true, subprocess: true, env: true } — Smithers needs to talk to GitHub, spawn worker containers, and read environment.
  • Skills: emacs-code-intelligence and matrix-awareness (their content is in src/prompts/skills/).

Both skills are eligible to be referenced from a propose agency profile, though the wiring path is hand-coded in Smithers, not declarative in BUILT_IN_SKILLS.

What Smithers does NOT do via system.agents

  • Inference for the supervisor itself. The supervisor does not enter the oracle loop; it calls inference directly to assess whether a constraint is ready.
  • Memory writes from within the supervisor's reasoning. Memories written during a propose session are written by the spawned agent, not by the supervisor.
  • Tool dispatch. Smithers's tools (GitHub adapter ops, container manager ops) are not Matrix tools projected through system.tools.mcpBridge; they are direct ops on Smithers's children.

See also

Source: projects/matrix-3/packages/smithers/matrix.json, projects/matrix-3/packages/agents/src/harness/AgencyInvokeTool.ts. Cognitive-stack workstream that would consolidate the path: WORKSTREAMS/loose-ends/items/P1.6-cognitive-stack-workstream.md (TODO).