Ari’s Space*   est. 2026
Skip to content
ari*s space[ a. ]
← Libraryworkflows / 2026-07-21

Work YOUR Way With Pi

Pi supplies a small extensible harness. The operator defines the parent seat, specialist boundaries, routing policy, and evidence gate.

6 parts / Hover to explore. Click to read.

Pi supplies a small extensible harness. The operator defines the parent seat, specialist boundaries, routing policy, and evidence gate.

Parent: outcome + boundaries
          | assess the work
          +-> Reason
          +-> Perform
          +-> Do
          | artefact + evidence
          v
     parent checks whole job
          |
    accept / retry / escalate
Route by consequence and complexity, keeping the parent responsible for the whole job. Ambiguity stops the Do lane for reassessment, and irreversible decisions retain human authority.
A small kernel keeps the work moving without leaving the seat.

Pi gives you a small, extensible harness. The surrounding way of working is yours to define: which agent stays with you, what gets delegated and what has to come back before a job can count as finished.

That last part matters more than the number of agents. A system can return a confident report without returning the thing you asked it to make.

Keep the stable core small

The harness holds the conversation and its basic agent machinery. Tools, skills, extensions, provider choices and working conventions can sit around that core.

I want those surrounding choices to be visible. If I change a tool or model, I should be able to change the relevant part of the setup without rebuilding the whole working relationship.

A small core still needs clear guarantees. Write down what it is responsible for, then make the operator's policy explicit around it.

The seat owns judgement. The worker owns the bounded task.

Keep a parent seat with the human

The parent seat receives the outcome, understands the constraints and keeps the whole job coherent. It decides which parts can be separated and checks how the returned work fits together.

It doesn't disappear after assigning tasks. A specialist can complete a narrow brief and still leave the overall job wrong.

Give each specialist four things: an outcome, its boundary, the evidence expected on return and a stop condition. Hidden priorities are a poor delegation mechanism. If a decision belongs to the human, the brief should say how to bring it back.

The specialist returns an artefact and concise findings. The parent keeps responsibility for the wider context and trade-offs, including conflicts between otherwise reasonable pieces of work.

Route by the work and its consequences

Keep reasoning close to the person. Make action explicit and inspectable.

Reason, Perform and Do describe different kinds of work. They aren't medals for the models occupying those seats.

Reason handles high consequences, deep ambiguity, architecture and difficult debugging. Ask it to expose assumptions, compare viable options and explain what getting the decision wrong would cost.

Perform implements a clear brief. There may be several coordinated changes, but the outcome and boundary are known. It returns the changed artefact, a targeted check and any conflict that needs the parent to decide.

Do handles bounded, repeatable work: classification, parsing, routine transformations, routing and basic boilerplate. Give it a rule and a sample check. If applying the rule becomes ambiguous, stop execution in the Do lane and return the task for reassessment.

Use consequence and complexity together. A simple irreversible action belongs in Reason. A complex but reversible implementation may fit Perform. Choosing by complexity alone misses the cost of a small mistake.

Consequence and complexity decide the route.

Make completion an evidence loop

A finished claim needs a visible artefact and a real check.

Keep the loop explicit:

claim → artifact check → test or inspection → accept / retry / escalate

First, find the claimed artefact. Does it exist, and does it match the requested shape? Then run the relevant test or inspect it against the stated constraint.

The parent can accept work that meets the brief, request a targeted retry when the fault is clear, or escalate a decision it cannot make. “Finished” is the start of this check, not a substitute for it.

Human authority stays with judgement-heavy and irreversible decisions. The parent can make the options clearer. It cannot quietly turn a choice about risk, intent, ownership or consequence into an implementation default.

Start with a contract you can inspect

Begin with one parent seat and a few specialist briefs. Write the outcome, boundary, evidence and escalation rule before increasing the automation.

The starter below contains that public contract. Adapt it to your work, give it one real task, and inspect what the parent does with the specialists' results.

↓AGENTS.md starter

If the evidence is missing, the job is still open. That's a useful rule to establish while the system is small enough to understand.

[ comments ]

guests welcome. members show first in the list

no comments yet. start the thread_

1 / 8