Choose the right job for an AI agent.

There is a big difference between software following a route and software choosing one. That difference matters more than whether a tool has “agent” in its name.

When a business wants to automate work, I would start by deciding where judgment is actually needed. Some steps deserve a predictable rule. Others need help interpreting incomplete information. Giving every step the same freedom makes the system harder to understand and harder to trust.

Use a fixed workflow when the route is known

Suppose an approved inquiry form needs to create a contact, record the request, and notify the person responsible. The destination and sequence are already known. Ordinary workflow automation can handle those steps without asking a model to choose what happens next.

The useful work is in the details. An existing contact should not become a duplicate. An optional company field should remain optional. A failed notification should be visible to someone who can retry it. These are rules you can describe and test directly.

Adding AI to the sequence does not remove those requirements. It introduces another component that needs a clear reason to be there.

Add interpretation where the input varies

Now suppose the inquiry includes a long description of a project. An AI step could suggest the relevant service, summarize the request, or flag information that is missing. The rest of the workflow can remain fixed.

Keep the original message. Store the suggested summary separately. Let the person reviewing the inquiry correct it before treating it as an accurate account of what the prospect wants.

This is a useful middle ground. A workflow can include AI without becoming an open-ended agent. Anthropic's architectural explanation distinguishes predefined workflows from agents that decide their own next steps and tool use. That distinction is useful even as individual products change.

Give an agent a bounded job

An agent becomes more relevant when the route cannot be fully specified in advance. For example, a hypothetical internal research assistant might need to choose which approved documents to inspect, notice a gap, search again, and assemble an answer with references.

Its job still needs limits. Define which sources it may access, how much work it can perform, when it should stop, and what a finished answer must contain. A request to “research this account” leaves too much unresolved if the tool can also change CRM records or send messages.

Start with access that fits the task. Research may require reading records. Sending a proposal is a different action with a different consequence. Keep that decision visible and require approval where the business needs it.

Draw the exception route

Before building, sketch the normal path and the situations that interrupt it. The source may be unavailable. Two records may disagree. The request may fall outside the service you offer. The model may produce an answer that is fluent but unsupported.

For each situation, choose a response the team can recognize. Pause for review, retry within a limit, return the original input, or report that the task could not be completed. “Try harder” is not a useful recovery plan when a system can keep spending time or making changes.

This is also where you decide what to record. Keep enough history to understand the input, the tools used, the resulting action, and any approval. Collect only what is appropriate for the task and the people allowed to inspect it.

Test the smallest useful version

Take one real task and write down what success looks like before choosing the architecture. If rules can accomplish it reliably, use rules. If one interpretation step needs a model, keep that step narrow. If the system needs to choose its route, give it explicit boundaries and test the choices it makes.

Run the same representative cases through the proposed system and the current process. Include confusing inputs and failures. Compare the review effort as well as the finished output. A fast draft that takes longer to correct may be a poor trade.

For the earlier question of which work to start with, read Make AI useful. Start with the work..

If you want help deciding what to automate and how much freedom to give it, Work with me.