The 657-message problem, and how single-flight fixes it

Every team that has put an automated agent next to a real messaging system has a version of this story. A workflow fires. The downstream API is slow to acknowledge, or returns a timeout that the agent reads as failure. So the agent does the reasonable thing: it tries again. The send had actually gone through. The retry sends a second. The acknowledgement is still slow. It tries again. By the time someone notices, a single customer has received 657 messages in twenty minutes, and the only question left is how to apologize.

Forty-four sends where one was intended. Same recipient, same minute.

It is tempting to file this under "bad luck" or "a bug we will fix." It is neither. It is a structural property of putting a non-deterministic decision-maker in front of an effect that touches the outside world. The model is not wrong to retry. Retrying is correct behavior for a flaky network. The mistake is letting the same intended action become many real actions. The fix is not a better prompt. It is a different shape for the system.

Two ideas, working together

Fibric makes the flood impossible with two kernel primitives that work as a pair: single-flight and idempotency keys. Neither is novel on its own. Both are old, boring, proven ideas from distributed systems. What matters is that Fibric treats them as non-negotiable foundations rather than something each connector remembers to implement.

Single-flight per entity

Single-flight means that for any one entity, at most one action is ever in flight at a time. There is exactly one order #4471. There is exactly one customer. While an action against that entity is running, a second action against the same entity does not run in parallel and does not pile up behind it uncontrolled. It collapses into the one already happening, or it waits its turn and re-evaluates against the new state.

This is the difference between a thermostat and a stuck relay. A thermostat that wants the room warmer does not send "heat on" forty times because it asked forty times. It holds a single intent for a single room. Fibric holds a single intent for a single entity, and that boundary is enforced by the kernel, not by hope.

Idempotency keys

Idempotency answers the second half of the question: what happens when the same action genuinely is attempted twice, because a process crashed and resumed, or a network call was retried after a timeout that hid a success? Every effect Fibric performs carries an idempotency key derived from what the action is, not when it ran. The first time a key is seen, the effect happens. Every time after, the system recognizes the key and returns the original result without doing the work again.

So the slow acknowledgement that started the flood is no longer dangerous. The agent can retry as many times as the network demands. The send with key notify:order-4471:shipped happens exactly once. The forty-three retries find the key already settled and quietly return the receipt for the send that already went out.

Why this belongs in the kernel, not the connector

You could ask every connector author to handle this themselves. Most distributed systems do exactly that, and it is why most distributed systems eventually send someone 657 messages. The discipline is real, but it is unevenly applied, and the one connector that forgets is the one that floods a customer.

Fibric pulls single-flight and idempotency down into the executor, below every connector. A connector author writing an integration for a new messaging platform, a door controller, or an order system does not opt in to safety. They inherit it. The capability they expose is wrapped by the same executor that wraps every other capability, and that executor is the only thing allowed to turn a proposed action into a real one.

What an operator never has to think about

The point of all this plumbing is that the people running an operation never see it. An operator named to handle shipping notifications says, in effect, "tell the customer when their order ships." It does not carry retry logic, deduplication tables, or a mental model of network timeouts. Those are the kernel's job. The operator reasons about the operation. The executor guarantees the effect.

• One intent, one entity, one action in flight. Concurrency against the same thing is serialized, not stacked.
• Every effect keyed and deduplicated. Retries are free and safe by construction.
• Every action leaves a receipt. When the dedupe catches a repeat, that is logged too, so you can always see what was prevented.

The 657-message problem is a good test for any agentic system you are evaluating, including ours. Ask how it makes the flood impossible. If the answer is "we are careful" or "our prompt is good," the flood is still in the building. If the answer is single-flight plus idempotency enforced below every action, the runaway has nowhere to run.

Keep reading: Point and go · Exactly-once effects for agents