MyDot Consultancy

Featured image: AI-generated conceptual illustration. Sources checked 26 October 2026.

Start with the decision, not the label

A supplier emails a revised invoice. Your business wants the right amount recorded, the discrepancy explained and any payment change approved. A vendor calls its solution an AI agent. Another calls the same process intelligent automation. Neither label tells you who decides what happens next, which systems can change or how mistakes are contained.

The useful distinction is control. In a workflow, software establishes the sequence and branches in advance. In an agentic process, a model has some discretion to choose its next step after inspecting the situation. Both can use language models. Both can call tools. Both can operate inside a tightly limited business process.

Anthropic makes this architectural distinction in Building effective agents. Its definitions are a useful vocabulary, not an industry-wide naming rule. The article also now warns that its original tooling discussion is historical. Use the concepts to examine a design rather than treating a 2024 article as a current product-selection guide.

Three ways to handle the same invoice

Consider a hypothetical distributor that receives an invoice with a delivery charge higher than the purchase order allows. There are at least three sensible designs, depending on how predictable the work is.

A rules-based workflow extracts the invoice fields, compares the delivery charge against the approved amount and sends mismatches to an employee. The rules determine the path. This may be exactly what the business needs if exceptions are uncommon and staff can resolve them quickly.

A model-assisted workflow adds language understanding at a fixed point. It asks a model to classify the supplier’s explanation, then follows a predefined branch: missing evidence, contract exception or duplicate charge. The model interprets text, but it does not choose an unrestricted investigation. A schema and application code constrain what happens after classification.

A bounded agent can inspect the purchase order, retrieve the applicable contract and check whether a delivery amendment exists. Its next read depends on the previous result. It may discover that the order number is wrong, switch to a supplier reference and request clarification when the evidence remains inconsistent. That flexibility is the reason to consider an agent. It also creates additional paths to test.

All three designs can end at the same approval gate. An agent’s ability to investigate does not require permission to change payment details. Separate those decisions in the architecture and in the commercial proposal.

Draw the parts that must remain predictable

Before choosing technology, draw the work on a whiteboard. Put a box around every consequential action: changing a bank account, issuing a payment, sending a supplier message or deleting a record. Beside each box, write who is allowed to authorize it and what evidence the action requires.

Then mark the uncertain sections. Does someone need to interpret an unfamiliar explanation? Search several systems? Decide which missing document matters? Those are possible locations for model judgment. By contrast, a tax calculation, access check or account identifier validation often has an exact rule that should remain in ordinary software.

This exercise usually produces a hybrid. A deterministic intake process launches a limited investigation, a human reviews the proposed resolution and a controlled API commits the approved change. Calling the entire system an agent or a workflow is less important than identifying the boundary of discretion.

Ask what the agent can actually do

A demonstration often emphasizes a natural conversation while hiding the integration contract. Ask the supplier to show one complete execution: the original request, selected tools, returned results, proposed action and final system state. A narrated success is weaker evidence than a verified record change.

The OpenAI function-calling guide helps explain a key boundary: the model can request a tool operation, while application code executes the integration. That boundary is where a business should expect input validation, authorization and clear failure handling. Tool availability should never be interpreted as blanket permission to use it.

• Which steps are fixed in code, and which can the model choose?
• Can the system only read and draft, or can it send, edit, approve and delete?
• What happens when a tool returns no result, an error or contradictory records?
• How is a proposed action linked to the approval that permits it?
• What observable evidence establishes completion, and who owns unresolved exceptions?

Compare against a simpler baseline

Build a small set of representative cases before debating architecture. Include ordinary invoices, malformed documents, conflicting references, missing contracts and attempts to access the wrong customer’s records. Write down acceptable outcomes independently of the system’s answer. “Ask an employee” may be the correct result for an unresolvable case.

Run the simpler workflow first. Record whether each case reaches a correct resolution, how much review it needs and which errors are consequential. Then test the agentic alternative on the same cases. The goal is to establish whether discretion solves a real bottleneck rather than simply making the demo more impressive.

A model-directed investigation might reduce unnecessary handoffs on ambiguous cases while taking longer on straightforward ones. It might also produce more useful explanations without improving the correctness of the final decision. Treat those as different outcomes. Decide which one justifies the operational complexity.

Make the choice reversible

Start with read-only investigation or draft recommendations when feasible. Keep external changes behind existing controls until the team understands the failure modes. Preserve a route back to the simpler process if an integration changes, a model update alters behavior or review demand becomes excessive.

The best architecture is the one whose authority, evidence and operating costs match the work. If the next step is known, encode it. If the next step genuinely depends on what the system discovers, bounded model judgment may help. In either case, make the boundary visible enough that an operator can explain what happened and stop what should not happen.

Sources and further reading

Anthropic: Building effective agents. Primary conceptual source for the distinction between predefined workflows and model-directed agents; original publication December 2024.

OpenAI: Function calling. Primary documentation for model-requested tools and application-side execution.