The Agentic Spectrum: Workflow to Agent
The workflow-to-agent distinction is a dial, not a binary: it measures how much control flow you delegate from your code to the model. At the deterministic end, an LLM fills fixed slots in a pipeline your code owns (classify, extract, draft, route), so behavior is testable and failure modes are enumerable. At the agentic end, the model owns the loop: it selects tools, sequences its own steps, and decides when it is done, which buys coverage of the long tail of inputs at the cost of variance, latency, and audit complexity. The design question for every step is therefore who owns the loop. Most enterprise use cases resolve to a workflow with one or two genuinely agentic steps inside it, and the mature move is to start deterministic and turn the autonomy dial up only where measured value justifies the added risk and evaluation burden.
Tool Use & Function Calling Mechanics
Function calling is the mechanism that turns a language model into an actor: you describe each tool with a JSON Schema (name, typed parameters, a description the model reads like documentation), the model emits a structured call instead of prose, the runtime executes it, appends the result to the conversation, and the loop repeats until the model produces a final answer. The model only ever proposes; execution, and therefore safety, lives entirely in the runtime. That is where the operational discipline goes: validate arguments against the schema before executing, enforce per-call timeouts so one hung API does not stall the whole loop, and make write operations idempotent, because a retried non-idempotent call is how an agent submits the same purchase order twice. Tool descriptions are prompt engineering; ambiguous ones cause more wrong calls than model weakness does. Cap iterations and spend per run, and design every tool so a wrong call is cheap to detect and reverse.
Model Context Protocol (MCP), a Deep Dive
The Model Context Protocol is an open standard, released by Anthropic in November 2024, for connecting models to tools, data, and prompts through one wire format instead of bespoke integrations. It uses a client-server architecture over JSON-RPC 2.0: servers expose three primitives (tools the model can invoke, resources it can read, prompt templates it can apply), and clients discover those capabilities at runtime rather than at build time, over stdio for local servers or streamable HTTP for remote ones. The economics are the point: without a standard, ten assistants times forty internal systems means four hundred bespoke connectors; with MCP you write a server once and every compliant client can use it. The spec now defines OAuth 2.1 authorization for client-to-server connections, but what a server does downstream is still your problem: it runs with whatever credentials you hand it, so treat each one as a privileged service: scope its access, log its calls, and be deliberate about combining powerful servers with prompt-injectable content.
Multi-Agent Patterns: Orchestrators, Handoffs, Specialists
Multi-agent systems split work across model instances with distinct prompts, tools, and context windows, and their real payoff is context isolation, not extra intelligence. The workhorse pattern is orchestrator-worker: a lead agent decomposes the task, dispatches subtasks to specialists in parallel, and synthesizes results. Variants include specialist routing, where a lightweight classifier hands the whole request to the right expert, and handoffs, where agents transfer control and conversation state peer to peer instead of reporting back up. Shared state (a blackboard, a task queue, checkpointed graph state) is what keeps them coherent. The costs are concrete: token spend commonly runs several times a single-agent baseline, latency compounds across hops, and coordination failures (duplicated work, contradictory partial answers) become the dominant failure mode. The honest default is one capable agent with good tools; reach for multiple agents only when subtasks are truly parallelizable or the context genuinely cannot fit in one window.
Planning & Task Decomposition
Planning is what separates an agent that converges from one that burns tokens in circles. Two styles dominate. Plan-then-execute has the model draft an explicit task list or dependency graph up front, which a runtime then executes node by node; it is auditable, parallelizable, and lets you route cheap steps to a smaller model, but it is brittle when step two's output invalidates step five's assumptions. ReAct-style interleaving alternates reasoning and action one step at a time, so the plan stays implicit; it adapts naturally to surprises but can drift, loop, and resist inspection. Production systems converge on a hybrid: an explicit plan held as a task graph, interleaved execution inside each node, and replanning triggered by concrete failure signals such as tool errors, validation failures, or budget overrun. Treat the plan as your primary control surface: persist it, show it to a human before expensive branches, and log every replan as an auditable event.
Human-in-the-Loop & Approval Workflows
Human-in-the-loop is what makes delegated autonomy defensible: a control layer where consequential actions pause for a person. The workable design starts with risk tiers: read-only actions run free, reversible writes run with logging, and irreversible or external-facing actions (payments, customer emails, production changes) require explicit sign-off. Mechanically, the agent checkpoints its state mid-run, emits an approval request into a queue the business already watches (Slack, ServiceNow, a custom console), and resumes or aborts on the decision, which demands durable state because approvals can take hours. Every gate needs an escalation path for timeouts and a full audit record: proposed action, inputs, approver, decision, timestamp. That trail is what regulators and incident reviews actually read, and it is what the EU AI Act's human-oversight expectations translate to in practice. The failure mode to design against is approval fatigue: if everything needs a click, humans rubber-stamp, so tier aggressively and sample-audit the auto-approved layer.
Agent Memory & State Management
Agent memory is layered, and each layer has a different failure mode. The working layer is the context window itself, augmented by a scratchpad: a file or state field where the agent writes intermediate findings so they survive when the transcript is compacted. The durability layer is checkpointing: persisting the full loop state (messages, tool results, pending plan) after every step so a crashed run, a rate-limit stall, or a multi-hour approval wait resumes from the last checkpoint instead of restarting; LangGraph's checkpointer and durable-execution engines like Temporal both formalize this. The long-horizon layer distills facts across sessions into a store the agent can query or that gets injected at start. The hard engineering problem is forgetting well: context fills within tens of steps, and a careless compaction silently deletes the one fact the next step needs. Treat memory as a governed data store too, since it accumulates PII, stale facts, and injected instructions, and deserves retention rules and inspection tooling.
Guardrails & Sandboxing for Autonomous Systems
Guardrails constrain what an autonomous system may do; sandboxing bounds the damage when a constraint fails. Start with least privilege: each agent gets the minimal tool set and narrowly scoped credentials for its task, so a research agent holds read-only API keys and no path to the production database. Layer permission tiers on top, mapping each action class to allow, allow-with-logging, require-approval, or deny. Run generated code and shell commands inside disposable sandboxes (containers hardened with gVisor's user-space kernel, or microVMs such as Firecracker) with no network egress by default and a filesystem scoped to a working directory. Filter outputs on the way out: schema validation, secret and PII scanners, and policy checks before anything reaches a user or a downstream system. Assume prompt injection eventually succeeds; an agent reading untrusted web pages or emails will one day be instructed to exfiltrate, and the defense that holds is permissions that make the instruction unexecutable. Controls belong in the runtime: a system prompt is a suggestion, an egress policy is a control.
The Agent Framework Landscape
The framework layer is where agent architectures either stay portable or quietly ossify. LangGraph models agents as explicit state graphs with built-in checkpointing and human-in-the-loop interrupts; Semantic Kernel anchors the .NET and Azure enterprise world, and Microsoft is folding AutoGen's multi-agent runtime into its successor Agent Framework; AutoGen itself popularized conversational multi-agent patterns in research settings; the Claude Agent SDK packages the production harness behind Claude Code (the loop, tool execution, context management) as a library. Keep frameworks distinct from protocols: MCP standardizes tool access and A2A standardizes agent-to-agent messaging, and protocols will outlive any of these frameworks. Churn in this layer is high, as LangChain's repeated rewrites demonstrated, so the defensive architecture keeps the framework thin at the edge: prompts, tool definitions, business logic, and evals live in your own code. Select for the controls you need (durable state, interrupts, observability), not demo velocity, and budget for a migration within a couple of years.