Idempotency is a kernel primitive, not a library
Every integration guide tells you to make writes idempotent. The Fibric reference architecture centralizes stable keys and duplicate checks on governed paths, while recognizing that external systems, ambiguous acknowledgements, and independent writers limit any end-to-end guarantee.
Distributed systems retry. Networks flake, lambdas time out, queues redeliver, and any honest architecture assumes each of these will happen on the worst possible write. The classical answer is the idempotency key: attach a unique token to the write, and let the receiving side deduplicate. The pattern is thirty years old and correct. What is usually wrong is the placement.
In most stacks, idempotency is a library concern. Each integration implements it — or doesn't. The payments client passes a key because the payment API demands one. The ticketing client dedupes with a lookup-before-write, racy under concurrency. The building-controls client does nothing, because the vendor SDK has no notion of a key and the author was on a deadline. The system's duplicate-safety is the minimum across all of its integrations, and that minimum is invisible until a retry storm finds it.
Agents make this non-negotiable
For a human-driven system, a duplicate write is an occasional support ticket. For an autonomous one, it is the difference between a platform you can leave running and one you babysit. An operator that senses, reasons, and acts will act often, unattended, across every connector at once — and its failure recovery is retry by design. If "retry" is only safe on some paths, autonomy is only safe on some paths, and nobody can tell you which ones from the outside.
Below the connector, not inside it
The reference kernel moves duplicate controls down a layer. It can mint stable keys and check a durable record before dispatch on governed writes. The resulting protection is bounded by key identity, settlement order, connector behavior, and downstream support.
That last row is the crux. A local ledger can suppress redispatch after a settled result. It cannot prove whether a device changed state if the external command succeeded and the acknowledgement was lost. Physical connectors need read-back and conservative ambiguity handling; where neither is reliable, automatic retry may be unsafe.
By construction, not by convention
The intended consequence is that connector authors inherit a common duplicate-control interface. They can still get key identity, downstream semantics, or reconciliation wrong, which is why managed conformance review matters. The catalog has 5 live BearScope listings and 43 managed early-access listings; public publishing is not open.
This pairs with single-flight per entity inside the governed runtime. Together, the controls can collapse matching duplicate attempts before dispatch or after a settled result. BearScope is the live product proof point for governed application paths, but it does not currently route through the generalized kernel, and no live hotel-controller retry claim is made here.
The placement test
When you evaluate an agent platform, ask where the key lives, when it is settled, whether the downstream system honors it, how ambiguous outcomes are reconciled, and which writers sit outside the boundary. Centralizing the control is useful, but no local primitive makes every external retry a safe no-op.
Keep reading: One action per entity · Anatomy of a connector: Kustomer