Where does the next step come from?

A useful distinction beneath the agent label

Ten blue storage boxes can be an awkward request without needing an open-ended agent to fulfil it. If two catalogue items are blue but differ in dimensions, the missing information is a size. That is one way into the distinction Anthropic made in Building effective agents on 19 December 2024: a predefined workflow can contain model interpretation, while another system lets a model direct its next steps and tool use.[1] The difficult part of an input and the owner of the process are separate design choices.

The source’s distinction helps ask who owns the next step, before a framework makes that choice for us. The two paths below are fully specified proposals, rather than model runs: a purchase draft with an ambiguous item description and an export investigation with a missing prerequisite. They place uncertainty in different parts of the work. That allows a more concrete design discussion than comparing agent labels or assuming that a difficult input must give the model control of the surrounding process.

Describing control explicitly in the brief helps the team avoid introducing an open-ended process when the actual difficulty is interpreting a value or agreeing a missing business rule.

Difficult wording inside an ordinary process

The first task is to prepare a purchase-request draft for ten blue storage boxes. The application knows where to read the catalogue, which fields the draft requires and that no supplier submission is part of this job. The awkward input is the description: two catalogue items are blue boxes, but their dimensions differ. A model may be useful for interpreting the wording and presenting candidates. It does not need to decide how the whole purchasing process works.

The proposed route is explicit. Fetch candidates from the configured catalogue; ask for an interpretation tied to existing candidate identifiers; validate that the result does not invent an identifier; and either build the draft or request the missing dimension. In the ambiguous case, the programme's rule selects clarification. Once the user supplies a size, the route returns to draft construction and review. The model contributes an interpretation at a known point. Code and the declared workflow policy decide what that interpretation permits next.

The fixed path does not guarantee that the model picks the right box. A confident interpretation can still be wrong, so the bounded step needs representative testing and review tied to the evidence. What becomes easier is locating the question: why this catalogue item? That is a smaller investigation than discovering why the assistant found another supplier and changed the approval route. Predictable control flow and reliable interpretation can support each other, but neither supplies the other automatically.

A workflow can route a clear catalogue identifier directly to validation and a loose description to a model, asking for clarification when a required attribute is absent. Those branches leave the outer process defined by the application. A model may help categorise an input while code still determines the allowed destinations and consequences. The design should identify these decision owners so that uncertainty in interpretation does not quietly extend into purchasing or approval authority.

When the next check depends on the last observation

The second task is to explain why an export check fails, without editing source. The permitted capabilities are narrow: inspect test output, read authorised files and a fixture manifest, and run an existing bounded check. The eventual explanation is known as the output, but the useful inspection sequence may not be known in advance. A missing fixture, a parsing error and an assertion failure can lead to different next questions. A model-directed investigation could choose among those checks from the evidence it encounters.

In the proposed export trace, the first result says a fixture path is unavailable. Reading the manifest is then more useful than studying the business mapping. It points to a file absent locally, so the investigator confirms the missing prerequisite and reports it. Inventing a replacement would make progress look more satisfying while changing what was being checked. A loaded fixture followed by an assertion failure would justify a different next read. The evidence changes the route, while the task still forbids source edits.

Nothing in that example requires unrestricted tools or permission to modify the repository. Dynamic selection and broad authority are separate choices. The investigator can choose a next read while remaining unable to edit source or fetch arbitrary private material. The application can also impose an overall work limit and require a report when a prerequisite is unavailable. These boundaries describe what the system may do; the model's chosen sequence describes how it tries to answer within them.

A decision tree may handle those diagnostic branches well. “Fixture missing, inspect manifest” can be stable logic worth writing once, rather than another decision for a model to rediscover. A dynamic route becomes more attractive when the checks vary enough that an exhaustive tree is harder to maintain than bounded evidence-led choices are to review. Calling a task investigation does not decide that trade-off. The relevant question is which kinds of cases will actually arrive, not whether the demonstration happens to contain a loop.

Put decision ownership in the design brief

The downloadable brief records each observation, the owner of the next decision and the allowed resulting action. In the box example, code owns progression from ambiguity to clarification; the model supplies a constrained interpretation. In the export example, the investigator chooses which authorised source to inspect, while the application owns the stop condition when the needed prerequisite is unavailable. This makes the difference reviewable without requiring agreement about which marketing label belongs on the product.

The designs can meet in the middle. A fixed process can call a bounded investigator and bring its result back through an ordinary review stage, retaining its own approval and submission rules. A model-directed investigation can likewise rely on deterministic tools and validators. There is no need to choose between scripting every line and controlling nothing. Assign the decisions where they occur, especially where new evidence could change the next action, and the mixed design becomes easier to explain.

Task length does not determine how much control the model needs. A large batch of standard letters can follow a known process, while a short diagnostic query may require exploration. An unfamiliar input may need only a clarification branch. More flexible routing is useful when it helps answer the actual question; otherwise it adds another process for the user or maintainer to supervise without resolving the original ambiguity.

Review effort changes with that choice. For a fixed workflow, inspect branch conditions, transitions and the quality of each bounded interpretation. For a dynamic route, inspect what evidence justified each selected action, whether alternatives were ignored and whether the stopping result matches the task. Neither approach eliminates judgement. They place it in different locations, which affects what must be recorded and what a maintainer will need when the output is challenged.

Choose flexibility where it earns its upkeep

A dynamic investigator may find a useful path its designer did not enumerate. It can also spend its allowance on an irrelevant theory or accept a plausible explanation too early. A fixed workflow has the opposite maintenance risk: an expanding set of special branches nobody can comfortably review. Compare those burdens using representative tasks. If the same missing-fixture branch keeps recurring, writing that branch once may be cheaper; if useful checks genuinely vary with new evidence, bounded selection may spare the maintainer a growing tree of exceptions.

Try the ordinary case and the awkward one before choosing the framework. The storage-box draft needs an explicit route to the missing dimension; the export investigation needs a next read justified by its failure evidence. Record who chooses those actions and what stops them. That exposes where flexibility would earn its upkeep and where it would merely add another process to supervise. The application can keep approval and submission authority even when part of the route is allowed to explore.