A changing situation does not automatically require an agent. Many systems handle exceptions through explicit branches, rules and human decisions. The useful question is where the next step can be prescribed reliably, and where choosing it depends on evidence that arrives while the work is happening.
Anthropic’s account of building effective agents distinguishes workflows with predefined code paths from agents that direct their process and tool use. I use that distinction as a starting point. The decision method here is my architectural proposal, drawing on the business-model essay. It does not establish that adaptive agents produce better business outcomes.
Begin with the stable part of the work
Describe the required result and the obligations that hold across cases. A request may need identity checks, evidence collection, an authorised decision and a recorded outcome. Those obligations remain useful even when the order of investigation changes.
If the inputs, branches and successful end states are sufficiently understood, a workflow offers a clear way to implement them. It can use models for bounded tasks such as classification or extraction without delegating the choice of the overall route. Calling a model inside a process does not by itself make the process adaptive.
For example, an application could classify an incoming request and route it to a defined queue. Code can reject an invalid classification, enforce the allowed queues and preserve the request’s identity. This might meet the business need without introducing open-ended planning.
Locate the uncertainty that changes the next step
Consider the fictional manufacturer in my Enterprise Agentic Mesh essay. A delayed machine creates a need to keep a customer’s production running. A temporary loan may involve engineering suitability, an equipment owner, transport and the next customer’s booking.
A workflow could handle that case if those options and their dependencies are known. An adaptive agent becomes a candidate when useful alternatives repeatedly depend on discovering and combining capabilities whose route is difficult to specify in advance. The architecture still has to preserve the obligations attached to each capability.
Ask whether the uncertainty concerns finding evidence, interpreting it or deciding what action is permitted. These are different problems. Adaptive retrieval may help find a missing record. A specialist may still own the judgment it informs. An action service may still enforce a deterministic limit. Giving all three jobs to one agent can make a trace harder to explain without adding useful capability.
Keep the route flexible and authority explicit
Flexibility in choosing a route does not create authority to make a commitment. A planning agent may discover an alternative supplier; the company still determines who may approve a purchase and which service can place it.
A useful intermediate design is a workflow with a bounded adaptive stage. Let the agent investigate or prepare options, then return structured evidence to an existing approval and execution process. Alternatively, an agent can coordinate a case while every action interface applies its own conditions. The appropriate boundary depends on the task, consequences and the team’s ability to operate the system.
Palantir’s action-type documentation provides a concrete example of operations associated with changes to business objects. It demonstrates an implementation concept, not a recommendation that every organisation needs that product. In the broader proposal, shared business definitions describe what can change; implemented controls determine which changes are allowed.
Compare with a baseline that could actually be chosen
Before adding adaptive planning, build or describe the simpler alternative: rules, a workflow, search, or a person supported by an assistant. Compare the approaches on the same cases and include the work required when they fail.
Measure outcomes that the decision needs: correct completion, evidence coverage, conflicting commitments, escalation, time and total resource use. Include model requests, tool calls and reconciliation work. A reduced node count is not automatically a cost improvement. My graph-walk experiment illustrates why: scoring routes adds model work even when it visits fewer nodes.
Separate development fixtures from cases reserved for evaluation. A mechanism test may show that path context affects routing under a particular setup. It cannot establish the reliability of future routes. Repeat evaluations where model variability matters, and inspect failures by cause rather than collapsing them into one attractive percentage.
Count the operating burden
A more adaptive system introduces decisions about context selection, tool availability, stopping, supervision and recovery. Someone must own each policy and maintain the capability descriptions as the company changes.
A stable workflow also has maintenance costs. Its branches can grow awkward as exceptions accumulate. Compare those costs honestly. The question is whether the adaptive stage handles meaningful uncertainty well enough to justify the new responsibilities it creates.
I would choose the smallest design that covers the useful outcome and exposes its limits. Use a prescribed workflow when the route is sufficiently stable. Consider bounded adaptation when new evidence must shape that route. Expand delegation only when evaluation and recovery support the additional responsibility. That is a decision to revisit as the work changes, rather than a permanent vote for one technology.
Continue with the architecture review to inspect the boundaries, or authority and recovery to follow a commitment across systems. For a decision in your organisation, Advisory provides a starting point for discussing focused advisory scope.