An unfamiliar task does not automatically need an AI agent. An agent does not automatically need permission to act independently. These are separate engineering decisions, and confusing them makes both architecture and risk harder to reason about.
The useful distinction is between choosing a path and authorizing an action. Discovery may require flexible reasoning. Execution still needs explicit boundaries, adequate evidence and an observable result.
First Decide Whether the Path Must Adapt
A deterministic function is a good starting point when explicit rules solve the task. If a known sequence includes an ambiguous transformation, a coded workflow can call a model at that step. An agent becomes a candidate when intermediate discoveries determine what to do next.
Anthropic distinguishes predefined workflows from systems in which the model directs its process and tool use. It also recommends starting with the simplest adequate solution. These are architectural distinctions, not a claim that every complex task needs autonomy.
Consider document processing. Reading an unstructured invoice may require a model. Extracting fields, checking a schema and comparing amounts against a purchase order can still follow a fixed route. There is no need to rediscover that route for every invoice.
Investigating an unexplained discrepancy is different. The system may need another document, a transaction record or a clarification from an owner. The useful next step depends on what it finds.
Then Decide What Each Action May Do
Architecture describes how the system chooses work. Authority describes which consequences it may create. A research agent can choose search queries while having no permission to publish. A coding agent can inspect files and prepare a patch while lacking production credentials.
This separation also applies to workflows. A fixed pipeline that sends an email or changes an account needs an execution boundary even though no agent chooses its route.
For each proposed action, check authorization and scope first. Then ask whether the evidence supports this particular action, whether the result can be observed and whether the consequences fall within agreed limits. Missing evidence can justify more investigation. Missing permission cannot be repaired by better reasoning.
Clear Goals Can Coexist with Open Routes
The strongest agent candidates often have a clear destination and an uncertain route. “Resolve this reproducible software failure” can satisfy that pattern. “Improve our business” usually needs further scoping before it becomes an executable assignment.
Several possible actions can be acceptable. The agent does not always need to prove that its choice is globally optimal. It needs to select a useful action within the permitted set and expose enough evidence for the system to assess progress.
That makes practical decidability more useful than an abstract demand for certainty. Can the runtime decide whether this tool call is allowed? Can it check its arguments? Can it detect a failed effect? Those questions produce controls that can be implemented and tested.
Compare Tasks at the Right Granularity
| Task | Minimum useful control style | Boundary that still matters |
|---|---|---|
| Normalize known data fields | Explicit rules | Validate input and output |
| Extract claims from supplied text | Model call or workflow | Retain source spans and uncertainty |
| Follow a conflicting source trail | Bounded agent | Limit tools, scope and research budget |
| Investigate an unfamiliar code failure | Bounded agent | Isolate edits and validate the patch |
| Publish an accepted article | Controlled pipeline | Bind approval to the accepted version |
These are design recommendations, not universal classifications. A different environment can change the answer. If a supposedly fixed process accumulates costly exceptions, an adaptive investigation step may become worthwhile. If an agent repeatedly follows the same route, that route may be better expressed as code.
Verify the Environment, Not the Success Message
A final answer can claim that an action succeeded even when nothing changed. The acceptance test therefore needs to inspect the relevant state: the saved artifact, the reservation record or the deployed page.
Anthropic’s evaluation guidance distinguishes the agent transcript from the outcome in its environment. SWE-bench provides a concrete coding example by applying patches and running repository tests. Those tests supply useful evidence, while their coverage still limits what success establishes.
The check should match the claim. A passing build proves that a build completed under its checks. It does not prove that every statement in the article is supported. An HTTP response proves reachability, not that the approved version was deployed. Production acceptance may require several observations.
Keep the Coordinator Outside the Proposal
The model can propose the next step. The coordinator owns accepted transitions, budgets, tool permissions and completion conditions. This is the principle developed in AI Coordinator Architecture .
This boundary makes models replaceable without redefining the organization’s authority. A model update can improve search or interpretation while the publishing rule remains stable. It also makes failures localizable: a poor proposal, a failed tool call and an incorrect acceptance decision are different defects.
Before adding an agent, write down the discovery that requires it, the actions it may propose and the checks needed before execution. Compare it with the simplest workflow using completed tasks, review effort, cost and unresolved failures. The objective is useful adaptive work under inspectable control.