Aestus-native

Every agent handoff is checked before it reaches you

Checks an agent's finished work against that ticket's own acceptance criteria, files a finding per problem, and sends it back when it falls short.

Join the waitlist See what it produces

Before a person reads it

Pre-review every agent handoff

Who it is for: Leads whose agents finish more work than they can read.
What starts it: Every time a ticket enters your review column; On a board move

Turn it on in Aestus

When agents finish faster than you can read, the review queue becomes the bottleneck, and the bottleneck is you. Every handoff arrives cold: re-read the brief, re-read the acceptance criteria, open the artifact, decide. That reading is the real cost of supervising agents, and it grows with every agent you add.

This use case puts an independent reviewer in front of you. The moment a ticket enters your review column, a read-only reviewer reads the ticket's own brief and acceptance criteria, opens what the producing run left behind, and checks the work one criterion at a time. It quotes each criterion back word for word and marks it met, not met, or unverifiable — and unverifiable means it says which evidence it could not open.

Every problem it finds becomes a row rather than a paragraph: a severity, a category, where to look, a quote copied from the work, and the fix it suggests. Rows can be counted, filtered and resolved later. Paragraphs cannot.

The part that decides whether any of this is worth reading is the check it runs on itself. A quote that is not a verbatim copy, a section heading that is not in the document, a figure with no traceable source — each of those sends the review back to be repaired before a single finding is filed. Two attempts, and then the run fails and writes nothing. A failed check never sends a ticket back and never advances one, so the ticket simply waits for a person.

It changes nothing it reviews. It has no write tools, it reaches no system outside your organization, and it does not move the ticket itself — a send-back is performed by your own board rules, under the round cap that already governs them. What reaches you is either work that passed a check, or a specific written reason it did not.

What you get

The artifact this use case produces, in the product view you would read it in.

Example — fictional team and data. Not a live run or customer result.

Worked example

document

Handoff review — MER-418 Draft the Q3 supplier risk brief

Produced by: Run EXAMPLE-PR-01 · read-only · document artifact

Summary: 3 of 5 acceptance criteria are not met. The reviewer read the brief and the artifacts the producing run left behind, and checked the work one criterion at a time. It changed nothing it read.
Checked against: One row per criterion, each quoting the criterion word for word from the ticket and marked met, not met, or unverifiable — with the evidence beside it. 5 criteria on this ticket.
Findings: 4 findings, each carrying a severity, a category, where to look, a quote copied from the work and a suggested fix — 2 critical. Every quote is a verbatim copy; a paraphrase fails the check before anything is filed.
Sent back: The written reason the ticket went back, naming the unmet criteria and what would make the handoff pass. It has to be specific enough to act on, so the next run starts knowing what was wrong.
Sources read: Everything the reviewer opened, listed by name: the ticket, each artifact and its revision, and the run that produced it. A figure the reviewer cannot trace to one of these is a finding, not a number it repeats.

How it runs

Each step is one node in the workflow graph the interpreter runs. Nothing here is a prompt chain hidden in a route handler.

Workflow steps

01Input
Somebody, or an agent, moves a ticket into your review column. The ticket's description and its acceptance criteria come with it.
02Agent
A read-only reviewer opens every artifact the producing run left behind and checks the work one criterion at a time, quoting each criterion back word for word and marking it met, not met, or unverifiable.
03Eval checkpoint
A judge checks the review itself before anything is filed. A quote that is not a verbatim copy, a locator that does not exist, or a figure with no source sends it back to be repaired. Two attempts, then the run fails and nothing is written.
04Output
The review is saved as a document on the ticket and each problem is filed as its own finding. On a request-changes verdict the ticket goes back to the column it came from, with the written reason attached.

By hand, and on Aestus

The same job, on either side.

By hand
You re-read the ticket to remember what was asked for.
On Aestus
Each acceptance criterion is quoted back word for word.
By hand
You hold five criteria in your head while reading a document.
On Aestus
Each one gets a row: met, not met, or unverifiable, with the evidence.
By hand
You write a comment, and next week nobody can find it.
On Aestus
Each problem is a finding row with a severity, a locator and a quote.
By hand
You say “this needs work” and hope the agent guesses which part.
On Aestus
The ticket goes back with a reason, and the next run starts with it.
By hand
A document handoff gets no first check, because there is no diff.
On Aestus
Documents, spreadsheets and research are reviewed the same way as code.
By hand
You have a feeling about which agent needs watching.
On Aestus
Findings and verdicts are rows, so first-time pass rates are a number.

What Aestus records

Every run is auditable after the fact, which is what makes handing the job over survivable.

The run
Cost, tokens, latency and outcome for the review, on the same ledger as every other run in the workspace.
The findings
One row per problem, carrying its severity, its category, where to look and the quote it was based on, so it can be filtered and resolved later.
The verdict
One verdict on the run's outcome record, and on a send-back the written reason, both on the ticket and in the next run's brief.
The document
The review is kept as an artifact you can open again, so a call made in week one can be reread in week six.

What it connects to

This use case reaches no system outside Aestus. It reads governed evidence and writes a document, so there is nothing to connect and no approval to wait on.

Questions teams ask

Does it change the work?

No. The reviewer has no write tools at all. It reads, it reports and it states a verdict. The ticket move on a failed review is done by your own board rules, not by the reviewer picking a column.

What if the reviewer is wrong?

The verdict is a first check, not the last word. Everything it filed is on the ticket, so you can dismiss a finding or move the ticket on yourself. It never merges, closes or approves anything.

Does this only work for code?

No, and that is the point. A pull-request reviewer needs a diff. This one reads whatever the run produced — a document, a spreadsheet, a research brief, a plan — and checks it against the ticket's acceptance criteria.

What stops it inventing a problem?

A judge checks the review before anything is filed. Every quote has to be a verbatim copy of something it read, every locator has to exist, and every figure has to be traceable. If that fails twice the run fails and nothing is written.

Can it bounce a ticket forever?

No. The send-back loop has a round cap, and when a review keeps reporting the same unfixed problem the ticket moves forward for a person instead of bouncing again.

All use cases How access is governed

Sources

docs/agent-ticket-workflow.md

Hand over Pre-review every agent handoff.

Tell us how your team does this today and we will set it up with you.

Talk to us

Questions teams ask

Does it change the work?

No. The reviewer has no write tools at all. It reads, it reports and it states a verdict. The ticket move on a failed review is done by your own board rules, not by the reviewer picking a column.

What if the reviewer is wrong?

The verdict is a first check, not the last word. Everything it filed is on the ticket, so you can dismiss a finding or move the ticket on yourself. It never merges, closes or approves anything.

Does this only work for code?

What stops it inventing a problem?

Can it bounce a ticket forever?

No. The send-back loop has a round cap, and when a review keeps reporting the same unfixed problem the ticket moves forward for a person instead of bouncing again.

Sources

docs/agent-ticket-workflow.md

Every agent handoff is checked before it reaches you

Pre-review every agent handoff

What you get

Handoff review — MER-418 Draft the Q3 supplier risk brief

How it runs

By hand, and on Aestus

What Aestus records

The run

The findings

The verdict

The document

What it connects to

Questions teams ask

Hand over Pre-review every agent handoff.

Every agent handoff is checked before it reaches you

Pre-review every agent handoff

What you get

Handoff review — MER-418 Draft the Q3 supplier risk brief

How it runs

By hand, and on Aestus

What Aestus records

The run

The findings

The verdict

The document

What it connects to

Questions teams ask

Hand over Pre-review every agent handoff.