Agentic best practices

See how an agent system works before you build one

The interaction library documents what a human sees when working with an agent. This library documents what is happening underneath: how an agent decides, calls tools, keeps state, hands work to other agents, waits for a person and recovers when something fails. Every pattern is a diagram you can run, step through, break and compare, with a deterministic simulation and the primary sources that back it.

3 interactive patterns · 46 planned · 9 lifecycle stages · 27 verified sources

Start with one of three

A request enters from the left into a model ring. Three tools sit to its right: read file, run tests, edit file. Each tool call returns to the ring, which holds a context window above it and a step budget below it. When the ring answers, the result leaves to the right; when the budget runs out, the loop escalates to the developer at the bottom right.promptevery turncallcallcallresultresultresultanswerexhaustedapproveRequestContext windowModel decidesStep budgetRead fileRun testsEdit fileAnswerDeveloper

foundations · established

Single-agent tool loop

One model decides, one tool runs, the result comes back, and the model decides again until the job is done or a budget runs out.

Run it →
A request enters a lead model ring. Above it sits the plan it wrote. Three worker rings run in parallel to the right, each with a slice of the task; one reads the public web and is marked untrusted. Their results join at a merge dot, return to the lead, and the answer leaves on the right. A per-worker budget sits beneath the lead.writesreviewbriefbriefbriefresultresultresultsynthesiseanswerthin · failedRequestPlanOrchestratorBudgetsWorker: public webWorker: internal docsWorker: codebaseResults joinAnswerResearcher

multi agent · established

Orchestrator and workers

A lead agent breaks a task into bounded sub-tasks, hands each to a worker with its own context, and synthesises what comes back.

Run it →
A change request enters a risk router. The low-risk edge goes straight to an implement ring, then a verify diamond, then a ship tool and the output. The high-risk edge drops to a plan ring, a checkpoint bar, and a reviewer double ring who can approve into implement, edit back into plan, or decline to the output. A typed state stack sits above the router; verify loops back to implement on failure.read/writelow riskhigh riskwaitapproveeditdeclinepassfail (≤2)3rd failureChange requestTyped stateRisk routerImplementPlanCheckpointReviewerVerifyOpen PRDone

graph · established

Stateful graph with branching and human approval

Explicit nodes and edges over typed, checkpointed state: the run branches on a condition, waits for a reviewer, and resumes later from where it stopped.

Run it →

Three layers, one site

Interaction

How a human understands, supervises and collaborates with an agent. The interaction library.

Engineering

How an agent reasons, uses tools, coordinates, keeps state and executes. This library.

Operations

How the system is secured, evaluated, deployed, observed and governed. Security and governance, the SDLC explorer.

Every engineering pattern names the interaction patterns a human meets when it runs, and the lifecycle stages where it earns its keep.

Six ways in

What a simulation is, and is not

Every run on this site is a learning simulation: a deterministic, authored trace with curated example inputs. It shows what each component receives, decides and produces, and it is repeatable. It is not a real model execution; no model is called to draw or step a diagram. A connected mode that runs real frameworks under consent and budgets is specified but not built. The label on every stage says which you are looking at.