FAQ

How do I apply this framework?

Choose one useful task whose result you can inspect. Bring together the people who understand its requirements, agree what an acceptable result would look like, and identify the context the agent needs. Start with close checkpoints, run the task, and inspect what worked and what needed correction. Use those findings to choose one improvement and try it on the next comparable task. The readiness skill can help identify missing conditions.

You can also give the book to your agent. Every page here has a plain-markdown twin (/loops.md, /grading.md, and so on for each page), the whole book is concatenated at /llms-full.txt, and there is a map at /llms.txt. Because agents love markdown, because everyone loves markdown, right? Hand the material to your agent and let it reason about your situation in these terms.

The book gives you and your agent a shared set of concepts. Read it to form your own judgment, then ask the agent to apply it to a specific task or team. Check its recommendations against what you know about the work.

What that looks like in practice, roughly in the order the book moves:

• Organizational readiness. Give the agent Loops, a few recent tasks or agent sessions, and relevant project documentation. Explain how your team decides what to delegate and who accepts the result. Ask it which current loop sizes fit the work and which reflect missing context, checks, or agreements.

• Loop sizing. Give it a specific task off your board and the seven sizing criteria, and ask it to explain its proposed size and review points.

• HarnessHarnessThe software around a model that lets it act, inspect results, and continue working: its execution loop, tools, context management, and controls. Harness engineering also covers checks and review arrangements across technical systems.An agent that can read files, run checks, and correct its work uses a harness. inventory. Inspect the available context, tools, permissions, quick checks, and review gates separately. Identify where backpressureBackpressureQuick, inexpensive feedback from checks built into the agent’s workflow. As the agent works, these checks report problems it can correct immediately.When the agent tries to save a code change as a commit, an automatic check rejects a variable name that breaks the project’s naming rules. The agent corrects the name. Its next commit attempt triggers the check again. helps the agent correct itself and which questions need review. Harness explains their interaction.

• Factory improvements. Use evaluations across comparable tasks to choose an improvement, assign responsibility, and assess its effect. Factory describes how to fund and maintain that work.

• Grading material. Point it at Grading and a slice of your domain, and have it draft evaluation material (rubricsRubricA guide that names the qualities to assess and describes what meeting each criterion looks like.For a dashboard, it might require the reason for each case’s priority to be visible and supported by the case details., scenarios, and especially counterexamplesCounterexampleA plausible but unsuitable result retained with the reason it fails the relevant criteria. It helps assess later results and the reviewer itself.A polished dashboard that hides a case the agreed rule marks as urgent shows what the reviewer should reject.) a loose loop needs before it can run.

An agent’s diagnosis depends on the evidence you give it. It may miss disagreements about delegation or recommend more independent work than your checks support. Ask what supports its conclusions and discuss them with the people responsible.

Do I need to be an engineer to apply it?

You can apply it from product, design, or domain work as well as engineering. You help decide whether something is worth building, compare variants, and assess whether the result meets its purpose. Some requirements can become automated checks; other questions need review or evidence from use. Roles describes these contributions.

Isn’t this just spec-driven development?

A specification records intent, constraints, and known requirements. The framework also asks how much work to delegate, which feedback the agent can use, and who evaluates the result. Keep the specification current as tests, reviews, and product use reveal what needs to change. Grading explains how requirements and evaluation develop together.

What changes about the team’s working rhythm?

Loop size describes the work delegated between human decisions. Product feedback has its own timing: a team can let an agent implement independently and try the result with users as soon as it is ready. Close supervision of implementation alone says little about whether the team is learning what users need.

Choose checkpoints for the task’s uncertainty and consequences. Keep product feedback frequent enough to change the direction before too much work depends on an untested assumption. The team still needs to coordinate responsibilities, dependencies, and priorities. Factory treats those as part of the operating model.

Faster implementation gives teams more opportunities to try ideas and revise them. It gives you a reason to examine the purpose of each meeting and review, then adapt the working rhythm based on evidence.

We are debating which model to standardize on. Where does that fit?

Evaluate the model together with the setup it will use. A capable model still needs the right context, working tools, and checks suited to the task. Compare candidate combinations on representative work and include the effort needed to review and repair their results. The fixed-model comparisons in Harness show why the surrounding setup deserves its own evaluation.

Should our harnesses be standardized, or custom to each use case?

Shared runtimes, permission controls, and execution tools can serve many teams. Product context and acceptance criteria need to fit the work. Evaluate the combination on representative tasks before relying on it.

A shared platform can provide reusable checks, review tooling, and ways to retrieve context. Teams contribute their domain rules and examples, decide who may accept results, and report failures that the shared setup needs to address. Factory explains how technical building blocks and team responsibility fit together.

Why is the book so short?

I want the book to remain useful as tools change. It concentrates on choosing how much work to delegate, supplying context, and evaluating results. Tool-specific instructions need more frequent updates.

Keeping it short also makes it easier to read and give to an agent. The framework supplies questions and distinctions; you supply the circumstances of your team.

Why is this book a website?

A website lets me update the book and give readers a link to the current version. Every page has a plain-markdown twin, and the whole book is available at /llms-full.txt, so your agent can read it too.

Give your agent the URL and ask it to apply the framework to your situation. That also makes it easier to revisit the book after an update.