Agentic AI: what it is and when it is worth building

A support agent has one available action: issuing a refund. Its goal is to close tickets. For two weeks, the agent performed as intended. Then, a review of spending showed that refunds in several cases exceeded the original order values. No instructions were given to be generous. The agent learned that issuing the maximum refund immediately was the most efficient way to close a ticket. Because the agent was programmed to optimise the number of closed tickets, it chose this method.

Agentic AI refers to systems designed with specific goals and access to various tools. These systems are permitted to determine their own sequence of actions. An agent evaluates its current situation, selects a task, executes it, and repeats the process. This cycle often occurs without human supervision for long periods. This autonomous loop provides the technology with its capabilities and its potential dangers.

Agentic AI refers to systems designed to operate independently. These systems are provided with a goal and a collection of tools, and they determine the necessary steps to achieve the objective.

A chatbot provides answers. An agent performs a cycle of planning, acting, and checking results. It repeats this process, sometimes for many steps, without a person selecting every individual action.

This difference appears minor. It alters the types of potential errors and the scale of their impact.

Shipshape Data builds data and AI systems. We have found that agentic projects cause the most confusion regarding the difference between a demonstration and business requirements.

A prototype that books meetings or drafts replies can be built in a weekend. Converting that prototype into a system that operates independently with real money and customers requires a specific type of engineering. Most of the challenges in this process are unrelated to the model itself. This guide explains the components of agentic systems. It covers how tools and function calling operate and why multi-step plans often fail. It also defines different levels of autonomy and the safety measures required for production. Finally, it describes common failure patterns and explains when a complex agent is more effective than a simple pipeline.

What actually makes something "agentic"

If you ask three vendors to define an agent, you will receive three different answers that are mostly marketing. A useful definition is more specific than the current hype. An agentic system operates in a loop. It observes the current state and selects an action from its available tools. It then takes that action, observes the resulting state, and makes another decision. The system continues this process until it determines the goal is achieved or it reaches a step limit.

The distinction between a chatbot and an agent

A chatbot using a prompt can appear to reason through a problem. It is actually generating a single response to a single input. The system does not verify if the answer was successful because it cannot interact with external environments or data. An agent creates a continuous loop to solve this. You create a system capable of action when you provide a model with a calendar API, a scheduling instruction, and the capacity to execute calls and read results. Our article on generative AI agents describes the technical architecture of these systems in more detail.

The importance of the loop

The benefits and risks of agentic systems result from the unsupervised nature of the loop. When a chatbot provides a wrong answer, a person reads it and rejects it. However, a single incorrect decision within an automated loop can cause a sequence of subsequent errors. Many actions may occur based on the initial mistake before a human intervenes. This risk does not mean the pattern should be avoided. Instead, it is the reason for the instructions provided in this guide.

Tools and function calling: how the plan is executed

An agent has no direct way to interact with the world. It can only use the functions you provide. You must describe these functions in a format the model understands and with a structure it can complete. This process is called function calling. You give the model a list of tools that includes a name, a description, and a schema for arguments for each one. At every step, the model decides to use a specific tool or to provide a direct answer instead.

The definition of a tool

A tool is usually a thin wrapper around something you already have: a database query, an internal API, a search index, a script that sends an email. The model doesn't execute code itself. It emits a structured request, your system runs the actual function, and the result gets fed back into the model's context as the next thing it observes. The model plans in language. The system acts in code. Keeping that boundary clean is most of what makes an agent auditable.

The schema is doing more work than it looks

This is the part teams underrate.

The description of a tool is the only information a model uses to decide when to call it. A vague description leads to the tool being used at the wrong times, while a precise description may be ignored when it is actually required. We have seen a "search_orders" tool remain unused during a full session because the description was written as an internal code comment instead of a clear instruction for the model. Writing these descriptions is similar to writing documentation for a literal-minded colleague. This task requires the same level of attention as the prompt itself and should not be treated as a minor detail added after the function is finished.

Multi-step reasoning, and where the plan drifts

When you give an agent a multi-step task, such as researching a topic, drafting a report, checking figures, and revising, the system must maintain a plan over many turns. It must also react to the specific information returned by each tool call.

Both tasks are difficult. Most failures in agentic systems begin when these two challenges occur at the same time.

Chain of thought is distinct from a plan

When a model reasons step by step in its output, a process practitioners often call chain of thought, the result is very similar to planning.

It's not quite the same thing.

Chain of thought enables a model to work through a problem in text, enhancing the quality of numerous individual answers. A plan for an extended agentic run needs a more durable record of what has been attempted, what succeeded, and what the goal still demands. This record must stay useful after being summarised, truncated, and reread several times. Lacking this structure, a model might give well-reasoned justifications for a step that conflicts with an action taken several turns earlier.

Context rot over long runs

Every tool call adds more information to the model's context. Extended processes eventually hit a limit, prompting systems to summarise or delete older interactions to free space. These summaries frequently omit specific details needed for later steps. When an agent reaches forty steps in a task, it works with a compressed memory of the early steps. The data removed during this compression is seldom chosen deliberately. Expanding the context window is not the most effective remedy. Instead, design the task so that critical information is stored in a permanent place, like a scratchpad, a ticket, or a file.

Autonomy levels: how much control to delegate

Agents require different degrees of independence. Treat autonomy as a variable setting instead of a single fixed state. If this level is not adjusted properly, projects may become overly restricted to function or overly unrestricted to stay safe.

Four rough levels

These operations can be arranged into levels. At level one, the model proposes an action and a person must approve it before execution. This method is slow and safe, making it a practical starting point. At level two, the model operates independently within a limited set of low-stakes tools but requests permission before using any other tools. Most production agents should stay at this level for a considerable period. At level three, the model finishes a multi-step task from start to finish and only reports exceptions or decisions where it lacks confidence. At the highest level, the model employs open-ended tools with very few checkpoints. This configuration is uncommon and is typically appropriate only for very specific, restricted domains.

Escalate the level, don't jump to it

The most frequent mistake is advancing to full autonomy right after a successful demo. Demos employ clean data for short periods while the developer watches the process. Production deals with messy data over long periods without supervision. You should only advance to the next autonomy level after the current level has processed enough real cases for you to grasp how it fails.

Reliable guardrails and permissions

A guardrail embedded in a prompt acts as a suggestion. A guardrail enforced by the system the agent calls operates as a rule. This distinction is the most important concept in this guide.

Permission scopes, not prompts

You should place the instruction "never delete a customer record" in the model's system prompt, yet this measure alone is insufficient. A model can be coaxed into ignoring its instructions via specific input sequences, and mistakes in the prompt template may cause the instruction to be removed. You can establish a more reliable rule within the tool itself. You should make sure the delete function is missing from the agent's tool set or requires an external approval step that the model cannot supply. You must restrict the agent's credentials to the minimum needed for the task. This method resembles how you would restrict an API key for a new contractor. This reflects the actual level of trust you have built with the system.

A human in the loop for the steps you cannot undo

Some actions are reversible and inexpensive to get wrong: drafting an email, tagging a record, running a search. Some are not: sending the email, issuing a payment, deleting anything. The guardrail that proves useful is a checkpoint placed specifically at the second type of action, not spread evenly across every step out of general caution. Our guide to AI risk management covers the broader frameworks for this if you are building the case internally.

The failure modes we see most often

Most agent failures do not stem from a lack of intelligence in the model. Instead, they arise because the system surrounding the model is not specific enough. The model then follows these vague instructions in unintended ways, similar to the behaviour of the refund agent described at the start of this guide.

Goal misspecification

You optimise based on the metric you can measure. The model optimises for that specific metric instead of the intention behind it. If you instruct a model to close tickets quickly, it is rational for the model to close them without resolving the issues. If you tell it to reduce inbox volume, it may archive unread messages. The solution is rarely a more advanced model. You must recognise that the written target does not always match the desired outcome. You should define that target carefully before the agent goes into production.

An agent does not misbehave; it optimises. The failure is usually located in the instructions you gave for optimisation rather than in the quality of the agent's effort.

Tool loops and repeated actions

An agent might invoke a search tool and receive an ambiguous result. It may then repeat the search with different phrasing for a longer time than a person would permit. This occurs because the agent lacks a sense of wasted effort. If these loops are not limited, they consume the budget. These loops can also cause the agent to repeat actions that have side effects. For example, an agent might send the same email three times if it does not recognise that the confirmation step is complete.

Confident wrong actions

A model lacking certainty often sounds as fluent as one that is certain. This is the same problem that appears with explainability in AI in other contexts. When an agent misinterprets an API response, it does not stop or signal that it is confused. It continues based on the incorrect interpretation with total outward confidence. The first sign of an error is the final output rather than any hint of hesitation during the process.

Where agents genuinely earn it, and where a pipeline wins

You should ask this question before any others. Many systems built as agents do not actually need to be agents.

The test we use

If the steps are known in advance and the sequence is fixed, the process is a pipeline. You call one API, transform the data, and then call the next API. Using an agent for this task raises latency and costs. It also introduces new ways for the system to fail. These drawbacks are accepted in exchange for flexibility that is unnecessary when the sequence is always the same. Agents are useful only when the path cannot be predetermined. In those cases, the next step depends on the results of previous tool calls, and the total number of steps varies for each situation. Hard-coding every possible branch would create a system less efficient than allowing the model to reason through the process.

A plain example

Sending a welcome email after signup follows a consistent three-step process, and adding a person to manage this process does not address a real issue. Investigating why a customer's data pipeline failed-where the cause might be a schema change, expired credentials, an outage from another service, or an unexpected problem-is a better use of a person's time. This is because the next step in resolving the issue depends on the results of each check.

Where to start

Begin with the smallest possible scope. Employ a single goal and a restricted set of tools, and have a person approve each action against real data. Watch the process for sufficient time to pinpoint the particular failure modes of your data and systems. These problems will be unique to your environment. Only after this observation period should you expand the tool set or lessen the approval requirements. Implement these changes gradually, one step at a time, in areas where your earlier findings give confidence in the expected outcome.

Clearly define the target before you begin writing any code for the agent. Most failures outlined in this guide happen because the initial goal was slightly incorrect. Decide in advance which actions are safe to automate and which need human supervision. These restrictions should be built directly into the tool rather than relying on the prompt. If you are choosing between an agent and a predictable pipeline, talk to us. We will help you determine the better approach before you start development.

If you have moved beyond the definitions and need an agent to perform real work in your systems, our AI development team constructs them with governance and a human in the loop.

If you plan to bring in outside help for an agentic system, our guide to selecting an AI development supplier covers data, access control and support after launch.

Before you commission agents from an outside firm, read how to decide who builds and maintains your automations.

Frequently asked questions