Roles

The engineer: designer of the loop

Engineers design and maintain the technical conditions in which agents work. That includes making the application runnable, supplying relevant context, and building quick checks that provide 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.. They also arrange independent reviews and enforce permissions. Harness explains how these mechanisms work together.

For the dashboard, an engineer might encode dependency rules as architecture tests, investigate a reviewer’s security finding, or make a realistic preview available for product feedback. 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. engineering includes improving that setup as the team learns from its use. Where several people work in a shared factory, those changes go to the factory owner for approval.

The product owner

Acceptance criteria tell the agent what the result needs to satisfy. Product people contribute examples and explain which rules are settled and which questions still need exploration. A quick, inexpensive check against those criteria can provide backpressure. A more involved assessment belongs at a review gate, performed by a person, an agent, or both.

In practice that splits into seven jobs:

1. Explain the problem, who it affects, and the intended result. Separate firm requirements from assumptions the team can explore.
2. Keep product rules, examples, and decision history available where the agent can find them.
3. Make options and trade-offs visible before committing.
4. Test variants with representative behavior and data, so the team can assess whether they would work in the product.
5. Limit proposed work to what the team can assess and prioritize.
6. Design the evaluation with designers, engineers, testers, and domain experts.
7. Use findings from product use, repairs, and support to guide the next task.

Product people help define the search spaceSearch spaceThe set of candidate solutions an agent can explore for a task.Several implementations can satisfy the same requirement. Constraints help narrow the choice. through intent, context, and constraints. They also supply evaluation material, including acceptance scenarios, 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., and 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.. The team needs these contributions throughout implementation and evaluation.

Write the evaluation material while you shape the request, before implementation starts. The agent can help here. It can ask what a good and a bad result would look like and propose examples from earlier tasks, which you then accept or correct. Thinking about the assessment this early often exposes a requirement nobody had written down.

Store that material where the agent implementing the change can’t read it. A separate reviewer applies it once the work is done, so the implementation can’t be tuned to the examples it will be judged by. Grading explains how to keep such holdoutHoldoutCases set aside while developing a solution or adjusting an evaluator, then used to assess it on unfamiliar cases.Keep some support cases separate while refining the dashboard, then check how it handles them. cases separate and how to check the reviewer.

The designer

Designers provide the examples and constraints that make work fit the product and its audience. Approved components and brand assets give agents usable context. Fast checks can verify properties such as allowed colors, while a design review assesses the choices those checks leave open. Review findings can lead to better examples or new checks; their effect needs evaluation on subsequent work.

For the dashboard, designers can help the team explore how people understand a priority order and choose what to handle next. The comparison in Grading keeps that product question open while tests verify each proposed rule.

The domain expert

Domain experts explain the rules, exceptions, and past decisions that an agent may be unable to find in the code or documentation. They can supply golden examplesGoldenAn accepted result retained as a reference for assessing later results.An approved support reply shows the tone and level of detail expected in later replies. of accepted results and counterexamples that explain why a plausible answer fails. For the dashboard, this might include cases where the apparent urgency hides a contractual or operational consequence. Give experts time to make that knowledge usable.

Domain experts and product people often decide whether a result may proceed. They shouldn’t need to read code to make that decision. Ask the factory for evidence they can assess: a demonstration of the important cases, including invalid input, a recording of the behavior, or an explanation that connects each change to the requirement it serves. A text change needs less of this than a change to how the dashboard ranks contractual obligations; let the depth of evidence follow the risk.

The people who run the process

The people responsible for the team’s working process help connect findings across tasks with decisions about improvement. They make room to investigate recurring problems, assign responsibility, and follow up on the effect of changes. The Factory chapter develops this part of the operating model. Harness engineering supplies technical improvements within it.

The factory owner

A shared factory needs someone responsible for the setup the whole team works in. That includes the environment where agent runs continue after someone closes their laptop, and the context, checks, and review requirements kept under version control. The owner approves changes after the team has tested them on representative tasks, and restores the previous version when a change fails.

The factory also needs its own backlog. Evaluations across tasks turn up recurring problems: a missing tool, stale guidance, a check that keeps passing work people then have to repair. The owner keeps those items next to the product backlog, finds out what the team needs, decides which improvements to try, and checks whether later work benefits. That treats the factory as an internal product whose users are the people delegating to it.

When agents keep making the same mistake, the owner follows the problem until the fix is in use. If the dashboard keeps using an obsolete component, that means involving the component’s maintainer, getting the corrected guidance approved, and checking whether later runs still make the mistake. Factory explains how to measure the time from failure to fix.

Someone also owns the quality of the evaluations: which criteria the team applies, how closely an evaluator’sJudge/EvaluatorAn AI used to assess work against defined criteria. Check its judgments against examples evaluated by people who understand the task.For a dashboard, it can assess whether the explanation of each case’s priority is supported by the case details. judgments match those of the people who know the work, and when to recheck it after a model change. The factory owner may hold that responsibility, or a product or quality person who already assesses the work.

The engineering leader

Leaders make the investment and delegation decisions explicit:

• Use evaluations of completed tasks to examine recurring failures, human rework, and evidence of improvement.
• Investigate why a task needs close supervision. Missing context or unreliable checks may be repairable; an unresolved product question may need continued collaboration.
• Budget for maintaining context, checks, and review, including time from product and domain experts and from the factory owner.
• Define authority and escalation. The delegation agreement distinguishes starting work, reporting progress, and taking actions that need separate approval.

Do these become new jobs?

Most of these responsibilities can sit within existing roles. The factory owner is the one most likely to need dedicated time. When several teams share a factory, owning its reliability and development can become someone’s main job. In a smaller team, a product owner or engineer may take it alongside product work and look after two products. The role needs product judgment as much as engineering skill. The owner decides which improvements the team needs and whether they paid off.

Assign responsibility and time for evaluation, access controls, and investment decisions. The Factory chapter describes how the team makes those duties part of its operating model.

If someone outside the team set up the factory, the team has taken it over once it notices a recurring failure itself and improves the check or guidance that should have caught it. Until then, the people who built the setup still carry that responsibility.

When handoffs stop making sense

Agents can produce drafts, prototypes, and tests quickly enough for several roles to examine the same work together. Product and domain experts can question the behavior while engineers assess the implementation. Some handoffs remain necessary, especially where responsibility or access changes. Others can become a shared review of a working result.

Try it on one task

Pick one bounded task whose result you can inspect, such as a small change to the dashboard. Before the agent starts, name who decides what the change should do, who assesses the result, and who looks after the setup. Agree on the criteria together and collect two or three examples of results you would accept or reject.

Run the task with close checkpoints and the people involved watching the work. Afterwards, look at what each of them had to correct or supply, and choose one improvement for the next comparable task. The FAQ describes how to widen the approach from there.

For your team, whose knowledge is missing from the context and review?