Three different answers with three different costs, and the wrong one is expensive. Describe the workflow and get a recommendation, the risks, a minimum architecture, and the approval points it would need.
Output
Your brief, triage, or architecture recommendation will appear here.
The output is designed to be copied into a planning document and reviewed by a person before implementation.
How much the input varies decides everything downstream. Enumerable inputs want deterministic code, which is cheaper, faster and easier to debug.
A misfiled document and a mispriced invoice are not the same risk. The harder an action is to reverse, the more approval it needs.
Typed tool contracts, retrieval you can inspect, human approval points, evaluation cases and cost logging. Agents fail in production for want of these, not for want of a better model.
The order matters. Classify the workflow before pricing the technology, because a workflow with enumerable inputs does not need a model at all, and discovering that after the build is the expensive way to learn it.
Most of the time, and that is not a fashionable thing to say. If the inputs can be enumerated, deterministic code is cheaper to run, faster, easier to debug and does not fail in novel ways. An agent earns its cost when the input varies too much to write rules for.
A feature makes one call and returns a result: classify this, summarise that. An agent decides which steps to take and calls tools in a loop to get there. The loop is the expensive part, in cost and in failure modes, so it should be justified rather than assumed.
Keep permissions outside the model. The agent should not hold credentials or be able to take a consequential action directly. Give it typed tools with narrow scopes, put a human approval step in front of anything hard to reverse, and log every call with its cost.
Real anonymised cases with known correct outcomes, including the awkward ones. Twenty realistic examples catch more than a hundred synthetic ones, and without them you cannot tell whether a change improved the system or just changed it.
Yes, if the workflow allows it. Let the system produce its answer alongside the human doing the work, and compare. It costs one sprint and it is the cheapest way to find out whether the thing works before anyone depends on it.