#184 — How Agentic AI works

A workflow follows a fixed, pre-programmed sequence of steps. An agent decides its own sequence at runtime — it perceives its environment, reasons about what to do next, acts, and loops back until the goal is met. The practical implication: workflows are predictable and auditable but brittle when inputs vary. Agents are flexible but require explicit stop conditions and failure-mode detection or they'll loop indefinitely and burn your token budget.

The agent loop is the repeating cycle a harness runs within a single agent turn: assemble context → invoke the model to reason → act on its decision → repeat until a stop condition ends the run. It exists because long-horizon tasks — research, coding, multi-step workflows — cannot be completed in a single LLM call. Each iteration appends its trace (assistant messages, tool outputs, state updates) back into context before the next reasoning step begins.

The three modes are Assistant (multi-turn tasks requiring memory of prior context), Deep Research (iterative search, synthesis, and gap-filling across multiple sources), and Coding (edit, run tests, observe failure, edit again until the build passes). In each case, the task requires reasoning across multiple steps where the output of one step informs the next — impossible in a single LLM call. Claude Code, Codex, and Cursor all operate in coding mode.

Swapping GPT-4o for Claude Sonnet or Gemini Ultra in most production agents changes outcomes far less than fixing the harness around it. The harness — context assembly, memory reads, tool routing, stop conditions, failure detection — determines what the model sees and when it stops. Most production agent failures (repeated tool calls, lost context, inconsistent sessions) are harness failures, not model failures. Budget accordingly: more engineering time in the harness, less time benchmarking models.

Define explicit stop conditions in the harness. Common patterns: the model produces a final response with no pending tool calls, a goal-completion predicate returns true, a maximum iteration count (10 is the standard default) is reached, a wall-clock timeout expires, an unrecoverable error occurs, or a repetition detector fires — meaning the agent called the same tool with identical arguments 3× in a row. A well-instrumented harness catches that last pattern and exits with a diagnostic instead of burning remaining iterations on a stalled run.

No — and this is a common production mistake. A terminal message (no further tool calls) means the model has stopped emitting actions. It does not mean the user's goal is satisfied. The harness is responsible for verifying goal completion, not the model. The model may return a partial result, a clarifying question, or a response that requires follow-up. This distinction becomes critical as tasks grow longer and more complex — goal completion checks belong in the harness, not in whether the model stopped talking.

A memory-augmented agent retrieves and injects information into context — memory happens to it passively. A memory-aware agent treats memory as a first-class concern: it actively encodes, stores, retrieves, injects, and forgets — managing its own cognitive state within each run and across sessions. The practical difference shows up at scale: memory-augmented agents accumulate stale, irrelevant context over time. Memory-aware agents prune and update, improving retrieval quality rather than degrading it.

The six types are: Conversational (prior chat history, retrieved by thread ID via SQL — exact lookup, no vector search), Knowledge base (retrieved documents and facts, retrieved by vector similarity), Workflow (learned action patterns and tool sequences, retrieved by semantic similarity), Toolbox (vector-indexed tool definitions enabling semantic discovery), Entity (extracted people, places, and systems persisted across sessions), and Summary (compressed context for long conversations, with on-demand expansion). You need conversational memory from your first multi-turn product. You need the rest as session complexity and user count grow.

Context window monitoring tracks token usage across iterations to detect when compaction is needed before the window fills and performance degrades, not after. Without it, long-running agents silently hit context limits mid-task and produce truncated or incoherent outputs. Watching whether token counts stabilize across runs also tells you whether your context engineering is actually working. It's a primitive but important observability signal — the equivalent of watching memory usage in a long-running server process.

Conversation compaction replaces verbose chat history with compressed summaries once the context window comes under pressure. The key is to never delete originals — instead, mark messages with a summary_id in the database and keep the full record available for audit and on-demand expansion. The agent loads only the compact summary by default; when it needs the full content (for audit, follow-up, or debugging), it expands by ID. OpenAI's Codex agent uses this pattern explicitly for long multi-step coding runs.

Tool output offloading means persisting full tool results to a log table and replacing them in context with a compact one-line reference (e.g., '[Tool Log ID: 47] Results stored. Call read_tool_log to retrieve.'). Without it, a single web search returning 3,000–4,000 tokens gets carried forward in every subsequent iteration, compounding fast. With offloading, the model only sees the reference until it explicitly needs the content. For a 10-iteration run with 5 search calls, this can reduce per-session token consumption by 60–80%.

Semantic tool discovery means using vector search to retrieve only the tools relevant to the current query, rather than passing every tool schema to the model on every call. Tool selection accuracy measurably degrades past roughly 10–15 tool definitions passed simultaneously, and token costs climb regardless of relevance. The fix is a vector-indexed tool registry with LLM-enriched metadata — embeddings that capture intent and use case, not just function names — so only the 3–5 most relevant tools are surfaced per query.

Assign each tool call a stable idempotency key before execution — typically a hash of the tool name, arguments, and session context. When the harness retries on a network error or rate limit, it passes the same key. The downstream service (payment processor, database write, email sender) uses that key to detect and skip duplicate calls. Without idempotency, a transient API failure on a payment tool can result in double charges. Build this in from day one — retrofitting it after a production incident is far more expensive.

Most LLM providers (Anthropic, OpenAI, Google) implement prefix-based prompt caching: if the opening of your prompt is identical to a recent request, the provider reuses cached computation — reducing latency by 40–80% and cost by 50–90% on cached tokens. Breaking prefix stability — by rewriting earlier messages to clean history or inject inline instructions — destroys cache hit rates. The correct pattern: append new instructions to the end of your message history, never modify existing messages. OpenAI's Codex agent explicitly preserves old prompts as exact prefixes of new prompts to maintain this benefit across long runs.

Token costs compound fast because each iteration carries the full accumulated context. A 10-iteration run on a 128K-context model can consume 500K–1M tokens per user session without tool output offloading or conversation compaction. At GPT-4o pricing (~$2.50/1M input tokens), that's $1.25–$2.50 per session. At 10,000 daily sessions, that's $12,500–$25,000/month before any engineering mitigation. Context engineering — compaction, tool log offloading, semantic tool retrieval — is directly a margin lever, not just a performance concern.

Design pause conditions in advance, not reactively. The right pause points are wherever the agent lacks the authority, context, or accountability to proceed — not wherever it's uncertain. Examples: approving a financial transaction, sending an external communication, deleting production data, or making a decision requiring legal judgment. When the agent pauses, it must surface a specific blocking question. An agent asking 'What should I do next?' is a UX failure. An agent asking 'The invoice total ($14,300) exceeds your auto-approve threshold. Approve or reject?' is a product.

The training loop is the cycle that produced the model: data collection, gradient updates, evaluation, release. It runs offline over days or weeks on fixed datasets. The agent loop runs online in real time on live interactions. Today they are decoupled — weights are frozen and the agent loop runs on top of them. What looks like an agent 'learning' within a session is retrieval from memory, not weight updating. This boundary defines what memory engineering can solve vs. what requires retraining — a critical distinction before you promise customers an agent that 'learns.'

Every action the agent takes produces feedback: tool results, user corrections, system-level metrics like hallucination rate, task completion, and citation accuracy. At Level 3, a well-instrumented harness makes the feedback loop explicit. More sophisticated systems route evaluation signals back into memory stores, marking retrieved content as reliable or unreliable based on downstream outcomes — gradually improving retrieval quality without retraining. Without a feedback loop, every invocation starts from the same baseline regardless of what the agent has done before.

Continual learning is the ability of a model to acquire new knowledge from a stream of incoming data over time without retraining from scratch and without catastrophically forgetting prior capabilities. It is not available in current production agents — what you observe is retrieval, not weight updating. The agent loop and training loop are still decoupled. Continual learning is the formal ML discipline that will eventually bridge them: the agent loop generates experience, and continual learning is the process by which the training loop absorbs that experience into model weights.

For most early-stage products, a single well-designed agent is enough — and significantly easier to debug. Multi-agent architectures introduce coordination overhead, inter-agent context passing, and compounding failure modes. Start with a single Level 2 or Level 3 agent. Reach for multi-agent only when a task has clearly separable parallel workstreams (e.g., one agent searches while another synthesizes) or when you need role-isolated trust boundaries. OpenAI's deep research product uses parallel agent subgraphs — but only after years of single-agent iteration.

A Level 2 agent (memory reads before LLM call, memory writes after) is achievable by a single full-stack engineer in 2–4 weeks using LangChain, a vector database, and a relational store. Level 3 adds context window monitoring, conversation compaction, tool output offloading, semantic tool discovery, idempotency, and prompt caching — typically requiring a dedicated AI infrastructure engineer and 4–8 additional weeks. The upgrade trigger is production data showing token costs growing faster than sessions, or agent quality degrading on long conversations.

As agents accumulate experience across millions of runs, the information they generate — episodic memories, entity graphs, workflow patterns, evaluation signals — becomes training signal. Agents with well-engineered memory (clean episodic records, accurately extracted entities, reliable retrieval) produce better training data than agents that let context accumulate without structure. The architectural decisions you make about memory today don't just determine how your agent performs tomorrow — they determine what it can learn from. The memory layer is where the agent loop and the training loop eventually converge.