Start with the workflow
Before selecting a framework, write down the work. What arrives, what information is needed, what decisions must be made, and what outcome would count as useful? A workflow diagram often reveals that only one step needs a language model.
Consider a fictional support inbox. Each request needs a category, a relevant policy, and a suggested reply. The system might also need to check an order. These are different responsibilities; they do not automatically require one autonomous agent.
Use predictable steps where you can
When the inputs and rules are well understood, ordinary software gives you a direct way to test behavior. Checking that an order exists or enforcing a refund limit can remain deterministic. A model can help interpret a message while the surrounding application controls permissions.
The design question is whether the next action needs to be selected dynamically. If every request follows the same sequence, a fixed workflow may be easier to inspect. If the system must choose among tools based on intermediate results, an agent approach may be worth evaluating.
Retrieval is its own decision
A question-answering feature can retrieve relevant documents and generate a cited response without choosing an open-ended series of actions. Start by asking whether the missing capability is access to knowledge or the ability to plan and act.
For the support example, retrieving the applicable returns policy may be enough. Issuing a refund introduces a different responsibility and should have its own authorization rule.
Make autonomy explicit
Write an allowed-action list before connecting tools. Specify which actions are read-only, which can change state, which require a person, and what happens after a timeout. Bound the number of steps and the resources a run can consume.
An illustrative pilot could draft a response and propose an action for review. That creates an opportunity to observe failure patterns before considering broader autonomy. It does not prove that unattended execution will be safe.
Define the comparison
Compare the proposed agent with a simpler baseline on the same representative tasks. Record task completion, incorrect tool choices, human corrections, elapsed time, and cost. Keep ambiguous examples in the test set so the system's ability to ask for help is visible.
Do not reduce the decision to one aggregate score. A workflow that completes more tasks but performs an unacceptable action may be a worse fit. Agree the failure boundaries with the people who own the workflow.
A practical first brief
Describe one workflow, its current pain point, the tools it touches, and the outcome you want to measure. List the actions that must stay under human control. This gives an architecture review something concrete to assess.
These are design considerations and an illustrative example, not a report of a deployed client system. Explore architecture and workflow services or discuss your use case.