Tony (chief of staff agent) received a PR_READY message from Mel (engineering agent). It acknowledged the message. It told Adam it would surface the PR in the next morning briefing.
That’s not what Adam asked for.
“Don’t wait till the morning brief. Let me know when the PRs are ready as they become ready.”
Tony’s response:
“Got it. I’ll ping you here as soon as Mel posts PR_READY.”
Then, in the same message:
“Note: I did not schedule a reminder in this turn, so this will not trigger automatically.”
The promise was made. The mechanism wasn’t.
Why This Happens
Agents treat incoming information as data to include in the next scheduled output. It’s not laziness — it’s how they’re built to handle async signals when there’s no explicit instruction otherwise. A PR_READY message arrives. The agent files it under “things to report.” The next reporting opportunity is the morning briefing. So that’s when it gets reported.
Nothing goes wrong by the agent’s reasoning. The information isn’t lost. It just arrives eight hours late.
The agent also understood what Adam wanted when asked directly — it promised to notify immediately. But understanding and acting are different. Without workspace instructions that wire the event to an action, the promise has no mechanism behind it. The next session starts fresh. The correction is gone.
The Fix
Two changes in workspace files.
1. Separate event-driven from scheduled in your registry:
### Obi's Responsibilities
1. **Route engineering tasks** — send TASK to Mel via curl when Adam gives eng work
2. **Approve breakdowns** — reply with APPROVAL when Mel sends BREAKDOWN
3. **Surface PRs immediately** — when PR_READY arrives, post to Adam in #dev
RIGHT AWAY. Do not hold for the morning briefing. The message arrives via
the agent bus — respond to it immediately.
4. **STATUS in briefings** — morning briefing pulls routine STATUS updates.
PRs are the exception: time-sensitive, surface on arrival.The key move: PR_READY and STATUS are listed separately with different action verbs. “Surface immediately” vs “include in briefing.” One is an event. One is a data point.
2. Add a correction to AGENTS.md:
| 2026-03-04 | When Mel sends PR_READY, notify Adam in #dev IMMEDIATELY —
do not hold for the morning briefing. Promising to notify without acting
on the message when it arrives is a broken promise. |The last sentence matters. It names the failure pattern the agent just demonstrated — so it can recognize and avoid it rather than re-deriving the same wrong answer.
Key Takeaway
Agents default to “batch and report.” Every async signal gets treated as information to include in the next scheduled output unless you tell them otherwise. For time-sensitive events, that default is wrong.
The fix is classification: in your workspace instructions, separate what requires immediate action from what belongs in a briefing. Name the message type, name the action, name the anti-pattern you’re preventing. A promise to notify is only meaningful if the instructions that back it up survive the next session.