Know what your agent actually did

Every call Anlyon makes gets a receipt: what was sent, which version ran, for which user, and a grade that says how far the outcome was checked. When a response is lost, Anlyon records unknown instead of guessing, and never sends it twice.

Start building Read the docs

A few lines on your server, then connect a user.

1.PreviewedBefore the call: the exact request, and what it would change.
2.Sent onceWith an idempotency key, so a retry is answered from the record.
3.Read backWhere the action declares one, a read of the provider's record checks the write.
4.Gradedconfirmed, acknowledged, unknown, failed, refused or denied.

A timeout tells you nothing about whether the refund happened, and a blind retry can make it happen twice. With Anlyon each write is sent once and graded by what the provider's own record shows.

Less risk

A lost response is never sent again, and its allowance stays held until someone settles it.

Less cost

No double refunds or duplicate emails to unwind after a retry.

Less effort

No outcome table, retry ledger or reconciliation job to build. Filter receipts by user or action.

From the request to the record. A receipt holds the provider's evidence.

Each one is a database record, filed under the user the call was for.

Seven grades, one meaning each

A governed action's receipt carries a grade derived by one rule in the database, never written by hand. It says how far the outcome was checked, from a read-back that matched to a call Anlyon refused before it left. Your agent, your app and your team read the same word.

Every receipt names the action version that ran
Filter calls and receipts by user, action or grade
Webhook and event payloads carry the user

Read about receipts and grades

Receipt gradesseven grades

confirmedA read-back matched the request.
acknowledgedThe provider accepted the request. Nothing read it back.
unknownNo usable response. Anlyon does not send it again. It stays unknown until a read-back or an operator settles it.
failedThe provider rejected the request, or it never left Anlyon.
refusedAnlyon refused it at dispatch.
deniedThe approval was denied.
pendingNo receipt yet.

derived by one rule, never written by hand

Confirmed means the provider's record matched

An action can declare a verify rule: a read of the record the write created or changed, and the fields that must match. Anlyon runs it after the write. The Stripe, Resend and GitHub adapters read the provider's own record, and an OpenAPI import proposes a read-back where the spec has one.

Without a read-back, a 2xx grades acknowledged
A GraphQL read-back posts a fixed, read-only query
Packs ship with read-backs where the provider allows

Read about governed actions

A retry is answered from the record

Send an Idempotency-Key, or let the SDK make one for each invoke. The same key and request, any time later, is answered from the call as it is now, with X-Idempotent-Replay: current-state. It is not run, admitted or charged again. The same key with a different body is refused: 409 idempotency_key_reuse.

A failed or unknown call keeps its key: running it again is a new decision
retryOf links a deliberate retry to the call it retries
A lost Stripe or Resend write can be replayed under the provider's own key

Read about idempotency

Unknown is a grade, not a guess

When a request may have reached the provider and no usable response came back, the receipt says unknown. Anlyon does not send it again, the allowance stays held, and an action.unknown event tells your app. A read-back, a same-key replay where the provider supports it, or an operator with evidence settles it.

Resolving needs evidence, and records who resolved it and when
The key that made the call can never resolve it
Workspace defaults can alert your team when it happens

Resolve an unknown outcome

Send it once. Read the grade.

Tie the key to the business operation, not the attempt. A resend after a timeout gets the recorded result, and the grade says whether Stripe's own record matched.