Before You Build an Agent, Draw the Decision Boundary

“We could build an agent for that.”

It is an understandable response to a messy workflow. The agent can read the request, find the information and work out what to do next. The demonstration is often convincing.

Before choosing the technology, I would want the team to draw three boundaries: where rules are clear, where interpretation is useful and where someone must retain authority.

That drawing can save a considerable amount of unnecessary complexity.

Separate the kinds of work

Consider a supplier-onboarding request.

Checking that mandatory fields exist is predictable. Comparing a bank-account format against a defined rule is predictable. Reading an unfamiliar document and identifying missing evidence may benefit from AI interpretation. Accepting a material commercial or security exception requires an authorised decision.

Putting the whole process inside one agent blurs these differences. It becomes harder to explain which part is allowed to vary, which part must be consistent and who owns an exception.

My starting point would be a controlled workflow with a bounded place for AI reasoning. The surrounding services validate requests, enforce access, authorise changes and record outcomes. The AI component helps with the work that needs interpretation.

Distinguish explicit rules, bounded interpretation and consequential human judgement.

Give the reasoning a useful limit

For each AI task, define its purpose, approved sources, permitted tools and stopping conditions.

The supplier assistant might inspect submitted evidence, compare it with approved requirements and propose the next step. It should not grant itself access to another system, alter the approval policy or invent a route around a missing authorisation.

Where an action changes a business record, a governed service should check whether it is permitted. A generated recommendation provides input to that check; it should not be able to bypass it.

This distinction matters even when the model is performing well. A mistaken interpretation becomes more manageable when the surrounding system constrains what it can cause.

Keep interpretation within clear boundaries and enforce action permissions through the execution path.

Design the untidy path

Production workflows encounter partial information, expired credentials, slow services and repeated requests. An agent adds the possibility that an intermediate interpretation is wrong or that it keeps trying an unproductive approach.

Set time and cost limits. Make repeated operations safe where possible. Record state outside the model's conversation when the workflow needs durable progress. Provide a visible human queue for unresolved cases, with enough context for someone to continue the work.

Those choices affect the business experience. A request that silently loops for twenty minutes is a service problem, even if no security boundary has been crossed.

Add another agent when there is a reason

Multiple agents can help where responsibilities are genuinely distinct, specialist context matters or separate work can proceed in parallel. They also introduce more coordination, state and failure paths. Microsoft's orchestration guidance describes several patterns, each with design trade-offs.

I would ask the team to demonstrate why the additional agent improves the outcome compared with a simpler arrangement. “More intelligent” is too vague. Better evidence might be stronger task isolation, a demonstrable quality improvement or an operational requirement that one agent cannot meet cleanly.

Before the next build starts, label each step in the workflow: rule, interpretation or authorised judgement. Then decide where an agent earns its place. The resulting architecture will be easier to explain, test and operate.