Agentic AI Patterns

Agentic AI Patterns

An LLM agent is a model placed in a loop where it can take actions — call tools, read results, and decide what to do next — to accomplish a goal, rather than emitting a single response. The power comes from the loop; so does the risk, since a model that can act can act wrongly.

A useful distinction (from Anthropic’s Building Effective Agents): workflows orchestrate LLM calls along predefined paths, while agents dynamically decide their own steps. Prefer the simplest thing that works — most problems need a workflow, not a fully autonomous agent.

Tool use (function calling)

Tools are how an agent affects the world: search, code execution, API calls, database queries. The model is given tool schemas, decides which to call with what arguments, and receives the results back in context.

• Describe tools precisely — clear names, argument descriptions, and when to use this. Underspecified schemas are a common source of tool-use failures.
• Validate and sandbox — never execute model-chosen actions without validation; a tool that deletes or spends needs guardrails and ideally human confirmation.
• Return structured, concise results — dump less; summarize what the model needs.

Planning loops

Pattern	How it works	Best for
ReAct	Interleave Reason → Act → Observe each step	Open-ended tasks where each step depends on the last
Plan-and-Execute	Make a full plan first, then execute (and optionally replan)	Multi-step tasks that benefit from up-front structure; fewer model calls
Reflexion (self-critique)	Act, then critique and retry	Tasks with a checkable result (tests, validators)

ReAct is the common default; Plan-and-Execute reduces cost and drift on longer tasks by committing to a plan instead of re-deciding every step.

Multi-agent orchestration

Split a hard problem across specialized agents — e.g. an orchestrator that decomposes work and delegates to workers, then synthesizes. This helps when subtasks are independent (parallelizable) or need distinct expertise/tools.

Caution

Multi-agent systems multiply cost and failure surface. Add agents only when a single agent with good tools genuinely can’t do the job — coordination overhead and compounding errors are real. Start with one agent.

Memory patterns

Context windows are finite, so agents need memory beyond the current conversation:

• Short-term — the running scratchpad of recent steps/observations; trim or summarize as it grows to avoid “lost in the middle.”
• Long-term — facts persisted across sessions, typically retrieved with RAG (vector store of past interactions/knowledge) rather than stuffed into every prompt.
• State/working memory — explicit task state (plan, todo list, intermediate results) the agent reads and updates deterministically.

Security: injection and excessive agency

An agent that can act turns prompt injection from a nuisance into a real-world risk: if untrusted input (a web page, a retrieved document, a tool result) can smuggle instructions into the model, it can also steer the model’s actions — calling tools, spending money, exfiltrating data. This pairing is why the OWASP Top 10 for LLM Applications lists both Prompt Injection (LLM01) and Excessive Agency (LLM06).

• Treat all tool output as untrusted input — a document or API response can contain injected instructions; don’t let it rewrite the agent’s goals. See the defenses in Prompt Engineering Taxonomy.
• Least privilege / minimize agency — give the agent the narrowest set of tools and permissions for the task; scope API tokens; prefer read-only where possible.
• Human-in-the-loop for consequential actions — gate destructive, costly, or irreversible tool calls behind confirmation rather than trusting the loop.
• Don’t use model output as a security control — validate and authorize actions server-side, outside the model.

Observability

You cannot debug an agent you can’t see. Instrument:

• Tracing — capture every step: prompts, tool calls, arguments, results, token counts, latency. Tools like LangSmith or OpenTelemetry-based tracing make loops inspectable.
• Guardrails & limits — cap iterations and spend; detect loops (the agent repeating the same failing action) and halt.
• Evals — score agent runs against expected outcomes so changes don’t silently regress; see the evaluation discussion in RAG Patterns.

Related

• RAG Patterns — retrieval as an agent tool and long-term memory
• Prompt Engineering Taxonomy — the prompts that drive tool use and planning
• Claude Code — a production coding agent in practice
• AI/ML Learning — foundational concepts