Order fulfilment.
An agent that verifies and fulfils commerce orders from an operator upload, with an explicit dry-run boundary before any live mutation. Cut over to the shared runtime; the first live fulfilment is still pending an operator.
Pilot — cut over and serving, but not yet exercised end to end in production. The first live run is still pending.
Classified as an agent: it holds a defined responsibility and chooses, recommends or routes a permitted action from context.
No model anywhere in this entry. It is deterministic end to end — the behaviour comes from rules, arithmetic and explicit boundaries.
Problem it stands behind
Objective
Turn an operator's order file into verified fulfilments, keeping verification and mutation separate and making every run replay-safe.
Runtime
01
Receive
Accepts an uploaded order workbook from the operator surface.
02
Parse
Reads and normalises order rows below the capability seam.
03
Compare
Reconciles uploaded rows against live commerce state.
04
Gate
Stops at verification unless the run is explicitly marked live.
05
Fulfil
Applies permitted fulfilment mutations and returns a typed run summary.
Agent anatomy
Context
- Uploaded order workbook
- Live commerce order state
- Fulfilment state
- Resolved commerce credentials
Capabilities
- orders.fulfillment_run
Activation
- Operator upload in the surface
- In-process agent dispatch
Authority
What can it change?
- Autonomy
- Bounded
- Horizon
- Operator-invoked
Read
- Orders
- Fulfilment state
- Uploaded workbook contents
Write
- Order fulfilments, on a live run only
Conditional
- Mutate commerce state when the run is explicitly live and the grant is held
Prohibited
- Mutate anything during a dry run
- Cache a result across tenants
- Take credentials from the request body
Escalate
- Missing grant
- Concurrent claim on the same key
- Ambiguous upstream failure — fails closed to a runbook
Composition and verification
Made from explicit parts.
Composition
- Shared capability runtime
- Durable idempotency ledger
- Commerce API integration
- Dry-run / live execution boundary
Verification
- Dry-run guard covered by tests
- Tenant-unsafe replay cache removed and regression-tested
- Shared ledger keyed per tenant and capability
- Typed run summary for every execution
No evidence is published for this entry. The items above are our own account of its source, read before publishing — not something you can check without taking our word for it.
Next step
What you can do with this.
This configuration is cut over and serving, and its first live run is still pending. A conversation can start now; a claim that it has run end to end in production cannot be made yet, and this page does not make it.
Related entries