Agentic AI

Agentic AI systems let an LLM plan, call tools, and act over multiple steps toward a goal, instead of answering in one shot. The core design decisions interviews probe are single- vs multi-agent, ReAct vs plan-then-execute, how much autonomy vs human-in-the-loop, and how many tools to expose.

What is Agentic AI?

Agentic AI refers to systems where an LLM operates autonomously, reasoning about goals, making decisions, invoking tools, and iterating on its outputs without step-by-step human guidance. Unlike a single prompt-response interaction, an agent loops: it observes, thinks, acts, and observes again until the task is complete.

Core Agent Loop

The fundamental pattern is Observe → Think → Act → Observe:

Observe: the agent receives a task or new information (user input, tool output, environment state)
Think: the LLM reasons about what to do next, often producing a chain-of-thought
Act: the agent calls a tool, writes code, searches the web, or produces a final answer
Observe: the result of the action feeds back into the loop

This loop continues until the agent determines the task is complete or a termination condition is met (max steps, budget, timeout).

Tool Use

Tools are the bridge between LLM reasoning and real-world action. A tool is a function the agent can call: web search, code execution, database queries, API calls, file I/O, or even other LLMs.

Function calling (structured tool use) is now the standard interface: the LLM outputs a structured JSON tool call, the runtime executes it, and the result is fed back. This replaced earlier regex-based parsing of free-text tool invocations.

Tool design principles:

Each tool should do one thing well with a clear, typed interface
Tool descriptions are part of the prompt, so they must be concise and unambiguous
Provide error messages that help the agent self-correct
Limit the number of tools to avoid decision paralysis (typically 5 to 15)

The Model Context Protocol (MCP)

Function calling tells you how a model emits a tool call, but not where the tools live or how they're served. Before MCP, every agent app hand-wrote a custom integration for every tool — an M×N problem: M agents times N tools equals M·N bespoke connectors. The Model Context Protocol (Anthropic, open-sourced Nov 2024) collapses that to M+N: each tool is wrapped once as an MCP server, and any MCP-compatible client can use it with zero custom code. It's often described as "USB-C for AI tools" — a universal port. It has become the default integration layer, adopted across Claude, Cursor, Windsurf, OpenAI's Agents SDK, and most agent frameworks.

The three primitives an MCP server can expose:

Tools — functions the model can call (search, run code, query a DB). Model-controlled.
Resources — read-only data the client can pull into context (files, records, docs). App-controlled.
Prompts — reusable, parameterized prompt templates the server offers (e.g. a "summarize PR" workflow). User-controlled.

Architecture. A host application (the AI app) runs one client per server connection; each server is an independent process — a local subprocess or a remote service. One client talks to exactly one server, so capabilities stay isolated and composable.

Transports. Messages are JSON-RPC 2.0. Two standard transports: stdio (the server is a local subprocess; the client reads/writes its stdin/stdout — fast, no network) and Streamable HTTP (remote servers, with Server-Sent Events for streaming; superseded the older HTTP+SSE transport in the 2025 spec).

Lifecycle. A session is a fixed handshake: (1) initialize — client sends its protocol version and capabilities; (2) capability negotiation — the server replies with what it offers (tools/resources/prompts) and the client acknowledges; (3) discovery — the client calls tools/list (and resources/list) to fetch the catalog, whose descriptions and JSON schemas enter the model's context; (4) invocation — the model decides, and the client sends tools/call; (5) the result is fed back into the model's context, and the loop continues.

Security — the part interviews probe. MCP widens the attack surface because a server is untrusted input the model reads and acts on:

Tool-description / prompt injection: the server controls its tool descriptions, and those strings land in the model's prompt. A malicious server can smuggle instructions ("also run DROP TABLE…") the model may follow. Treat server metadata as untrusted; review or sandbox third-party servers.
Confused deputy: the agent holds broad credentials and can be tricked into using them on an attacker's behalf. Defend with least-privilege scoping — grant each server only the permissions it needs, and gate destructive tools behind explicit human approval.
Token/secret handling: OAuth tokens and API keys pass through the host; leaking or over-scoping them is a common failure.

MCP vs function calling — they compose, not compete: function calling is the model emitting a structured call; MCP is the transport + discovery standard for where those tools live. MCP tools surface to the model as ordinary callable functions.

Planning and Reasoning

Agents must break complex tasks into steps. Key approaches:

ReAct (Reasoning + Acting) interleaves chain-of-thought reasoning with tool calls. The agent thinks step-by-step, acts, observes, and adjusts. Simple and effective for many tasks.

Plan-then-Execute: the agent first generates a full plan (a list of steps), then executes each step. Better for long-horizon tasks but plans can become stale as new information emerges.

Reflection / Self-Critique: after producing an output, the agent critiques its own work and iterates. Reflexion extends this with episodic memory of past attempts.

Tree-of-Thought explores multiple reasoning paths in parallel or sequentially, evaluating and pruning branches. More compute-intensive but better for problems with many valid approaches.

Memory

Agents need memory beyond the context window:

Short-term memory: the conversation history and scratchpad within the current session
Long-term memory: persisted knowledge across sessions, stored in vector databases or structured stores
Episodic memory: records of past task attempts and their outcomes, enabling learning from experience

Context window management is critical: as agents loop, the context fills up. Strategies include summarization of earlier steps, sliding windows, and hierarchical memory with retrieval.

Multi-Agent Systems

Complex tasks can be decomposed across multiple specialized agents:

Orchestrator pattern: a lead agent delegates subtasks to specialist agents (researcher, coder, reviewer)
Debate/consensus: multiple agents propose solutions and critique each other
Pipeline: agents form a chain, each processing and passing results to the next
Swarm: agents self-organize around tasks without a central coordinator

Frameworks: CrewAI, AutoGen, LangGraph, OpenAI Swarm.

Harness vs Agent Loop

It's worth separating two things that often get conflated. The patterns above (ReAct, Plan-and-Execute, LLM Compiler, reflection, multi-agent orchestration) are agent loops: the in-context reasoning and tool-use behavior of the model. The harness is everything that wraps the loop: the curated environment, the persistent state files (AGENTS.md, progress files), the verification gates that decide "done", the trajectory store that lets you debug a session, and the cleanup discipline that leaves the environment usable for the next run. The same agent loop can ship at radically different reliability depending on the harness around it; this is the gap between a SWE-bench score of 22% and 50%+ with identical model weights. See Harness Engineering for the four-pillar framing (environment, state, verification, observability) and the failure modes the harness exists to prevent.

Evaluation and Safety

Agent evaluation is harder than single-turn LLM eval because you must assess multi-step trajectories:

Task completion rate: did the agent achieve the goal?
Efficiency: how many steps/tokens/tool calls did it take?
Error recovery: did the agent handle failures gracefully?
Safety: did the agent stay within its authorized scope?

Guardrails are essential: tool permission scoping, budget limits (max tokens, max API calls), human-in-the-loop approval for high-stakes actions, and output validation.