Your automation keeps breaking because the steps change from one run to the next, and someone asked whether an agent would fix it. Use an agentic system when the goal is open-ended, the environment changes and the next step depends on the last result. If you can write the steps down, choose a workflow.
An agentic system is a program that looks at its surroundings, picks its own next step and acts toward a goal without a fixed script. Agentic AI development is the work of building that loop safely: what the agent can touch, how it chooses, and how you will know when it fails. You will also see it called agentic software development, agentic development or agentic engineering; the names describe the same practice.
The agent or workflow rule. If you can write the steps down before the run, build a workflow. Build an agent only when the next step depends on what the last step returned and you cannot list the branches in advance. A workflow is cheaper to run, faster and easier to audit, so the agent has to earn its place.
Who this is for, and who it is not for. This is for the developer or technical lead who has been asked to “add an agent” and needs to decide whether the task deserves one. It is not for someone choosing a chat model or writing a prompt. Our guide to reducing manual work in operations covers which handoffs to automate first.
Most agent requests we get start in store operations: returns, stock exceptions, and order edits that cross into an ERP, the system that runs stock, orders and finance. Those tasks touch live order and customer records, so the integration layer decides how safe an agent can be. Autonomous Technologies is a Vancouver-founded Shopify agency, and stores hire us to stop orders and records going missing between systems. Our Shopify integrations and custom apps work settles who owns each record before any agent is allowed to write.
Which scenarios most clearly benefit from an agentic system?
Scenarios with an open-ended goal, a changing environment and no fixed sequence of steps benefit most from an agentic system. Multi-step research, working out why a system broke, and any task where the next action depends on what the last one returned all qualify. A task with known inputs and a written procedure does not. A plain workflow is cheaper, faster and far easier to audit, so choose the workflow whenever the steps are known.
The test is simple. Try to write the procedure as a numbered list. If you finish the list, you have a workflow. If you keep writing “it depends on what comes back”, you have a candidate for an agent.
| Scenario | Fits an agent? | Why |
|---|---|---|
| Research across sources you cannot list in advance | Yes | Each result changes which source to read next |
| Working out why production broke, across logs, metrics and tickets | Yes | The path depends on what the first check finds |
| Nightly report from a fixed query | No | The steps never change |
| Copying orders between two systems with a known field mapping | No | A workflow with automatic retries does this with no judgement |
Notice that “uses a language model” is not in the table. A workflow can call a model at one step and still be a workflow. Control over the sequence is what makes a system agentic.
An agentic system decides the path; a workflow follows one
The cleanest distinction comes from Anthropic’s engineering guide, Building effective agents, published December 2024. A workflow runs models and tools along code paths set in advance. An agent lets the model direct its own process and tool use. The same guide recommends starting with the simplest design and adding complexity only when the task needs it.
Inside an agent, that self-direction is a loop. The agent looks at the current state, works out the gap to its goal, picks a tool and calls it. The result comes back as a new observation and the loop runs again. The ReAct paper by Yao and colleagues (arXiv 2210.03629, 2022) describes this reason-then-act pattern.
| Property | Agentic system | Workflow |
|---|---|---|
| Who decides the path | The system, at run time | You, before the run |
| State between steps | Required | Optional |
| Cost per run | Varies, because each step is a paid model call | Fixed and known |
| How you test it | A fixed set of scenarios, checked against the run log | A unit test on each step |
| Audit trail | Must be built in | Falls out of the code |
| Typical failure | Loops, drifts or overreaches | Stops on an unhandled case |
Five components every agentic system needs
Strip away the framework and every agentic system has the same five parts. Miss one and we can tell you in advance how it will fail.
| Component | What it does | What breaks without it |
|---|---|---|
| Goal and stop condition | Says what done looks like and when to quit | The agent loops or runs up cost |
| Decision logic | Picks the next action from the current state | Every run follows the same path: a workflow |
| Tools and boundary | What the agent can read or change | It reaches systems nobody meant it to touch |
| Memory | Carries results from one step to the next | It repeats work or forgets what it found |
| Feedback | Scores runs so you can correct behaviour | Nobody knows if it is getting better or worse |
Memory here means working state inside one run, not training. Most production agents learn nothing between runs; they get better because someone changes the prompts, tools and rules.
The boundary is the part developers skip. The environment is everything the agent can see and change: files, databases, other systems’ APIs and user input inside its reach. Write it as an allowlist, a short list of what is permitted.
Decision logic and learning are separate choices
Decision logic is the part that picks the next action. Learning is how that logic gets better over time, if at all. Bundle the two and you end up with a model you cannot explain running a decision you could have written as a rule. There are three practical options.
- Rules. If this state, then that action. Use rules when you can write every case down. They multiply as cases grow.
- A trained model. It predicts the right action from past examples. Use one when you have a history of good decisions. The examples go stale.
- A language model as planner. It reads the state and proposes the next step in plain text. Use it when the steps are hard to list but the tools are well defined. Each run differs, so it needs guardrails: hard limits on what it may call and how often.
Reinforcement learning, where an agent learns by being rewarded over many trials, needs a simulator or a cheap, safe way to try things. Most business tasks have neither. If you have a history of correct decisions, start with the trained model. It is cheaper and easier to explain.
Design the agent around what it can reach
Design starts with the goal and the boundary, not the model. Write the goal as a condition code can check. “Every open return ticket has a decision and a logged reason” works. “Handle returns well” does not. Then write the stop condition, with a cap on steps and a cap on spend.
Next, set the boundary: every tool the agent may call, every record it may read and every record it may write. That list is the blast radius, the worst thing a bad run can do, so keep it as small as the goal allows.
Gate every write that matters. Let the agent read, draft and summarise on its own. Put a named person between the agent and any write that touches an order, a price, stock or a customer record. In our builds the refund is the first write we gate. The gate is a person, not another rule.
Then add the trace, the step-by-step log of one run. Every step records what the agent saw, what it decided, which tool it called and what came back. The trace is how you debug an agent and how you prove what it did. Build it before the first real run, because you cannot add it after the incident.
| Step | What the agent saw | What it decided | Tool called | Gate |
|---|---|---|---|---|
| 1 | New return request with an order number | Look up the order | Read order | None |
| 2 | Item is final sale | Check the exception list | Read policy | None |
| 3 | Exception applies, repeat buyer | Draft a refund approval | Draft message | None |
| 4 | A refund changes an order | Ask for approval | Notify reviewer | Named person |
| 5 | Approved | Issue the refund, close the ticket | Write refund | Logged, after approval |
If a reviewer cannot read the trace and see why the agent did step 4, the design is not finished. An agent you cannot explain is an agent you cannot sign off.
Tools for building and testing agents
You rarely need more than two of these. A language model planner needs a framework to run the loop and a standard way to hand it tools. Reinforcement learning needs a simulator and a training library. Each link is the vendor’s own page.
- Running the loop: LangGraph, a framework for agent loops with branches and state.
- Handing tools to a model: Model Context Protocol, an open standard for exposing tools and data to a model.
- Training models: PyTorch for deep learning, scikit-learn for simpler statistical models.
- Reinforcement learning and simulation: Gymnasium for training environments, Stable-Baselines3 for reference algorithms, Mesa for agent-based modelling.
Inclusion is not a recommendation. Favour the tool your team can debug at two in the morning over the one with the best published benchmark.
Test the loop, not just the model
Model accuracy is rarely the metric that fails first. Test the loop: does the agent reach the goal, how many steps does it take, what does it cost and how often does it need a person.
| Metric | Unit | How to measure |
|---|---|---|
| Task completion rate | Per cent of runs that reach the stop condition | Goal-met runs over total runs on a fixed scenario set |
| Decision accuracy | Per cent of steps a reviewer would also have taken | A person grades a sample of traces, step by step |
| Steps per run | Count | From the trace; watch the spread, not the average |
| Cost per run | Currency, or tokens, the units a model bills by | Model and tool costs per trace |
Run these on the same fixed set of scenarios before every change, the way you would run a test suite. After launch, keep them running on real traffic and alert when they drift. Add a regular audit where a person reads a sample of traces end to end. The numbers tell you something changed. The traces tell you what.
Where agents break, and what that costs you
The main reason to hesitate is not the model. It is that an agent’s cost and behaviour vary from run to run, and your team has to own that. Three breaks follow from it. In our own integration work, ownership is the one we see first, so it is worth reading to the end.
Cost is the first. A workflow costs the same every night. An agent that takes 4 steps on Monday and 40 on Tuesday costs ten times more on Tuesday, and you find out from the invoice. That is what the step cap and spend cap are for.
Overreach is the second. Give an agent broad access and it will use it, because the planner is chasing the goal, not your change-control rules. The boundary and the human gate exist for this reason.
Ownership is the third. Someone has to read traces, tune prompts and answer for a bad run. Unowned automation gets switched off after the first incident, so name the owner before the build starts.
Where this does not apply. If the task is a fixed sequence with retries and error handling, none of the above is your problem. Build the workflow and ship it. Our real-world examples of agentic systems show the cases where the sequence genuinely cannot be fixed in advance.
Write the steps down first
Here is the whole guide in one action you can do today. Take the task someone wants an agent for and write it as a numbered procedure. If you finish, build a workflow with automatic retries. If you cannot, build the smallest agent that closes the gap: set the boundary, write the stop condition, and test the loop on fixed scenarios before it touches live data.
Agentic AI development questions
What are agentic systems?
An agentic system looks at its environment, decides what to do next and acts toward a goal with little human input. The distinguishing feature is not intelligence but control over the sequence: it chooses its own next step rather than following a script. It keeps state between steps, uses tools to act, and stops when the goal is met.
What is the difference between an agentic system and a workflow?
A workflow follows a path the developer fixed before the run. An agent decides the path while it runs. That makes a workflow predictable, testable and cheap, and an agent flexible but harder to reason about. Choose the workflow whenever the steps are known. Our guide to reducing manual work in operations covers which handoffs to automate first.
How do agentic systems plan, reason and act?
Through an action loop. The agent looks at the current state, works out the gap to its goal, picks a tool and calls it. The result feeds back as a new observation. Tool use is how it touches the world. Guardrails set which tools it may call, how often, and which actions need a person’s approval first.
What is an agent environment?
The environment is everything the agent can see and change: the files, APIs, databases, services and user inputs inside its reach. Defining it is a design decision, because the boundary sets the blast radius. Anything outside it the agent cannot see and cannot break. Setting the boundary tightly is the first safety control, before any prompt.
Is agentic software development different from normal software development?
The build is mostly the same: version control, tests, deployment, monitoring. Three things change. The path is decided at run time, so you test with scenario suites and traces, not unit tests alone. Cost varies per run, so you cap steps and spend. And every write that matters needs a human gate, because the system can act without asking.
Tool and platform facts checked October 2026. Vendor pages linked above were read on 9 October 2026.
