Every intelligent decision needs another LLM call

Which worker should act next

Is this source relevant

Is the result safe to publish

Does the task look finished

Should the system retry, escalate, or stop

None of those decisions require a paragraph

Yet most agent stacks still ask a generative model to reason in prose, emit JSON, wait for a parser, and hope the schema survives

That is not intelligence architecture

It is a chatbot being used as a switch statement

Jev changes the primitive

It does not generate text

It reads the current state of a system, evaluates typed questions, and returns probabilities that software can act on directly

The gains aren’t free: Jev can't generate text

Diogo Almeida, TypeSafe AI's founder

That limitation is the entire point

When a model gives up open-ended strings, it can become a much faster and more composable decision layer inside code

Diogo Almeida post

The important launch is not another model

It is a new division of labor inside an agent

LLM   creates the work
JEV   decides what happens next
CODE  executes and enforces the decision

This article is about how to engineer that split properly

Subscribe now

The expensive mistake inside most agents

An agent loop looks simple from the outside

goal -> model -> tool -> observation -> model -> tool -> result

But zoom in and you find dozens of small judgments hidden between the large actions

Is the request clear enough
Which tool should run
Which model should receive this task
Which source should survive retrieval
Is the tool call risky
Did the action actually work
Is the evidence strong enough to stop

The usual response is to send every question back to the same frontier LLM

That creates four problems

Latency compounds

One extra model call does not feel expensive

Twenty sequential calls do

An agent can spend more time deciding whether to continue than doing the work itself

Cost moves into invisible branches

The final answer may be short

The internal routing, scoring, checking, and retry decisions can consume most of the token budget

Strings create integration work

The model returns prose or JSON

Your code validates it, repairs it, retries it, or quietly accepts a malformed edge case

Confidence is improvised

An LLM can say it is 95% confident

That number is usually another generated token, not a calibrated operating signal

The deeper problem is architectural

Generation and decision-making have been collapsed into the same call

Jev engineering begins by separating them

Jev is not a smaller chatbot

TypeSafe calls Jev its first System One Model

The interface is closer to a frontier-intelligence function than a conversation

INPUT
current state + typed questions

OUTPUT
typed answers + probability distributions

Jev does not draft the email

It can decide which queue should receive the email

It does not write the research report

It can score whether the collected evidence is sufficient

It does not execute the shell command

It can estimate whether the proposed command requires approval

It does not explain itself in a long chain of thought

It returns a constrained answer your code already knows how to handle

TypeSafe built the model around a training method it calls Reinforcement Learning for Calibrated Decisions, or RLCD

The goal is not prettier language

The goal is decision quality plus useful uncertainty

TypeSafe reports end-to-end latency of roughly 70–500ms for Jev-shaped queries and pricing of $0.042 per million input tokens, with no metered output-token cost

Its larger speed and cost claims come from favorable workflow evaluations and should be treated as ceilings, not promises for every application

That nuance matters

Jev is valuable even when it is not 200x faster

The deeper win is that a decision becomes an explicit, typed, testable component

TypeSafeAI post

The three-layer agent stack

The cleanest architecture has three different owners

GENERATE  ->  LLM
DECIDE    ->  JEV
ENFORCE   ->  CODE

The LLM generates

Use a generative model when the output itself must be created

• Research

• Writing

• Planning

• Code

• Explanations

• Open-ended synthesis

Jev decides

Use Jev when the meaning is fuzzy but the possible answer shape is known

• Route to one worker

• Score against a rubric

• Estimate yes or no

• Choose whether to retry

• Select whether to escalate

Code enforces

Use deterministic code when the rule must be exact

• Permissions

• Budgets

• Retry limits

• Account access

• Database writes

• Publishing

• Deletion

• Money movement

This creates a useful rule

If the system must create language, use an LLM

If it must interpret meaning and choose from known outcomes, use Jev

If it must obey an exact invariant, use code

The most dangerous mistake is to let a confidence score become permission

Jev can recommend an action

Only the harness should authorize it

Jev has three decision primitives

Jev keeps the interface deliberately small

The three primitives are enough to build most semantic branches inside an agent

Choice

Use Choice when exactly one option should win

from typesafe_sdk import Choice

next_worker = Choice(
    instructions="Which worker should act next?",
    criteria={
        "research": "Important evidence is still missing",
        "write": "Enough evidence exists to draft the answer",
        "review": "The request is unclear, complete, or consequential",
        "none": "No listed worker is appropriate",
    },
)

The result includes the selected option, a probability distribution over the options, and confidence

Do not design a closed menu when reality is open

If the options might be incomplete, include ‘none’, ‘other’, or ‘escalate’

Otherwise probability mass is forced onto the least-wrong answer

Score

Use Score when the decision lives on an ordered rubric

from typesafe_sdk import Score

evidence_quality = Score(
    instructions="How well does the evidence support the requested conclusion?",
    criteria=[
        "No direct support",
        "Partial support with important gaps",
        "Strong support from multiple independent sources",
    ],
)

The output can fall between levels

That does not turn an ordinal rubric into an exact measurement

A score of 1.6 is not “80% good”

It is a position between descriptions you defined

Noul

Use Noul for a yes-or-no probability

from typesafe_sdk import Noul

requires_approval = Noul(
    instructions=(
        "Would executing the proposed action publish, purchase, delete, "
        "change permissions, or represent the user externally?"
    ),
)

A result near 1.0 means likely yes

A result near 0.0 means likely no

A result near 0.5 means the model cannot distinguish confidently

It does not mean medium approval risk

If you need low, medium, and high risk, use Score

The question is part of the program

Many builders will treat Jev questions like casual prompts

That wastes the entire advantage

A production question is a decision contract

It defines what evidence matters, which outcomes exist, and how the result enters code

DECISION CONTRACT

state fields
question instructions
option descriptions or rubric
fallback outcome
confidence thresholds
allowed action
escalation path
version

One subtle detail matters immediately

Jev does not learn the task from your internal question ID

Calling a field safe_to_publish does not instruct the model what safe means

The actual rule must appear in the instructions and criteria

# weak
"safe_to_publish": Noul(
    instructions="Is this safe?"
)

# stronger
"safe_to_publish": Noul(
    instructions=(
        "Does the draft contain only verified claims with citations, avoid "
        "private information, and require no unresolved legal or financial approval?"
    )
)

The key name helps your code

The instructions help the model

Confusing the two creates invisible bugs

State engineering matters more than prompt decoration

Jev can only judge the state you provide

Do not send a giant conversation and expect the model to reconstruct your workflow

Give it the compact evidence required for the decision

state = {
    "goal": "Prepare a cited briefing on three new agent tools",
    "constraints": {
        "publish": False,
        "deadline": "09:00 UTC",
        "max_sources": 12,
    },
    "completed_work": {
        "sources_collected": 7,
        "draft_exists": True,
        "fact_check_complete": False,
    },
    "evidence": [
        {"id": "s1", "kind": "official_docs", "supports": ["pricing"]},
        {"id": "s2", "kind": "launch_post", "supports": ["availability"]},
    ],
    "available_workers": ["research", "write", "fact_check", "review"],
}

Good state is separated by function

GOAL          what success means
FACTS         what the system knows
ARTIFACTS     what already exists
EVIDENCE      what supports the next judgment
CONSTRAINTS   what the system may not cross
OPTIONS       what can happen now

Bad state mixes claims, instructions, old attempts, and irrelevant history into one text blob

The model may still return a valid type

It can still choose the wrong valid option

This is the most important correction to the “zero hallucination” headline

Jev cannot break the declared output schema

It can still be semantically wrong

Type safety removes one failure class

It does not remove the need for evidence, thresholds, tests, and review

Ask independent questions in parallel

Most agent decisions are evaluated sequentially because LLM generation is sequential

Jev is designed to evaluate multiple typed questions against the same state in one request

client = TypeSafeClient(model="jev-latest")

response = client.system_one(
    state=state,
    questions={
        "next_worker": Choice(
            instructions="Which available worker should act next?",
            criteria={
                "research": "Evidence gaps remain",
                "write": "Evidence is sufficient for drafting",
                "fact_check": "A draft exists but claims need verification",
                "review": "The work is complete, unclear, or consequential",
            },
        ),
        "urgency": Score(
            instructions="How urgent is the request?",
            criteria=[
                "No time pressure",
                "Time-sensitive but can wait",
                "Immediate business impact",
            ],
        ),
        "requires_approval": Noul(
            instructions="Would the next action create an external side effect?"
        ),
    },
)

The three questions inspect one snapshot of reality

That makes the decision record easier to understand

{
  "state_version": "run_184:step_7",
  "next_worker": "fact_check",
  "next_worker_confidence": 0.91,
  "urgency_score": 1.24,
  "approval_probability": 0.82
}

Parallel does not mean dependent

One question cannot consume another question’s fresh answer inside the same call

If the second decision depends on a search result, perform the search first, update state, then ask again

The boundary is simple

SAME EVIDENCE     -> ask together
NEW EVIDENCE      -> update state first

Confidence is a routing signal

Most systems flatten probability into a label too early

0.51 -> YES
0.99 -> YES

Those answers should not receive the same authority

The probability distribution should change the route

def route_decision(choice, confidence, consequence):
    if consequence == "irreversible":
        return "human_review"

    if confidence >= 0.90 and consequence == "low":
        return choice

    if confidence >= 0.70:
        return "collect_more_evidence"

    return "human_review"

This creates three operating zones

High confidence, low consequence

Automate the branch

Examples: choose a worker, sort an internal queue, rank a shortlist

Medium confidence

Improve the state

Fetch another source

Ask a stronger model

Run a deterministic check

Narrow the options

Low confidence or high consequence

Escalate

Do not make the system repeat the same uncertain decision with the same evidence

Confidence without a different next action is decoration

Calibration only becomes useful when the harness routes uncertainty somewhere

Jev belongs inside the harness

The best Jev integrations do not put the model at the center of everything

They place small decision nodes at expensive or risky transitions

Before the model: route the task

simple classification  -> Jev or code
routine drafting       -> fast LLM
ambiguous research     -> stronger LLM
high-stakes request    -> human review

The router should know the models currently available, their capabilities, and the cost or latency budget

Do not hard-code yesterday’s model menu into a permanent prompt

Before the tool: gate the action

The LLM proposes a tool call

Jev classifies its semantic risk

Code decides whether the action can proceed

decision = classify_tool_call(proposed_call)

if decision == "allow":
    execute(proposed_call)
elif decision == "review":
    queue_for_human(proposed_call)
else:
    block(proposed_call)

Jev does not receive the authority to publish, purchase, delete, or change permissions

It only supplies judgment to the policy engine

After the tool: verify the outcome

A successful HTTP response is not proof that the goal was achieved

The verifier should inspect new evidence

ACTION
create the report

EVIDENCE
file exists
required sections exist
claims have citations
output path is correct

DECISION
pass / repair / escalate

The builder and verifier should not share a vague feeling of completion

They should share an artifact and a rubric

Around retrieval: filter and rank context

Embeddings find things that are topically close

They do not always identify evidence that is decision-relevant

A useful retrieval pipeline is

cheap deterministic filter
        ↓
embedding shortlist
        ↓
Jev relevance score
        ↓
small evidence packet
        ↓
generative model

The generative model receives less noise

The trace shows why each item survived

Rebuild the menu after every action

One of the strongest patterns appears in browser agents

The available actions change after every click

The decision layer should choose from what exists now, not from a static list written before the run

controls = observe_current_page()

criteria = {
    control.id: control.semantic_description
    for control in controls
    if control.is_visible and control.is_enabled
}

question = Choice(
    instructions="Which available control best advances the current goal?",
    criteria={**criteria, "stop": "The goal is complete or no safe action exists"},
)

This pattern generalizes beyond browsers

Workers come online and go offline

Sources become stale

Budgets shrink

Files appear

Permissions change

Queues fill

A decision model choosing from a stale menu is not making a bad inference

It is operating on an invalid graph

For very large option sets, pre-filter obvious mismatches in code

Then score the survivors

Then make one explicit Choice

Use Jev for semantic ambiguity

Do not make it rediscover facts your program already knows

What Jev should not do

New tools are usually overused before they are understood

Jev has clear boundaries

Do not use it to generate the artifact

If you need an explanation, email, plan, program, or report, use an LLM

Jev returns decisions, not prose

Do not use it for exact rules

# use code
if attempts >= 3:
    stop()

if spend_usd > budget_usd:
    block()

Semantic judgment should not replace arithmetic, date comparison, exact strings, allowlists, or permission checks

Do not ask it to invent unknown values

Jev can choose from declared possibilities

It is not an extraction engine for arbitrary names, URLs, IDs, or numbers that are absent from the schema

Do not hide a multi-step plan inside one label

If a decision requires new evidence, run the tool that creates the evidence

Then ask the next question

Do not confuse type safety with truth

Jev can guarantee that the answer matches the declared type

It cannot guarantee that the chosen valid answer is correct

The system still needs evaluation

The production rollout

Do not replace every decision at once

Start with one high-volume, low-consequence branch where the correct answer can be labeled later

GOOD FIRST DECISION
route an internal support ticket

BAD FIRST DECISION
approve a payment with no human review

Step 1: define the contract

Write the state fields, options, criteria, fallback, threshold, and allowed action before integrating the model

Step 2: build a representative set

Include normal examples, ambiguous cases, missing evidence, adversarial language, and cases where no option fits

Step 3: run in shadow mode

Let the existing production path make the real decision

Log what Jev would have chosen

{
  "decision_contract": "ticket-router@3",
  "state_hash": "b476...",
  "jev_model": "jev-latest",
  "answer": "technical",
  "confidence": 0.87,
  "production_answer": "technical",
  "human_label": null,
  "action_taken": false
}

Step 4: plot accuracy against confidence

Do not ask only whether the average answer is correct

Ask whether high-confidence answers are actually more reliable than low-confidence answers in your workload

That determines where automation is safe

Step 5: automate one branch

Start with the safest outcome

Keep uncertain, rare, or consequential cases behind the existing review path

Step 6: monitor drift

Your options, users, tools, and language change

Version the decision contract separately from application code

router@1  broad options
router@2  adds none-of-the-above
router@3  separates billing from account access

A semantic decision is production logic

Treat changes like code changes

Review them

Test them

Roll them back when necessary

Failure modes that look like model problems

The state contains conclusions instead of evidence

BAD
the research is probably enough

BETTER
7 sources collected · 3 official · pricing verified · security claim unresolved

The model should judge the evidence

It should not inherit the previous agent’s confidence as a fact

The menu has no escape hatch

The answer is forced into one of several wrong options

Add other, none, stop, or review

One threshold controls every consequence

Routing an internal note and publishing a public statement should not share an automation threshold

Thresholds belong to the action class, not only the model output

The option list is stale

The selected worker is unavailable

The chosen button disappeared

The cited source changed

Rebuild the choice set from live state

The same state is retried

Nothing new was learned

The model is asked again anyway

Retries should spend new evidence, not just more tokens

The decision has no receipt

The system stores only the winning label

Keep the contract version, state reference, full distribution, threshold, route, and resulting action

The policy lives inside the classifier

The question says what should be allowed

The code blindly executes the answer

This turns probabilistic judgment into unbounded authority

The safe order is

JEV JUDGES
CODE CHECKS POLICY
TOOL EXECUTES
TRACE RECORDS

The Jev engineering playbook

Use this sequence for the first integration

01  Map the agent loop
02  Mark every hidden yes / no / route / score decision
03  Keep exact rules in code
04  Keep open-ended creation in the LLM
05  Choose one repeated semantic decision for Jev
06  Define state, rubric, options, and escape hatch
07  Ask independent questions in parallel
08  Route confidence into auto / improve / human paths
09  Run shadow mode and measure calibration
10  Automate the safest branch first

Then expand one boundary at a time

FIRST
internal routing

THEN
retrieval filtering
completion verification
model selection
low-risk tool gating

LATER
consequential actions with explicit policy and approval

The point is not to maximize the number of Jev calls

It is to remove expensive generative calls from places where generation was never needed

The economics are downstream

TypeSafe’s published price makes the decision itself extremely cheap

But cost per call is not the metric that matters

Cost per completed task is

A cheap router that sends a worker down the wrong branch can create more cost than it saves

A fast verifier that passes weak work can create more latency later

Track the whole system

decision latency
decision cost
branch accuracy
downstream tool cost
recovery cost
human review rate
completed-task rate

This is where Jev engineering becomes more important than Jev itself

The model provides a new primitive

The graph decides where that primitive sits

The loop decides what happens after uncertainty

The harness decides what the system is allowed to do

The trace tells you whether the architecture worked

The Jev launch checklist

Before a Jev decision controls a production branch, ask

[ ] Is this truly a semantic decision rather than generation or an exact rule
[ ] Is the state compact, current, and evidence-based
[ ] Are the instructions explicit instead of hidden in the question ID
[ ] Does every Choice include an escape hatch when the menu may be incomplete
[ ] Are Score levels ordered descriptions rather than fake measurements
[ ] Is a Noul probability interpreted as yes / no uncertainty
[ ] Are independent questions batched against the same state
[ ] Are dependent questions separated by a state update
[ ] Does confidence change the route
[ ] Are thresholds specific to the consequence of the action
[ ] Does code retain authority over permissions, budgets, and side effects
[ ] Is the decision contract versioned
[ ] Is the full distribution logged with the resulting action
[ ] Has the decision run in shadow mode on representative examples
[ ] Can the system escalate when no safe option exists
[ ] Does every retry add new evidence

If several answers are no, the system is not ready for more automation

It is ready for a better decision contract

The real shift

Jev is not a replacement for the LLM

It is a missing layer beside it

LLM
turns context into new work

JEV
turns state into typed judgment

CODE
turns judgment into controlled action

Most builders will continue asking one expensive model to generate, classify, route, verify, authorize, and explain

Their agents will spend frontier-model time on decisions that never needed a sentence

The better stack is smaller and more explicit

Use the LLM where open-ended intelligence creates value

Use Jev where software needs a fast semantic branch

Use code where the rule cannot be negotiable

That is Jev engineering

Not a smarter prompt

A better boundary between intelligence and execution

If you read this far

-> Join my Telegram

-> Bookmark this article before you add another LLM call to your agent loop

-> Follow @0xwhrrari

Subscribe now

Most builders still design AI agents as a straight line

Research first

Write second

Review third

Ship last

Each step waits for the one before it, even when half of them never needed the previous result

The system does not branch

It does not parallelize

It does not know how to recover

It just keeps feeding one context window until the agent gets slow, confused, or expensive

The problem is no longer the prompt

The problem is the shape of the work

That is what graph engineering fixes

I publish practical breakdowns of AI agents, workflows, and production systems on Substack

Join the newsletter here

What graph engineering actually means

Graph engineering is the practice of turning an agentic workflow into an explicit execution map

Instead of hiding every decision inside one model loop, you define the system as nodes and edges

NODE   = one bounded unit of work
EDGE   = a real dependency between two nodes
STATE  = the data that survives between nodes
ROUTER = the rule that selects the next edge
GATE   = the check that decides whether work can continue

A node can be an agent, a tool call, a deterministic function, a verifier, or a human approval step

An edge says what is allowed to run next and what data crosses the boundary

The graph decides which loops run, in what order, with which branches, joins, and recovery paths

A loop helps one agent improve its work A graph coordinates many loops into one system

1. Stop treating every “and then” as a dependency

Most agent workflows are linear because that is how people write instructions

Do A, then B, then C

But sequence is not the same as dependency

If B does not consume A’s output, there is no reason for B to wait

BAD

collect market data -> inspect repository -> check competitor pricing

BETTER

                 -> collect market data ---------
USER REQUEST     -> inspect repository ----------> SYNTHESIZE
                 -> check competitor pricing ----

The first question in graph engineering is simple

Does the next step actually read the previous step’s output

If the answer is no, cut the edge

That single change usually turns a slow chain into a fast parallel graph

2. Give every node a contract

A node you cannot describe precisely is a node you cannot route, test, or replace

Every useful node needs four things

• One job

• Explicit input

• Structured output

• A clear failure state

{
  "node": "source_researcher",
  "input": {
    "topic": "string",
    "source_type": "primary"
  },
  "output": {
    "claim": "string",
    "source_url": "string",
    "confidence": "high | medium | low"
  },
  "failure": "no_primary_source_found"
}

Free text forces the next node to guess what happened

Structured output turns a model response into something the graph can trust

This also makes nodes replaceable

You can swap the model, prompt, or tool without rebuilding the entire system as long as the contract stays the same

3. Treat edges as data contracts, not arrows

An edge should not mean “B comes after A”

It should mean “A produced data that B is allowed to consume”

That distinction matters because most workflow plumbing does not need another model call

Flattening arrays, removing duplicates, filtering nulls, checking a status, and joining records are deterministic operations

const usable = results
  .filter(Boolean)
  .flatMap(result => result.items)

const unique = [...new Map(
  usable.map(item => [item.source_url, item])
).values()]

No agent is needed here

Save model calls for judgment

Use code for plumbing

A graph where every edge is another agent is paying tokens for its own wiring

4. Learn the four shapes behind almost every agent graph

You do not need fifty patterns

Most production graphs are combinations of four shapes

The chain

A -> B -> C

Use it when every step genuinely requires the previous output

It is simple, predictable, and often slower than necessary

The diamond

        -> B1 -
A ->    -> B2 --> C
        -> B3 -

Split one job into independent branches, run them together, then merge the results

This is the workhorse for research, code review, due diligence, and market scans

The router

             -> QUICK PATH
CLASSIFY  ---
             -> FULL AUDIT

Inspect state and choose only the path the task needs

Small work stays cheap

Risky work gets a deeper graph

The controlled cycle

WORK -> VERIFY -> PASS -> EXIT
          |
          -> FAIL -> FEEDBACK -> WORK

Repeat only when evidence says the result is incomplete

Every cycle needs a hard stop, a budget, and a convergence rule

5. Fan out independent work, then join it deliberately

Parallelism is the easiest graph advantage to understand and the easiest one to abuse

If five nodes are independent, run them together

const settled = await Promise.allSettled(
  sources.map(source => researchNode(source))
)

const findings = settled
  .filter(result => result.status === "fulfilled")
  .map(result => result.value)

One failed branch should not destroy the other four

But do not place a barrier after every stage

A join is worth the wait only when the next node needs the complete set

Examples include cross-source deduplication, ranking all candidates, comparing alternatives, or deciding whether coverage is complete

If each item can continue independently, keep the graph streaming

Parallel is not automatically fastYour topology decides where the system waits

6. Make routing inspectable

The model can make a judgment

The graph should enforce what that judgment is allowed to trigger

const decision = await classifyRisk(change)

switch (decision.severity) {
  case "low":
    return quickReview(change)

  case "high":
    return fullParallelAudit(change)

  default:
    return humanReview(change)
}

The classifier is probabilistic

The allowed routes are deterministic

This gives you the model’s flexibility without giving it unlimited control over the system

OpenAI’s visual Agent Builder makes this shift obvious: agent behavior is increasingly designed as an inspectable workflow instead of a hidden chain of prompts

OpenAI Developers

Introducing AgentKit—build, deploy, and optimize agentic workflows.

ChatKit: Embeddable, customizable chat UI

Agent Builder: WYSIWYG workflow creator

Guardrails: Safety screening for inputs/outputs

Evals: Datasets, trace grading, auto-prompt optimization

7. Put verification on the edge

The highest-leverage node in a graph is often the one that produces nothing new

Its job is to stop weak work from moving downstream

A verifier can check

• Whether every claim has a source

• Whether the cited source supports the claim

• Whether code passes tests

• Whether the result matches the requested schema

• Whether another independent path reaches the same conclusion

GENERATOR -> VERIFIER -> PASS -> SYNTHESIZER
                 |
                 -> FAIL -> REPAIR

Do not ask the same agent to generate, approve, and publish its own work in one context

Separate the roles

Separate the prompts

Separate the failure boundaries

Anthropic’s production research system follows this logic at a larger scale: a lead agent coordinates parallel subagents, findings are synthesized, and a dedicated citation stage attaches evidence before the result reaches the user

Claude

Introducing Claude Managed Agents: everything you need to build and deploy agents at scale. It pairs an agent harness tuned for performance with production infrastructure, so you can go from prototype to launch in days. Now in public beta on the Claude Platform.

8. State is the part most diagrams hide

Boxes and arrows look clean until the system has to resume after a crash

A production graph needs durable state

task_id
current_node
completed_nodes
artifacts
decisions
evidence
budgets
retry_counts
human_approvals

Do not move giant transcripts between nodes

Move references to artifacts

A research node should store its report and return a path, ID, or structured summary

A reviewer should read the artifact directly instead of receiving a compressed retelling through three agents

This reduces context loss and makes every transition auditable

The graph should be able to answer three questions at any moment

What has already happened
Why did the system choose this route
Where can execution safely resume

If it cannot answer them, the graph is still a demo

9. Add cycles only when they converge

A cycle is useful when the amount of work is unknown in advance

Bug discovery, deep research, and iterative repair are good examples

But “repeat until good” is not a stop condition

Use measurable convergence

let dryRounds = 0
let iteration = 0
const seen = new Set()

while (dryRounds < 2 && iteration < 6) {
  const findings = await discover()
  const fresh = findings.filter(item => !seen.has(item.key))

  fresh.forEach(item => seen.add(item.key))
  dryRounds = fresh.length === 0 ? dryRounds + 1 : 0
  iteration += 1
}

Notice what the system remembers

It deduplicates against everything already seen, not only the findings that passed verification

Otherwise rejected ideas keep returning and the graph pays to rediscover the same dead ends forever

Every controlled cycle needs

• A completion test

• A maximum number of rounds

• A token or cost budget

• A record of previous attempts

• An escalation path when convergence fails

10. Design failure as a local event

In a chain, one broken step can freeze the whole workflow

In a graph, failure should stay inside the smallest possible boundary

Each node needs a policy

RETRY      transient tool or network failure
FALLBACK   preferred model or source unavailable
SKIP       optional branch failed
REPAIR     output failed validation
ESCALATE   risk or uncertainty crossed a threshold
STOP       budget, safety, or permission boundary reached

Checkpoint after expensive nodes

Make writes idempotent so a retry does not duplicate side effects

Give parallel workers isolated workspaces when they modify files

Record every routing decision with the state that produced it

Reliability does not come from hoping every node succeeds

It comes from deciding what the graph does when one does not

11. Topology is your cost model

A graph is not automatically cheaper than one agent

It can burn far more tokens if every task spawns a fleet

The shape controls both latency and cost

Use cheaper models for bounded extraction, classification, and formatting

Use stronger models for decomposition, synthesis, and difficult verification

Route simple tasks through a short path

Reserve the full graph for work that earns it

SIMPLE REQUEST -> SMALL MODEL -> QUICK CHECK -> DONE

COMPLEX REQUEST -> PLANNER -> PARALLEL SPECIALISTS
                              -> VERIFIERS
                              -> STRONG SYNTHESIZER
                              -> HUMAN GATE

Anthropic reports that multi-agent research can materially outperform a single agent on breadth-first work, but it also uses far more tokens

That is the tradeoff

Graph engineering is not about maximizing the number of agents

It is about spending coordination only where parallelism, specialization, or independent verification creates enough value

12. A production graph for research and publishing

Here is a practical graph for turning one idea into a cited article

                                  -> COMPANY SOURCES -----
TOPIC -> SCOPE -> DECOMPOSE       -> PAPERS --------------> DEDUPE
                                  -> EXPERT POSTS ---------
                                                             |
                                                             v
                PUBLISH <- HUMAN GATE <- FINAL CHECK <- DRAFT
                                                |          ^
                                                -> FAIL -> REPAIR

The system works like this

1. The scope node defines the question, audience, and completion criteria

2. The decomposition node creates independent research lanes

3. Research nodes run in parallel with separate contexts

4. Deterministic code removes duplicates and normalizes sources

5. The draft node writes from structured evidence

6. The checker validates claims, citations, style, and missing sections

7. Failed checks route only the relevant section back to repair

8. A human approves the final artifact before publishing

This is not one giant agent pretending to be a team

It is a system with explicit ownership, state, and authority

When a graph is the wrong answer

Do not turn every prompt into an architecture diagram

Keep one agent in one loop when

• The task is short

• One context can hold all relevant information

• There are no independent branches

• Failure is cheap

• A human can review the final result quickly

Move to a graph when

• Work can run in parallel

• Different nodes need different tools or permissions

• Outputs require independent verification

• The task must resume after interruption

• Several loops need shared state

• Cost and authority must be controlled by route

Start with one loop

Draw a graph only when the dependencies force you to

The graph engineering checklist

Before you ship, ask

[ ] Does every edge carry real data or authority
[ ] Does every node have one bounded job
[ ] Are inputs and outputs structured
[ ] Can independent nodes run in parallel
[ ] Are joins placed only where the full set is required
[ ] Are important results verified before moving downstream
[ ] Can failures be retried without duplicating side effects
[ ] Can the graph resume from a checkpoint
[ ] Does every cycle have a hard stop and budget
[ ] Can a human interrupt high-risk paths
[ ] Can you explain why every route was selected
[ ] Is the graph simpler than the problem it solves

If the answer to the last question is no, delete nodes

The real shift

Prompt engineering improves the instruction

Context engineering controls what the model sees

Harness engineering builds the environment around the model

Loop engineering makes one unit of work improve through feedback

Graph engineering coordinates the entire job

PROMPT -> CONTEXT -> HARNESS -> LOOP -> GRAPH
message    memory     machine    run     coordination

The model is only one node

The product is the system around it

A prompter asks the agent to do more An architect redesigns the graph so the system can do more safely

For shorter notes, new tools, and AI systems I am testing

Join my Telegram

For deeper breakdowns delivered directly

Subscribe to my Substack

If you read this far

Bookmark the article so you can use the patterns later

Follow

@0xwhrrari

for more practical AI systems

And send this to a builder who is still forcing every agent through one long chain

Most agent systems do not fail because the model is too weak

They fail because the system around the model was never designed as a system

The tools are unreliable

The state disappears between runs

The agent retries without learning anything

The workflow branches in ways nobody can inspect

Then every failure gets blamed on the model

That is the wrong diagnosis

There are three different engineering layers behind a serious agent:

• the harness gives the model a place to work

• the loop gives the work a feedback cycle

• the graph gives the process an explicit route

They overlap

They can contain one another

But they solve different problems

A model decides

A harness lets it act

A loop makes it prove the result

A graph controls what is allowed to happen next

The 30-second version

Harness engineering builds the operating environment around the model

Tools, memory, files, permissions, sandboxes, routing, checkpoints, traces and human approvals all live here

Loop engineering designs repeated work and feedback

The agent produces something, checks it against evidence, receives a useful failure signal and tries again under a bounded rule

Graph engineering makes control flow explicit

It defines the nodes, branches, joins, parallel work, legal cycles, state transitions and exit paths

The easiest way to remember the difference is:

HARNESS = ENVIRONMENT
LOOP    = FEEDBACK
GRAPH   = FLOW

This distinction matters as soon as an agent leaves a demo and starts touching real files, APIs, customers, money or production code

Why people keep mixing them together

All three layers sit around the same model

All three affect reliability

All three may include something that looks like a loop

And in a small prototype, all three are usually buried inside one script

That makes them feel interchangeable

They are not

Consider a basic tool-using agent

ask model
receive tool call
run tool
return observation
ask model again
stop when finished

That small cycle is part of the runtime

But the tool definitions, filesystem and state store belong to the harness

The test-and-retry policy is a loop design decision

The choice between researcher, reviewer and publisher is a graph design decision

One piece of software can contain all three layers at once

The cleanest architecture starts by naming them separately

Layer 1: Harness Engineering

A raw model can transform input into output

It cannot independently maintain project state, run a test suite, inspect a browser, write files safely, enforce permissions or resume tomorrow where it stopped today

The harness supplies those capabilities

The simplest definition is:

The model is the intelligence

The harness is the machinery that makes that intelligence useful<br>

Remove the model from your architecture diagram

Everything still visible is probably part of the harness

This is the production shift Boris Cherny keeps pointing at through Claude Code: hooks, scheduled runs, isolated worktrees, custom agents and parallel execution are not prompt tricks

They are harness primitives

What belongs inside a serious harness

Context

• system instructions

• retrieved knowledge

• conversation state

• task policies

• skills and operating procedures

Action surfaces

• APIs

• browser control

• shell and code execution

• databases

• MCP tools

• specialist agents

Persistence

• files

• checkpoints

• session state

• progress logs

• git history

• long-term memory

Execution control

• timeouts

• retry limits

• token and cost budgets

• model routing

• handoffs

• approval gates

Safety

• isolated environments

• least-privilege permissions

• allow lists

• secret handling

• human authorization

Observability

• traces

• tool inputs and outputs

• state transitions

• cost and latency

• evaluation results

Where harness engineering earns its keep

Harness work becomes critical when tasks last longer than one context window

A coding agent that works for hours cannot rely on chat history alone

It needs durable artifacts that another session can understand

A useful setup might include:

• an initializer that inspects the workspace

• a progress file that explains what is done and what remains

• git commits that preserve working states

• checkpoints before risky actions

• verification tools that produce clear evidence

This is not a better prompt

It is a better working environment

Start with harness engineering when the agent:

• cannot access the right capability

• loses progress between sessions

• has permissions that are too broad

• behaves differently across environments

• cannot be paused, inspected or resumed

• produces failures nobody can reconstruct

Layer 2: Loop Engineering

Every tool-using agent already has a small internal loop

model -> action -> observation -> model

Loop engineering begins when you intentionally design the cycles around that behavior

The goal is not to make the agent repeat itself forever

The goal is to turn a one-shot attempt into a managed process

The verification loop

The most useful outer loop is simple

BUILD
  ↓
CHECK AGAINST EVIDENCE
  ↓
PASS? ── yes ──> STOP
  │
  no
  ↓
RETURN SPECIFIC FEEDBACK
  ↓
RETRY WITH A LIMIT

The check may be deterministic:

• tests pass

• schema validates

• links resolve

• numbers reconcile

• files compile

Or it may require a reviewer:

• the argument is complete

• the tone matches the audience

• the evidence supports the conclusion

• the change is scoped correctly

The rule is the same

Do not loop on confidence

Loop on evidence

“The agent says it is finished” is not proof

“The tests pass, the sources resolve and the reviewer approved the diff” is proof

The leverage comes from building the cycle once and letting the system run it for you

Claude’s scheduled tasks are the visible product version of the same shift: define recurring work once and let the system re-enter it without another manual prompt

Scheduling is only the trigger

The checks, feedback and exit condition are what turn the recurring task into an engineered loop

The anatomy of a useful loop

Every production loop needs seven things

1. Trigger

What starts another cycle: a request, schedule, webhook, failed test, new document or evaluator result

2. Goal

A measurable state to reach, not “keep improving”

3. State

What the next attempt must know without replaying the entire history

4. Action policy

What the agent may change, call, delegate or spend

5. Evidence

Tests, citations, diffs, metrics, schemas or human review

6. Feedback

A compact explanation of what failed and what must change

7. Stopping rule

Success, maximum attempts, budget exhaustion, timeout, hard error or human escalation

Loops can stack

The agent loop performs the work

The verification loop checks the work

An event loop wakes the system when new work arrives

An improvement loop studies production traces and changes the harness itself

EVENT LOOP
└── VERIFICATION LOOP
    └── AGENT LOOP

TRACE IMPROVEMENT LOOP
└── updates prompts, tools, policies and graders

This is why loop engineering is larger than prompt engineering

A prompt defines what should happen during one model call

A loop defines what the system does after that call

The cost is obvious

Every retry, grader and reviewer adds latency and spend

Add a loop when the expected cost of failure is higher than the cost of verification

Layer 3: Graph Engineering

Graph engineering asks a different question

Not “how should the agent work”

But “what is allowed to run next”

Work becomes nodes

Allowed transitions become edges

State moves through the graph

That structure can represent:

• fixed sequences

• conditional branches

• parallel fan-out

• joins

• bounded cycles

• recovery paths

• human interrupts

What graph engineers actually decide

Node boundaries

Which work belongs in normal code, an LLM call, a specialist agent or a human review step

State schema

What each node may read or update and how parallel results are merged

Routing conditions

Which evidence moves work forward, backward, sideways or into escalation

Concurrency

What can run in parallel and what must wait for a join

Cycles and exits

Where retries are legal, how many attempts are allowed and what makes the cycle safe

Durability

Where execution is checkpointed and how it resumes after interruption

When a graph is worth the ceremony

Use a graph when the process contains meaningful branches, parallel specialists, approvals, recovery routes or stateful handoffs

Do not start with a graph only because the workflow has multiple steps

If one capable agent with three tools can solve the task, a graph may add structure without adding value

There is another failure mode

Teams formalize the workflow before they understand the work

The result is a beautiful diagram that encodes the wrong assumptions

Start with a simple harness

Study real traces

Formalize the paths that remain stable

The next step after loops is making the execution topology explicit

OpenAI packaged the same idea into Agent Builder: a visible workflow canvas for multi-agent execution with guardrails and evals around the graph

How all three layers work in one real system

Imagine a research-and-publishing agent that produces a factual industry briefing

The harness provides:

• browser and search tools

• source storage

• a writing workspace

• citation checking

• permissions and approval rules

• checkpoints and traces

The graph controls the route:

RESEARCH
   ↓
DRAFT
   ↓
FACT CHECK ── fail ──> RESEARCH
   │
  pass
   ↓
EDITORIAL REVIEW ── fail ──> DRAFT
   │
  pass
   ↓
HUMAN APPROVAL
   ↓
PUBLISH

The loops live inside that route

The research node may search until source coverage is sufficient

The drafting node may revise until the style grader passes

The fact-check node may return exact unsupported claims instead of a vague rejection

The nesting is the important part

The graph runs inside the harness

The loops run inside parts of the graph

The harness supplies the tools, state and evidence those loops need

The layers overlap because real software layers overlap

They still give you three different levers when the system fails

Diagnose the failure before changing the architecture

The agent cannot access the right data safely

Start with: Harness

Better tool contract, permissions, sandbox and context injection

The agent forgets progress between sessions

Start with: Harness

Durable state, checkpoints, progress artifacts and compaction

The first attempt is close but unreliable

Start with: Loop

External grader, deterministic tests, actionable feedback and bounded retry

The agent continues after success or stops before proof

Start with: Loop

Evidence-based terminal states and budget-aware stop rules

Specialists must run in a controlled order

Start with: Graph

Explicit nodes, edges, routing conditions and joins

A multi-step failure is impossible to locate

Start with: Graph + harness

Stateful traces aligned with nodes and transitions

The process changes too quickly for a fixed diagram

Start with: Simpler harness

Keep planning model-driven and delay graph formalization

This table is more useful than arguing about terminology

Find the layer that owns the failure

Fix that layer first

The expensive mistakes behind weak agent systems

Building the graph too early

Do not convert an imagined business process into forty nodes before watching a strong agent perform the work

Trace first

Formalize second

Letting the maker grade itself

Self-review is useful but shares the same blind spots as the original attempt

Prefer deterministic checks where possible

Use an isolated reviewer context for subjective checks

Require human approval for high-impact actions

Defining the loop as “keep trying”

An unbounded retry is not reliability

It is a cost leak

Every cycle needs fresh evidence, a maximum attempt count and a named escalation path

Turning the harness into a warehouse

More tools do not automatically create a better agent

A crowded toolset increases selection errors

Noisy context increases confusion

Broad permissions increase risk

Give the agent the smallest environment that can complete the job

Blaming the model for orchestration failures

A stronger model cannot reliably repair stale state, broken APIs, ambiguous tool schemas or missing exit conditions

Do not upgrade the model before proving the model is the problem

A production-ready checklist

Harness

• are the tools narrow, documented and observable

• is state durable across sessions

• are permissions least-privilege

• can an operator pause, inspect and resume the run

• can every important action be reconstructed from traces

Loop

• what evidence proves success

• what feedback is returned after failure

• how many retries are allowed

• what happens when the budget is exhausted

• where human judgment is required

Graph

• which paths must be deterministic

• where can work run in parallel

• what state is shared

• where are the joins, approvals and recovery routes

• which cycles are legal and how do they terminate

Evaluation

• can the team replay real traces

• can versions be compared against the same tasks

• can an improvement be attributed to a specific change

Operations

• are cost and latency monitored

• is failure rate visible by node and tool

• is human intervention measured

• is task-level success measured in production

The simplest way to remember the difference

Harness engineering makes the model operational

Loop engineering makes the work iterative and verifiable

Graph engineering makes complex execution explicit and controllable

None replaces the others

A perfect graph cannot save an agent that loses its state

A perfect harness still wastes money if the loop has no evidence or stop rule

A strong loop becomes difficult to operate when branches, parallelism and approvals are hidden inside ad hoc code

Reliable agents appear when all three layers are designed together

And when every layer has one clear job

ENVIRONMENT -> HARNESS
FEEDBACK    -> LOOP
FLOW        -> GRAPH

That is the whole framework

Sources and further reading

• Claude scheduled tasks

• OpenAI AgentKit

• OpenAI Agents SDK

• AutoGen GraphFlow

• Building Effective AI Agents

If you read this far

Bookmark the article and follow for more practical agent engineering

Also follow X and Telegram

Subscribe now

Most people are still prompting agents manually.

They type one task.

Wait for one answer.

Review it themselves.

Fix the mistakes themselves.

Then prompt again.

That means the human is still the loop.

The next step is different.

You do not just prompt the agent.

You design the loop that prompts the agent, checks the result, decides the next move, and keeps running until the work passes.

That is loop engineering.

“You should not be prompting coding agents anymore. You should be designing loops that prompt your agents.”

Then Boris Cherny, head of Claude Code at Anthropic, said the same thing differently:

“I do not prompt Claude anymore. I have loops running that prompt Claude and figure out what to do. My job is to write loops.”

Why Most People Never Build Real Loops

Loops sound amazing until you look at the token bill.

A normal agent loop can burn a lot of context fast:

• One medium coding loop can use 50K-200K tokens

• A fleet loop with one orchestrator and several specialist agents can use 500K-2M tokens

• A scheduled daily loop can reach millions of tokens per week

Every retry costs tokens.

Every self-correction costs tokens.

Every verification step costs tokens.

Every subagent costs tokens.

That is the hidden problem nobody talks about enough.

Loop engineering is not hard because the idea is complicated.

It is hard because most people cannot afford to let agents run freely for long.

“Easy for you to say, you have unlimited OpenAI access.”

That reaction is fair.

This is why cheaper long-context models matter.

If you want loops to run every day, you need:

• Cheap input tokens

• Cheap output tokens

• Large context windows

• Tool calling

• JSON output

• High concurrency

• Enough context to remember what happened earlier in the loop

Without that, loops become expensive experiments.

With that, loops become practical workflows.

The Old Way vs The New Way

For the last two years, most people used agents like this:

You prompt.

The agent answers.

You review.

You find the mistake.

You prompt again.

That works, but it does not scale.

The old way:

• You give a prompt

• The agent gives an output

• You review the output

• You fix the weak parts

• You repeat manually

The new way:

• You define the goal

• The loop discovers what is needed

• The loop plans the work

• The agent executes

• A checker verifies the result

• The loop fixes failures

• The system stops when the goal is reached

Prompting gives an agent an instruction.

Loop engineering gives an agent a job.

What Loop Engineering Actually Is

Loop engineering is the practice of designing repeatable feedback cycles for AI agents.

The goal is simple:

Get from attempt to verified result without needing a human to manually drive every step.

The basic cycle has five stages:

1. Discover

2. Plan

3. Execute

4. Verify

5. Iterate

If the output passes, ship it.

If it fails, send it back into the loop.

That is the whole idea.

Not one perfect prompt.

A system that keeps improving the output until it meets the standard.

Single Agent vs Fleet

There are two basic sizes of loops.

Single-Agent Loop

One agent runs the whole cycle.

It discovers what is needed, plans the work, executes the task, checks the result, and improves it if something fails.

This is like one person rewriting their own draft.

Good for:

• Focused tasks

• Small scopes

• Simple goals

• Content drafts

• Bug fixes

• Research summaries

One brain.

One loop.

Self-improvement.

Fleet Loop

A fleet loop is bigger.

You give one orchestrator agent the main goal.

It breaks the work into pieces.

Then it sends those pieces to specialist agents.

Each specialist can also use smaller subagents for narrow tasks.

Example:

Example: "Build a productivity app"

Orchestrator owns the mission
    ↓              ↓              ↓
Research      Engineering        QA
Specialist    Specialist         Specialist
    ↓              ↓              ↓
Web           Code Writer        Test Writer
Researcher    + Debugger         + Bug Tracker

This is not one agent working alone.

It is closer to a small team running a project end to end.

Open Loops vs Closed Loops

This is the most important practical distinction.

Not all loops are equal.

Open Loops

Open loops are exploratory.

You give the agent a broad goal and let it search for the path.

This is powerful because the agent can discover things you did not specify.

But it is also expensive and messy.

Open loops can:

• Try too many paths

• Burn too many tokens

• Create low-quality output fast

• Drift away from the real goal

• Become hard to control

Open loops are exciting.

But for most people, they are not the best place to start.

Closed Loops

Closed loops are bounded.

The human designs the path first.

The loop still runs on its own, but inside clear rules.

A closed loop has:

• Clear goal

• Defined steps

• Evaluation after each step

• Stop condition

• Hand-off point if it gets stuck

This is the version that actually pays off today.

It is cheaper.

It is more reliable.

It produces cleaner output.

Start with closed loops.

Open them up later when your checks are strong.

The 6 Building Blocks Of A Good Loop

Conceptually, every loop has five stages.

But practically, you need six building blocks to make the loop work.

1. Automations

This is the heartbeat.

The automation starts the loop without you manually remembering to run it.

Examples:

• Run every morning

• Run when a PR opens

• Run when a file changes

• Run when a new ticket appears

• Run until all tests pass

If you still need to start everything manually, the loop is not really doing enough work.

2. Worktrees

Worktrees matter when multiple agents are editing code.

Without separation, agents collide.

Two agents can edit the same file.

One can overwrite the other.

A worktree gives each agent its own clean workspace and branch.

That lets multiple agents work in parallel without turning the repo into a mess.

3. Skills

Skills are reusable project knowledge.

Instead of explaining your project every time, you write the important context once.

Good skill files include:

• Vision

• Architecture

• Rules

• Build steps

• Testing steps

• Things the agent must never do

Without skills, every loop starts cold.

With skills, every loop starts with accumulated context.

4. Plugins And Connectors

A loop that only sees files is limited.

Connectors let the loop touch your real tools.

Examples:

• GitHub

• Slack

• Linear

• Jira

• Gmail

• Google Drive

• Database

• Staging API

This is the difference between “here is a suggested fix” and “I opened the PR, linked the ticket, watched CI, and posted the update.”

5. Subagents

The maker and checker should not always be the same model.

The agent that wrote the code will often be too generous when reviewing it.

The agent that wrote the article will miss its own weak sections.

Use separate agents for:

• Exploration

• Implementation

• Review

• Testing

• Fact-checking

• Final summary

Quality improves when the reviewer is not the same agent that made the work.

6. Memory

Memory is what lets a loop continue across runs.

The model forgets.

The repo does not.

The notes do not.

The project log does not.

Memory can live in:

• Markdown files

• Project logs

• Linear tickets

• GitHub issues

• Obsidian vaults

• Databases

• Claude Projects

A long-running loop needs to know what was tried, what passed, what failed, and what still needs to happen.

Without memory, it starts from zero every time.

Real Loop Examples

Here are the loops that make the idea concrete.

Coding Loop

The loop:

Read VISION.md + ARCHITECTURE.md
↓
Plan next change
↓
Edit code
↓
Run tests
↓
If tests fail → read error → fix → test again
↓
If tests pass → summarize changes
↓
Stop

No human needs to push every step.

The agent writes, tests, fixes, and verifies.

Research Loop

The loop:

Define research question
↓
Search for sources
↓
Summarize findings
↓
Verify claims against sources
↓
Compare conflicting information
↓
Synthesize final answer
↓
Stop when confidence threshold met

This is much better than asking for one quick summary.

Content Loop

The loop:

Topic + audience + goal defined
↓
Draft created
↓
Critique agent reviews draft
↓
Rewrite based on critique
↓
Score against success criteria
↓
If score passes → publish
↓
If score fails → rewrite again

The loop turns one idea into a content system.

Sales Outreach Loop

The loop:

ICP (Ideal Customer Profile) defined
↓
Find leads matching profile
↓
Enrich with company data
↓
Qualify against criteria
↓
Personalize message
↓
Quality review
↓
Send or escalate to human

Same skeleton:

Goal.

Action.

Check.

Fix.

Repeat until done.

Prompt Engineer vs Loop Engineer

This is the skill gap opening in 2026

Prompt Engineer

A prompt engineer focuses on better instructions.

They improve the wording.

They get a better single output.

But the human still reviews everything after the run.

The human is still the feedback loop.

Loop Engineer

A loop engineer designs the feedback system.

They decide:

• What starts the loop

• What context the agent needs

• What tools it can use

• What counts as success

• Who checks the work

• When the loop should stop

• Where the result should be saved

A prompt engineer says:

“Write me a function.”

A loop engineer says:

“Write it, test it, fix it until it passes, then summarize the change.”

Same tools.

Different mindset.

The highest-leverage AI builders are not just writing better English prompts.

They are designing systems that discover, plan, execute, verify, and stop correctly.

The Short Version

Loop engineering is the shift from manual prompting to automated feedback cycles.

The shift:

• Old way: Prompt agents one task at a time

• New way: Design loops that run the full cycle

The 6 things you actually build:

• Automations: The heartbeat that starts the loop

• Worktrees: Parallel agents without file conflicts

• Skills: Project knowledge reused every run

• Plugins and connectors: Access to real tools

• Subagents: Makers and checkers separated

• Memory: The loop remembers across runs

The 2 sizes:

• Single-agent loop: One agent improves its own work

• Fleet loop: Orchestrator plus specialists plus subagents

The 2 types:

• Open loop: Powerful, exploratory, expensive

• Closed loop: Bounded, reliable, affordable

The 5 stages:

1. Discover

2. Plan

3. Execute

4. Verify

5. Iterate

The real cost problem:

• Loops burn tokens fast

• Cheap long-context models make loops practical

• Without affordable tokens, most people never get past experiments

The mindset shift:

• Prompt engineers ask AI for outputs

• Loop engineers design systems that produce verified outcomes

That is the real unlock.

Stop trying to write one perfect prompt.

Start building the loop that makes imperfect outputs better.

A reliable loop beats a perfect prompt.

If you read this far:

• BOOKMARK THIS.

• Follow X @0xwhrrari

• Follow Substack

• Follow my Private Telegram Channel

  ---