What is an AGLedger recipe?

A recipe is a tested, multi-step set of contract types for a whole domain workflow (the contract types, their relationships, and the Notify config) that you import into your own Server and adapt. It is a starting point you own, not a turnkey product. Insurance, healthcare prior-authorization, finance KYC, payments disputes, content-moderation, software-delivery, HMRC VAT-filing, and FCRA employment-screening recipes are available today, along with two horizontal recipes that work in any domain: Agent Work Context for checkpoint and resume, and Agent Drift, an ops loop that flags the agents whose behavior moved. The catalogue grows over time.

Which industries have a recipe?

Insurance auto-claims, healthcare prior-authorization, finance KYC and sanctions onboarding, payments disputes and chargebacks, content-moderation takedown under the EU Digital Services Act, software delivery on GitHub, UK VAT filing to HMRC under Making Tax Digital, and employment background screening under the FCRA. Each was built and exercised against the real systems its industry uses: the prior-auth recipe against an HL7 Da Vinci payer system, the KYC recipe against OpenSanctions screening, the payments recipe against Stripe’s dispute API, the content-moderation recipe against a self-hosted EU DSA Transparency Database, the delivery recipe against live GitHub, the VAT recipe against the HMRC developer sandbox, the employment recipe against the Accurate Background sandbox. That way the gate decision matches how an actual system of record renders decisions. Alongside the verticals there are two horizontal recipes: Agent Work Context, which gives any domain durable checkpoint-and-resume state for its agents, and Agent Drift, an ops loop that compares each agent against its own previous window and hands the ones that moved to a reviewer. We add and exercise new verticals over time; if you need one that is not here yet, contact us.

Do recipes lock me into a fixed schema?

No. A recipe installs under your own org as ordinary, editable contract types; keep, edit, rename, or delete any of them. AGLedger ships a deliberately minimal core rather than opinionated built-in types; a recipe is a head start you own, not a platform-managed type kept in lockstep with your business.

How do I adapt a recipe to my own gates and systems?

Import the recipe, then reshape it: edit the contract types to your fields, wire your own system of record or screening engine into the gate seam, and set your own thresholds and authority bands. The recipe gives you the structure and a working example; the decisions and policy stay yours. If you want help adapting one to your process, contact us.

Tested templates · adapt to your shop

Start from a tested template, not a blank schema editor

You model your own work on AGLedger with custom contract types, and a recipe means the first version of that model is already written.

A recipe is a tested, multi-step set of contract types for a whole domain workflow: the types, their relationships, and the Notify config. Import one into your own Server, adapt it to your gates and systems of record, and you have a working pipeline instead of a blank page. For how recipes fit the product, see how it works.

Two kinds of head start

Every instance seeds example contracts

A new org is created with editable example contracts already in place: a generic notarize-only on-ramp plus a gate example.

Industry recipes for a whole workflow

For an entire domain, an industry recipe gives you a tested, multi-step pipeline to adapt rather than author.

Available recipes

Insurance: auto claims

watch demo →files →

First notice of loss through coverage, property and bodily-injury assessment, fraud and SIU review, an engine-decided authority gate, and the human settlement decision.

Records: intake (FNOL), coverage check, damage and injury assessment, fraud / SIU referral, settlement outcome
Gates: authority band (engine), settlement decision (human)
Notify: claims ops, SIU / fraud
System of record: the carrier’s claims system
Human role: supervisor only on the over-authority settlement

Exercised cold by several agent models on live infrastructure.

Healthcare: prior authorization

watch demo →files →

A prior-auth decision rendered by the payer utilization-management system, with contested cases routed to a medical director, so a human is in the loop only where one is needed.

Records: PA request, payer adjudication disposition, appeal / peer-to-peer re-determination
Gates: medical-director determination (human), appeal re-determination (human)
Notify: PA determinations, UM queue
System of record: payer utilization-management system (HL7 Da Vinci PAS / X12 278)
Human role: medical director only on contested cases

Built against a reference HL7 Da Vinci payer system.

Finance: KYC and sanctions

watch demo →files →

Sanctions and PEP screening, an engine-decided score-band gate, two-tier review, and the regulator-facing no-tip-off notice.

Records: onboarding case, sanctions screen, regulatory report (SAR / OFAC)
Gates: score band (engine), alert disposition (human), onboarding decision (human)
Notify: compliance ops, regulator reports, applicant notices
System of record: external sanctions / PEP screening engine (OpenSanctions)
Human role: L1 analyst dispositions the alert; L2 / MLRO renders the onboarding verdict

Built against OpenSanctions screening.

Payments: disputes and chargebacks

watch demo →files →

The card-dispute lifecycle: the filing, a human-authorized one-shot decision to contest or concede with the evidence package hash-bound before it is submitted, and the relayed won/lost disposition. Includes the Visa Compelling Evidence 3.0 and inquiry paths.

Records: dispute filing, final disposition (won / lost + funds movement)
Gates: contest / concede decision (human), CE3.0 evidence decision (human), inquiry resolution (human)
Notify: disputes ops, fraud review
System of record: Stripe dispute API (issuer and network render the verdict)
Human role: a fraud-ops lead authorizes the contest or concede; a separate analyst assembles the evidence

Built against Stripe’s dispute API as the system of record.

Content moderation: DSA takedown

watch demo →files →

The EU Digital Services Act enforcement lifecycle: an inbound flag, the platform’s own human-gated takedown decision, the Article 17 statement of reasons to the user, the Article 24(5) submission to the DSA Transparency Database with its receipt bound on-chain, and the Article 20 appeal.

Records: inbound flag, Article 17 statement of reasons, Article 24(5) Transparency DB submission + receipt
Gates: enforcement decision (human, own-decision), Article 20 appeal (human)
Notify: moderation ops, transparency & appeals
System of record: none upstream (the platform’s own call); downstream, the EU DSA Transparency Database returns a receipt
Human role: moderator submits; an independent reviewer renders each verdict

Built against a self-hosted EU DSA Transparency Database.

Software delivery: GitHub

watch demo →files →

An agent-driven code-delivery flow end to end: the authoring agent’s stated intent and claims, the CI conclusion as GitHub computed it on the exact commit, the human authorization to merge or deploy rendered before the sha-pinned one-shot, and the outcome as GitHub reports it. GitHub is the first system of record in the catalogue that holds human gates of its own; the recipe composes AGLedger’s Gate with them under a one-decision-one-holder rule.

Records: authored change (intent, diff hash, claims), CI conclusion, review-verdict relay, deployment-approval relay, delivery outcome
Gates: merge authorization (human), deploy authorization (human), or relay GitHub’s native review and environment gates instead; one holder per decision
Notify: delivery ops, release authorizations
System of record: GitHub (Actions CI, protected branches, environment protection)
Human role: a release manager renders the merge or deploy verdict; GitHub’s author-cannot-self-approve stays on as an independent second line

Built against live GitHub: Actions, protected branches, and environment protection.

Tax: HMRC MTD VAT filing

watch demo →files →

A UK VAT return filed to HMRC under Making Tax Digital: the open obligation as HMRC states it, the nine-box return, an engine pre-flight arithmetic gate, the responsible officer’s statutory “true and complete” declaration held before the irreversible submission, and HMRC’s returned form bundle number (or typed rejection) bound to the exact bytes filed. The first government system of record in the catalogue, and the first where the bound receipt is itself the legally operative artifact: the taxpayer’s proof of having filed, and of when.

Records: obligation retrieved, return prepared, filing receipt (form bundle number or typed rejection), penalty observation
Gates: pre-flight well-formedness (engine), statutory declaration (human)
Notify: VAT filing ops, the officer’s declaration queue, receipts and penalties
System of record: HMRC Making Tax Digital VAT API (HMRC alone adjudicates acceptance)
Human role: the preparer submits the return; a distinct responsible officer renders the declaration verdict

Driven live against the HMRC developer sandbox, including the typed-rejection and duplicate-submission paths.

Employment: FCRA adverse action

watch demo →files →

A background screen where the gate is a clock. The CRA renders the adjudication; an engine gate auto-clears only a clean pass and routes everything else to a human EEOC individualized assessment. If the outcome is adverse, the FCRA two-step runs: the pre-adverse notice starts a mandatory waiting period so the candidate can dispute, an engine-enforced wait gate refuses a final action before the window elapses (the clock runs on the engine’s own signed timestamps, so nothing the orchestrator supplies can shorten it), and the final §615(a) decision is a person’s call. The elapsed interval is a litigated fact (Tyus v. USPS); here it is provable offline from two signed timestamps.

Records: screening order, CRA adjudication (verbatim label + normalized outcome, report hash), pre-adverse notice (starts the clock)
Gates: adjudication auto-clear (engine), wait window (engine-enforced clock), individualized assessment (human), final adverse action (human)
Notify: screening ops; candidate notices, scoped server-side to the two notice types
System of record: external consumer reporting agency (Accurate Background)
Human role: a reviewer renders the EEOC assessment; a distinct authorizer renders the final adverse action

Driven live against the Accurate Background sandbox; in a blind run, a cold agent given a final action that fell inside the waiting period stopped and reported it rather than working around the clock.

Pharma: GxP complaint investigation and batch record release

files →

Two GMP quality workflows. A read-only complaint investigation: a named QA investigator opens the case, automations read the manufacturing, laboratory, distribution and complaint-history datasets as engine-gated children (the gate settles only on a computed mutating flag, so a reader that wrote to a system of record fails the case), and the close-out binds the systems’ own write stamps. A batch record release: an LLM may propose, QA opens the release from the control plan, a deterministic checker runs every check the plan names against the quality system, the engine refuses the release while the check is open and holds it when the check fails, QA signs with a Part 11 signature meaning, and the writer’s receipt carries the same payload hash QA approved. The check record carries the control plan’s hash, never a list an agent could shorten.

Records: complaint case, evidence reads, batch record proposal, batch record release, precondition check, system-of-record write receipt
Gates: read-only invariant (engine), all required checks passed (engine), case close-out (human), release approval (human)
Notify: the QA queue (the two human gates), the automation gates, the batch record channel
System of record: Odoo 18.0 Community with the OCA quality modules, standing in for the MES, LIMS and ERP
Human role: a QA investigator closes the case; a distinct QA release signer approves the batch record

Built against a self-hosted Odoo with the OCA manufacture quality modules; the check record carries a hash of the full check list because, when the list was left for the agent to carry, some models dropped the failing check. Ships a validation package: intended use, requirements, traceability, OQ and PQ guidance.

We add and exercise new verticals over time. If you need one that is not here yet, tell us which one you need.

Horizontal: works in any domain

Agent Work Context: checkpoint and resume

read the guide →

Durable work state for AI agents, the mechanism behind agent memory. In-progress work is checkpointed as typed, immutable records under one root, so a fresh process resumes or takes over in one query, without the prior conversation. A stale or missed supersession surfaces as a visible fork on the next read; a client-side checker proves the lineage.

Exercised with cold model runs across four model families against a live server, committed traces included. The checkpoints sit beside your own work records under the same root, so the state and the work share one tree.

Agent Drift: an ops loop over the fleet

get the recipe →

The Server reports, per agent, what it did this window against the window before: records, completions, verdicts, acceptance rate, completion time. It deliberately sets no threshold. A short script selects the agents whose numbers moved in either direction and gathers the records behind each change; a reviewer, model or person, decides expected, watch or escalate from the records, not the counts.

Each tick’s decisions are notarized, so what the ops loop saw and decided on a given day verifies offline like any other record. No contract types to register.

Adapt it to your shop

AGLedger works from a narrow input: the contract shape for the work an agent is allowed to perform. That means the records, the gates, the authority checks, and the notifications that show up in any controlled workflow. A recipe gives you that shape for a whole domain workflow.

Import it under your org as ordinary, editable contracts, then reshape it: replace the example fields with your own, set your own thresholds and authority bands, and wire your own system of record or screening engine into the gate seam. A recipe is a starting point you own, not a turnkey product: it gives you the structure and a working example, and the decisions and the policy stay yours.

The recipe is plain files. Follow the install guide to register a recipe against your own Server in one command. If you want help adapting one to your process, talk to us.

Get a free developer key Install a recipe Request a vertical