If you can write the process down as a fixed sequence of steps, you want automation. If the system has to work out what to do next based on what it finds, you want an agent. That one question resolves most of the projects that reach us described as agentic AI, and it usually resolves them in favour of the simpler option.
This is a commercial decision before it is a technical one. Automation is predictable to build, cheap to test and straightforward to debug when it misbehaves. An agent is none of those three. Choosing the wrong one does not get corrected in code review - it sets the budget, the timeline and the failure mode for the whole engagement. If you want the definitional version first, our glossary entry on AI agent development covers the terms; this piece is about which one to build.
The test: can you write the decision down?
Take the process you want to automate and try to describe it as rules. When a refund request arrives, check the order date; if it is inside 30 days, approve it; if it is outside, route it to a human. That is a workflow. It has a fixed shape, the same input produces the same output every time, and you can list the exceptions.
Now try the same exercise with something like triaging inbound support across seven years of undocumented product history. You cannot enumerate the branches, because the branches are the work. That is where an agent earns its place.
The honest answer for most businesses is that the process is mostly writable, with one genuinely ambiguous step in the middle. The right build is then a workflow with a narrow model call inside it, not an agent wrapped around everything. You keep the determinism where determinism is cheap and spend the unpredictability budget on the one place that needs it.
What scoped automation looks like when it works
For Crop Shop Boutique we connected ShipBob, Klaviyo and Shopify in a 2-week development cycle: 100 percent of pre-shipment customer notifications automated and the manual CSV export workflow eliminated. There is no agent in that system and there does not need to be. The decisions were all writable, so writing them down was the fastest route to the outcome.
Two weeks is the number worth sitting with. A great deal of what gets scoped as an AI programme is really an integration problem wearing a more fashionable label, and integration problems have known shapes and known costs.
When the ambiguity is real
The counter-example from our own work is EzLicence. We shipped an AI knowledge system called The Handbook for EzLicence in 4 weeks: it consolidated seven years of product evolution, delivers a 50 percent efficiency gain across workflows, and automates 90 percent of documentation updates with 10 percent human oversight.
That last figure is the part to notice. Ninety percent automated with ten percent human oversight is not a hedge, it is the design. A system operating over unstructured history will be wrong occasionally, so the build has to include the place where a person catches it. If a proposed agent has no such place, the proposal is not finished.
OpBill is a third shape again - not an agent, but a model doing one hard thing inside an otherwise conventional product. Its AI-powered OCR claiming flow, Snap, Scroll, Done, made medical billing 90 percent faster with 98 percent user satisfaction, built in 4 months. The intelligence sits in a single step. Everything around it is ordinary, testable software, which is precisely why it could ship in four months.
The questions to answer before either
Whichever way the decision goes, the same four questions decide whether the build succeeds:
- What does wrong look like, and who notices? If nobody is positioned to catch a bad output, you are not ready to automate the decision.
- What is the cost of a wrong answer? High-consequence decisions favour deterministic systems, because you can trace exactly why they did what they did.
- Is the input structured? Structured inputs rarely justify an agent. Language-heavy and highly variable inputs often do.
- What does this replace? If the honest answer is a spreadsheet that works, the return may not be there yet.
Where this leaves you
Start with the workflow. Add the model where the workflow genuinely cannot decide. Build the human oversight step in from the beginning rather than adding it after the first bad week.
That sequence is not caution for its own sake - it is the fastest route to something running in production, which is the only place you learn whether the harder version was ever needed. How we build with AI internally, and where we keep engineers in the loop, is set out on our AI software engineering page. And if the process turns out to be a full product rather than a feature, how long it takes to build an app covers the timeline side.
If you would like a second opinion on which side of the line your process sits, that is a conversation worth having before the budget is set rather than after.