Automation / Field note
Agentic systems are AI systems that accomplish a goal with limited supervision — through planning, reasoning, memory, perception and tool use. A clear introduction to what they are, how they differ from chatbots and simple automation, and where they earn their place in business.
The term "agentic systems" gets used loosely these days — sometimes for a chatbot with a few tools, sometimes for a fleet of autonomous assistants working across an organisation. That ambiguity is not harmless: it leads teams to either oversell what they can build or underinvest in the capabilities that would actually make a system useful.
So let's be precise. An agentic system is an AI system that can accomplish a goal with limited supervision — not by following a fixed script, but by planning, reasoning, using tools and adapting as it goes. The key word is goal. The system is given an outcome to achieve, some latitude in how to get there, and the ability to make intermediate decisions along the way.
That distinguishes agentic systems from two other common categories:
Agentic systems sit between those two. They are more directed than a passive assistant, but more flexible than a rigid automation. They combine the goal-orientation of a human operator with the consistency and scale of software.
There's no single agreed-upon taxonomy, but most serious accounts — including IBM's working definition and Anthropic's practical framework — point to a common set of capabilities. A system is more "agentic" to the extent that it has these building blocks:
The system is given an objective to achieve, not just a command to execute. That objective might be narrow ("summarise this document and extract the action items") or broad ("resolve this customer's issue"). The point is that the system has something to aim for, and some latitude in how it gets there.
The system must be able to take in information about its environment — a user's message, a document, a database query result, the output of a tool call. Without perception, a system is flying blind: it can't reason about anything it can't observe.
This is where agentic systems earn their name. They don't just react; they decide what to do next. Planning means breaking a goal into steps, sequencing them, and adjusting when something goes wrong. Reasoning means evaluating options, weighing evidence, and deciding when a plan needs to change. Not every agentic system plans in the classical sense — some reason step-by-step rather than building a full plan up front — but some form of deliberative decision-making is essential.
A system that can remember what it has done, what it has learned, and what context surrounds the task is more capable than one that treats every moment as isolated. Memory can be short-term (the current conversation, the last tool call) or longer-term (documents, past interactions, learned preferences). In agentic systems, memory is what lets a system build on its own experience rather than starting from zero every time.
Tool use is what turns a reasoning model into something that can actually do things. A system might call a search API, query a database, run code, send a message, or trigger an external service. Tool calling is the bridge between "thinking" and "acting." Without it, a system is confined to whatever its base model can produce as text.
Anthropic's research on building effective agents makes the point sharply: the most successful implementations don't reach for the most complex framework; they invest in clean, well-defined tools. The tool interface — what the system can call, how it's described, what parameters it expects — is where a lot of agentic behaviour is actually determined.
A rigid automation does the same thing every time. An agentic system can adjust to new information, unexpected inputs, and changing conditions. It might retry a failed tool call, choose a different approach when the first one doesn't work, or ask a human for help when it hits the edge of what it can safely do.
Anthropic makes a distinction that's worth borrowing: between agentic workflows and agents.
Workflows orchestrate LLMs and tools through predefined code paths. The overall structure is fixed by a developer; the model is used at specific points for reasoning, generation, or classification. A workflow might call an LLM to interpret a document, then route the result to one of several tools based on a rule.
Agents are systems where the LLM dynamically directs its own process and tool usage. The model decides what to do next, which tool to call, and when to stop. It maintains control over how it achieves the goal.
Both are agentic in the broader sense — they use models, reasoning, and tools to pursue a goal — but the distinction matters for design, testing, and risk management.
Workflows are more predictable, easier to test, and usually cheaper to run. They're a good choice when the steps are reasonably well-understood and the main value is in the reasoning or generation at specific points. Agents are more flexible, but they trade cost and latency for that flexibility, and they need stronger guardrails.
The practical takeaway: start simple. For many business problems, a well-designed workflow with a few strategic LLM calls is enough. Add more autonomy only when the problem genuinely requires it.
A model that can only produce text is limited. Tool use is what lets an agentic system interact with the world — search a knowledge base, read a customer record, draft an email, update a status, query an API.
Tool use in agentic systems usually works through some form of structured interface. The system produces a tool call — often in a structured format like JSON — and an execution layer runs the actual tool and returns the result. That result then feeds back into the model's reasoning, which may decide to call another tool, refine its plan, or produce a final answer.
A few principles make tool use more reliable:
This is one area where the "agent-computer interface" concept from Anthropic's research is particularly apt. The quality of the tools — their design, clarity, and constraints — shapes the quality of the agentic behaviour as much as the model itself.
Agentic systems are not a universal solution. But there are patterns where they consistently add value, especially when combined with good data, clear goals, and appropriate human oversight.
A support agent might triage incoming requests, retrieve relevant knowledge, draft a response, and escalate to a human when needed. The value isn't just in deflecting tickets — it's in responding faster, more consistently, and with better use of the organisation's knowledge. But the agentic part matters: the system needs to decide which information is relevant, when a question is out of scope, and when a human should take over.
Agentic systems can help with research, synthesis, and repetitive cognitive tasks — finding information across documents, preparing summaries, checking compliance, or assembling reports from structured and unstructured sources. The key is a clear goal and reliable sources of information.
Extracting structured information from unstructured documents, validating data quality, or transforming information from one format to another. These tasks often involve reasoning about content (not just pattern matching) and can benefit from an agentic approach — especially when the inputs are messy or varied.
Traditional workflow automation is great for fixed sequences. But many real processes have decision points — cases that need judgement, exceptions that need handling, or paths that depend on the content of the data. Agentic systems can add that flexible reasoning layer to an otherwise structured workflow.
Synthesising information from multiple sources — documents, databases, the web — into a coherent output. This is a natural fit for agentic systems because it involves perception (gathering information), reasoning (evaluating and weighing it), and tool use (searching, querying, retrieving).
The difference between a useful agentic system and a dysfunctional one is rarely the model. It's usually the surrounding design.
If you're considering agentic systems for your organisation, a few principles are worth holding onto:
Start with the problem, not the technology. What are you trying to achieve? What's the goal? What does success look like? The right architecture follows from the problem.
Begin with workflows, not fully autonomous agents. Workflows give you a way to introduce reasoning and tool use into a structured process without the full complexity and risk of autonomous agents. You can always add more autonomy later.
Invest in tools and data, not just models. A capable model with poor tools and messy data will underperform. A modest model with clean data and well-designed tools can be surprisingly effective.
Design for observability from the start. You need to know what the system is doing — what it's perceiving, what it's deciding, what tools it's calling, and what results it's getting. That observability is essential for debugging, improvement, and trust.
Plan for human oversight. Decide where a human needs to be in the loop, what they need to see, and how they'll intervene. The goal isn't to eliminate human judgement; it's to direct it where it adds the most value.
Test with realistic scenarios. Agentic systems need to be evaluated on the cases they'll actually face — including the messy, ambiguous, and exceptional ones. A system that works on clean demo data but fails on real inputs is not ready.
Agentic systems represent a real shift in what AI can do — from passive generation to directed action. But the shift is incremental, not instantaneous. The most effective organisations are building carefully: starting with clear problems, designing good tooling and data foundations, introducing autonomy where it's justified, and keeping humans in the loop where it matters.
The goal isn't to build the most autonomous system possible. It's to build systems that reliably achieve their goals — with the right balance of automation, reasoning, tool use, and human judgement. That's what makes agentic systems worth understanding, and worth building well.
