A workflow describes how work moves. An automation starts or executes some of those steps without a person repeating them. An agent can make decisions inside a workflow, but it still needs clear inputs, allowed actions, and a way to stop.
A useful way to picture it
A kitchen has a preparation sequence and a timer. The sequence is the workflow. The timer is one automation. Adding a timer does not fix a recipe with missing steps, and giving someone a flexible role does not remove the need for a food-safety check.
How the pieces actually work
TRIGGER
Decide what starts the work
A form submission, an approved request, a scheduled run, or a person’s action can begin the sequence. Record a unique request ID so repeat delivery does not create duplicate work.
STEPS
Make the handoffs explicit
Each step needs a usable input and an identifiable output. A drafting step should produce a draft, its sources, and unresolved questions, so the review step has something concrete to assess.
DECISION
Use judgment where it adds value
Code is useful for fixed calculations and required fields. A model is useful for interpreting messy language or proposing a draft. Put each kind of work where its behavior can be checked.
RECOVERY
Design the failed path
Give retries a limit. Save enough state to resume safely. Send unresolved work to a named person. A failed run should not silently produce an apparently successful output.
What this looks like in a business
The Pricing Engine demonstrates the separation: the model estimates the effect of a price, the interface makes the tradeoff visible, and a human decides whether to accept a recommendation. The demonstration uses fictional inputs; it is not a forecast of a real business.
Run the workflow manually with a missing field, a duplicate request, and an unavailable service. Automate only after the team knows where each one goes.