๐Ÿ“„ work-your-way-with-pi.md21/07/2026
Documents โ€บ workflows

Work YOUR Way With Pi

A small kernel keeps the work moving without leaving the seat.

Pi Is The Kernel

Pi is deliberately small. It gives you a stable harness for an agent, then leaves the surrounding system open to design. That distinction matters because the useful part of an agent system is rarely a single model call. It is the contract around the call: what work enters, who owns the decision, what evidence returns, and when the system must stop.

Tools, skills, extensions, provider choice, and agent conventions can sit around that kernel without becoming the kernel. The result is a system that can change its working parts without forcing you to rebuild the conversation layer every time a tool changes.

Minimal extensibility is not an empty starting point. It is a boundary. Keep the stable core responsible for the smallest possible set of guarantees, then make the policy around it visible, inspectable, and owned by the operator.

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

The Parent-Seat Contract

The parent seat stays with the human. It receives the outcome, interprets constraints, decides what can be separated, and retains the context that makes the work coherent. A parent agent is not a queue manager that disappears once it has handed out tasks. It is the reviewer of the whole system.

Specialists receive bounded work. A useful specialist brief names one outcome, the constraints that shape it, the evidence expected at closeout, and the stop condition. It should not require a specialist to infer hidden priorities or make a decision that belongs to the human.

That split protects both sides. The parent can keep the long-lived conversation and the responsibility for tradeoffs. The specialist can concentrate on a small surface, return an artifact and concise findings, then surface a blocked decision instead of silently expanding scope.

Route The Work, Not The Prestige

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

Reason, Perform, and Do are descriptions of work, not rankings of intelligence.

Reason is for high-consequence work, deep ambiguity, architecture, and hard debugging. It should identify assumptions, compare viable options, and make the cost of being wrong explicit before a decision moves forward.

Perform is for substantive implementation inside a clear brief. The work may involve several coordinated changes, but the outcome and the boundary are known. Its closeout should show the changed artifact, a targeted check, and any conflict that needs a parent decision.

Do is for bounded, repeatable work such as classification, parsing, routine transforms, routing, and basic boilerplate. It needs a stated rule and a sample check. If the rule becomes ambiguous, it stops being Do work.

Route by consequence and complexity together. A simple action with irreversible consequences belongs in Reason. A complex but reversible task may belong in Perform. This avoids the prestige trap of sending every task to the most capable seat, even when a smaller, inspectable process is safer and easier to review.

Consequence and complexity decide the route.

Evidence Before Completion

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

An agent saying it is finished is a claim, not a completion event. The parent closes work through one explicit loop:

claim โ†’ artifact check โ†’ test or inspection โ†’ accept / retry / escalate

First, confirm the claimed artifact exists and matches the requested shape. Then run the relevant test or inspect the output against the stated constraint. Only then can the parent accept it, send it back for a targeted retry, or escalate the unresolved question.

This is not bureaucracy for its own sake. Agent systems can produce detailed reports that sound complete while the expected file, change, or behavior is absent. Evidence keeps completion grounded in a thing another person can inspect.

The human remains the authority for judgment-heavy and irreversible decisions. The parent can frame options and expose failure modes. It cannot quietly convert a decision about risk, intent, ownership, or consequence into a technical default.

Build Your Own Parent Seat

Start with one parent seat and a small number of specialist contracts. Write down the outcome, boundary, evidence, and escalation rule before you add more automation. The system becomes trustworthy through clear handoffs, not through a larger pile of autonomous steps.

The starter below contains the public version of that contract: specialist boundaries, tier routing, evidence requirements, and escalation rules. Adapt the language to your own work, then make the parent responsible for checking what the specialists return.

โ†“AGENTS.md starter

๐Ÿ“Œ Files attached

Related