Cheat sheet · LLMs & Agents

Agentic AI & Tool Use cheat sheet

The key ideas on one page — plus common pitfalls and interview tips. Skim it before an interview, or print it for revision.

An agentic AI system is an LLM that plans, calls external tools, observes results, and iterates in a loop toward a goal — moving from a one-shot text generator to a stateful actor. This sheet covers the agent loop, tool-calling mechanics (function calling, MCP), planning/memory patterns, multi-agent orchestration, and how to evaluate and harden these systems for production.

Core Concept: The Agent Loop

An agent = LLM (reasoning) + tools (actions) + memory (state) + a control loop that runs until a stop condition. The canonical pattern is ReAct: interleave Reason (thought) -> Act (tool call) -> Observe (tool result) -> repeat.
Each iteration appends the tool result back into context, so the model conditions its next decision on real-world feedback rather than hallucinated state. This grounding is the main reason agents beat single-shot prompting on multi-step tasks.
Stopping conditions matter: an explicit 'final answer' / end-turn signal, a max-iteration or token/cost budget, or a confidence/verification check. Without a hard cap, agents loop forever on ambiguous tasks.
Autonomy spectrum: (1) tool-augmented single call, (2) fixed workflow / chain (deterministic edges), (3) router (LLM picks a branch), (4) fully autonomous agent (LLM controls the loop). Prefer the least-autonomous design that solves the task — it is cheaper, more reliable, and easier to debug.
'Agentic' is about control flow, not a model property: the same model is 'agentic' when wrapped in a loop with tools, and non-agentic when used for one-shot completion.
Key distinction: workflows orchestrate LLMs through predefined code paths; agents let the LLM dynamically direct its own process and tool usage. Most SDKs ship a 'tool runner' helper that drives this loop for you, but the manual loop is what you reach for when you need approval gates, custom logging, or conditional execution.

Tool Use / Function Calling Mechanics

Tools are declared with a JSON Schema (name, description, typed parameters). The model does NOT execute anything — it emits a structured request (name + arguments); your code runs the function and returns the result. This client-side execution boundary is a critical security and design point.
The description and parameter docs ARE the prompt the model uses to choose and fill a tool — vague descriptions cause wrong-tool selection and malformed args. Be prescriptive about WHEN to call a tool, not just what it does. Treat tool specs as prompt engineering, not just API typing.
Forcing/steering: most APIs support tool_choice = auto | any/required (must call some tool) | a specific tool | none, plus parallel tool calls (several tool_use blocks in one turn). Disable parallel calls (e.g. disable_parallel_tool_use) when calls are order-dependent.
Return all results from a parallel turn in a SINGLE follow-up message, each keyed to its tool_use_id. Splitting them across messages, or dropping one, is malformed and degrades future parallel-calling behavior.
Anthropic's Model Context Protocol (MCP), introduced late 2024, is the open standard — by 2026 the de facto way — for connecting models to tools/data via reusable servers, decoupling tool implementations from any single agent ('USB-C for LLM tools'). Strict structured outputs (JSON-Schema-constrained tool args) are now common for guaranteeing valid arguments.
Validate and sanitize arguments before execution: the model can produce out-of-range, hallucinated, or injection-bearing arguments. Never pass tool args straight into shells, SQL, or eval.
Return concise, structured, model-readable results, including recoverable error messages (e.g. set is_error and say 'Error: city not found, try a valid name'). Dumping raw 50KB API blobs wastes context and degrades reasoning.

Planning, Reasoning & Memory

Planning patterns: ReAct (reason+act inline), Plan-and-Execute (generate full plan first, then execute steps — fewer LLM calls, but rigid), Tree/Graph-of-Thoughts (explore branches), and Reflexion / self-critique (reflect on failures and retry).
Reflection loop: after acting, a critic step (same or separate model) evaluates output against the goal and feeds corrections back. Boosts accuracy on coding/math at the cost of more tokens and latency.
Memory tiers: (1) short-term = the context window / message history; (2) long-term = external vector store or DB retrieved via RAG; (3) episodic/procedural = past trajectories and learned skills. Agents need explicit memory because the context window is finite and resets between sessions.
Context management is a first-class concern: summarize/compact or prune old turns, store full detail externally, and re-inject only what is relevant. Long agent runs fail mostly from context bloat and lost-in-the-middle effects, not model IQ.
Extended/'thinking' modes (interleaved reasoning between tool calls) let the model deliberate before acting; budget the reasoning effort since it adds cost and latency.
Decomposition: break a goal into sub-tasks (the LLM can generate the task list), which improves reliability and makes failures localizable and retryable.

Multi-Agent Orchestration

Use multiple agents when the task has separable roles or needs parallelism / context isolation — e.g. an orchestrator (lead) that decomposes work and spawns specialized sub-agents (researcher, coder, critic), each with its own context window.
Common topologies: orchestrator-worker (hub-and-spoke, most common in production), pipeline/sequential (output of A -> B -> C), hierarchical (managers of managers), and debate/voting (agents critique each other to improve quality).
Communication: agents coordinate via a shared scratchpad/blackboard, message passing, or by exposing each other as tools ('agent-as-tool'). Define a strict handoff schema so outputs are machine-parseable.
Trade-offs: multi-agent multiplies token cost (Anthropic reported roughly 15x a single chat for their research system) and latency, and adds failure modes (coordination errors, duplicated work, conflicting state). Justify it — many tasks are better served by one well-equipped agent.
Context isolation is the strongest argument FOR multi-agent: each sub-agent gets a clean, focused window, avoiding the pollution that degrades a single long-running agent.
Frameworks to name-drop accurately: LangGraph (graph/state-machine control), CrewAI (role-based crews), AutoGen / AG2 (conversational multi-agent), OpenAI Agents SDK (handoffs + guardrails), and Anthropic's MCP for tool/data plumbing plus server-managed agent runtimes.

Evaluation, Observability & Safety

Evaluate at two levels: end-to-end task success (did it achieve the goal?) and trajectory quality (right tools, right order, no redundant/looping calls, cost & step count). Final-answer-only metrics hide pathological loops.
Use LLM-as-judge with a clear rubric for open-ended outputs, but anchor on deterministic checks (assertions, golden answers, unit tests, tool-call exact-match) wherever possible — judges are noisy and gameable.
Observability/tracing is non-negotiable: log every prompt, tool call, args, result, and token cost per step (LangSmith, Langfuse, OpenTelemetry GenAI conventions). You cannot debug a non-deterministic loop without full traces.
Security threats specific to agents: prompt injection (malicious instructions in tool/web data hijack the agent), excessive agency / over-broad permissions, data exfiltration, and confused-deputy attacks. Treat all tool-returned content as untrusted.
Defenses: least-privilege tools, human-in-the-loop approval for irreversible/high-blast-radius actions (payments, deletes, sends), sandboxing/allowlists, input+output guardrails, and spend/rate limits.
Cost & latency control: cap max steps, cache repeated tool/LLM calls, use prompt caching for stable system prompts and tool defs, and route easy steps to cheaper/smaller models.

Common pitfalls

Assuming the model executes tools — it only emits a structured call; YOUR code runs it and returns the result. Forgetting this hides where validation and security must live.
No iteration cap or budget, so the agent loops indefinitely or burns tokens on an unsolvable/ambiguous task.
Treating tool descriptions as throwaway docs. Vague/overlapping descriptions are the #1 cause of wrong-tool selection and bad arguments.
Splitting parallel tool results across multiple messages, dropping one, or mismatching tool_use_id — malformed history that degrades future parallel calling.
Reaching for multi-agent by default. It multiplies cost/latency and adds coordination failures; a single agent with good tools usually wins.
Trusting tool/web/RAG output as safe — prompt injection rides in on that content. Untrusted data should never carry executable authority.
Stuffing raw, verbose tool outputs back into context, causing context bloat, lost-in-the-middle, and higher cost. Summarize/compact and structure results.
Evaluating only the final answer and ignoring the trajectory, so silent loops, redundant calls, and runaway cost go unnoticed.
Giving the agent broad, irreversible permissions with no human approval or sandbox (excessive agency).
Confusing autonomy levels — calling a fixed deterministic chain an 'agent', or building full autonomy when a router/workflow suffices.
Ignoring non-determinism in testing: the same input yields different paths, so a single passing run is not a passing test — you need eval sets and multiple samples.

Interview tips

Be able to draw and explain the ReAct loop end to end, and state precisely who executes the tool (the harness/your code, not the model).
Articulate WHEN to use an agent vs a fixed workflow vs a single LLM call — interviewers probe for 'use the least autonomy that works' judgment.
Explain function-calling internals: JSON Schema, tool_choice (auto/any/specific/none), parallel calls returned in one message, strict structured outputs, and how descriptions drive selection.
Know MCP at a conceptual level (open standard to connect models to tools/data; decouples tool servers from agents) and contrast it with bespoke function calling.
Discuss memory tiers (context window vs vector store vs episodic) and concrete context-management strategies (summarize/compact/prune) for long runs.
Compare multi-agent topologies and HONESTLY state the cost/latency/complexity trade-offs — name LangGraph, CrewAI, AutoGen, OpenAI Agents SDK accurately.
Detail prompt injection and excessive agency as the headline agent risks, with mitigations: least privilege, human-in-the-loop, sandboxing, guardrails.
Describe how you'd EVALUATE an agent: task success + trajectory metrics, LLM-as-judge with deterministic anchors, and full tracing/observability.
Mention concrete cost controls (step caps, prompt caching, model routing, result caching) — production-readiness is a frequent differentiator.
Have one war story / design: a task you'd build agentically, the tools you'd expose, the stop condition, and how you'd test it.

Read the full lesson