"The coordination of the builders is not direct. It is the work already done
that directs and triggers the work that follows."
— Pierre-Paul Gras...
For further actions, you may consider blocking this person and/or reporting abuse
The overlap shows up most reliably right at the edge between public schemas and internal state. When GitHub or Stripe changes a response shape or rejects an untruncated payload, every setup hitting that endpoint catches the same 422. Where the trail breaks down across setups is local context: token refresh drift, SQLite locks held across async tool calls, or filesystem watchers triggering mid-write.In my own loops, system prompt instructions never stopped the cycle because an agent under context pressure treats advice as optional. The only thing that killed the retry loop cold was moving the circuit breaker into the tool dispatcher: if the normalized error signature repeats twice in a sliding window of three calls, the runner raises an unrecoverable exception and aborts the turn instead of letting the agent guess again.
Yeah, that makes sense. The shared/public failures are the interesting part to me too, especially schema changes, payload limits and other things everyone can hit. Also moving the stop condition into the dispatcher feels more reliable than hoping the agent listens to a prompt when it’s already stuck in a loop :D
The Grassé quote earns its place - stigmergy is exactly what's missing. Three identical 422s happen because the retry has no memory of the previous attempts as work, only as log lines; a colleague would leave a note saying "that door is locked, I tried it." Coordination through the work already done is a design choice, not an emergent property. Are you building the note-leaving, or naming the gap?
Building it :) The post is the honest version of the question because I genuinely don't know yet if the overlap is big enough to matter. But yeah, there is a thing behind it. It's in my bio.
And I think you nailed the hard part. A note saying "that door is locked" only helps if the next person can tell it's the same door. Raw error strings are terrible for that because they almost never match exactly twice.
So most of the interesting work is really the normalising and fingerprinting. The storage part is basically just a table 😀
So what you think though. If you building the note-leaving part, what would you treat as the minimum useful trace for the next agent?
We've actually got a retry_policy field on every tool response in our stack and honestly the hardest part was code review. People under deadline pressure just tag everything as transient and then you're back where you started. I caught about a dozen of those in a two-week sprint before we added a linter check for it.
Part of the missing signal usually does exist, one layer below where the agent is looking. The distinction between a bad ten minutes and a renamed field is often carried by the status code and headers - 429 with Retry-After versus a 422 body naming the field - and then the tool wrapper flattens the whole response into str(e) before the model ever sees it. So the agent is guessing from a string that had the answer stripped out of it upstream. Passing status, retriable and the offending field through as structure seems like the cheaper half of your colleague idea.
I’d put the stop rule in the tool layer too. Once the model has tried the same thing twice, giving it another prompt usually just burns tokens. The dispatcher should know when to say no more.