AI fundamentals

What is Agentic AI? Definition, Architecture and Limits

How to recognise an AI agent and when a fixed workflow is the better choice

Berkay Özgür

AI & Fullstack Engineer

· Updated · 7 min read

Abstract image of a person interacting with an AI agent

Contents

What is Agentic AI?

Agentic AI describes systems that decide which permitted step or tool to use next in pursuit of a defined goal. An agent plans an action, performs it, checks the result and adapts its approach. This loop continues until the task is complete or a predefined limit stops it.

The term does not have one universal definition. Anthropic offers a useful distinction in Building effective agents. In a workflow, program code determines the sequence. In an agent, the language model controls the sequence and selects tools dynamically.

An agent is not automatically autonomous or self-learning. People or software can approve every important step. The underlying model does not change by itself during operation. Persistent learning needs a separate process for stored experience, evaluation and model updates.

Chatbot, workflow or agent?

  • A chatbot is a text or voice interface. It may call one model, run a fixed workflow or operate an agent behind the interface.
  • An AI workflow uses AI within a fixed sequence. Code might first classify a document, then extract a field and finally save a draft.
  • An AI agent chooses the next permitted step based on the current result. It might search for missing data, call a tool again or ask a follow-up question.

Agents are not inherently better. Fixed workflows are easier to test, faster and usually cheaper. Agents fit tasks where the required path varies between cases. Anthropic recommends starting with the simplest approach that works and adding autonomy only when it earns its cost.

How does an AI agent work?

An agent needs more than a language model:

  1. Task and limits: The system receives a goal, rules and stop conditions.
  2. Context: The agent reads approved documents, database records or earlier results.
  3. Decision: The model selects the next action within its permissions.
  4. Tool: A defined interface searches data, updates a record or prepares a draft.
  5. Check: The agent evaluates the result, continues, stops or hands the case to a person.

Tools turn a text response into an action. The OpenAI practical guide to building AI agents distinguishes data tools, action tools and orchestration. A data tool might read an order from an ERP system. An action tool creates or changes a record and therefore needs stricter permissions.

Memory is optional. An agent can keep the current case in context or store selected information for later runs. The application must implement either capability explicitly.

A business process example

Consider a shared inbox for technical customer enquiries. An agent could:

  1. read the message and attachments,
  2. identify the product number and request,
  3. retrieve approved product data and previous cases,
  4. identify missing details,
  5. prepare a response and ticket assignment.

Sending remains blocked at first. An employee reviews the draft and triggers the external action. This human-in-the-loop design combines flexible processing with a clear control point.

The example also shows when an agent is unnecessary. If every message follows fixed rules into one of five inboxes, a classifier in a fixed workflow is enough. The added complexity of an agent only makes sense when research and processing steps vary.

Schmidt Embedded Systems develops AI agents for documents, processes and product data. Our AI Mux development log also shows how we coordinate several coding agents in our own work.

When is an AI agent useful?

A suitable use case usually has several of these traits:

  • The task has a clear goal, but the path varies.
  • Required information is spread across several approved systems.
  • A person currently searches, compares and chooses between next steps.
  • Concrete criteria can determine whether the result is correct.
  • Errors can be detected, reversed or stopped before an effective action.

An agent is a poor fit when fixed rules fully describe the process. It is also unsuitable when nobody can define a correct result or one error would cause immediate serious harm.

Our AI readiness guide for industrial companies provides a wider assessment of process, data, integration, risk and operation.

Limits and safeguards

An agent can produce plausible but incorrect intermediate results. Each additional tool also adds possible failure modes. Emails, documents and websites can contain manipulated instructions. NIST describes this risk as agent hijacking.

Practical safeguards include:

  • Give the agent only the data and actions required for its specific task.
  • Require approval for changes or external actions while their consequences remain uncertain.
  • Set hard limits for runtime, cost and tool calls.
  • Log inputs, tool calls and results.
  • Test complete outcomes with representative cases before launch and after changes.
  • Assign a person to take over when the system is uncertain, conflicted or unavailable.

The voluntary NIST AI Risk Management Framework recommends defining tasks, responsibilities and human oversight in advance. It also calls for realistic testing and continued monitoring in operation.

How to start

Start with one task and a limited set of tools. Let the agent read information and prepare drafts without changing production data. Test it against completed real cases. Measure correctness, human intervention and the time saved across the whole process.

Only then should the agent receive write access. Every new action needs its own acceptance test, permission and recovery path. If a fixed workflow produces the same result more reliably, use the fixed workflow.

Sources