platform/autonomous-engine
Automation is easy. Automation you can undo is the product.
Anything can write to a marketplace API. The engineering is in what happens when the write half-succeeds, the channel rate-limits you at 2am, a supplier revises the document underneath a published claim, or somebody needs yesterday’s catalog back.
Every transition is recorded · every write carries the version of the input, the agent and the rule set that produced it
History is append-only. Reverting is a write, not a restore.
Input, agent and rule-set version recorded per write.
Deltas only. Unchanged records never touch a channel API.
Acknowledged and reconciled against live channel state.
Six properties, and what each one costs.
Every guarantee here is a trade. We would rather name the trade than describe the runtime as simply reliable.
Idempotent by key
Every unit of work carries a caller-supplied key. Replaying a run cannot produce a second write, so a retry after a network failure is always safe.
At-least-once, deduplicated
Delivery is at-least-once because exactly-once across a third-party API is a fiction. Duplicates are absorbed at the write boundary rather than wished away.
Versioned writes
Every write records the input version, the agent version and the rule-set version that produced it. A result is reproducible or it is not trusted.
Backpressure, not failure
When a channel rate-limits, work queues rather than erroring. Priority classes let a price correction overtake a bulk backfill.
Bounded blast radius
A run is scoped to a SKU set and a channel set. There is no operation whose failure mode is the whole catalog.
Reversible
Because history is append-only, any publish can be reverted to the exact prior state, including on channels that have no undo of their own.
At-least-once rather than exactly-once. Exactly-once delivery across a third-party API you do not control is not achievable — a channel can accept a write and fail to acknowledge it. What is achievable is making a duplicate harmless, which is what idempotency keys are for. Any vendor claiming exactly-once against a marketplace API is describing a wish.
Five states. One of them is a success that looks like a failure.
0
units of work
Compliance and schema validation. Nothing proceeds that cannot be substantiated.
Work sitting at the gate is not backlog. It is exposure that was caught before it reached a customer, a regulator or a marketplace. A runtime with an empty gate queue is not performing well — it is not checking.
A price correction is not queued behind a bulk backfill · budget is allocated per class, not first-in-first-out
What happens at 2am, specifically.
Uptime figures describe the good case. These are the six bad cases and the exact behaviour of each.
Channel returns 429
Work re-queues with backoff inside its priority class. Nothing is dropped, nothing is retried into a wall.
Channel returns 500
Retried under the same idempotency key, so a write that actually succeeded before the error does not duplicate.
Agent times out
The run resumes from its last checkpoint rather than restarting the SKU from the beginning.
Compliance gate blocks
The run halts at the gate. This is a successful outcome, not an error — the exposure was caught before publication.
Source document revised
Affected attributes are invalidated and re-derived. Downstream emissions are re-queued automatically.
Operator reverts
The prior version is re-emitted to every affected channel from append-only history.
Note that none of the six outcomes is “error, investigate tomorrow.” Every failure mode a marketplace integration actually encounters has a defined behaviour, because the ones without a defined behaviour are the ones that become a Monday morning.
Run it against one channel, in dry-run.
Connect a single channel in read-and-simulate mode. You get the full diff of what would be written, the rate-limit projection, and the rollback plan — with nothing actually sent until you say so.
One channel · Nothing written · Full diff and rollback plan