Coding agent

Run Pi from a complete task and return proof to the same card

Give Pi the brief, workspace memory, policy, and proof contract before the session starts.

Pi with Aestus

Keep the tool. Change what the team can see.

Each Pi session starts with the Workspace Memory brief and relevant cited claims available to that session. Personal, team, workspace, and organization claims keep their audience rules. At handoff, it can propose what it learned for human review.

Pi runs from the accountable card rather than an isolated prompt. The task supplies the repository, expected result, constraints, linked evidence, focused verification, and applicable policy. Aestus records which runtime took the work, where the session is running, and which human still owns acceptance.

The adapter can stop a supported tool call for a native approval. That pause is narrow: it decides whether the named action can continue. Pull request review, task acceptance, and memory promotion remain separate decisions, so one approval cannot silently approve every result of the run.

At handoff, Pi returns the patch, checks, cost, and any cited memory proposal to the same card. The proposal names what the session learned and where it learned it. A promotion rule or person can accept, correct, or reject that lesson without rewriting the delivery record.

Good first workflows

Repair a bounded contract
Give Pi one failing fixture, a stable interface, and the exact focused check to run.
Use a native approval pause
Hold a supported consequential tool call until the named person approves or rejects it.
Return useful memory
Let the session propose a cited lesson without promoting it before a person reviews it.

A complete Pi example, from trigger to proof.

The example names the people, task event, tool boundary, returned evidence, and acceptance state. The run row below it is a fixed product example, not customer data.

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

Inside the connected tool

What the handoff looks like in Pi

Pi starts from the assigned card inside the governed coding session and returns the patch, checks, and cited lessons to it.

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

Developer terminal

Live

pi
sandbox ready · policy "Engineering default" v7 · egress restricted
PiReading src/billing/invoice.ts
PiEdit src/billing/invoice.ts
Blocked by policy: api.unknown-host.dev
PiRan tests · 41 passed

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

Concrete workflow example

Repair a review receipt with a governed Pi session

A receipt stopped showing the approval reason. The card names the stable schema, the failing fixture, and the proof needed for review.

TriggerAES-536 is assigned to Pi

1
Iris · Platform
Pins the receipt contract to the card
Restore the missing reason without changing the export schema or older receipts.
contract v4 · failing fixture
2
Pi
Claims the task and reads the workspace brief
The session starts with the relevant cited claims, then reports when work moves to implementation.
claim · memory brief loaded
3
Pi
Returns the patch and proposes one learned claim
The focused receipt checks pass, and the proposed claim keeps its source for a person to review.
PR #219 · 12 tests passed
4
Iris · Platform
Reviews the patch and the proposed memory
Code acceptance and memory promotion remain named decisions on the same task.
accepted · claim promoted

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

Deterministic product example — not a production run

Repair the approval receipt

Example run		Runtime	Outcome
EXAMPLE-PI-01	Pi	pi	Completed	$0.02	36.5s

Tokens in / out: 5,200 / 420
Failure code: —
Agent: coding-agent

Example source: lib/marketing/integration-run-examples.ts

Example run cost

$0.0186 in the deterministic product example

This checked-in example defines one Pi run with 5,200 input tokens, 420 output tokens, and a 36.5-second duration. It is not customer data or a price promise.

Set it up in four steps.

Follow the real Pi connection path. Provider steps link to the provider documentation. Aestus steps name the contract they follow.

01
Choose Pi for coding work
Select Pi as the coding runtime for the task or for the board column that starts it.
Aestus contract: docs/runbooks/aestus-cli.md
02
Name the result and proof
Put the repository, expected change, acceptance rules, and focused checks on the card before the run starts.
Aestus contract: docs/agent-ticket-workflow.md
03
Start the governed session
Aestus launches Pi inside the organization-defined sandbox with the workspace brief and applicable policy.
Aestus contract: docs/runbooks/aestus-cli.md
04
Review both outputs
Review the pull request and any cited memory proposal as separate decisions, then accept or return the work.
Aestus contract: docs/agent-ticket-workflow.md

The boundary stays visible while the work moves.

See what Pi can do, where a person still decides, and what Aestus records for every governed run.

Where control lives

Native approval support

The Pi adapter can pause supported tool calls for an Aestus approval gate.

A person makes the decision

The request names the action, reason, and approver before the held tool call continues.

Review stays separate

A tool approval does not accept the patch or promote a proposed memory claim.

What Aestus records

Usage

The run keeps its runtime, tokens, model spend, tool spend, and elapsed time.

Delivery

The branch, pull request, focused checks, and handoff stay attached to the requesting card.

Memory proposal

A proposed lesson keeps its source and waits for the applicable promotion rule.

Questions teams ask

Do I install Pi on my laptop?

No for this path. Aestus starts the Pi harness inside the governed coding session selected on the task.

Can Pi pause for an approval?

Yes. The current Pi adapter supports native approval pauses for tool calls covered by the active policy.

Does every proposed lesson become workspace memory?

No. Pi proposes a cited claim. The applicable promotion rule and human review decide whether it becomes served memory.

See all integrations See the security controls

Start with one Pi run.

Bring one real run. Map its actors, boundary, evidence, cost, and acceptance step.

Talk to us

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

Concrete workflow example

Repair a review receipt with a governed Pi session

A receipt stopped showing the approval reason. The card names the stable schema, the failing fixture, and the proof needed for review.

TriggerAES-536 is assigned to Pi

1
Iris · Platform
Pins the receipt contract to the card
Restore the missing reason without changing the export schema or older receipts.
contract v4 · failing fixture
2
Pi
Claims the task and reads the workspace brief
The session starts with the relevant cited claims, then reports when work moves to implementation.
claim · memory brief loaded
3
Pi
Returns the patch and proposes one learned claim
The focused receipt checks pass, and the proposed claim keeps its source for a person to review.
PR #219 · 12 tests passed
4
Iris · Platform
Reviews the patch and the proposed memory
Code acceptance and memory promotion remain named decisions on the same task.
accepted · claim promoted

Example run

Runtime

Outcome

EXAMPLE-PI-01

Completed

$0.02

36.5s

Questions teams ask

Do I install Pi on my laptop?

No for this path. Aestus starts the Pi harness inside the governed coding session selected on the task.

Can Pi pause for an approval?

Yes. The current Pi adapter supports native approval pauses for tool calls covered by the active policy.

Does every proposed lesson become workspace memory?

No. Pi proposes a cited claim. The applicable promotion rule and human review decide whether it becomes served memory.

Run Pi from a complete task and return proof to the same card