Agents, tools & MCP — autonomy is engineered, not prompted

1What makes an agent

The cleanest definition is Anthropic's, worth quoting: workflows are systems where LLMs and tools are orchestrated through predefined code paths; agents are systems where the LLM dynamically directs its own process and tool usage, deciding what to do next based on what it observes.

while not done:
    perceive   # context: task + tool results + environment state so far
    reason     # model decides: what's the next action? am I done?
    act        # execute a tool call; append the result to context

Every agent — coding agents, computer-use, Sentinel's analysis stage — is this loop with different tools and stop conditions. Three properties fall out of it:

2The loop, live — an issue arrives

Walk one concrete run of a Sentinel-style pipeline. Flip the reviewer toggle to watch the evaluator–optimizer loop physically reject a draft and send it back with a critique.

3Tool / function calling — the mechanics

How the model "does things":

Engineering details that separate practitioners from readers

• Descriptions are prompts. The model chooses tools by reading names/descriptions; vague descriptions → wrong tool choice. Great tools have crisp one-purpose descriptions, examples for tricky parameters, and unambiguous names (search_logs vs query beats run vs exec).
• Tool design > prompt design for agent quality. Fewer, higher-level tools beat many primitive ones — a get_incident_context(service, window) beats four chained low-level calls the model must orchestrate; every extra decision is an error opportunity. Return results in a model-friendly shape: concise, structured, relevant — a tool that dumps 50KB of JSON poisons the context (§9).
• Errors are information: return actionable messages ("date must be ISO-8601; got '2days'") — agents self-correct well when told how they failed. But cap retries: a tool failing identically 5 times should abort the loop, not consume the token budget.
• Validate every input as untrusted: the model can emit any arguments — schema-validate (Pydantic), then authorize (is this agent allowed to touch that resource?). Hallucinated parameters are routine, not exceptional.
• Parallel tool calls (model emits several at once) cut latency for independent reads — but require idempotency discipline for writes.

4MCP — Model Context Protocol

The problem it solves: the M×N integration explosion — M agent applications × N tools/data sources, each pairing hand-integrated. MCP standardizes the interface so any MCP-speaking client can use any MCP server. The popular framing is "USB-C for AI tools"; the more precise one is LSP for tools — as the Language Server Protocol did for editors×languages, MCP does for agents×integrations.

What a server exposes — the three primitives

The distinction is who decides — naming that trichotomy signals real MCP knowledge. (Servers can also request sampling — asking the host's LLM to complete something — keeping the server model-agnostic.)

Plumbing: JSON-RPC 2.0 messages; transports are stdio (server as local subprocess — simple, secure-by-locality) or streamable HTTP (remote servers; OAuth for auth). Sessions negotiate capabilities at init, and servers can notify clients when tool/resource lists change.

5The five Anthropic workflow patterns

From "Building Effective Agents" — the industry's shared vocabulary for LLM system design. Use these names in interviews.

6Multi-agent patterns — and their honest costs

Split into multiple agents only when one context window can't hold the whole job, or roles genuinely conflict:

• Supervisor / sub-agents: a lead agent decomposes and delegates; workers run in their own context windows and return summaries. The real win is context isolation — a worker can burn 100k tokens exploring and return the 500 that matter — plus parallelism. This is orchestrator–workers where workers are full agent loops.
• Adversarial pairing: generator vs critic as separate agents. The separation matters: a model reviewing its own in-context output inherits its own framing and misses its own blind spots; a fresh-context reviewer whose prompt's job is to find problems is a genuinely different distribution. You built exactly this — explain why the separation matters, not just that it exists.
• Role/debate ensembles: multiple perspectives argue, a judge aggregates — occasionally worth it for high-stakes judgment; often just 3× cost.

7Human-in-the-loop design

The question underneath: which actions is the system allowed to take without a human?

• Approval gates at irreversibility boundaries. Classify actions: reversible + low blast radius → autonomous (reading logs, drafting, opening a PR — revertable); irreversible or high blast radius → gated (merging to prod, spending money, sending external messages, deleting data). Sentinel's Telegram gate sits exactly at the merge boundary — the last reversible moment. Framing gate placement as "find the irreversibility boundary" is the senior articulation.
• Make approval real, not rubber-stamp theater. An approver shown a wall of JSON approves blind. The approval surface must present: what will change, the evidence/reasoning, the risk level, an easy diff. Design the approval UX as carefully as the agent — otherwise you've automated the generation of unread checkboxes. 100+ PRs/month through a gate only works because review cost per item is kept low; that's a design achievement worth describing.
• Escalation as a tool: give the agent an ask_human(question, context) tool so uncertainty has a legitimate exit — reduces forced guessing, and what gets escalated becomes a signal for where the agent needs improvement.
• Graduated autonomy: start everything gated; expand autonomy per action-class as eval + track-record justify it; keep audit logs of every action + approval. Autonomy is earned by data, not granted by optimism.
• Attention economics (the deep point): human review capacity is the scarce resource. If the agent generates more decisions than humans can genuinely review, you've moved the bottleneck, not removed it. Triage (auto-approve trivial classes, gate risky ones), batch, and measure review quality, not just throughput.

8Guardrails, sandboxing & the lethal trifecta

Defense-in-depth layers, inside-out:

9Agent failure modes — the field guide

10Rapid-fire interview Q&A

Self-test