From request to accepted result: an Aestus walkthrough

Full review transcripts

Fictional review examples. All notes, people, outputs, and decisions are made up. No customer data or live action is used.

Research brief

Three fictional interview notes. These people are not Aestus customers.

Brief: Summarize the three fictional interview notes. Link each claim to a quote. Keep names private.

1. Cover all three notes and attach a matching quote to each summary claim.

2. Use only anonymous note labels; include no person or company names in the output.

Source material:

• Note A: “I need to see the source beside the claim.”

• Note B: “I cannot tell which draft is ready to use.”

• Note C: “Tell me the checks before the work starts.”

1. Set the brief and two rules

Research lead (fictional) · Brief v1

The three anonymous source notes below are the complete input. The reviewer will check both rules before using the summary.

2. Read the first draft

Research agent (fictional) · Summary v1

Note A: The reviewer needs the source beside each claim. Quote A: “I need to see the source beside the claim.”

Note B: The handoff needs a clear version. Quote B: “I cannot tell which draft is ready to use.”

Note C: The reviewer needs the checks before work starts. Quote: missing.

3. Check the draft against both rules

Research reviewer (fictional) · Summary v1

All three notes are summarized, but the third claim has no quote. A plausible summary is not enough.

• Rule 1: Not met: the Note C claim has no matching quote attached.

• Rule 2: Met: the output uses only anonymous note labels.

4. Send the draft back

Research reviewer (fictional) · Summary v1 — sent back

Decision: send back Summary v1. Add the exact Note C quote to its claim. Keep the anonymous labels. This version is not accepted.

5. Inspect the correction

Research agent (fictional) · Summary v2

Note A: The reviewer needs the source beside each claim. Quote A: “I need to see the source beside the claim.”

Note B: The handoff needs a clear version. Quote B: “I cannot tell which draft is ready to use.”

Note C: The reviewer needs the checks before work starts. Quote C: “Tell me the checks before the work starts.”

6. Record the review decision

Research reviewer (fictional) · Summary v2 — accepted

Decision: accept Summary v2 against these two rules. The reviewer checked all three claims against their supplied notes. Summary v1 remains sent back; the decision applies to v2 only.

This fictional decision shows the review method. It does not prove that AI output is always correct.

• Rule 1: Met: all three notes have a summary claim and a matching quote.

• Rule 2: Met: the output contains no person or company names.

Code release handoff

A separate fictional review of the Meridian customer-import release handoff. This is not the original 71-minute journey or its P-12 approval story.

Brief: Prepare the customer-import-v1.0.0 release handoff for Maya. Show the required checks and explain how to return to the prior release.

1. Include results for invalid-row rejection and duplicate-safe retry checks.

2. Include rollback instructions and name the person who owns the rollback decision.

Source material:

• Fictional check report: invalid-row rejection passed; duplicate-safe retry passed.

• Fictional release owner: Maya. No repository, deploy, or external tool is connected to this example.

1. Set the brief and two rules

Maya, release owner (fictional) · Brief v1

A release handoff needs more than a passed check. Maya will compare the written handoff with both rules before accepting it.

2. Read the first draft

Coding agent (fictional) · Release handoff v1

Release handoff v1: customer-import-v1.0.0. Check report: an invalid row is rejected; retrying a valid row does not create a duplicate. Both checks pass in this fictional report.

Rollback instructions: missing.

3. Check the draft against both rules

Maya, release reviewer (fictional) · Release handoff v1

The required check results are present. The handoff does not say how to return to the prior release.

• Rule 1: Met: invalid-row rejection and duplicate-safe retry results are included.

• Rule 2: Not met: rollback instructions and their decision owner are missing.

4. Send the draft back

Maya, release reviewer (fictional) · Release handoff v1 — sent back

Decision: send back Release handoff v1. Add rollback steps and the decision owner. Passed checks do not replace the missing handoff requirement.

5. Inspect the correction

Coding agent (fictional) · Release handoff v2

Release handoff v2: customer-import-v1.0.0. Check report: an invalid row is rejected; retrying a valid row does not create a duplicate. Both checks pass in this fictional report.

Rollback instructions: pause new imports, restore the prior release, then check the saved row count before imports resume. Maya owns the rollback decision. These are fictional handoff notes, not instructions for a real system.

6. Record the review decision

Maya, release reviewer (fictional) · Release handoff v2 — accepted

Decision: accept Release handoff v2 against these two rules. The reviewer checked the report and rollback notes. Release handoff v1 remains sent back; the decision applies to v2 only.

Accepting this fictional document does not deploy code, authorize a payment, or prove production safety.

• Rule 1: Met: both required check results remain in the handoff.

• Rule 2: Met: rollback steps are present and Maya owns the decision.

Join the waitlist

The original Meridian journey — a separate fictional example

The two review transcripts above are separate teaching examples. The original timestamped record below is unchanged. Its 71-minute timeline and P-12 approval are not the timing or approval history of either new review track.

This is an illustrative internal example, not a customer story or production run. It uses the fictional Meridian Freight workflow defined in Aestus's checked-in marketing demo data.

The example follows ticket AES-184, “Ship the governed customer import,” inside the fictional Launch Operations workspace. The work starts with a goal and ends with the accepted artifact customer-import-v1.0.0.

1. A person sets the goal

At 09:00, Maya Chen, the fictional customer operations lead, sets the goal. The attached artifact is the customer import goal brief.

This creates the outcome and accountable owner before an agent starts. The request is not inferred from a later run transcript.

2. A planning agent drafts the spec

At 09:08, Aestus Planning creates the governed customer import spec. The spec becomes another artifact on the same work record.

The planning output is progress, not completion. It gives the coding step a defined input.

3. A coding agent produces the change

At 09:24, Claude Code writes the change and produces PR #184 · customer import.

The pull request is a delivered artifact. It still does not prove that the requested workflow is accepted.

4. A review agent runs checks

At 09:41, Aestus Review records that tests passed and attaches an import validation report.

Passing checks provide quality evidence. They move the work toward acceptance, but they do not replace the human decision defined by this example.

5. A named person reviews the governed step

At 10:03, Priya Raman, the fictional security approver, records the P-12 approval step. The checked-in fixture describes P-12 as a policy for transfer.create calls that holds the action for Priya's sign-off.

The accepted-result story records this approval as part of the workflow history. A separate fictional card, AES-179, demonstrates the deny path: an $80,000 transfer is held by P-12 and denied. That second card is a policy counter-example, not a claim about real funds or a real customer.

6. The accountable person accepts the artifact

At 10:11, Maya accepts customer-import-v1.0.0. The checked-in demo marks the artifact status as “Accepted.” The elapsed time from the first goal event at 09:00 to acceptance at 10:11 is 71 minutes.

This final event changes the meaning of the record. The workflow now has a named result, acceptance evidence, and a clear finish. Earlier events remain available as its history.

What this example proves—and what it does not

The example shows the data model Aestus uses in its public product demo:

• one ticket carries the goal, workers, artifacts, checks, approval, and acceptance;
• agent output and accepted completion are different states;
• a human decision has a named actor and policy record; and
• the final artifact stays linked to the steps that produced it.

It does not show customer performance, production reliability, or a measured cost saving. Meridian Freight, its people, the ticket, and the amounts are fictional. The times and artifacts are deterministic demo values stored in the repository.

For the operating model behind the example, read what AI agent operations is. For the control design, read human approval workflows for AI agents. For measurement, read AI agent cost tracking.

Checked-in fact sources

The fixture facts come from app/(marketing)/_components/demo/site-demo-data.ts and app/(marketing)/_components/demo/board-story.ts. The Aestus resource parser keeps this page's label and source note part of its public content contract.