Home

mweinbach / agent-coworker

publicmweinbach/agent-coworker
Overview Code History Branches Pull requestsIssuesInsights
main
HomeOverview Code PRsIssues

feat(workflows): drive child agents from workflow scripts

2 months ago

4905423
Authored
mweinbach7/26/2026, 4:19:34 PM
`agent()` maps onto the existing AgentControl facade: spawn -> wait -> validate
-> repair -> close, transcribed from the production loop in taskReview.ts with
three corrections a fan-out needs and a single review does not.

- StatusBus counts `errored` as terminal, so `wait()` returns timedOut:false for
  a child that crashed. Reading its text there would surface a failure as a
  plausible-looking result, so `executionState` is checked first.
- `AgentWaitInspection` carries no usage fields, so wait() alone cannot fund
  `budget.spent()`. Each agent is inspected once before close.
- A single 600s wait leaves cancellation latency up to ten minutes on the last
  agent, so waits are sliced into ~120s windows that re-check the abort signal.

Schema-validated returns use a `<workflow_result>` envelope with exactly one
repair turn, rather than widening the `<agent_report>` contract that every child
already shares. The schema stays a JSON Schema literal: it has to survive a
structured-clone boundary and be journal-serializable, which a live zod object
is not.

`onError` defaults to "fail" so failures reach the script, and task-lock or
cancellation errors abort the whole run regardless — otherwise a 300-way fan-out
degrades into 300 silent nulls. Concurrency is capped at 12, below
MAX_ACTIVE_CHILDREN_PER_PARENT, leaving headroom for the parent turn's own
spawnAgent calls.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Kk98XjGKJrKp5ynbiNFMFu

Parent9d74a75

3 files changed
  • src/workflows/WorkflowRunner.ts+389−0
  • src/workflows/hostAgent.ts+206−0
  • src/workflows/resultSchema.ts+113−0