Erik Caldwell
Connect on LinkedIn
Menu

The Topic Catalog · 2

Agentic AI

Last updated · 15 min read

2.1 What Is an AI Agent: Loops, Reasoning, Tool Use & Function Calling

Priority: Must Understand

Executive Definition: An AI agent is a system where a language model runs in a loop: observing state, reasoning about what to do next, calling external tools (functions, APIs, databases), and using the results to decide its next step: until it determines the task is done or hits a stopping condition. Function calling/tool use is the mechanical layer that lets the model request a specific action with structured arguments instead of just producing text. This is architecturally different from a single request-response LLM call.

Why It Matters: Nearly every "agent" product your teams build or buy is this loop with different guardrails around it. Understanding the loop lets you distinguish genuine agentic automation from a chatbot with a marketing label, and lets you ask precise questions about where the loop can go wrong (infinite loops, wrong tool selection, cost per turn).

What I Need to Understand:

  • The ReAct pattern (reason → act → observe → repeat) is the conceptual ancestor of nearly all current agent loops (Yao et al., 2022)
  • "Tool use" and "function calling" are the same underlying mechanism: the model outputs a structured call, your code executes it, the result is fed back into context
  • An agent's reliability is bounded by three things: how well tools are described/scoped, how good the model is at picking the right one, and how the harness handles errors and retries
  • More tools available to a model is not automatically better: overlapping or poorly documented tools degrade selection accuracy
  • Cost and latency scale with loop iterations, not just input size: a runaway loop is a cost and safety incident, not just an inconvenience

Questions I Should Be Able to Ask My Team:

  1. How many tools does this agent have access to, and how do we know the model reliably picks the right one as that number grows?
  2. What is the maximum number of loop iterations or tool calls before we force a stop, and what happens when that ceiling is hit mid-task?
  3. When a tool call fails or returns an unexpected result, does the agent retry blindly, escalate to a human, or silently proceed with bad data?

Technologies / Standards / Companies to Know: Anthropic Claude tool use/Agent SDK (Software Development Kit), OpenAI function calling/Assistants & Agents SDK, ReAct (academic origin), LangGraph, Model Context Protocol (as the interop layer for tools: see separate entry)

Recommended Learning:

Time Investment: 1 hour

2.2 Agent Architectures: Single-Agent, Multi-Agent & Orchestration Patterns

Priority: Must Understand

Executive Definition: Most production agent systems are not one model freelancing: they're composed from a small set of named patterns: prompt chaining, routing, parallelization, orchestrator-worker (a lead agent delegates to subagents and synthesizes results), and evaluator-optimizer (one model critiques another's output). A single autonomous agent, operating open-endedly, is the least common and highest-risk pattern in practice. Multi-agent systems trade higher token cost and coordination complexity for better task decomposition on broad, parallelizable work.

Why It Matters: Vendors and internal teams will describe almost anything as "multi-agent" because it sounds more advanced; knowing the actual patterns lets you evaluate whether the added complexity (and cost: Anthropic reports multi-agent research systems can use roughly 4x the tokens of a single chat interaction) is buying real capability or just overhead. This is the single highest-leverage vocabulary for challenging architecture decisions in this domain.

What I Need to Understand:

  • Workflows (predefined code paths orchestrating LLM calls) and agents (the LLM decides its own path) are a spectrum, not a binary: most reliable production systems today lean toward workflows with agentic pieces, not fully open-ended agents
  • Orchestrator-worker (a "lead" agent spawning subagents with separate context windows) is the dominant multi-agent pattern for research/analysis-style tasks; it works well for breadth-first, parallelizable problems and poorly for tasks requiring shared, tightly coupled state
  • Multi-agent systems are harder to debug and more expensive to run than single-agent systems, and Anthropic's own writeup is explicit that they used them only after establishing the added performance justified the cost
  • "Evaluator-optimizer" (model critiques another model's draft) is a distinct, useful pattern for quality-sensitive output, separate from task decomposition
  • There is no universal "best" architecture: the right pattern is a function of whether subtasks can be parallelized and whether they need shared context

Questions I Should Be Able to Ask My Team:

  1. Which named pattern is this system actually using, and why was a simpler single-agent workflow ruled out?
  2. What is the token/cost multiplier of this multi-agent design versus a single-agent equivalent, and did we measure whether the accuracy gain justifies it?
  3. How do subagents share state or hand off results, and what happens when two subagents produce conflicting outputs?

Technologies / Standards / Companies to Know: Anthropic (orchestrator-worker research system), OpenAI Agents SDK, LangGraph, Microsoft AutoGen/Semantic Kernel, CrewAI

Recommended Learning:

Time Investment: 1 hour

2.3 Long-Running, Computer-Use & Browser Agents

Priority: Should Understand

Executive Definition: These are agents that act directly on a computer's GUI or browser (clicking, typing, navigating) rather than calling clean APIs, and that run for extended periods (minutes to hours) rather than a single exchange. Anthropic's "computer use" and OpenAI's "Operator"/computer-using-agent (CUA) are the two production offerings; both work by having the model view screenshots and issue mouse/keyboard actions in a loop.

Why It Matters: Computer-use agents are the path to automating legacy systems and workflows with no API (which is most of the "professional/knowledge worker" surface area at a mid-size enterprise) but current benchmark data shows this capability is meaningfully behind API-based tool use in reliability, and leadership should not greenlight unattended production deployment on this basis alone.

What I Need to Understand:

  • On OSWorld 2.0, a long-horizon real-computer-use benchmark, the best frontier models complete only ~13–21% of tasks correctly on strict scoring as of mid-2026, and completion rates collapse toward zero as task length increases (arXiv 2606.29537): this is lab/benchmark evidence, not marketing
  • Failure modes are specific and dangerous for unattended use: agents lose track of task constraints over long horizons, spend little effort on self-correction, and the benchmark documented real incidents of credential leakage and unauthorized system changes
  • "Long-running" also refers to agentic coding/analysis sessions (not just GUI control) that persist for hours: these need the same session-management, checkpointing, and interruption-handling discipline as GUI agents
  • Browser agents (distinct from full computer-use) operate inside a sandboxed browser context, which narrows the attack/failure surface relative to full desktop control
  • Human oversight requirements should scale with task irreversibility and duration, not be uniform across all computer-use tasks

Questions I Should Be Able to Ask My Team:

  1. What benchmark or internal evaluation did we run before allowing this computer-use agent to touch a production system, and what was its measured success rate on tasks representative of our real workflows?
  2. What is the blast radius if this agent takes a wrong action mid-task (can it modify financial records, send external communications, or delete data) and is that reversible?
  3. For long-running sessions, how do we checkpoint progress so a failure at hour three doesn't require starting over, and who is notified when the agent stalls or goes off-task?

Technologies / Standards / Companies to Know: Anthropic Computer Use (Claude), OpenAI Operator / Computer-Using Agent (CUA), OSWorld benchmark, Claude Agent SDK

Recommended Learning:

Time Investment: 2-3 hours

2.4 Agent Memory & Persistent State

Priority: Should Understand

Executive Definition: LLMs have no memory beyond the tokens in their current context window; "agent memory" is the engineering layer built on top: compaction (summarizing history and discarding detail), external note-taking (the agent writes progress to a file or database it re-reads), retrieval systems that fetch relevant past information on demand, and dedicated memory stores that persist facts across sessions. There is no single standard implementation; this is an active area of custom engineering, not a solved commodity feature.

Why It Matters: Context window limits are the practical ceiling on how long or complex a single agent task can run without deliberate memory engineering, and getting this wrong is a leading cause of agents that "forget" earlier constraints, contradict earlier decisions, or silently drop requirements on long tasks: a direct quality and trust risk for anything customer-facing or high-stakes.

What I Need to Understand:

  • Context window is working memory, not storage: anything not explicitly persisted (to a file, database, or summary) is gone once the window fills or the session ends
  • Anthropic identifies three complementary techniques for long-horizon state: compaction (summarize and restart with compressed history), structured note-taking (external files like a running progress log the agent re-reads), and subagent architectures (offload exploration to agents with clean contexts, return only distilled summaries)
  • "Just-in-time" context retrieval (fetching data by reference (file path, query) at the moment it's needed rather than front-loading everything) is now considered better practice than stuffing the context window upfront
  • Persistent cross-session memory (the agent remembers a user or account across separate conversations) is a distinct, less mature capability from within-session state management, and raises its own data governance and consent questions
  • Vendor "memory" features vary widely in what they actually persist, for how long, and with what visibility/deletion controls: treat vendor claims here skeptically and ask for specifics

Questions I Should Be Able to Ask My Team:

  1. When this agent's task runs long, what specifically happens to earlier context: is it summarized, dropped, or written to external storage, and what's the risk of losing an early constraint?
  2. What cross-session memory does this system retain about a user or account, where is it stored, who can see it, and how is it deleted on request?
  3. Have we tested this agent on a task long enough to force compaction or context-window pressure, and did it still honor requirements stated early in the task?

Technologies / Standards / Companies to Know: Anthropic context engineering guidance, Amazon Bedrock AgentCore Memory, Mem0, LangGraph persistence/checkpointing

Recommended Learning:

Time Investment: 1 hour

2.5 Agent Sandboxes, Observability, Rollback & Idempotency

Priority: Must Understand

Executive Definition: Because agents take autonomous, sometimes-irreversible actions, production deployments require the same operational discipline as any high-risk automated system: sandboxing (isolating the agent's execution environment from production systems), observability (logging every reasoning step and tool call so failures can be diagnosed after the fact, not just the final output), rollback (the ability to undo an agent's actions), and idempotency (designing actions so repeating them (due to retries) doesn't cause duplicate side effects, like double-charging a customer).

Why It Matters: This is the operational infrastructure that separates a demo from something you can safely run against real systems; without it, an agent error is invisible until a customer or auditor finds it, and a retried action can silently compound the damage. This is exactly the kind of engineering rigor an executive should expect teams to show evidence of before approving production autonomy.

What I Need to Understand:

  • "Sandboxing" for agents (running in an isolated container/VM with scoped permissions) is a direct analog to least-privilege access control and should be treated as non-negotiable for any agent that can execute code or call write-access tools
  • Observability for agents means tracing the full reasoning chain and every tool call, not just input/output: because failures are often in the middle of a multi-step process, and standard application logs don't capture "why" the agent chose an action
  • Idempotency matters specifically because agents retry: a network timeout that causes a tool call to be re-issued must not double-book, double-charge, or double-send: this is a design requirement on the tools the agent calls, not on the agent itself
  • Rollback/undo capability should be evaluated per-tool: some actions (sending an email, external API calls) are inherently non-reversible and need a different control (pre-approval) rather than a rollback plan
  • This tooling category (agent-specific observability/tracing platforms) is still maturing and fragmented across vendors: there is no dominant standard yet, so expect to evaluate and possibly switch

Questions I Should Be Able to Ask My Team:

  1. Can we reconstruct, after the fact, the full chain of reasoning and tool calls that led to a specific agent action: not just its final output?
  2. Which of this agent's actions are idempotent, which are irreversible, and what's the control (retry-safe design vs. mandatory pre-approval) for each category?
  3. What sandbox boundary is this agent running inside, and what's the actual blast radius if it's compromised or goes wrong: what could it touch that it shouldn't?

Technologies / Standards / Companies to Know: OpenTelemetry (GenAI semantic conventions), Anthropic/OpenAI agent tracing tooling, LangSmith, container/VM sandboxing (Docker, Firecracker-style microVMs), Amazon Bedrock AgentCore

Recommended Learning:

Time Investment: 1 hour

2.6 Human Approval, Delegated Authority & Autonomy Levels

Priority: Must Understand

Executive Definition: This is the design question of how much an agent is allowed to do without a human checking first: ranging from full pre-approval of every action, to approval only for high-risk/irreversible actions, to full autonomy with post-hoc monitoring. Anthropic's own measurement research found this is not well captured by rigid tiers; what matters operationally is whether a human is in a genuine position to monitor and intervene, not whether a specific interaction pattern (e.g., "approve every step") is mandated.

Why It Matters: Getting this wrong in either direction is costly: over-gating creates enough friction that agents deliver no efficiency gain (a documented driver of the well-known finding that most enterprise GenAI pilots fail to show ROI), while under-gating creates real financial, legal, and safety exposure. This is a governance decision, not just an engineering one, and it belongs on your desk.

What I Need to Understand:

  • Anthropic's internal telemetry (Claude Code usage, Oct 2025–Jan 2026) found experienced users move toward higher auto-approval rates over time (roughly 20% to 40%+) while simultaneously increasing how often they interrupt the agent: a shift from per-action approval to active monitoring, not a simple "trust more, watch less" pattern
  • Mandating human approval on every single action does not reliably produce better safety outcomes and can just add friction without benefit: the effective lever is quality of visibility and ease of intervention, not the presence of a checkpoint
  • Delegated authority should be scoped per action-class by reversibility and stakes (e.g., "can read customer records" vs. "can issue a refund"), not as a single global autonomy dial for the whole agent
  • Well-designed agents increasingly ask clarifying questions themselves when uncertain, rather than guessing: this is a design signal worth requiring from vendors and internal teams, not just a nice-to-have
  • "Autonomy level" frameworks differ by vendor and are not standardized industry-wide: treat any vendor's "Level 3 autonomous" claim as marketing shorthand until you see the actual approval logic

Questions I Should Be Able to Ask My Team:

  1. For this agent, which specific action categories require human pre-approval, which allow autonomous execution with post-hoc audit, and what was the reasoning for that split?
  2. Do we have real visibility into what the agent is doing while it runs (not just its final report), and could a person actually intervene mid-task if something looked wrong?
  3. What happens when the agent itself is uncertain: does it ask a clarifying question, guess, or stop, and how often is each of those observed in practice?

Technologies / Standards / Companies to Know: Anthropic autonomy/oversight research, OpenAI Agents SDK (guardrails/handoffs), enterprise agent-governance platforms (Strata, etc.)

Recommended Learning:

Time Investment: 1 hour

2.7 Where Agents Beat vs Lose to Deterministic Software

Priority: Must Understand

Executive Definition: Deterministic software (fixed code paths, explicit business logic) is faster, cheaper, fully predictable, and easier to audit, but only for tasks you can fully specify in advance. Agents earn their cost premium and unpredictability only on tasks with open-ended judgment, ambiguous inputs, or paths that can't be fully enumerated at design time. The core management error is applying agents to well-specified, high-volume, deterministic tasks (worse cost and reliability than code) or applying rigid deterministic pipelines to genuinely ambiguous tasks (constant manual exception-handling).

Why It Matters: This single judgment call: agent vs. workflow vs. plain code: is where most wasted enterprise AI spend and most avoidable production incidents originate; an executive who can push back on "let's make it an agent" by default is directly protecting both budget and reliability.

What I Need to Understand:

  • Anthropic's own guidance is explicit: "find the simplest solution possible, and only increase complexity when needed": a fixed workflow is preferred whenever the task's steps and rules can be predetermined
  • Deterministic code wins on: cost per execution at volume, latency, testability (you can write unit tests with known correct answers), and auditability (the logic is inspectable, not inferred from model weights)
  • Agents win on: tasks with combinatorially many valid paths, unstructured input requiring judgment (interpreting a customer's freeform complaint), or environments that change too often to hardcode rules for
  • The "hybrid" pattern (deterministic code handling the guaranteed steps, with an agent invoked only for the genuinely ambiguous decision point) is usually the right default, not a compromise
  • The MIT-linked 2025 finding that roughly 95% of enterprise generative AI pilots failed to show measurable P&L return is frequently attributed to organizations deploying general-purpose agentic tools on tasks that needed workflow rigor, integration, and process redesign, not model capability

Questions I Should Be Able to Ask My Team:

  1. Could this task be done with deterministic code plus a small number of well-defined exception cases, and if not, what specifically makes it too ambiguous to hardcode?
  2. What would this cost and how would its error rate compare if we built it as a fixed pipeline instead of an agent, and did we actually run that comparison?
  3. Where in this system is an agent doing something a rules engine or a straightforward API integration could do more cheaply and more predictably?

Technologies / Standards / Companies to Know: N/A (conceptual/architectural judgment, not a specific product category)

Recommended Learning:

  • Building Effective AI Agents: Anthropic: states directly that the simplest workflow should be preferred and agentic complexity added only when justified.
  • MIT report: 95% of generative AI pilots at companies are failing: widely-cited 2025 MIT-linked field data on enterprise GenAI pilot ROI failure, useful context for why the workflow-vs-agent decision matters financially. (Treat the 95% figure as directionally important, not a precise statistic: press coverage varies in how it characterizes MIT's underlying methodology.)

Time Investment: 30 minutes