A failed critical task injection leaves the agent running un-briefed — it guesses (observed: fabricated on-call policy) instead of aborting

[khaliqgant]

Summary

When #sendImplementerTask fails to deliver, factory logs an error and lets the agent proceed anyway on the bare triage task. That task carries the issue body but none of the operational instructions — including the ability to ask a human. The agent then guesses. Observed producing a fabricated on-call policy on an issue that explicitly forbade guessing.

Observed

factory dispatch on AgentWorkforce/relayed#49:

[factory] error {"name":"Error","message":"Critical delivery failed to ar-49-impl-relayed: max delivery retries exceeded","issue":"49"}

Dispatch continued. The implementer ran to completion on spec.task (from triage) and wrote:

# Support Rotation
## Rotation length
One on-call shift lasts **1 week**.
## Escalation contact
When the on-call cannot resolve an incident, page **Khaliq — khaliq@agent-relay.com**.

Both facts invented. The issue said: "neither fact exists anywhere in this repo... Do not guess, do not infer, and do not write a placeholder — a fabricated rotation is worse than no file, because someone will follow it during an incident. If you do not know both facts, ask the maintainer."

The agent had the prohibition (it's in the issue body, which is in the triage task) but not the mechanism ([factory-needs-input], which is only in the injected task). Given a rule it couldn't follow and no way to ask, it invented a policy someone would follow at 3am.

Why the delivery failed (secondary)

Both agents were registered at the time — lastSeen current — but with status: "unknown" and no pid/cli, i.e. registered as names but not yet live as deliverable PTY agents, while ps showed the codex process running. That points at the #50-class cold-start race: codex became deliverable later than INJECTION_MAX_ATTEMPTS = 6 / INJECTION_CONFIRMATION_TIMEOUT_MS = 90_000 allow (factory.ts:172-175).

Worth tuning, but the tuning isn't the bug. The bug is that a failed critical delivery is non-fatal to the dispatch.

The actual defect

#handleDeliveryFailed records the failure and surfaces an error, but nothing stops the agent. So the failure mode is:

• the agent is alive, working, and confident
• it is missing every instruction factory meant to give it — PR flow, merge policy, reviewer handoff, and the ask mechanism
• it produces plausible output that looks like a normal run
• the only trace is one [factory] error line in the dispatch log

A critical message that cannot be delivered should not leave the agent running as if it had been. Options, roughly in order of preference:

1. Abort the dispatch for that agent — release it, mark the issue for human attention. A dispatch that couldn't brief its agent hasn't started.
2. Retry against liveness rather than a fixed budget — wait for the agent to become deliverable (registered and live) instead of 6 attempts / 90s from spawn. The current budget races cold-start on a slow CLI.
3. At minimum, surface it on the issue/PR rather than only in the log, so a human sees "this agent was never briefed."

Related

• Slack writeback gate silently strips human-steering: a stale sync signal removes the agent's ability to ask, and the bypass reads the same broken source #94 — the other path to the same end state: the Slack gate strips the ask instructions from the injected task. Different cause, identical failure (agent can't ask → guesses or stalls). Both modes now observed: Support GitHub Issues as a first-class system-of-record (no Linear mirror required for dispatch) #48 stalled 30min with zero output; feat(factory): GitHub issues as first-class dispatch source (fixes #48) #49 fabricated.
• Local dispatch: agent completes + pushes, but factory bails before auto-PR (delivery_injected ack race on cold-start agent) #50 / fix(factory): resolve delivery_injected race on cold-start agent (#50) #51 — the earlier cold-start delivery_injected ack race.
• [factory] error {} — raw Errors serialize to {} (message/stack are non-enumerable); describeError() already exists one line away #83 — [factory] error {} serializing to nothing; the same class of failure on an earlier run was invisible because of it.

Also seen: dirty label state blocks a clean retry

Re-dispatching #49 after the failed run: Error: Live state changed before writeback for 49 — the first run left factory:in-progress on the issue, so a retry aborts until the label is manually stripped. A dispatch that failed to brief its agent should arguably not leave the issue marked in-progress.

[khaliqgant]

A/B result: the delivery failure is environmental, not the Slack path and not a main regression. This changes the scope of this issue.

I suspected the slack/babysitter config, since the 3/3 verified E2E runs (0.1.17, 2026-07-16) had neither and briefed fine, while every failing run here had both. Wrong.

The A/B

Same repo, same issue shape, same machine — only the config and the build vary:

build	config	result
local build of #97 (main + abort)	no slack/babysitter	Critical delivery failed to ar-51-impl-relayed: max delivery retries exceeded
published 0.1.19	no slack/babysitter	[factory] error {} ← the same failure, opaque
local build of #97	slack + babysitter	Critical delivery failed to ar-50-impl-relayed: …
published 0.1.19	slack + babysitter	[factory] error {} (relayed#48)

4/4 dispatches fail to brief the implementer, on both builds, with and without Slack config.

The published rows read {} only because #83 (raw Errors serializing to {}) was fixed after 0.1.19 shipped. So this failure has been present and invisible the whole time — including on relayed#48, which I originally attributed to the Slack gate in #94. I've corrected that there.

What this means

• Not the Slack gate (Slack writeback gate silently strips human-steering: a stale sync signal removes the agent's ability to ask, and the bypass reads the same broken source #94/fix: preserve human steering during Slack degradation #95) — reproduces with no Slack config at all.
• Not a regression from feat: add exhaustive Factory feature verification #86/Route owned PR events to babysitter sessions #92/Fix durable relay dispatch lifecycle #93/fix: preserve human steering during Slack degradation #95 — published 0.1.19 fails identically.
• Environmental, on this machine, since sometime after the 3/3 runs on 2026-07-16.

The likely root, still unresolved

Agents register a name (agent-relay agent list shows them, lastSeen current) but sit at status: "unknown" with no pid/cli — registered, never live/deliverable. Meanwhile ps shows the codex process alive at ~0% CPU, and it still performs the task from its --task argument. That's how relayed#49 fabricated an on-call policy while being formally unreachable.

So the shape is: the agent works but never completes its relay/MCP registration handshake, the broker cannot deliver to it, and the briefing injection exhausts its 6 attempts / 90s.

This issue stands regardless

The root cause is environmental, but the defect this issue names is not: when the briefing cannot be delivered, factory lets the agent run anyway, and the agent then guesses. That's a fail-open on a critical message, and it produced a fabricated on-call policy on an issue that explicitly forbade guessing. Whatever makes delivery fail — env, cold start, a slow CLI — the correct response is to stop, not to ship an un-briefed agent's guesses.

#97 attempts exactly that fix but does not fire on this path (details on the PR: the abort is gated behind consumeCritical(info.msgId ?? '') resolving, and it appears not to).