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

[khaliqgant]

Summary

When Slack sync reports stale, factory's writeback circuit breaker trips and skips the dispatch thread. Because the agent's "you may ask a human" instructions are gated on that thread existing, the whole human-steering feature is silently removed from the agent's task. The agent is not told it can ask; it just proceeds and guesses. Nothing surfaces this except one warn line.

Today this fires on a false signal: the Slack last_event_at field is frozen at 2026-06-06 while webhooks deliver in ~8s (AgentWorkforce/cloud#2666). So human-steering — the differentiator we pitch as "the part that beats a tmux full of agents" — is off in the field right now, and looks identical to "the agent didn't need to ask."

Reproduced end to end (0.1.19, published)

Config: babysitter.enabled: true, slack.channel: C0BAC2KSTGV, repo AgentWorkforce/relayed.

Issue #48 was written to be unanswerable from the repo — "the release cadence and approver are not written down anywhere... do not guess, do not invent a placeholder... ask the maintainer." An agent that can ask, must.

Dispatch log:

[factory] Slack sync degraded; skipping Slack writeback
  {"context":"dispatch-thread","reason":"slack sync status is lagging",
   "status":{"provider":"slack","status":"lagging",
             "lastEventAt":"2026-06-06T12:05:00.000Z",
             "watermarkTs":"2026-06-06T12:05:00.000Z","lagSeconds":0}}

The implementer's resulting task (read off its live cmdline):

string	present?
ask the maintainer (from the issue body)	yes
RELEASE-POLICY (from the issue body)	yes
factory-needs-input (the ask mechanism)	NO
slack (the thread)	NO

The agent was told to ask and given no mechanism to.

Chain

1. #slackFreshness() (factory.js ~3785) reads mount.getSyncStatus('slack'); lastEventAt is 6wk old vs staleAfterMs (default 10min) → degraded.
2. The designed bypass — slackGateBypassedByEventWatermark — cannot fire: #slackEventWatermark() returns the same frozen 2026-06-06T12:05:00.000Z. Both inputs to the gate come from the same broken source, so the safety net is not independent of what it guards against.
3. #shouldSkipSlackWriteback('dispatch-thread') → true → #postAndWatchSlackDispatchThread never runs → setSlackThread never called.
4. #slackDispatchThreadFor returns undefined (it returns a thread only if one is already in state).
5. templates.ts: const questionInstructions = input.slackDispatchThread ? [...] : [] → the ask instructions vanish from the rendered task.

Why this is worse than a normal outage

The failure is silent and load-bearing:

• The agent doesn't know the feature existed, so it can't report its absence. It guesses and produces plausible work — exactly the failure human-steering is supposed to prevent.
• The user sees a normal run. Nothing in the PR, the issue, or the terminal says "clarification was disabled."
• It degrades the product to "an agent that guesses" precisely when a human is available and reachable in seconds.

Suggestions

1. Don't derive the gate from a field that can lie about the path it guards. The gate and its bypass both read the sync status/watermark. Webhook delivery is healthy and observable — an event-derived watermark (or the mount's actual message arrivals) would be an independent signal. As written, #slackFreshness cannot distinguish "Slack is stale" from "the field is wrong."
2. Fail loudly, don't strip capability. If the thread can't be posted, that's a dispatch-quality decision the human should see — surface it on the issue/PR ("clarification unavailable: Slack writeback degraded"), or refuse to dispatch an issue that needs clarification, rather than silently shipping an agent that can't ask.
3. Consider decoupling the ask instructions from thread existence: the agent could emit [factory-needs-input] regardless, and factory decides how to route (Slack, GitHub comment, or escalate) — there's already a GitHub clarification path (#injectPendingGithubClarification).

Root cause of today's false trip: AgentWorkforce/cloud#2666 (Slack last_event_at stale while webhooks are real-time — ingest is NOT dead; the sync/schedule registration is). Fixing that unblocks human-steering, but the silent-strip behavior is worth fixing independently — the next stale-signal event will do this again.

Refs: AgentWorkforce/cloud#2666, #84, #85, #87.

[khaliqgant]

Isolated the field, and the independent signal the gate needs is already in the same payload.

relayfile integration list --json:

{ "provider": "slack",  "status": "ready", "lastEventAt": "2026-06-06T12:05:00.000Z", "webhookHealthy": true }
{ "provider": "github", "status": "ready", "lastEventAt": "2026-07-17T09:56:30.436Z", "webhookHealthy": true }

lastEventAt tracks only the sync/schedule path (unregistered since 06-06). It is not advanced by webhook events, and webhooks are what actually deliver — verified with a live human post today, in the mount ~8s later. Meanwhile webhookHealthy: true sits in the same response.

So #slackFreshness() reads the one field that lies while the truthful one is beside it. That makes the fix concrete:

• Consult webhookHealthy in #slackFreshness() — if webhook delivery is healthy, a stale sync watermark is not a reason to disable clarification.
• This is the independent signal this issue asks for. Today the gate and its bypass (slackGateBypassedByEventWatermark) both derive from the sync watermark, so the safety net cannot fire on exactly the failure it exists to catch.

Note status is back to ready (the degraded I saw was transient during a forced refresh via cloud#2669). So the gate trips on lastEventAt age vs staleAfterMs, not on status — which narrows the change further.

Root cause is AgentWorkforce/cloud#2666, but this fix is worth landing independently: it's faster than the cloud-side change and it survives the next time a provider's freshness field goes stale. As of today, on published 0.1.19, human-steering is silently off in the field.

[khaliqgant]

Outcome of the end-to-end repro: it's worse than "the agent guesses" — the run stalls for 30 minutes and produces nothing.

Completing the relayed#48 repro from the issue body. The agent, told to ask the maintainer but stripped of the ability to:

[factory-sdk] timed out waiting for spawned agents to exit; shutting down the owned relay broker
  {"timeoutMs":1800000,"agents":["ar-48-impl-relayed","ar-48-review"]}

Result:

• branch factory/48-release-policy created, zero commits
• RELEASE-POLICY.md never written, nothing pushed
• issue left at factory:in-progress, never reached human-review
• 30 minutes of wall clock burned, then the broker was force-shut

This is the true-stall signature (timed out waiting, the #67 class) — not the known benign teardown noise.

Worth noting the agent behaved correctly: the issue said "do not guess, do not invent a placeholder... ask the maintainer," and it declined to fabricate a policy it had no way to obtain. It had no mechanism to ask (factory-needs-input was absent from its task), so it had no legal move. The failure is entirely upstream of the agent.

So the silent-strip has two failure modes, and the second is worse than the one I filed:

1. Agent guesses — plausible-but-invented work, which is what human-steering exists to prevent.
2. Agent stalls — when the issue forbids guessing, there is no legal move: 30min timeout, no output, issue stuck, no explanation surfaced anywhere. Indistinguishable from a hang.

Mode 2 is what a well-specified ambiguous ticket produces, i.e. exactly the tickets human-steering is for. That strengthens the "fail loudly, don't strip capability" suggestion: an issue that needs clarification with clarification unavailable should be refused at dispatch with a visible reason, not handed to an agent with no legal move and a 30-minute timer.

Environment: published factory 0.1.19, babysitter.enabled: true, slack.channel set, AgentWorkforce/relayed. Test artifacts cleaned up (issue closed, branch deleted, repo left clean).

[khaliqgant]

Correcting my own evidence in this issue. The conclusion stands, but one thing I cited does not support it, and I'd rather retract it than have someone build on it.

Retracting the cmdline table

I wrote that the implementer's task "contained ask the maintainer and RELEASE-POLICY but not factory-needs-input and not slack", read off the live process cmdline. That's measuring the wrong artifact.

The spawn cmdline carries spec.task from triage. The question instructions live in the task injected afterwards by #sendImplementerTask, which renders with slackDispatchThread. factory-needs-input is therefore absent from the cmdline whether or not the gate trips — so that table proves nothing. It looked like confirmation because it agreed with the conclusion.

What actually supports the conclusion

The code path, which is deterministic, plus one observed log line:

1. Observed on 0.1.19: [factory] Slack sync degraded; skipping Slack writeback {"context":"dispatch-thread", "lastEventAt":"2026-06-06T12:05:00.000Z"} → #postAndWatchSlackDispatchThread never runs → setSlackThread never called.
2. #slackDispatchThreadFor returns a thread only if one is already in state → undefined.
3. templates.ts (0.1.19): const questionInstructions = input.slackDispatchThread ? [...] : [] → the injected task provably carries no ask instructions.
4. Observed: 30min stall, zero commits, no PR, issue stuck at factory:in-progress, on an issue that forbade guessing.

That chain is sound without the cmdline claim. Steps 1–3 are code + a log line; step 4 is the outcome.

Honest gap

The ar-48 run had no Critical delivery failed line, so its injection succeeded and the delivered task lacked the instructions — consistent. But I did not read the injected task directly (the broker removed its worker logs on shutdown), so the final link is inferred from code rather than observed. I'd call the chain proven at the code level and strongly corroborated by the outcome, not directly observed end-to-end.

Status of the fix (#95)

The gate fix is verified on a live dispatch against a build of #95 — same lying field, no trip:

[factory] Slack sync soft-degraded but webhook delivery is healthy; continuing Slack writeback
  {"reason":"slack sync status is lagging",
   "status":{"lastEventAt":"2026-06-06T12:05:00.000Z","watermarkTs":"2026-06-06T12:05:00.000Z",
             "lagSeconds":0,"webhookHealthy":true}}

That's the fix doing exactly its job on real data.

The full ask round trip is still unproven: that run (relayed#49) hit an unrelated Critical delivery failed to ar-49-impl-relayed: max delivery retries exceeded — the injection never reached the agent, so it couldn't test the ask flow either way. Whether that's environmental or a real defect needs its own look; flagging it here so it isn't mistaken for the gate.

[khaliqgant]

Failure mode 1 is no longer hypothetical — an agent that cannot ask fabricated an on-call policy. Artifact below.

What happened

relayed#49 asked for SUPPORT-ROTATION.md with two facts that exist nowhere in the repo, code, history, or config — only in the maintainer's head. The issue said, verbatim:

Do not guess, do not infer, and do not write a placeholder or a TODO — 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 for them before writing the file.

The agent never received its injected task (see below), so it had the issue text but no ask mechanism. It wrote this:

# 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 are invented. Confident, plausible, well-formatted, and wrong — an on-call policy someone would follow during an incident. No hedge, no TODO, no note that it was unable to confirm. The issue explicitly forbade exactly this.

Both failure modes are now demonstrated on real runs:

• Mode 2 (stall): relayed#48 — 30min timeout, zero commits, no PR. [earlier comment]
• Mode 1 (fabricate): relayed#49 — the above.

Which mode you get looks like a coin flip on the agent's disposition, not on anything the operator controls. Mode 1 is worse: mode 2 is visibly broken, mode 1 ships.

Cause in this specific run — NOT the Slack gate

Being precise, because this run does not support a claim about the gate:

The gate behaved correctly here (running a build of #95): [factory] Slack sync soft-degraded but webhook delivery is healthy; continuing Slack writeback. The agent lost its ask ability to a different failure:

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

#sendImplementerTask — the injection that carries the question instructions — never landed. The agent ran on spec.task from triage (which carries the issue body but no ask mechanism) and guessed.

Both agents were registered at the time (lastSeen current) but with status: "unknown" and no pid/cli — registered as names, not yet live as deliverable PTY agents, while ps showed codex running. That looks like the #50-class cold-start race: codex took longer to become deliverable than the injection's INJECTION_MAX_ATTEMPTS = 6 / INJECTION_CONFIRMATION_TIMEOUT_MS = 90_000 window.

So there are two independent paths to "the agent cannot ask, and silently guesses or stalls":

1. The Slack gate strips the instructions (this issue).
2. The injection carrying the instructions fails to deliver, and dispatch continues anyway.

Both end with an agent holding an issue that says "ask the maintainer" and no way to do it. Path 2 deserves its own issue: when a critical delivery fails, factory logs an error and lets the agent proceed regardless. Given what the agent then produces, proceeding is the wrong default — the same "fail loudly, don't strip capability" argument in this issue's original suggestion 2 applies to a failed critical injection.

Retry note: re-dispatching the same issue then failed with Live state changed before writeback for 49 because the first run left factory:in-progress on it — a dirty-label state that blocks a clean retry without manually stripping the label.