Stork Delivery
When to use a workflow instead of an AI agent
Use predictable rules where the path is known, and reserve model-directed decisions for work that benefits from them.
The problem: an agent can add complexity to a predictable workflow
A new intake process needs to read a request, classify it, and send it to the right team. Does that require an AI agent?
Perhaps. It may also need a conventional workflow with one model-assisted step.
Choosing between those approaches starts with how much of the path is already known and how much judgment the work requires.
A practical approach
Map the decisions first
Take a request for a replacement part. The application can check whether required fields are present, whether the account exists, and whether the part number matches a catalog entry using ordinary software rules.
A model may help interpret a free-text description when the customer does not know the part number. That does not automatically mean the model should also decide whether to approve the replacement or create the order.
Keep predictable decisions explicit. It makes the behavior easier to inspect and the failure easier to locate.
Ask where flexibility helps
An agent can be useful when the system must choose among tools or adapt its sequence based on intermediate results. That flexibility comes with additional evaluation and operational work.
Anthropic's Building effective agents distinguishes predefined workflows from systems where the model directs its own process. The distinction is useful because it separates a flexible execution path from simply including AI in an application.
Use that flexibility where it improves the task. Do not make the whole process less predictable just to give it an agent label.
Compare the complete operating cost
Evaluate the time, model usage, review effort, and failure handling required by each approach. A short automated workflow with one review point may be more useful than a longer autonomous run that needs extensive checking afterward.
Test representative exceptions. What happens when the customer describes two different problems? What if the catalog search returns no result? What if a tool is unavailable?
The right design should produce an understandable outcome in those cases, even when that outcome is a request for human help.
Start with a boundary you can control
You can expand authority after the application demonstrates useful behavior. For example, let it recommend a route before allowing it to assign requests automatically within a narrow category.
Keep the conventional application responsible for permissions, validation, and recording consequential changes.
The aim is a dependable business workflow. Sometimes an agent is the right component. Sometimes a small amount of AI inside an otherwise ordinary application is the more effective design.
The result: the simplest design that handles the required decisions
Take one intake task and compare a defined workflow with an agent only where flexible tool selection is useful. Run both against the same ordinary and difficult cases. Compare completed work, review effort, elapsed time, and failures. Choose the design whose behavior the team can operate and explain. Start by separating fixed business rules from the one decision that actually needs interpretation.