THE SMALL TEAM FIELD NOTES

Choose by how much the next step can vary

You do not need an agent just because a task uses AI. Start with the work itself: are the steps known in advance, or must the system interpret changing context and choose what to do next?

The useful distinction

Workflow automation follows a route a person can describe ahead of time: when an event happens, check a condition, then act. For example, save a new enquiry, notify the right team, and create a reminder. A workflow can include an AI step, such as sorting a message into a few categories, while the overall route stays defined.

An AI agent uses a model to decide how to progress through a task. It may read context, choose among permitted tools, check the result, and stop or ask for help. That flexibility can help with varied language and exceptions, but makes behavior less predictable. OpenAI's guide describes an agent as using a model to manage execution and select tools, while a workflow is a sequence of steps.

Ask whether a colleague could draw every normal step and branch before the task starts. If yes, begin with a workflow. If the system must inspect new information and choose among several valid next actions, consider a bounded agent. Often a workflow handles dependable steps while an AI step handles one narrow judgment.

Separate repeatable work from judgment

List the task from trigger to accepted finish. Mark each step as lookup, fixed rule, interpretation, decision, or external action. Queries and rules can often stay deterministic; a model may help interpret free text. Assign a human owner to decisions that affect money, access, or customer rights.

Synthetic example: a small shop receives order questions. A workflow captures the message, retrieves order status, and prepares a draft. A classifier can sort delivery, damaged-item, or product questions. A person handles disputed payments and refunds. An agent might choose among approved read-only tools for incomplete messages, but should ask for clarification or hand off; a person authorizes consequential changes.

This division also makes failures easier to locate: did the trigger fail, was the category wrong, was the source record wrong, or was a draft approved in error? Avoid a broad instruction like 'resolve every customer issue' when you can state a narrower task and escalation path.

  • Write the trigger and the desired end state in plain language.
  • Mark which steps are fixed, which interpret free text, and which change important records.
  • Give each uncertain case a safe stop, clarification, or human handoff.

Use the least flexible design that works

Start with the smallest version that answers the question. If a rules-based workflow handles the important examples, keep it. If language understanding is needed, add one model step with named output choices or a draft. Consider an agent only when the next action depends on information found during the run and fixed branches are hard to maintain.

A fixed process can send an order-status message from an order record. A more open-ended process might compare a customer's description with a policy, ask which item they mean, and choose whether to draft or route the case. An agent still needs limited tools, clear access rules, a step limit, and a completion condition.

UK Government guidance recommends checking whether AI fits the problem and considering alternatives. Define the delay, repeated task, or error first. If the process or data is unclear, autonomy will not clarify the policy.

Test the process, not the label

Prepare representative cases before connecting live actions. Include ordinary examples, missing information, contradictions, and out-of-scope requests. Compare results with what a trained person accepts, and define when the system should stop or hand off. A neat demo does not show readiness for every case.

Initially, let a person review each suggested category, draft, or next step. Track what they accept, edit, or reject and why. Fix repeated source or policy gaps instead of widening the model's authority. OpenAI also recommends incremental development and evaluation before adding complexity.

  • Define an acceptable result and a measurable baseline for the current process.
  • Run examples in a test environment and review both correct and incorrect results.
  • Measure staff review time, exceptions, reversals, and the cost of supporting the system.
  • Expand access only after an accountable owner approves the observed behavior.

A decision you can revisit

Use a workflow when the route is stable and predictable execution matters. Add a model step for narrow interpretation or drafting. Use an agent for a bounded task whose steps vary with context and whose tools, stop conditions, and human escalation can be checked.

Record the chosen pattern, why it fits, supported cases, permitted actions, handoffs, and evidence needed before expansion. Revisit the design as you learn. A system is easier to improve when people can see which decisions it owns.

Sources and further reading

START WITH ONE USEFUL THING

What’s slowing your team down?

Tell us about the task, the tools you use, and what you want to make easier. We’ll work out a useful first step together.