{"title":"What Is Agentic AI?","description":"","content":"Building an agent that calls a weather API and returns an answer is straightforward. Building one that navigates a 500-file codebase, writes a fix, and iterates until tests pass is a completely different problem.\n\nThe gap between a demo agent and a production agent is enormous. Real-world agents deal with messy environments (screenshots, codebases, web pages instead of clean APIs), long time horizons (minutes to hours instead of seconds), and high-stakes actions (executing code and writing files instead of just generating text).\n\nThis chapter defines what \"agentic AI\" means as a systems-level concept, introduces the specialized agent types you will build in this module, and gives you a framework for deciding when you actually need an autonomous agent versus a simpler pattern.\n\n---\n\n# From Agent Loops to Agentic Systems\n\nYou already know the core agent loop: the model receives a prompt, decides whether to call a tool, observes the result, and repeats until it has a final answer. That loop is the engine. But an engine is not a car.\n\nAn agentic system is what you get when you wrap that engine in everything it needs to operate in the real world. The agent loop handles reasoning and tool calling. The agentic system handles everything else: how the agent perceives complex environments, how it persists state across long runs, how it communicates with other agents and tools through standardized protocols, and how you keep it from doing something dangerous.\n\nThink of it as five layers stacked on top of each other:\n\n\n```mermaid\nflowchart LR\n A[\"Agent Core
Reasoning + Tool Calling\"]:::primary\n B[\"Environment Layer
Screenshots, Code, Web Pages\"]:::orange\n C[\"Persistence Layer
Checkpoints, Memory, Context Management\"]:::teal\n D[\"Communication Layer
MCP, A2A, Tool Discovery\"]:::rose\n E[\"Security Layer
Sandboxing, Permissions, Audit Logs\"]:::red\n\n A --> B\n B --> C\n C --> D\n D --> E\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n classDef rose fill:#f783ac,stroke:#000,color:#000\n classDef red fill:#ff8787,stroke:#000,color:#000\n```\n\n\nIf you have built basic agents before, you already have the top layer. This module builds the rest. Each chapter addresses a specific combination of these layers, and by the end you will understand how they fit together into systems that can operate autonomously for extended periods.\n\nThe key mental shift is this: for basic agents, the hard problem is getting the LLM to reason correctly. For agentic systems, the hard problem is everything around the LLM. The reasoning loop is table stakes. What makes or breaks a real-world agent is whether it can recover from crashes, stay within its security boundaries, manage a context window that fills up after an hour of work, and interact with environments that were never designed for AI.\n\n---\n\n# The Three Shifts: What Makes Real-World Agents Different\n\nBasic agents operate in a comfortable world: clean API inputs, short interactions, low-stakes outputs. Real-world agents face a fundamentally different set of challenges. Let's break down the three shifts.\n\n### Unstructured Environments\n\nBasic agents call tools with well-defined JSON schemas. A weather API returns temperature as a number. A database query returns rows. The agent never has to figure out what it is looking at.\n\nReal-world agents interact with environments that were designed for humans, not machines. A computer use agent stares at a screenshot and has to figure out which pixel region is a \"Submit\" button. A coding agent opens a file and has to understand how it fits into a 500-file repository. A research agent reads a blog post and has to decide whether the author is credible or just confidently wrong.\n\nThis means perception becomes a first-class problem. Before the agent can reason about what to do, it has to figure out what it is looking at. And unlike APIs, the answer changes constantly: UIs get redesigned, codebases evolve, web pages have different layouts on different days.\n\n### Long Time Horizons\n\nA basic agent typically completes its task in one conversation turn, maybe two. The context window never fills up. The process never crashes. Cost is negligible.\n\nProduction agents run for minutes, sometimes hours. A deep research agent might make 50+ web searches and read 100+ pages before producing a report. A coding agent might iterate through 10 rounds of edit-test-fix before arriving at a working solution. This introduces problems that simply do not exist in short-lived agents: context windows overflow, processes crash and need to resume, API costs accumulate to real money, and the user needs progress updates because they cannot just sit and wait.\n\n### High-Stakes Actions\n\nBasic agents mostly generate text. The worst case is a bad answer. Real-world agents take actions that are difficult or impossible to reverse. A coding agent writes files and executes shell commands. A computer use agent clicks buttons and submits forms. A research agent might access internal documents and synthesize information that gets presented to executives.\n\nThis means security is not optional. You need sandboxing, permission models, audit logging, and kill switches. You need to think about what happens when the agent is wrong, not just inaccurate, but actively destructive.\n\nHere is how these shifts compare across specific dimensions:\n\n\n| Dimension | Basic Agents | Real-World Agents |\n|-----------|-------------|-------------------|\n| **Environment** | Clean APIs, JSON schemas | Screenshots, codebases, web pages |\n| **Task duration** | Seconds to minutes | Minutes to hours |\n| **Context usage** | Small fraction of window | Multiple context windows |\n| **Risk level** | Bad text output | File writes, code execution, network requests |\n| **Failure mode** | Wrong answer | Crash, data loss, security breach |\n| **Cost per task** | Fractions of a cent | Dollars to tens of dollars |\n\n\n---\n\n# A Taxonomy of Specialized Agents\n\nGeneral-purpose agent patterns are a solid foundation. This module introduces three specialized agent types, each optimized for a particular kind of environment. They share the same underlying reasoning loop, but their perception-action cycles are fundamentally different.\n\n### Computer Use Agents\n\nThese agents interact with software through its graphical interface. The loop is: capture a screenshot, send it to a vision model, decide where to click or type, execute the action, observe the result. They are the automation tool of last resort, useful when the target system has no API, no CLI, no programmatic interface at all.\n\nThe challenge is fragility. Pixel coordinates shift when windows resize. Layouts change between software versions. A pop-up dialog can derail an entire workflow. But when the alternative is rebuilding a legacy system or hiring someone to click buttons all day, computer use agents earn their keep.\n\n### Coding Agents\n\nCoding agents read, write, and execute code. The loop is: understand the task, search the codebase for relevant files, make an edit, run the tests, and iterate if something breaks. Products like Claude Code and Cursor have demonstrated that this loop can handle real software engineering tasks, from bug fixes to feature implementations.\n\nThe challenge is codebase understanding. A 500-file repository has complex dependency chains, implicit conventions, and context that does not fit in a single prompt. Coding agents need strategies for indexing repositories, scoring file relevance, and managing context windows that fill up fast when you are reading source code.\n\n### Deep Research Agents\n\nResearch agents search the web, read documents, and synthesize findings into structured reports. The loop is: generate search queries, retrieve results, read and extract claims, cross-reference across sources, and compile everything into a coherent output with citations.\n\nThe challenge is information quality. Not every source is reliable. Claims contradict each other. The agent needs to assess credibility, handle conflicting information gracefully, and produce reports that a human can verify by following the citations back to the original sources.\n\nDespite their different environments, all three agent types converge on shared infrastructure:\n\n\n```mermaid\nflowchart TD\n subgraph Specialized Agents\n CUA[\"Computer Use Agent
Screenshot → Click → Observe\"]:::primary\n CA[\"Coding Agent
Read → Edit → Test\"]:::primary\n DRA[\"Deep Research Agent
Search → Read → Synthesize\"]:::primary\n end\n\n subgraph Shared Infrastructure\n PROTO[\"Agent Protocols
MCP + A2A\"]:::orange\n PERSIST[\"Persistence
Checkpoints + Context Mgmt\"]:::teal\n SEC[\"Security
Sandboxing + Permissions\"]:::red\n end\n\n CUA --> PROTO\n CA --> PROTO\n DRA --> PROTO\n PROTO --> PERSIST\n PERSIST --> SEC\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n classDef red fill:#ff8787,stroke:#000,color:#000\n```\n\n\nThis is the structure of the module: three specialized agent types on top, three infrastructure chapters underneath, and a capstone chapter that ties everything together with production patterns.\n\n---\n\n# The Infrastructure Layer\n\nSpecialized agents get the attention, but the infrastructure underneath them is what makes the difference between a demo and a production system. Three infrastructure concerns cut across every agent type in this module.\n\n### Agent Protocols: MCP and A2A\n\nMost agent tutorials show you connecting a single agent to a few MCP servers with hardcoded configurations. That works for a prototype, but production agent systems need dynamic tool discovery. An agent working on a coding task needs to find and connect to a Git server, a test runner, and a file system server, without someone manually configuring each connection.\n\nMCP (Model Context Protocol) handles the agent-to-tool relationship: how agents discover, authenticate with, and call external tools. A2A (Agent-to-Agent) handles the agent-to-agent relationship: how a research agent delegates fact-checking to a specialized fact-checking agent, or how a coding agent asks a testing agent to validate its changes.\n\nTogether, these protocols turn a collection of isolated agents into a coordinated system where capabilities can be composed dynamically.\n\n### Long-Running Execution\n\nA research agent that searches 50 sources and reads 100 pages will run for 20 to 30 minutes. A coding agent debugging a complex issue might iterate for an hour. These agents need infrastructure that short-lived agents never think about.\n\nCheckpointing lets an agent save its progress so it can resume after a crash. Context management strategies (summarization, sliding windows, hierarchical memory) keep the agent functional as its conversation history grows beyond the context window. Progress reporting keeps the user informed. Cost tracking prevents a runaway agent from burning through your API budget.\n\n### Security and Sandboxing\n\nEvery agent in this module takes actions in the real world: clicking buttons, writing files, executing code, making network requests. Each of these is an attack surface. A prompt injection hidden in a web page could tell your research agent to exfiltrate API keys. A malicious GitHub issue could trick your coding agent into running destructive commands.\n\nDefense in depth means layering multiple security controls: sandboxed execution environments (Docker, microVMs), least-privilege permission models, network isolation, audit logging, and kill switches. No single control is sufficient. The goal is that even if one layer fails, the others catch the problem before real damage occurs.\n\n\n```mermaid\nflowchart TD\n subgraph Agent Types\n A1[\"Computer Use\"]:::primary\n A2[\"Coding\"]:::primary\n A3[\"Research\"]:::primary\n end\n\n subgraph Protocols\n MCP[\"MCP
Tool Discovery + Calling\"]:::orange\n A2A[\"A2A
Agent Communication\"]:::orange\n end\n\n subgraph Persistence\n CP[\"Checkpointing\"]:::teal\n CTX[\"Context Management\"]:::teal\n COST[\"Cost Tracking\"]:::teal\n end\n\n subgraph Security\n SB[\"Sandboxing\"]:::red\n PERM[\"Permissions\"]:::red\n AUDIT[\"Audit Logging\"]:::red\n end\n\n A1 --> MCP\n A2 --> MCP\n A3 --> MCP\n A1 --> A2A\n A2 --> A2A\n A3 --> A2A\n\n MCP --> CP\n A2A --> CP\n MCP --> CTX\n A2A --> CTX\n\n CP --> SB\n CTX --> SB\n CP --> PERM\n CTX --> PERM\n SB --> AUDIT\n PERM --> AUDIT\n COST --> AUDIT\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n classDef red fill:#ff8787,stroke:#000,color:#000\n```\n\n\n---\n\n# Choosing the Right Agentic Pattern\n\nNot every problem needs a fully autonomous agent. One of the most common mistakes in AI engineering is reaching for an agent when a simpler pattern would work better. More autonomy means more latency, more cost, more failure modes, and more security surface area. The right question is always: what is the minimum level of autonomy this task requires?\n\nThere are three levels to choose from:\n\n**Pipeline:** A fixed sequence of LLM calls with no branching or looping. The system does not decide what to do next; you hardcode the flow. Use this when the steps are predictable and the same every time. Example: extract data from an email, classify it, generate a response template.\n\n**Supervised agent:** The agent reasons and selects tools, but a human approves critical actions before they execute. The agent handles the thinking, the human handles the risk. Use this when actions are high-stakes but the reasoning is too complex to hardcode. Example: a coding agent that proposes changes but waits for developer approval before committing.\n\n**Autonomous agent:** The agent runs independently, making decisions and taking actions without human intervention. Use this only when the task is long-running, the action space is well-sandboxed, and the cost of errors is manageable. Example: a research agent that searches the web and produces a report, operating entirely within a read-only environment.\n\n\n```mermaid\nflowchart TD\n START[\"New Task\"]:::primary --> Q1{\"Are the steps
predictable?\"}:::yellow\n Q1 -->|Yes| PIPELINE[\"Use a Pipeline
Fixed sequence, no loops\"]:::green\n Q1 -->|No| Q2{\"Are actions
high-stakes?\"}:::yellow\n Q2 -->|Yes| Q3{\"Can you sandbox
the environment?\"}:::yellow\n Q3 -->|No| SUPERVISED[\"Supervised Agent
Human approves actions\"]:::orange\n Q3 -->|Yes| Q4{\"Is the task
long-running?\"}:::yellow\n Q4 -->|No| SUPERVISED\n Q4 -->|Yes| AUTONOMOUS[\"Autonomous Agent
Full autonomy, sandboxed\"]:::teal\n Q2 -->|No| AUTONOMOUS\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef yellow fill:#ffd43b,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n```\n\n\nThe default should be the simplest option that works. Start with a pipeline. If you need dynamic decision-making, add an agent loop. If the agent takes risky actions, add human oversight. Only go fully autonomous when you have the sandboxing and monitoring infrastructure to support it.\n\n---\n\n# A Minimal Agentic System in Python\n\nTo make the architecture concrete, here is a skeleton that shows all five layers in about 30 lines. This is not a production system. It is a map of the territory, showing where each chapter's content plugs in.\n\n\n**main.py**\n\n```python\nimport json\nfrom datetime import datetime\n\ndef run_agent(task: str, max_steps: int = 10):\n context = []\n checkpoint_file = f\"checkpoint_{hash(task)}.json\"\n\n # Persistence layer (Chapter 18.5)\n context = load_checkpoint(checkpoint_file)\n\n for step in range(len(context), max_steps):\n # Environment layer (Chapters 18.1-18.3)\n observation = perceive_environment(task, context)\n\n # Agent core (reasoning + planning)\n action = reason_and_plan(observation, context)\n\n # Security layer (Chapter 18.6)\n if not is_action_permitted(action):\n context.append({\"step\": step, \"blocked\": action})\n continue\n\n # Communication layer (Chapter 18.4)\n result = execute_via_protocol(action) # MCP tool call or A2A delegation\n\n context.append({\"step\": step, \"action\": action, \"result\": result})\n\n # Persistence layer (Chapter 18.5)\n save_checkpoint(checkpoint_file, context)\n\n if is_task_complete(result):\n return compile_result(context)\n\n return compile_result(context) # Return best effort after max_steps\n```\n\n\nEach function in this skeleton is a stub that an entire chapter will replace:\n\n- `perceive_environment()` is the perception loop whether that means taking a screenshot, reading a file, or fetching a web page.\n- `reason_and_plan()` is the agent core, the reasoning loop that decides what to do next.\n- `is_action_permitted()` is the security model from Chapter 18.6, checking permissions before every action.\n- `execute_via_protocol()` is the communication layer from Chapter 18.4, calling tools via MCP or delegating to other agents via A2A.\n- `save_checkpoint()` and `load_checkpoint()` are the persistence layer enabling crash recovery.\n\nThe power of this architecture is that you can swap out any layer independently. Replace the perception function to move from a coding agent to a computer use agent. Tighten the permission check to increase security. Add a more sophisticated checkpointing strategy for longer runs. The layers are independent, but the system only works when all of them are in place.\n\n---\n\n### Further Reading\n\n- [Building Effective Agents](undefined) - Anthropic's guide to agent architectures and patterns\n- [Model Context Protocol Specification](undefined) - The MCP specification for agent-to-tool communication\n- [Google A2A Protocol](undefined) - Google's Agent-to-Agent communication protocol\n- [The Landscape of Emerging AI Agent Architectures](undefined) - Survey of agent design patterns and architectures\n- [Practices for Governing Agentic AI Systems](undefined) - OpenAI's whitepaper on agent safety and governance","pageType":"ai-engineering"}

What Is Agentic AI?

Ashish Pratap Singh

Get Premium