Summary
The operator hit a stack of distinct-but-related runtime issues during a single 2026-05-25 session. Each one is small in isolation; together they constitute a trust failure in the agent runtime that is separate from any individual feature bug. Filing as an umbrella for a dedicated session focused on the agent dispatch / worker lifecycle / model routing layer rather than feature bugfixes.
Symptoms observed live, 2026-05-25
1. Tool calls silently skipped on certain model+think combinations
openai-codex/gpt-5.3-codex with think: low acknowledged tasks ("I can check that right now") then ended turns without emitting any tool_use blocks. Confirmed by operator transcript and by the lack of [Log] [AEVP] Activity: working events for the expected tools. Swapping to gpt-5.4-mini restored tool dispatch immediately.
Possible cause: Codex provider path has different tool-emission compliance than the Anthropic-direct path. Low reasoning budget compounds — model decides "I can answer from context" instead of dispatching. Worth verifying whether the model card / system prompt explicitly mandates tool emission for tool-required tasks.
2. SpecForge intake state machine loops forever
Filed separately as #421 — intake_interview stage doesn't advance even after the operator answers every question it asks. Turns urgent bugfixes into ceremony with no escape hatch besides explicit operator override.
3. Family-dev handoff routing fails ("forge isn't allowed to spawn")
When SpecForge tried to escape its own intake loop via a family-dev handoff to a coder worker, the spawn was refused with a routing/permission error. The agent fell back to a background subagent on the allowed default model.
Question: What's the policy that prevents the forge family from spawning into the dev family? Is the policy intentional (security boundary) or accidental (missing entry in tool-policy.ts)? If intentional, the SpecForge intake doc / agent prompt should know about it and not suggest that path.
4. Subagents spawn but do zero useful work
Operator's first subagent spawn (736b0781-...) created a session key but had zero messages in its history when inspected — it received the spawn signal but never started. A restart on the same allowed model spun up a working session (e6b459d1-...), suggesting transient infrastructure flake rather than a config bug. But there's no diagnostic surface for "subagent spawned but never started" — the operator only discovered the failure by manually inspecting sessions_history.
Diagnostic gap: subagent spawns should self-report "I'm alive and processing" within N seconds, or the parent should surface "child appears stuck" to the operator.
5. Worker cancel messages time out without acknowledgement
When the operator decided to cancel the subagent and hand work off to Claude, the cancel message to the worker timed out. Task board reflected the cancellation; the worker itself never acknowledged.
Risk: task-board state can drift from actual worker state. A cancelled task could still have a running worker producing changes. Need either: (a) hard-kill semantics that don't require worker ack, or (b) timeout-and-confirm-shutdown flow that escalates to a hard kill after N seconds.
6. doc_panel "Invalid token" persisted through the session
Filed and fixed in PR #422 (gateway-side dashboardApiHeaders falling back to gateway.auth.token from argent.json). The runtime impact: the operator could not save the diagnostic doc that Argent produced during the session — they had to fall back to a direct file write. That's a runtime degradation that should have surfaced as a banner, not as a tool error inside an agent turn.
7. Memory reranker buried exact answers
Filed as #418, fixed in PR #420. Symptomatically similar to "her systems are not working" — the operator's trust is degraded by a string of small wrong-answer events even when individual systems are otherwise functional.
What I think this points to
Three layers worth a dedicated session:
A. Dispatch + worker lifecycle (items 3, 4, 5)
- Worker spawn → "I'm alive" handshake within N seconds, surface to operator if missed
- Worker cancel → hard timeout + confirm shutdown, not best-effort
- Tool policy: surface family-spawn permission rules in the agent's "what can I do" context so it doesn't try paths the operator can't see are forbidden
B. Model routing (item 1)
- Investigate gpt-5.3-codex low-think tool-emission compliance
- Consider raising minimum reasoning budget for tool-required prompts to medium
- Or detect "agent claimed to do work but emitted no tools" as a routing-quality signal and downgrade the model/think combination
C. Runtime degradation surfacing (items 6, 7)
- Banner/toast surface for runtime degradations that today appear only as silent tool failures (e.g. doc_panel "Invalid token", reranker burying answers)
- Active health probes that fire BEFORE the operator notices: "doc_panel returned 401 on the last 3 calls, did you rotate the token?"
Out of scope (don't fix in this session)
Suggested approach
Half-day dedicated session focused on the dispatch layer (A) first — that's the hottest path. Items B and C are valuable but lower-frequency. Pull telemetry from ~/.argentos/agents/argent/sessions/ to see how often each symptom fires in real operator traffic before optimising any one of them.
cc: tracked symptoms #418 (closed by #420), #421 (open), PR #422 (auth fix)
Summary
The operator hit a stack of distinct-but-related runtime issues during a single 2026-05-25 session. Each one is small in isolation; together they constitute a trust failure in the agent runtime that is separate from any individual feature bug. Filing as an umbrella for a dedicated session focused on the agent dispatch / worker lifecycle / model routing layer rather than feature bugfixes.
Symptoms observed live, 2026-05-25
1. Tool calls silently skipped on certain model+think combinations
openai-codex/gpt-5.3-codexwiththink: lowacknowledged tasks ("I can check that right now") then ended turns without emitting anytool_useblocks. Confirmed by operator transcript and by the lack of[Log] [AEVP] Activity: workingevents for the expected tools. Swapping togpt-5.4-minirestored tool dispatch immediately.Possible cause: Codex provider path has different tool-emission compliance than the Anthropic-direct path. Low reasoning budget compounds — model decides "I can answer from context" instead of dispatching. Worth verifying whether the model card / system prompt explicitly mandates tool emission for tool-required tasks.
2. SpecForge intake state machine loops forever
Filed separately as #421 — intake_interview stage doesn't advance even after the operator answers every question it asks. Turns urgent bugfixes into ceremony with no escape hatch besides explicit operator override.
3. Family-dev handoff routing fails ("forge isn't allowed to spawn")
When SpecForge tried to escape its own intake loop via a family-dev handoff to a coder worker, the spawn was refused with a routing/permission error. The agent fell back to a background subagent on the allowed default model.
Question: What's the policy that prevents the forge family from spawning into the dev family? Is the policy intentional (security boundary) or accidental (missing entry in tool-policy.ts)? If intentional, the SpecForge intake doc / agent prompt should know about it and not suggest that path.
4. Subagents spawn but do zero useful work
Operator's first subagent spawn (
736b0781-...) created a session key but had zero messages in its history when inspected — it received the spawn signal but never started. A restart on the same allowed model spun up a working session (e6b459d1-...), suggesting transient infrastructure flake rather than a config bug. But there's no diagnostic surface for "subagent spawned but never started" — the operator only discovered the failure by manually inspectingsessions_history.Diagnostic gap: subagent spawns should self-report "I'm alive and processing" within N seconds, or the parent should surface "child appears stuck" to the operator.
5. Worker cancel messages time out without acknowledgement
When the operator decided to cancel the subagent and hand work off to Claude, the cancel message to the worker timed out. Task board reflected the cancellation; the worker itself never acknowledged.
Risk: task-board state can drift from actual worker state. A cancelled task could still have a running worker producing changes. Need either: (a) hard-kill semantics that don't require worker ack, or (b) timeout-and-confirm-shutdown flow that escalates to a hard kill after N seconds.
6. doc_panel "Invalid token" persisted through the session
Filed and fixed in PR #422 (gateway-side
dashboardApiHeadersfalling back togateway.auth.tokenfrom argent.json). The runtime impact: the operator could not save the diagnostic doc that Argent produced during the session — they had to fall back to a direct file write. That's a runtime degradation that should have surfaced as a banner, not as a tool error inside an agent turn.7. Memory reranker buried exact answers
Filed as #418, fixed in PR #420. Symptomatically similar to "her systems are not working" — the operator's trust is degraded by a string of small wrong-answer events even when individual systems are otherwise functional.
What I think this points to
Three layers worth a dedicated session:
A. Dispatch + worker lifecycle (items 3, 4, 5)
B. Model routing (item 1)
C. Runtime degradation surfacing (items 6, 7)
Out of scope (don't fix in this session)
Suggested approach
Half-day dedicated session focused on the dispatch layer (A) first — that's the hottest path. Items B and C are valuable but lower-frequency. Pull telemetry from
~/.argentos/agents/argent/sessions/to see how often each symptom fires in real operator traffic before optimising any one of them.cc: tracked symptoms #418 (closed by #420), #421 (open), PR #422 (auth fix)