Shape the Work Before the Agent Shapes the Output

The workbench can preserve state and verify a diff, but it cannot decide whether the team is solving the right problem. In ai-engineering-from-scratch, the Product Judgment and Delivery path addresses that gap by defining an outcome before choosing an output, discovering the workflow people actually perform, testing assumptions, and designing measurement before release. This chapter follows that path because a capable agent can make the wrong build faster.

The practical distinction is simple. “Build an incident assistant” names a product form. It does not say who needs what to improve, what evidence the result must contain, or what must remain safe. An outcome describes an observable change in the world. It leaves room for a tool, a runbook, a data repair, or a smaller interface if those alternatives achieve the result with less risk.

Start with an outcome, not a favorite artifact

The repository’s outcome lesson asks what should become better, for whom, under which constraints, and how the improvement would be observed. It also asks for non-goals. This is not an exercise in making a request sound more sophisticated. It protects the decision from solution leakage—the tendency to smuggle a model, interface, framework, or architecture into the problem statement before evidence has earned it.

Suppose a team says it wants an agent that summarizes every production incident. The output is a summary. The desired outcome might instead be that an on-call engineer can identify the first verified cause and the next safe action within a defined review window. That outcome changes the design questions. Maybe the critical intervention is better log retrieval, a timeline template, or a human-approved evidence packet rather than an autonomous writer. The repository’s method keeps the team attached to the result instead of the first artifact someone proposed.

Constraints belong inside the outcome frame. A system that reaches the desired result by exposing private data, changing production without approval, or hiding uncertainty has not achieved the outcome in the relevant sense. Non-goals make the boundary explicit. If the first slice only supports evidence collection and a draft timeline, it should not quietly grow into automatic remediation because the model can produce a plausible command.

This framing also connects directly to the workbench. The scope contract can say which files or systems are allowed. The verification gate can state what proves completion. The outcome frame supplies the reason those boundaries exist. Without that reason, constraints become arbitrary obstacles that an agent or a team may try to remove under deadline pressure.

Discover the workflow before automating it

The next step in the repository’s route is to understand the work as people actually perform it. A named role or a polished process diagram can hide exceptions, handoffs, missing data, and informal judgments. An AI system inserted into the wrong description of the workflow may automate the visible part while making the hard part harder to notice.

A useful workflow description identifies triggers, inputs, decisions, actions, outputs, and handoffs. It asks where a person checks a source, where they ask for clarification, where they stop because authority is missing, and where a later reviewer corrects an earlier assumption. These transitions are the places where an agent needs context, permission, or escalation.

For the incident example, the real workflow may begin with an alert, move through log and deployment lookup, bring together evidence from several owners, and end in a review meeting.