Order invoicing.
A deployed agent that turns retail orders into accounting invoices, deciding for each one whether to issue, skip or hand it to a human — and holding a lock so a duplicate webhook cannot invoice twice.
Deployed agent — this configuration is running in production. Client identities are withheld.
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.
Objective
Keep the accounting ledger matched to the order book without a person transcribing each sale, and make a duplicate invoice structurally difficult rather than merely unlikely.
Runtime
01
Verify
Checks the webhook signature and drops topics that cannot change invoice content.
02
Claim
Takes a shared processing lock on the order, so a concurrent delivery is ignored rather than raced.
03
Compare
Hashes the mapped order and checks the accounting system for an invoice already matching it.
04
Decide
Issues, skips as unchanged, or escalates when the order cannot be mapped.
05
Release
Records the hash and releases the lock, leaving a replay cheap and safe.
Agent anatomy
Context
- The incoming order and its version
- A content hash of the last invoiced state
- Existing invoices in the accounting system
- A configured cutoff date for historical orders
- Whether a human has already been notified about this order
Capabilities
- Verify webhook authenticity
- Map an order to an invoice
- Detect an unchanged or already-invoiced order
- Issue an invoice idempotently
- Escalate an unmappable order to a person
Activation
- Order created or updated in the commerce platform
- Operator-run backfill over historical orders
Authority
What can it change?
- Autonomy
- Escalating
- Horizon
- Event-driven
Read
- Orders and their addresses
- Existing invoices
- Prior notification state
Write
- Invoices in the accounting system
- Processing locks and content hashes
- A notification flag on the order
Conditional
- Issue an invoice only while holding the order's lock
- Replace an existing invoice only when the order content has actually changed
Prohibited
- Invoice an order that predates the configured cutoff
- Act on a webhook whose signature does not verify
- Re-notify a human about an order already escalated
- Re-invoice on a fulfilment event, which cannot change invoice content
Escalate
- Order missing a usable address — emailed to a person, recorded, and left uninvoiced
- Lock already held — the delivery is dropped, not queued behind a race
- Accounting system unreachable — no invoice is assumed to exist
Composition and verification
Made from explicit parts.
Composition
- Signed webhook receiver
- Shared lock store with expiry
- Content hashing of mapped orders
- Accounting system API
- Email escalation to a person
Verification
- Locks carry a TTL, so a crashed run does not block the order forever
- Content hash makes an unchanged replay a no-op
- Existing invoices are queried before issuing, not assumed absent
- Fulfilment topics explicitly excluded, with tests covering the filter
- Escalation is recorded so a person is told once, not on every retry
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 runs in production, client identity withheld. To discuss the same for your operation, start with the problem rather than the system: a first call is thirty minutes and costs nothing.
Related entries