https://agenticmap.co The definitive interactive skill map for agentic coding. One map. One canvas. The entire agentic AI landscape. en-us https://agenticmap.co/node/token-economics https://agenticmap.co/node/token-economics Large language model (LLM) pricing runs on tokens, the chunks of text models process as input and output, with output tokens typically costing 3 to 5 times more than input tokens and costs accumulating fast inside agent loops that call the model repeatedly. An unoptimized agent loop can burn through hundreds of dollars per day in production, so understanding tokenization, context window costs, and price differences between models is a prerequisite for building economically viable systems at scale. Prompt caching, model routing to cheaper models for simpler tasks, and context window discipline can reduce costs by 10x or more without sacrificing output quality. foundations https://agenticmap.co/node/agent-loop https://agenticmap.co/node/agent-loop The agent loop is the core observe-think-act cycle that drives all agentic behavior: the model receives context, reasons about what to do next, executes a tool or produces output, then feeds the result back into the next iteration. This cycle continues until the agent determines the task is complete, hits a predefined limit, or requires human input, making the termination condition one of the most important design decisions you will encounter. Every other concept on this map, from context engineering to evaluation, is ultimately about making individual iterations of this loop more reliable, efficient, or safe. foundations https://agenticmap.co/node/agentic-vs-chat https://agenticmap.co/node/agentic-vs-chat Chatbots respond to individual messages in a turn-by-turn exchange, while agentic systems take autonomous actions across multiple steps, using tools and making decisions in a loop without waiting for human input at each turn. The key distinction is agency: an agent decides what to do next, executes that action, observes the result, and iterates until it reaches a goal or determines it needs human guidance. This shift from reactive conversation to goal-directed task execution is what makes agentic coding fundamentally different from a basic chat interface, and recognizing the boundary tells you when agent patterns are worth the added complexity versus when a simpler chat-based approach is the right tool. foundations https://agenticmap.co/node/llm-fundamentals https://agenticmap.co/node/llm-fundamentals Large language models (LLMs) generate text through next-token prediction, using transformer architectures with self-attention mechanisms to process and produce sequences of language. Understanding how scale, training data, and architecture choices affect model capabilities is essential for building effective agents, because these fundamentals explain why models can follow instructions, use tools, and reason through complex problems. The relationship between pretraining data, fine-tuning, and reinforcement learning from human feedback (RLHF) determines a model's behavior and limitations, which directly shapes how agents perform in production. foundations https://agenticmap.co/node/api-basics https://agenticmap.co/node/api-basics Every agentic tool, from integrated development environment (IDE) agents to custom pipelines, ultimately sends HTTP requests to a model application programming interface (API) and processes the structured response, making direct API fluency the foundation for building anything beyond pre-built tools. You need to understand request anatomy, including authentication, endpoints, and model parameters, as well as response handling for token usage, finish reasons, and tool call outputs, and the differences between providers such as OpenAI's chat completions, Anthropic's Messages API, and Google's Gemini API. The API layer is also where you control cost, latency, and reliability through parameters like temperature and max_tokens, and where you implement production concerns like retries, fallback logic, and rate limit handling. foundations https://agenticmap.co/node/when-not-to-agent https://agenticmap.co/node/when-not-to-agent Not every problem benefits from an agentic approach: deterministic tasks, simple data operations, and well-defined algorithms run faster, cheaper, and more predictably with traditional software than with a language model in the loop. Reaching for agents when a regular expression, SQL query, or rule engine would suffice adds unnecessary cost, latency, and unpredictability to a problem that has a single correct answer derivable from a fixed algorithm. The clearest signal that you need an agent is when a task requires judgment, ambiguity resolution, or multi-step reasoning across unstructured information, where the problem space cannot be fully specified in advance. foundations https://agenticmap.co/node/model-selection https://agenticmap.co/node/model-selection Model selection is the process of matching the right language model to each task in your agent system based on cost, latency, capability, and context window size. Frontier models like Claude Sonnet and GPT-4o handle complex reasoning and multi-step planning well, while smaller models like Claude Haiku and GPT-4o-mini handle high-volume, low-complexity tasks like classification or extraction at a fraction of the cost. Before deploying, run your top two or three candidate models against your eval suite, because performance rankings reverse depending on task type and the cheapest model often wins on narrow, well-specified tasks where a frontier model's general capability adds no value and only adds latency and cost. foundations https://agenticmap.co/node/agent-benchmarks https://agenticmap.co/node/agent-benchmarks Agent benchmarks are standardized evaluation suites that measure how well models and agent systems perform on specific task categories like coding, web navigation, tool use, and multi-step reasoning, with widely used examples including SWE-bench (real-world GitHub issue resolution), HumanEval (code generation), and Chatbot Arena (human preference rankings). Benchmarks give the field a shared vocabulary for comparing models and architectures, but benchmark scores often overstate production utility because vendors optimize for known test sets in ways that do not generalize to the specific problems you actually need to solve. The practical lesson is to treat public benchmarks as a first filter for model selection, then validate against domain-specific evaluations you build yourself before committing to any model in production. foundations https://agenticmap.co/node/reasoning-models https://agenticmap.co/node/reasoning-models Reasoning models like OpenAI's o1/o3 and Anthropic's Claude with extended thinking spend more computational effort at inference time to solve harder problems, trading latency and cost for significantly improved accuracy on complex tasks. Unlike standard large language models that generate output in a single forward pass, reasoning models run chain-of-thought internally, sometimes generating thousands of thinking tokens before producing a response. The routing decision is more specific than "use reasoning for complex tasks": reach for a reasoning model when the problem requires multi-step inference where intermediate conclusions depend on earlier ones, because that is the structure that benefits from extended thinking time; if the task is hard but self-contained in a single step, the extra cost buys little. foundations https://agenticmap.co/node/autonomy-spectrum-topic https://agenticmap.co/node/autonomy-spectrum-topic Agent autonomy exists on a spectrum from fully human-controlled, where agents suggest but do not act, to fully autonomous, where agents independently execute multi-step workflows and deploy changes without human intervention, and deciding where to position your system on this spectrum is one of the most consequential design choices in agentic architecture. Most production systems operate in the middle, using tiered permissions where routine actions execute automatically while high-stakes decisions route to a human for approval. The spectrum is not just a technical setting: even a capable agent should start at lower autonomy and earn higher trust incrementally as it demonstrates reliability in your specific environment, because failure modes scale with autonomy level. foundations https://agenticmap.co/node/cli-agents https://agenticmap.co/node/cli-agents Command-line interface (CLI) agents operate directly in the terminal, reading and writing files, running commands, and iterating on code without requiring a graphical IDE, which means they work in any environment with a shell, including headless servers and Docker containers. Tools like Claude Code, Aider, and OpenAI Codex excel at large-scale refactors, headless workflows, and tasks where you want an agent to operate independently across many files with full access to your system tools. The architectural advantage of CLI agents is composability: you can pipe them together with other Unix tools, orchestrate them from scripts, and integrate them into automated pipelines in ways that GUI-based IDE agents do not support, making them the right choice whenever automation or repeatability matters more than interactive editing. coding-tools https://agenticmap.co/node/test-generation https://agenticmap.co/node/test-generation Agents can generate unit tests, integration tests, and test fixtures by analyzing your code's behavior, edge cases, and type signatures, which makes them useful for adding coverage to legacy codebases that have little or none. The key risk is that generated tests tend to encode current behavior rather than intended behavior, potentially locking in existing bugs as passing tests and producing a false sense of confidence. The most reliable pattern pairs human-written test specifications that define correctness with agent-written implementation that satisfies them, ensuring the tests reflect intent rather than whatever the code happens to do today. coding-tools https://agenticmap.co/node/code-review-agents https://agenticmap.co/node/code-review-agents Code review agents automatically analyze pull requests to catch bugs, flag style inconsistencies, identify security vulnerabilities, and suggest improvements before human reviewers get involved, integrating directly with platforms like GitHub and GitLab to post inline comments on diffs. They work best as a triage layer that handles routine checks, such as style violations, obvious bugs, and missing tests, freeing human reviewers to focus on architecture, design decisions, and business logic that require domain expertise. The most effective deployments pair code review agents with agent config files that encode team-specific standards, ensuring the agent's feedback reflects your actual conventions rather than generic best practices. coding-tools https://agenticmap.co/node/ide-agents https://agenticmap.co/node/ide-agents Integrated development environment (IDE) agents are AI coding assistants embedded directly in editors like VS Code and JetBrains, providing inline completions, chat-driven editing, and multi-file refactoring without leaving your workspace. Tools like GitHub Copilot, Cursor, and Windsurf understand your project through open files, workspace structure, and configuration files, which means the quality of suggestions depends directly on how much relevant context the tool can see. The key differentiator between IDE agents is indexing depth: the best tools index your entire repository and produce suggestions that stay architecturally consistent with your existing patterns, rather than generating plausible-looking code that ignores your conventions. coding-tools https://agenticmap.co/node/agent-config-files https://agenticmap.co/node/agent-config-files Configuration files like CLAUDE.md, .cursorrules, and .github/copilot-instructions.md give agents persistent context about your project's conventions, architecture, and constraints, loading automatically at the start of each session so you do not have to re-explain the same rules every time. These files live in your repository alongside the code they describe, which means the context compounds across every interaction and stays in sync as the codebase evolves. The best config files encode the implicit knowledge that experienced developers carry mentally: naming conventions, architectural boundaries, forbidden patterns, and file organization rules, converting that tacit knowledge into machine-readable instructions that any team member can read and update. coding-tools https://agenticmap.co/node/documentation-agents https://agenticmap.co/node/documentation-agents Documentation agents generate and maintain docs by analyzing source code, type definitions, and existing documentation patterns across a codebase. They work best on API references, inline code comments, and README files that need to stay in sync with the code, reducing the maintenance burden that causes most project docs to go stale within weeks of creation. Trust agent output for the "what" (parameter types, return values, method signatures) but rewrite anything that explains "why": architectural tradeoffs, deprecation reasons, and the intent behind a design decision are invisible to an agent reading code structure and will be confidently wrong when it attempts to infer them. coding-tools https://agenticmap.co/node/refactoring-agents https://agenticmap.co/node/refactoring-agents Refactoring agents restructure code across multiple files while preserving behavior, making them useful for large-scale migrations, API updates, and codebase modernization tasks that would take a human developer days or weeks. They appear after code review agents in the sequence because you review first to understand what needs to change, then automate the change; skipping review means the agent refactors without a shared understanding of which patterns are intentional and which are the actual problems. The critical dependency is test coverage: without a strong test suite, you have no way to verify the agent's changes are safe, which is why test generation is a natural prerequisite for any refactoring workflow you plan to hand off to an agent. coding-tools https://agenticmap.co/node/choosing-your-stack https://agenticmap.co/node/choosing-your-stack Selecting the right combination of agentic coding tools means evaluating language and framework support, model flexibility, privacy requirements, and how well each tool integrates with your existing workflow rather than defaulting to whatever is most popular. The right answer depends on your context: a solo developer often finds an all-in-one integrated development environment (IDE) agent like Cursor sufficient, while a team might combine a command-line interface (CLI) agent for automation, a code review agent for quality assurance, and a dedicated pull request reviewer for governance. The most productive developers use multiple specialized tools together rather than forcing one tool to cover the entire development lifecycle, so understanding which tool excels at which stage is a concrete advantage worth developing early. coding-tools https://agenticmap.co/node/tool-specialization https://agenticmap.co/node/tool-specialization Different agentic coding tools have different strengths: integrated development environment (IDE) agents like Cursor handle high-context, interactive work within a single file or feature, command-line interface (CLI) agents like Claude Code handle multi-file refactoring and codebase-wide tasks, and code review agents work best as asynchronous quality gates in continuous integration pipelines. The most effective developers compose toolchains where each tool handles its area of strength, for example using Claude Code for initial implementation on a feature branch, then Cursor for fine-tuning within specific files, then a review agent to gate the pull request. Treating tools as specialists rather than substitutes gives you the coverage of a coordinated team without the overhead of coordinating one. coding-tools https://agenticmap.co/node/auto-fix-loops https://agenticmap.co/node/auto-fix-loops The auto-fix loop is the pattern where an agent writes code, runs tests or linters, observes failures, and iterates until all checks pass, distinguishing a coding agent from a one-shot code generator by having the agent validate and repair its own work through interaction with the real development environment. This tight write-run-fail-fix cycle works best when the success criteria are machine-verifiable, such as passing tests, clean types, and no lint errors, and breaks down when evaluation requires human judgment like architectural fit or code quality. The key failure mode to watch for is an agent that "fixes" a failing test by weakening the assertion rather than correcting the implementation, so reviewing what changed in the test files is as important as reviewing what changed in the source files. coding-tools https://agenticmap.co/node/context-window-budget https://agenticmap.co/node/context-window-budget Every model has a finite context window measured in tokens, and treating that space as a budget is essential for effective agent design. You must allocate tokens across system instructions, conversation history, retrieved context, tool definitions, and the model's own reasoning and output, since exceeding the window causes silent truncation or errors while wasting tokens on irrelevant information degrades performance even within the limit. Research on the "lost in the middle" problem shows that models disproportionately attend to information at the beginning and end of the context, making strategic placement of critical information as important as total quantity. context-engineering https://agenticmap.co/node/few-shot-examples https://agenticmap.co/node/few-shot-examples Few-shot learning provides the model with concrete examples of desired input-output pairs directly in the prompt, guiding its behavior through demonstration rather than instruction alone. This technique is one of the most reliable ways to improve output quality for formatting, tone, and domain-specific conventions that are difficult to describe in words but obvious when shown, and it is particularly useful in agentic coding for demonstrating exactly what a correct tool call should look like in your system. The key tradeoffs are coverage versus cost: examples must represent edge cases well enough to steer behavior, but each example consumes context window tokens that might otherwise hold task-relevant information, so selecting the most representative few examples matters more than using many. context-engineering https://agenticmap.co/node/system-prompts https://agenticmap.co/node/system-prompts The system prompt is persistent context the model reads before every user interaction: it sets the agent's role, behavior boundaries, output format, and decision-making rules, functioning as the agent's standing instructions that govern all subsequent reasoning. Well-designed system prompts specify what the agent should and should not do, include examples of desired behavior, and give the model a clear framework for handling ambiguous situations without asking for clarification. The gap between a mediocre agent and a production-grade one often comes down entirely to system prompt quality, because every inference the model makes runs through this foundational context. context-engineering https://agenticmap.co/node/context-engineering-vs-prompt https://agenticmap.co/node/context-engineering-vs-prompt Context engineering is the discipline of designing everything a model sees, not just the user-facing prompt: it encompasses system instructions, conversation history, retrieved documents, tool definitions, few-shot examples, and tool results that together shape model behavior. Prompt engineering focuses narrowly on crafting individual instructions, but in agentic systems the user's prompt is a small fraction of the total context; the majority arrives dynamically from tool results, retrieved data, and conversation state. Mastering context engineering means architecting the entire information environment the agent operates within, which sets the ceiling of what the agent can accomplish regardless of the quality of the underlying model. context-engineering https://agenticmap.co/node/chain-of-thought https://agenticmap.co/node/chain-of-thought Chain-of-thought prompting instructs a model to show its reasoning steps before arriving at an answer, which measurably improves accuracy on complex tasks like math, logic, and multi-step planning by forcing the model to work through a problem rather than pattern-match to a surface-level answer. For agent systems, visible reasoning also makes decisions transparent and debuggable: when an agent explains why it chose a particular tool or took a particular action, you can identify exactly where reasoning broke down rather than treating a failure as an opaque black box. Extended thinking features in models like Claude 3.7 Sonnet provide a dedicated reasoning space that does not count against output tokens, giving the model room to work through complex problems before committing to a response, which is especially valuable in multi-step tool-use loops where a wrong early decision compounds into larger mistakes. context-engineering https://agenticmap.co/node/retrieval-augmented-gen https://agenticmap.co/node/retrieval-augmented-gen Retrieval-Augmented Generation (RAG) is a pattern where a system retrieves relevant documents from an external knowledge source and injects them into the model's prompt before generating a response, grounding answers in specific source material rather than training data alone. This matters because language models have a knowledge cutoff and will confidently hallucinate facts outside their training, so any agent that needs to answer questions about your data, your codebase, or recent events needs RAG to be accurate. Every variation of the pattern, from simple vector retrieval to multi-hop agentic RAG, builds on this same core loop: retrieve relevant context, then generate. context-engineering https://agenticmap.co/node/context-caching https://agenticmap.co/node/context-caching Context caching lets you reuse previously processed prompt prefixes across multiple API calls, cutting both cost and latency for repeated content like system prompts, documentation, or few-shot examples. Anthropic's prompt caching can reduce input token costs by up to 90% and latency by 85% for cached content, and OpenAI and Google offer comparable automatic caching mechanisms. This technique becomes especially valuable in agent systems that make many calls with the same base context, which is the default pattern in any multi-step agent loop where the system prompt and tool definitions stay constant across iterations. context-engineering https://agenticmap.co/node/structured-output https://agenticmap.co/node/structured-output Structured output constrains a model's response to follow a specific format, such as JSON or XML, validated against a schema you define, so that downstream code can parse the result reliably instead of wrestling with free-form text. In agent systems, a single missing field or wrong type in a tool call response can crash an entire pipeline, so structured output eliminates a whole class of integration bugs that would otherwise require fragile regex parsing or post-hoc validation. Most providers now support structured output natively through response format parameters or tool-use schemas, making the output of one agent call reliable enough to feed directly as input to the next. context-engineering https://agenticmap.co/node/context-assembly-pipelines https://agenticmap.co/node/context-assembly-pipelines Context assembly pipelines are the programmatic systems that gather, filter, and format information from multiple sources before injecting it into a model's context window for each inference call. A pipeline might pull relevant files from a codebase index, recent conversation history, retrieved documentation, and active tool outputs into a single structured prompt, replacing the static template approach with dynamic, task-aware assembly. The quality of your context assembly pipeline sets the ceiling for agent performance: the same model with the same tools will produce sharply different results depending on whether it receives a well-organized, relevance-ranked context or a noisy dump of everything available. context-engineering https://agenticmap.co/node/context-density https://agenticmap.co/node/context-density Context density measures how much useful, task-relevant information each token carries, and optimizing for it is the primary lever for improving agent performance within fixed context window limits. Low-density context burns tokens on boilerplate, irrelevant examples, and redundant information; high-density context uses tight type signatures instead of full source files, relevant test failures instead of entire test suites, and summarized history instead of raw transcripts. Research on "lost in the middle" effects shows that models attend less to information placed in the center of long contexts, so density optimization is not just about fitting more in but about placing critical information where the model will actually use it. context-engineering https://agenticmap.co/node/json-schema https://agenticmap.co/node/json-schema JSON Schema is the formal specification language used to define the structure, types, and constraints of the parameters that agents pass to tools, serving as the contract between the model's output and the tool's input. Every major large language model (LLM) provider uses JSON Schema as the standard for defining tool interfaces, making it the universal language for describing what an agent can do. Poorly specified schemas lead to malformed tool calls, while well-constrained schemas with precise descriptions and strict typing directly improve tool-use reliability. tool-design https://agenticmap.co/node/tool-sandboxing https://agenticmap.co/node/tool-sandboxing Tool sandboxing runs agent tool calls inside isolated environments, such as Docker containers, virtual machines, or Firecracker microVMs, so that a hallucinated command or prompt injection cannot modify production data, execute destructive system calls, or access resources outside the agent's intended scope. The scenario where this matters most is an agent with file system access executing user-supplied code: without isolation, a malicious or malformed input can read credentials, overwrite arbitrary files, or exfiltrate data before any human review occurs. The real tradeoff is calibration, not just presence: over-sandboxing adds cold-start latency and can prevent the agent from reaching the resources it legitimately needs, so the practical goal is the minimum isolation that contains the worst-case blast radius. tool-design https://agenticmap.co/node/function-calling https://agenticmap.co/node/function-calling Function calling is the mechanism through which language models invoke external tools by outputting structured requests that match predefined function signatures, producing a JSON (JavaScript Object Notation) payload specifying the function name and arguments rather than a free-text description of intent. This structured interface is what transforms a language model from a text generator into an agent capable of taking real-world actions like reading files, querying databases, or calling APIs. The reliability of function calling depends heavily on tool definition quality: clear names, precise descriptions, and well-typed parameters with constraints make the difference between an agent that reliably selects the right tool and one that consistently misroutes. tool-design https://agenticmap.co/node/tool-definition-patterns https://agenticmap.co/node/tool-definition-patterns A tool definition is the interface contract between an agent and the external world: it includes a name, a description the model reads to decide when to call it, and a typed parameter schema that constrains what the model can pass in. The most common failure mode is vague descriptions: a tool named "search" with the description "searches for things" will be invoked incorrectly far more often than one named "search_codebase_by_symbol" that specifies exactly what it searches and what format results take. Every agent system depends on tool definitions to bridge language understanding and real-world action, so investing in precise names, descriptions, and parameter constraints pays back through fewer misrouted calls and more reliable end-to-end behavior. tool-design https://agenticmap.co/node/human-in-the-loop https://agenticmap.co/node/human-in-the-loop Human-in-the-loop (HITL) patterns insert human checkpoints into agent workflows at critical decision points, requiring explicit approval before the agent takes high-stakes or irreversible actions. This is the primary safety mechanism for production agent systems, because even capable models make mistakes, and HITL ensures those mistakes are caught before they reach databases, customer-facing systems, or financial transactions. The most effective patterns use risk-based escalation, where routine actions proceed automatically while destructive, expensive, or irreversible actions require human approval. tool-design https://agenticmap.co/node/tool-composition https://agenticmap.co/node/tool-composition Composable tools let agents build sophisticated workflows by chaining simple, focused primitives rather than relying on monolithic tools that bundle complex operations into a single call, mirroring the Unix philosophy of small tools that each do one thing well. This approach makes individual tools easier to test, debug, and reuse across different workflows, and gives the model more granular control over each step so that a failure in one operation does not silently corrupt the entire sequence. The trade-off is that heavily decomposed tools require the model to plan multi-step sequences, which increases reasoning burden and token cost per task compared to calling one large tool. tool-design https://agenticmap.co/node/error-handling-tools https://agenticmap.co/node/error-handling-tools Tools must return informative, structured error messages that help the model understand what went wrong and decide what to do next, rather than throwing opaque exceptions that crash the agent loop. Well-designed error handling includes error codes, human-readable descriptions, and suggested retry strategies: the difference between "Error 500" and "Rate limited: retry after 30 seconds" determines whether an agent recovers gracefully or loops forever. The most effective pattern returns errors as structured data within the tool's normal response schema rather than raising exceptions, keeping the agent in its reasoning loop where it can choose to retry, try an alternative tool, or escalate to a human. tool-design https://agenticmap.co/node/idempotent-tools https://agenticmap.co/node/idempotent-tools An idempotent tool produces the same result regardless of how many times you call it with the same arguments, making it safe to retry on failure without causing unintended side effects. This property is critical for agent systems because agents frequently retry failed tool calls, and without idempotency a retry could create duplicate records, send duplicate messages, or double-charge a payment. Designing tools to be idempotent by default, using unique request IDs, upsert operations, and check-before-act patterns, is one of the most important reliability practices for production agent systems. tool-design https://agenticmap.co/node/resilient-contracts https://agenticmap.co/node/resilient-contracts Resilient tool contracts come after tool design in the learning sequence because you first need a working tool interface before you can reason about keeping it stable as the system evolves around it. A resilient contract locks the input schema, error surface, and output format so that updates to the underlying implementation never silently break the agent calling it. The sharpest risk here is not a hard crash but a silent failure: when a schema changes without a version bump, the agent continues generating tool calls using the old shape, producing malformed requests that fail in ways that are difficult to trace back to a schema mismatch. tool-design https://agenticmap.co/node/micro-vs-god-tools https://agenticmap.co/node/micro-vs-god-tools The micro-tools vs god-tools spectrum defines the core granularity decision in tool design: whether to give an agent many small, focused tools like read_file and write_file, or fewer large multi-capability tools like a manage_codebase tool with subcommands. Micro-tools are easier for agents to learn and compose, produce interpretable execution traces, and fail in contained ways, but they require more tool calls and more context tokens to describe all available options. Production systems tend toward micro-tools with clear naming conventions because models consistently perform better when tool selection is unambiguous, with strategic exceptions when atomicity matters, such as combining "create file and add to git" into a single tool. tool-design https://agenticmap.co/node/mcp-server-primitives-tools https://agenticmap.co/node/mcp-server-primitives-tools Tools are one of the Model Context Protocol's (MCP) three server primitives, representing executable actions that an agent can discover and invoke through the protocol, such as querying a database, creating a file, sending a message, or triggering a deployment. Each tool carries a name, description, and JSON Schema for its input parameters, following the same patterns as native function calling but standardized across MCP so any conforming client can use any conforming server's tools. Tools are the primary mechanism by which agents affect the external world through the protocol layer, which makes tool design decisions, including naming, scope, and error handling, directly determine how reliably agents can complete real tasks. mcp-protocols https://agenticmap.co/node/mcp-server-primitives-prompts https://agenticmap.co/node/mcp-server-primitives-prompts Prompts are one of the Model Context Protocol's (MCP) three server primitives, representing reusable prompt templates that a server exposes for agents and users to invoke by name with parameters. Unlike tools, which execute actions, and resources, which expose data, prompts provide pre-built interaction patterns, such as "summarize this document" or "review this code," that encapsulate domain expertise into discoverable, parameterized templates. This primitive is particularly valuable for organizations that want to standardize how their teams interact with AI across different tools and clients, because domain experts can craft effective prompt patterns once and share them through MCP servers without each developer recreating them. mcp-protocols https://agenticmap.co/node/mcp-server-primitives-resources https://agenticmap.co/node/mcp-server-primitives-resources Resources are one of the Model Context Protocol's (MCP) three server primitives, representing data that a server exposes for an agent to read, such as files, database records, API responses, or live system state, identified by URIs that the agent or client retrieves on demand. Unlike tools, which perform actions, resources are passive data sources that let agents dynamically discover and pull in relevant information rather than requiring everything pre-loaded into the initial context. This primitive addresses the context engineering problem at the protocol level: instead of stuffing everything into a system prompt, a developer exposes resources that the agent requests as needed, keeping the context window focused on what actually matters. mcp-protocols https://agenticmap.co/node/mcp-overview https://agenticmap.co/node/mcp-overview The Model Context Protocol (MCP) is an open standard that gives AI models a universal interface for connecting to external tools, data sources, and services, analogous to how USB-C gives hardware a universal connector. Instead of building custom integrations for every tool-and-model combination, developers write one MCP server that any conforming client, including Cursor, Claude Desktop, and future agents, can discover and use without modification. Understanding MCP is foundational to modern agentic architecture because it determines how agents discover their capabilities and interact with the external world. mcp-protocols https://agenticmap.co/node/a2a-protocol https://agenticmap.co/node/a2a-protocol The Agent-to-Agent (A2A) protocol, introduced by Google, defines a standard for how independent AI agents discover each other, assign tasks, and exchange messages, filling the gap that the Model Context Protocol (MCP) leaves by covering agent-to-tool connections but not agent-to-agent coordination. Where MCP standardizes how a single agent connects to tools and data sources, A2A standardizes how one agent hands off work to another, enabling a planning agent to delegate to a research agent or a coding agent to coordinate with a testing agent. A2A is still early in adoption, but it signals the direction the ecosystem is moving: from individual agents augmented by tools toward networks of specialized agents that compose like software modules. mcp-protocols https://agenticmap.co/node/mcp-transport https://agenticmap.co/node/mcp-transport The Model Context Protocol (MCP) defines two transport mechanisms for communication between clients and servers: stdio (standard input/output) for local processes, and Server-Sent Events (SSE) over HTTP for remote servers, with both using JSON-RPC 2.0 as the message format. Stdio transport runs the MCP server as a child process of the client, making it ideal for IDE integrations and local tools where latency and reliability are paramount, while SSE transport connects to remote servers over the network for cloud-hosted integrations. Transport choice constrains your deployment architecture in concrete ways: a stdio-based server cannot serve multiple clients simultaneously, while an SSE server introduces network latency and authentication complexity that your implementation must address. mcp-protocols https://agenticmap.co/node/mcp-client-roots https://agenticmap.co/node/mcp-client-roots When your Model Context Protocol (MCP) client connects to a server, it declares roots: the specific filesystem paths or resource boundaries the server is allowed to operate within. Without roots, a server has no authoritative scope, and different server implementations resolve this ambiguity differently — some default to the working directory, some attempt to infer scope from the first tool call, and some operate on the full filesystem until explicitly constrained. The consequence of getting scoping wrong is not just a security exposure; it is an agent that silently reads or modifies files outside your project, producing changes you did not intend and cannot easily trace back to a misconfigured boundary. mcp-protocols https://agenticmap.co/node/mcp-security https://agenticmap.co/node/mcp-security The Model Context Protocol (MCP) creates a standardized channel through which language models can invoke external actions, making it both a useful integration layer and a potential attack surface that requires deliberate hardening. Key security concerns include transport security (encrypting and authenticating messages between clients and servers), input validation (preventing prompt injection attacks that could trick the model into invoking dangerous tools), and capability scoping (ensuring servers expose only the minimum capabilities each use case requires). The protocol's trust model places critical responsibility on the client application, which must evaluate tool call requests from the model and decide whether to execute them, often requiring human approval for destructive operations. mcp-protocols https://agenticmap.co/node/mcp-client-architecture https://agenticmap.co/node/mcp-client-architecture Model Context Protocol (MCP) client architecture defines how host applications, such as IDE agents, CLI tools, and custom agents, implement the client side of MCP: discovering servers, negotiating capabilities, managing connections, routing tool calls, and handling session lifecycle. The client is the trust boundary in the MCP ecosystem, deciding which tool call requests from the model to execute, which servers to connect to, and what permissions to grant, making client design the primary security control point. Most developers interact with MCP through existing clients like Claude Desktop or Cursor, but building a custom client unlocks the ability to create specialized agent systems that compose MCP servers in novel ways. mcp-protocols https://agenticmap.co/node/react-pattern https://agenticmap.co/node/react-pattern The Reasoning and Acting (ReAct) pattern is the foundational architecture where agents alternate between thinking steps and tool calls in a loop, combining chain-of-thought reasoning with grounded actions. Each cycle produces a thought (the model's reasoning about what to do next), an action (a tool call or output), and an observation (the result of the action) that feeds the next iteration; most modern agent frameworks use this pattern because the visible reasoning chain lets you understand why the agent chose a particular action without needing to instrument the model internals. Recognizing the pattern's failure modes, including unbounded loops, reasoning drift, and error compounding, is what drives the need for more constrained patterns like state machines, making ReAct the essential baseline to understand before any other architecture makes sense. architecture https://agenticmap.co/node/orchestrator-pattern https://agenticmap.co/node/orchestrator-pattern The orchestrator pattern uses a central agent that breaks complex tasks into subtasks, delegates them to specialized worker agents, and then synthesizes the results into a final output. This is the most common multi-agent architecture in production because it provides clear control flow: the orchestrator decides what to do, who does it, and when the task is complete, while avoiding the complexity of fully autonomous agent swarms. The pattern works best when subtasks have clear boundaries and can run independently, but the key design challenge is context management, specifically tracking the state of all subtasks and routing the right information to each worker without losing coherence when one worker returns an unexpected result. architecture https://agenticmap.co/node/multi-agent-architectures https://agenticmap.co/node/multi-agent-architectures Multi-agent architectures coordinate multiple specialized agents to complete complex tasks that exceed what a single agent can handle, distributing work across agents that each focus on a narrow capability with a smaller, more manageable context window. Common patterns include supervisor architectures (one agent manages others), swarm patterns (agents dynamically hand off to each other), and parallel execution (multiple agents work simultaneously on separate subtasks). The most important design principle is to exhaust single-agent solutions first, because multi-agent complexity is rarely justified by the problem and usually reflects insufficient tool design or context engineering rather than a genuine need for distribution. architecture https://agenticmap.co/node/single-agent-patterns https://agenticmap.co/node/single-agent-patterns A single-agent architecture assigns one agent full responsibility for a task from start to finish, using tools without delegating to other agents or routing through an orchestrator. This pattern keeps coordination overhead at zero and makes debugging straightforward: you have one reasoning chain to inspect, one set of tool calls to trace, and one system prompt to tune. The signal that you have actually hit the ceiling of single-agent capability is not task complexity in the abstract, but a specific failure mode: the agent is succeeding at each individual step yet producing a wrong final result because no single context window can hold all the state and history the task requires simultaneously. architecture https://agenticmap.co/node/planning-patterns https://agenticmap.co/node/planning-patterns Planning patterns address how agents decompose complex goals into sequences of concrete steps before executing them, rather than reacting one action at a time without foresight. When an agent executes without a plan, it makes locally optimal decisions that are globally incoherent: it writes a function that solves step 3 before understanding what step 5 requires, producing work that must be thrown away when the later constraint surfaces. Approaches range from plan-then-execute (generate a full plan upfront, then follow it) to iterative replanning (adjust the plan after each step based on results) to hierarchical planning (decompose into subgoals, then subgoals into tasks); the best production systems combine upfront planning with the flexibility to replan mid-task, because static plans go stale the moment an early step produces an unexpected result. architecture https://agenticmap.co/node/supervision https://agenticmap.co/node/supervision Supervision patterns govern how agent behavior gets monitored and controlled in production through a combination of human-in-the-loop checkpoints, automated guardrails, escalation policies, and anomaly detection. A supervisor can approve high-risk actions before execution, catch errors before they propagate downstream, and enforce policy constraints on agent behavior, acting as a safety layer between the agent's intentions and the real world. The guiding escalation principle is action reversibility: any action that cannot be undone, such as deleting a file, writing to a production API, or pushing code to a repository, requires explicit human approval before execution, while reversible actions can proceed autonomously with logging. architecture https://agenticmap.co/node/pipeline-pattern https://agenticmap.co/node/pipeline-pattern The pipeline pattern chains agent steps in a fixed sequence where each step's output becomes the next step's input, creating a predictable, linear workflow for tasks with well-defined stages. Unlike the orchestrator pattern, where the directing agent decides the order dynamically, pipelines enforce a predetermined sequence such as lint, then test, then fix, then verify, making them more deterministic and easier to monitor in production. The key limitation practitioners hit is that pipelines cannot handle dynamic branching: the moment your task requires a conditional decision mid-flow, such as "if tests pass, proceed; if they fail, diagnose the error and retry," the fixed sequence breaks down and you need an orchestrator or state machine instead. architecture https://agenticmap.co/node/error-recovery https://agenticmap.co/node/error-recovery Error recovery patterns determine how agents detect, respond to, and continue working after failures during execution, from tool call errors and malformed outputs to reasoning dead-ends and infinite loops. Common recovery strategies include retry with backoff for transient failures, fallback models when one provider is unavailable, context truncation when hitting window limits, and graceful degradation that completes partial work rather than failing entirely. The central architectural decision is whether to let the agent self-recover by including the error in its context and asking it to reason about alternatives, or to handle failures programmatically in the host application, and in production systems this choice determines the difference between 60% and 99% task completion rates. architecture https://agenticmap.co/node/orchestrator-worker https://agenticmap.co/node/orchestrator-worker The orchestrator-worker pattern is the most common production multi-agent architecture: a central orchestrator agent manages a pool of specialized worker agents, dynamically assigning subtasks based on each worker's capabilities and the requirements of the current step. Unlike the simpler orchestrator pattern where the orchestrating agent does all reasoning and merely delegates execution, the orchestrator-worker pattern gives workers genuine autonomy, each running its own agent loop with its own tools and system prompt, making independent decisions within the scope of its assigned subtask. The key design challenge is the handoff contract, meaning how the orchestrator and workers communicate results, errors, and progress without creating tight coupling that defeats the purpose of specialization. architecture https://agenticmap.co/node/state-machine-agents https://agenticmap.co/node/state-machine-agents State machine agents enforce explicit transitions between well-defined phases (gather requirements, plan, implement, test, review), while pure ReAct (Reasoning and Acting) agents let the model freely choose the next action at each step based on its own reasoning, representing a trade-off between predictability and flexibility. State machines excel when the workflow has a known structure and auditability matters, because every transition is explicit and observable; pure ReAct excels when the task is open-ended and the optimal action sequence cannot be predetermined upfront. The practical tradeoff a production team faces is that state machines give you auditability and predictability at the cost of requiring you to enumerate every state in advance, which fails for open-ended tasks where the necessary states only become apparent once work begins. architecture https://agenticmap.co/node/short-term-memory https://agenticmap.co/node/short-term-memory Short-term memory is the conversation history an agent carries within a single session: the messages array passed to each API call, which persists across turns but resets when the session ends. Without it, every agent response would be stateless and context-blind, making multi-step tasks impossible since the agent would forget what it was doing between each tool call. The failure mode of poor short-term memory management is subtle: an agent with a naively pruned or summarized history loses track of decisions it made two steps ago and either contradicts itself or repeats work it already completed, so production systems use relevance-weighted pruning and targeted summarization to keep the right context, not just the most recent context. memory-knowledge https://agenticmap.co/node/rag-patterns https://agenticmap.co/node/rag-patterns Retrieval-Augmented Generation (RAG) patterns address how agents dynamically retrieve relevant information from external knowledge sources and inject it into the model's context before generating a response. The core pattern involves chunking documents into segments, embedding them as vectors, storing them in a vector database, and at query time, retrieving the most semantically similar chunks to include in the prompt. Advanced RAG patterns include multi-step retrieval (using an initial retrieval to refine the query), hybrid search (combining semantic and keyword matching), re-ranking (using a second model to score relevance), and agentic RAG (letting the agent decide when and what to retrieve); understanding these variations matters because the right pattern depends heavily on your knowledge structure, query patterns, and latency budget. memory-knowledge https://agenticmap.co/node/long-term-memory https://agenticmap.co/node/long-term-memory Long-term memory lets agents persist and retrieve information across sessions, maintaining knowledge about user preferences, past interactions, learned facts, and project-specific context that survives beyond a single conversation. Implementation approaches include vector database storage for semantic retrieval, structured databases for explicit facts and relationships, and file-based persistence such as CLAUDE.md files that encode project knowledge in plain text. The primary challenge is retrieval quality: storing memories is straightforward, but reliably surfacing the right memory at the right moment requires careful indexing, relevance scoring, and decay mechanisms to prevent stale information from polluting the agent's context. memory-knowledge https://agenticmap.co/node/memory-types https://agenticmap.co/node/memory-types Agent memory systems divide into distinct types that mirror cognitive science categories, each solving a different persistence and retrieval challenge: short-term memory holds conversation history within a session, working memory tracks in-progress task state through scratchpads and variables, long-term memory persists facts across sessions in vector databases or knowledge bases, and episodic memory logs past interactions so agents can learn from previous experience. Understanding these categories is foundational because choosing the right memory type for each piece of information determines whether your agent maintains coherent state across complex multi-step tasks. The architectural decision of what to remember, for how long, and how to retrieve it is one of the highest-leverage design choices in any agent system. memory-knowledge https://agenticmap.co/node/embedding-models https://agenticmap.co/node/embedding-models Embedding models convert text, code, and other content into dense numerical vectors that capture semantic meaning, enabling similarity-based search and retrieval across agent memory systems. These vectors power retrieval-augmented generation (RAG) pipelines, semantic code search, and long-term memory retrieval by letting agents find conceptually similar content rather than relying on exact keyword matching. Embedding model choice breaks retrieval even when your vector database, chunking strategy, and query logic are all correct: a general-purpose model trained on web text has no representation for identifiers like `ctx.WithDeadline` or `BATCH_FLUSH_INTERVAL` as meaningful concepts, so queries using your codebase's own vocabulary return near-random neighbors, and the agent silently retrieves the wrong context on every call. memory-knowledge https://agenticmap.co/node/knowledge-graphs https://agenticmap.co/node/knowledge-graphs A knowledge graph represents information as a network of entities and relationships, providing structured, queryable knowledge that complements the unstructured retrieval of vector-based retrieval-augmented generation (RAG) systems. Vector similarity search breaks down on relationship queries: ask "which services does the payments module depend on, and which of those have open security advisories?" and the retriever returns semantically similar documents rather than traversing a dependency chain — producing an answer that sounds plausible but misses half the affected services. Knowledge graphs preserve those explicit connections so agents can follow chains of relationships that no embedding can encode. The trade-off is construction cost: building an accurate graph requires structured extraction, entity resolution, and ongoing updates, which is significantly more effort than embedding documents into a vector database. memory-knowledge https://agenticmap.co/node/vector-databases https://agenticmap.co/node/vector-databases Vector databases store and search over high-dimensional numeric embeddings using similarity metrics like cosine distance, enabling semantic search that finds documents by meaning rather than exact keyword match, for example letting an agent query a codebase with "functions that handle authentication" instead of a grep-style string search. They form the storage layer for most retrieval-augmented generation (RAG) systems, providing the infrastructure that gives agents access to knowledge that does not fit within a single context window. Key options include Pinecone, Weaviate, Chroma, Qdrant, and pgvector for Postgres, each with different trade-offs around managed versus self-hosted deployment, query performance, and scale. memory-knowledge https://agenticmap.co/node/memory-management https://agenticmap.co/node/memory-management Memory management governs when agents store new memories, how they retrieve relevant ones, and when they evict or summarize old information to stay within operational limits. The practical decision you face at every context boundary is not whether to save information but how: summarization compresses a long conversation into a durable paragraph the agent can reference later, truncation simply drops the oldest turns and accepts the loss, and explicit forgetting removes entries that are outdated or contradictory rather than just old. Choosing wrong here produces the most common agent failure pattern: an agent that truncates mid-task loses the constraints set at the start of the session and spends three steps rediscovering them, while an agent that never forgets fills its context with stale state that actively misleads its next decision. memory-knowledge https://agenticmap.co/node/graph-vs-vector-rag https://agenticmap.co/node/graph-vs-vector-rag Vector retrieval-augmented generation (RAG) finds information based on semantic similarity (locating chunks that "sound like" the query), while Graph RAG traverses structured relationships between entities (finding information that is "connected to" the query), and understanding when each approach excels determines the quality of your agent's knowledge retrieval. Vector RAG handles open-ended questions well when the answer lives in a specific passage, but it struggles when the answer requires connecting multiple pieces of information across a knowledge base, which is exactly where Graph RAG excels through multi-hop traversal and explicit entity relationships. The emerging best practice combines both: vector search handles initial discovery and graph traversal handles structured exploration, with each approach covering the other's weaknesses. memory-knowledge https://agenticmap.co/node/episodic-semantic-memory https://agenticmap.co/node/episodic-semantic-memory Episodic memory stores specific past experiences tied to a time and context (what happened during a particular debugging session, how the agent resolved a specific error), while semantic memory stores general, abstracted knowledge (project conventions, API patterns, architectural decisions) that the agent applies across many future tasks. Episodic memories are most useful for avoiding repeated mistakes: an agent that recalls "last time I tried this approach it failed and required a full rollback" can make better decisions than one that starts fresh every session. When episodic memories are never converted into semantic ones, the agent cannot generalize — it will fix the same class of bug four times in four sessions because each fix was stored as an isolated event rather than compressed into a rule it can apply on first recognition. memory-knowledge https://agenticmap.co/node/eval-driven-development https://agenticmap.co/node/eval-driven-development Eval-driven development treats evaluations as first-class development artifacts, measuring agent behavior against defined criteria before, during, and after every change, analogous to test-driven development but designed for non-deterministic AI systems. Instead of manually checking "does this seem right?", eval-driven teams build evaluation datasets that encode expected behavior and run them automatically whenever prompts, tools, or models change. Without systematic evaluation, prompt changes that improve one use case silently degrade others, creating a whack-a-mole dynamic that prevents meaningful improvement, and research consistently shows that subjective assessment underperforms even simple automated evals at detecting regressions. agentic-workflow https://agenticmap.co/node/debugging-agents https://agenticmap.co/node/debugging-agents Debugging agentic systems requires fundamentally different approaches from debugging traditional software because agent behavior is non-deterministic, multi-step, and depends on both the model's reasoning and the tool responses it receives. The core workflow involves inspecting traces (the full sequence of thoughts, actions, and observations), comparing expected versus actual tool call parameters, and identifying where the agent's reasoning diverged from the intended path. Unlike traditional debugging where you set breakpoints in deterministic code, agent debugging often involves replaying the same prompt and getting different behavior each time, which makes trace logging and structured observability essential infrastructure rather than optional tooling. agentic-workflow https://agenticmap.co/node/prompt-iteration https://agenticmap.co/node/prompt-iteration Prompt iteration is the practice of systematically improving prompts through testing, measurement, and refinement rather than ad-hoc trial and error. Effective prompt iteration treats prompts like code: teams use version control, evaluation suites, and side-by-side comparison to converge on better instructions, rather than relying on intuition or anecdotal feedback from a single session. Small changes to prompts can produce large, non-obvious shifts in agent behavior, so the developers who get the best results are those who instrument their prompts, measure outputs quantitatively, and iterate on data rather than gut feeling. agentic-workflow https://agenticmap.co/node/spec-driven-development https://agenticmap.co/node/spec-driven-development Spec-driven development means writing a detailed specification before letting an agent write code, giving the agent explicit success criteria, constraints, edge cases, and architectural context instead of a vague natural language request. The gap between "build me a login page" and a structured spec that defines auth flow, error states, styling conventions, and API contracts is the gap between throwaway code and production-ready output. A spec also becomes a natural review artifact: comparing the implementation against the written spec makes code review faster and more focused than reading code with no declared intent. agentic-workflow https://agenticmap.co/node/pair-programming https://agenticmap.co/node/pair-programming Pair programming with an agent means working alongside it in real-time as a collaborative coding partner, where you provide direction, catch mistakes early, and guide the agent through ambiguous decisions while it handles implementation velocity and mechanical consistency. This is the most common daily workflow for developers using agentic coding tools, and the quality of your prompts and corrections during a session directly determines the output: human judgment is the critical bottleneck, not model capability. The most important habit to build early is staying engaged rather than passively accepting suggestions, because blind trust in agent output compounds into architectural debt that is far harder to fix later. agentic-workflow https://agenticmap.co/node/ci-cd-agents https://agenticmap.co/node/ci-cd-agents Continuous integration and delivery (CI/CD) agents integrate agentic capabilities into deployment pipelines, automatically fixing failing tests, resolving dependency conflicts, managing infrastructure changes, and responding to pipeline alerts without human intervention at each step. These agents trigger on CI events such as build failures, test regressions, or security scan alerts, then autonomously branch, fix, commit, and open pull requests, extending the agentic coding paradigm from development-time assistance into fully automated pipeline operations. CI/CD pipelines are one of the better environments for autonomous agents because they provide well-defined success criteria, tests must pass and builds must succeed, and the infrastructure already enforces branch protection, test gates, and rollback mechanisms that naturally limit blast radius. agentic-workflow https://agenticmap.co/node/agentic-git-workflow https://agenticmap.co/node/agentic-git-workflow Working with agentic coding tools requires adapting your git habits to account for the volume and nature of AI-generated changes: create a dedicated branch for each agentic task, commit frequently so you can bisect and revert if the agent introduces regressions, and write descriptive commit messages that indicate AI involvement. The most effective mental model is treating each agent session like a junior developer's work session: give it a clear branch and a scoped task, then review the diff before merging rather than accepting the output wholesale. This discipline becomes critical as agents generate larger changesets, because without it you lose the ability to distinguish intentional modifications from accidental ones at review time. agentic-workflow https://agenticmap.co/node/code-review-workflow https://agenticmap.co/node/code-review-workflow Reviewing AI-generated code before it merges into the main codebase is the most important quality gate in any agentic workflow, and it requires a different mental model than reviewing human code: agents produce syntactically correct output that may be architecturally wrong, subtly misaligned with project conventions, or solving the right problem with the wrong abstraction. Effective AI code review focuses on intent alignment (did the agent build what you actually asked for?), architectural consistency (does it follow existing patterns?), and edge case coverage (does it handle error paths?) rather than syntax and formatting, which agents already handle reliably. The highest-leverage habit is reviewing the diff, not the final file state, because understanding what changed and why exposes mistakes that reading the output in isolation would miss. agentic-workflow https://agenticmap.co/node/tdad https://agenticmap.co/node/tdad Test-Driven Agentic Development (TDAD) adapts the classic test-driven development cycle for agent-assisted coding: you write tests first and then direct the agent to implement until all tests pass, using the test suite as executable specifications that define correctness rather than leaving that definition to natural language. This inverts the typical agent interaction, where you describe what you want and hope the agent interprets it correctly; instead, the tests encode your requirements unambiguously and the agent iterates until they pass. The trade-off is that writing good tests requires upfront domain knowledge, but this investment pays back through higher first-attempt success rates and fewer review cycles compared to open-ended implementation prompts. agentic-workflow https://agenticmap.co/node/autonomous-ci-cd https://agenticmap.co/node/autonomous-ci-cd Autonomous continuous integration and deployment (CI/CD) extends traditional pipeline automation by giving agents the ability to respond to pipeline events without human involvement: a failing build triggers an agent that diagnoses the cause, writes a fix, runs the test suite, and opens a pull request before a developer notices the failure. This represents the highest level of agent autonomy in the software development lifecycle, and it only works safely when the system enforces strict guardrails including mandatory test gates, human review requirements for production-bound changes, rollback triggers, and blast radius limits that prevent a fix from causing cascading failures. The patterns you establish here, around trust boundaries, approval gates, and rollback conditions, will inform how your organization approaches agentic automation in every other part of the development lifecycle. agentic-workflow https://agenticmap.co/node/trace-analysis https://agenticmap.co/node/trace-analysis A trace is the full recorded sequence of an agent's decisions, tool calls, inputs, outputs, and intermediate results across a single task execution, giving you a complete audit trail of every step the agent took. Without traces, agent failures are opaque: you see a wrong answer but cannot determine whether reasoning went wrong, a tool returned bad data, or the agent misread its context; traces make non-deterministic failures understandable and fixable. In production, traces also surface performance problems such as which tool calls are slow, which reasoning steps waste tokens, and where the agent loops unnecessarily. eval-observability https://agenticmap.co/node/cost-tracking https://agenticmap.co/node/cost-tracking Cost tracking monitors and attributes the token and API expenditure of agent systems, giving you financial visibility into what individual tasks, workflows, and users actually cost to serve. In agentic systems, costs are unpredictable in a way that standard API usage is not: reasoning depth, tool call count, and context window size all multiply against each other, so a task that takes 3 tool calls at 2k tokens each costs an order of magnitude less than one that takes 40 calls at 8k tokens each, and neither outcome is knowable in advance. Effective cost tracking aggregates at multiple levels from per-call token counts to per-task totals to per-workflow trends, giving you the data needed to distinguish normal variation from a runaway loop, target optimization efforts, and set defensible prices. eval-observability https://agenticmap.co/node/observability-platforms https://agenticmap.co/node/observability-platforms Observability platforms capture, store, and visualize the full execution telemetry of agent systems — traces, token usage, latency, cost, tool calls, and reasoning chains — giving you the production monitoring infrastructure that makes agents debuggable at scale. Observability comes before optimization in this sequence for a concrete reason: without a trace showing you which step consumed 40 of a 45-second run, any optimization attempt is a guess, and you will just as likely make things slower. Unlike traditional application performance monitoring tools built for deterministic software, large language model observability platforms handle non-deterministic systems where "errors" are often subtle reasoning failures rather than thrown exceptions, and tools like LangSmith and Arize Phoenix are built specifically to surface those failures. eval-observability https://agenticmap.co/node/eval-frameworks https://agenticmap.co/node/eval-frameworks Evaluation frameworks provide standardized tooling for defining test cases, running them against agent systems, and comparing results across different configurations of prompts, models, and tools. Key options include Promptfoo (an open-source CLI tool for comparing prompt variations), Braintrust (an end-to-end eval platform with trace analysis), and LangSmith (eval and observability integrated into the LangChain ecosystem), each handling the infrastructure that makes eval-driven development practical: test case management, parallel execution, regression detection, and human review for ambiguous outputs. The choice of eval framework shapes your entire quality improvement loop because it determines how easily you can run experiments, measure the impact of changes, and share results with the team. eval-observability https://agenticmap.co/node/ab-testing-agents https://agenticmap.co/node/ab-testing-agents A/B testing for agents means running two or more configurations, such as different prompts, models, or tool sets, against live production traffic simultaneously and measuring which one performs better on metrics that actually matter in your system. Offline evaluations on curated datasets tell you what a configuration can do in controlled conditions, but A/B tests reveal how it behaves against real users, real edge cases, and real environmental factors that no test suite anticipates. The core difficulty is that agent outputs are multidimensional: one configuration might be faster but less accurate, or cheaper but more prone to hallucination, so you need a weighted scoring model rather than a single conversion metric to declare a winner. eval-observability https://agenticmap.co/node/quality-metrics https://agenticmap.co/node/quality-metrics You cannot improve what you cannot measure, and most agent quality is not obviously measurable: task completion looks binary but collapses when you ask whether the task was completed correctly, efficiently, and safely at the same time. The metrics teams actually track in production are task completion rate, correctness, token and tool-call efficiency, latency, and error rate; the metrics they aspire to track, like code quality or architectural appropriateness, resist automated measurement and require a large language model acting as a judge or periodic human review. Defining metrics before building is critical because they determine what you optimize for: measuring only completion rate produces agents that technically finish tasks with low-quality output, while ignoring cost and latency produces agents that are correct but too slow or expensive to run. eval-observability https://agenticmap.co/node/latency-optimization https://agenticmap.co/node/latency-optimization Latency optimization reduces the end-to-end time for agent task completion through techniques like streaming responses, parallel tool calls, model routing for speed, prompt compression, and caching. In multi-step agent loops, latency compounds across iterations: a 2-second inference call in a 10-step task means 20 seconds of model time alone, making per-step optimization critical for user-facing applications. Most developers encounter this bottleneck sooner than they expect because the levers that matter most — streaming first tokens to the UI before the full response is ready, issuing independent tool calls in parallel rather than sequentially, and caching repeated retrieval queries — are each a separate implementation decision, and leaving any one of them at its default roughly doubles the time the user sits waiting. eval-observability https://agenticmap.co/node/regression-testing https://agenticmap.co/node/regression-testing Regression testing for agent systems verifies that changes to prompts, tools, models, or configurations don't break previously working behavior, catching the "fixed one thing, broke three others" pattern that is endemic to non-deterministic systems. The core challenge that makes this harder than traditional software regression testing is that agent outputs are probabilistic: a test that passed yesterday can fail today on identical input with no code change, because sampling temperature and model inference introduce variance that binary pass/fail assertions cannot absorb. This means agent regression suites require a different approach, using snapshot testing against golden examples, statistical quality measurement across a test suite, or canary deployments that monitor live traffic for degradation rather than asserting a single expected output. eval-observability https://agenticmap.co/node/deterministic-evals https://agenticmap.co/node/deterministic-evals You build deterministic evaluations first because they are the cheapest and fastest to run: fixed, rule-based criteria with binary pass/fail outcomes (does the output match the expected regex? does the code compile? do all required fields appear in the JSON?) give you an immediate feedback loop that costs fractions of a cent per run. Probabilistic evaluations use statistical methods or a language model acting as a judge to assess quality on a spectrum, capturing nuanced dimensions like helpfulness or reasoning quality that resist reduction to a rule, but they introduce variance that requires larger sample sizes to trust. The most effective evaluation suites layer both, using deterministic checks as fast guardrails for format validation and regression testing while reserving probabilistic assessment for the quality dimensions that determine whether users are actually satisfied. eval-observability https://agenticmap.co/node/least-privilege https://agenticmap.co/node/least-privilege The principle of least privilege dictates that agents receive only the minimum permissions needed to complete their assigned task, nothing more. This principle is foundational for agentic systems because agents are inherently unpredictable: a well-designed agent can still be manipulated through prompt injection, make reasoning errors, or hit unexpected edge cases that lead to unintended actions. In practice, least privilege means giving a code review agent read-only repository access rather than write access, limiting a database agent to SELECT queries rather than DELETE, and ensuring file system agents operate within scoped directories rather than at the root level. security-safety https://agenticmap.co/node/data-exfiltration https://agenticmap.co/node/data-exfiltration Data exfiltration in agentic systems occurs when an agent sends sensitive information, such as API keys, source code, customer data, or environment variables, to unauthorized external destinations. This happens through prompt injection (a malicious instruction tells the agent to include secrets in an outbound tool call), through tool misuse (the agent includes sensitive data in a response), or through context leakage (conversation history containing secrets reaches an unintended party). The risk increases sharply in agentic coding tools because they typically have access to the full project environment, including .env files, git history, and production credentials, so defending against exfiltration requires output filtering, network-level controls on which endpoints agents can reach, and secret management practices that keep sensitive values out of agent-accessible paths. security-safety https://agenticmap.co/node/prompt-injection https://agenticmap.co/node/prompt-injection Prompt injection is the primary attack vector against language model-based systems, where malicious input manipulates the model into ignoring its system instructions and executing unintended actions instead. Direct prompt injection embeds malicious instructions in user input, while indirect prompt injection hides instructions in data the agent retrieves, such as a malicious comment in a code file or a manipulated web page an agent processes during a tool call. This threat is especially dangerous for agent systems because agents take real-world actions: a successful injection against a coding agent can result in data exfiltration, code deletion, or unauthorized access rather than just a misleading text response, and no complete technical defense yet exists, making mitigation a defense-in-depth problem combining input filtering, output validation, privilege separation, and human oversight. security-safety https://agenticmap.co/node/permission-models https://agenticmap.co/node/permission-models Permission models apply the principle of least privilege to agents: each agent receives only the access it needs to complete its assigned task, nothing more. This topic appears after the autonomy spectrum in the learning sequence because you cannot design meaningful permissions until you know what level of autonomy you are granting. An agent that only reads files needs a very different permission boundary than one that writes to a database or calls external APIs, and the cost of getting it wrong scales with the autonomy level: a highly autonomous agent with overly broad permissions converts any prompt injection into a system-wide breach. security-safety https://agenticmap.co/node/compliance https://agenticmap.co/node/compliance Compliance in agentic systems addresses the regulatory, legal, and organizational requirements that govern how AI agents handle data, make decisions, and affect production environments, with key frameworks including the General Data Protection Regulation (GDPR) for data privacy in Europe, SOC 2 for security and availability in software as a service (SaaS) contexts, HIPAA for healthcare data, and the EU AI Act for AI-specific regulation. For agentic coding specifically, compliance concerns cover data residency (where model API calls route and process data), intellectual property (who owns AI-generated code), audit trails (proving what the agent did and why), and access control (ensuring agents only see data they are authorized to access). Building compliance requirements into your agent architecture from the start is far less costly than retrofitting it after deployment, so understanding the regulatory landscape early determines which tools your organization can adopt without creating liability. security-safety https://agenticmap.co/node/audit-logging https://agenticmap.co/node/audit-logging Audit logging creates a tamper-resistant record of every action an agent takes, including tool calls, file modifications, API requests, data access, and decision points, giving you the forensic trail needed for security investigations, compliance audits, and post-incident analysis. Unlike standard application logging, agent audit logs must capture the full reasoning context: not just what the agent did, but what information it had access to and what triggered each decision, because agent behavior is non-deterministic and you cannot reproduce an incident by simply re-running the same input. Organizations evaluating agentic coding tools for enterprise use treat audit logging as a prerequisite rather than a nice-to-have, because without it you cannot prove accountability for AI-initiated changes to regulators, auditors, or your own security team. security-safety https://agenticmap.co/node/owasp-top-10 https://agenticmap.co/node/owasp-top-10 The Open Worldwide Application Security Project (OWASP) Top 10 for Large Language Model Applications catalogs the most critical security risks specific to language model-based systems, giving teams a standardized checklist for identifying and mitigating vulnerabilities in agent systems. The list covers prompt injection, insecure output handling, training data poisoning, model denial of service, supply chain vulnerabilities, sensitive information disclosure, insecure plugin design, excessive agency, overreliance, and model theft. For agentic coding specifically, prompt injection, excessive agency, and sensitive information disclosure are the highest-priority risks, because agents with real-world capabilities amplify the blast radius of each vulnerability far beyond what a chatbot-only deployment would face. security-safety https://agenticmap.co/node/rate-limiting https://agenticmap.co/node/rate-limiting Rate limiting constrains how many actions, application programming interface (API) calls, or tokens an agent can consume within a given time period, preventing runaway loops, denial-of-service conditions, and unexpected cost spikes. Without rate limits, a single malfunctioning agent caught in an infinite retry cycle (retrying a failed tool call every two seconds across a 200-step planning loop) can generate a $400 bill from a single run before any human notices, and that is not a hypothetical edge case but a recurring incident pattern documented across public agent deployments. Effective rate limiting operates at multiple levels: per-call limits (maximum tokens per request), per-session limits (maximum total spend per task), and circuit breakers that halt execution when spend or iteration counts cross a threshold you set before the agent ever starts. security-safety https://agenticmap.co/node/ephemeral-sandboxing https://agenticmap.co/node/ephemeral-sandboxing Ephemeral execution environments are short-lived, isolated sandboxes that the system creates fresh for each agent task and destroys after completion, ensuring no state, credentials, or side-effects persist between executions. This pattern provides the strongest form of isolation for agentic systems: even if prompt injection compromises an agent or the agent makes a destructive mistake, the damage stays contained within a disposable environment that the system then wipes. Technologies like Docker containers, Firecracker microVMs, and cloud-based sandboxes (E2B, Modal) make it practical to spin up a clean environment in seconds, run the agent's work, extract the outputs, and tear everything down, which is especially valuable for agentic coding tasks that involve running arbitrary code, installing packages, or modifying files. security-safety https://agenticmap.co/node/blast-radius https://agenticmap.co/node/blast-radius Blast radius containment is the practice of designing agent systems so that any single failure, error, or security compromise affects the smallest possible scope, using strategies like filesystem scoping to restrict agents to specific directories, network isolation to limit which endpoints they can reach, transaction boundaries to make destructive operations reversible, and resource limits to cap tokens and compute per task. The concept comes from infrastructure engineering, where blast radius describes failure domains, and it applies directly to agentic systems because agents are non-deterministic by nature: you cannot prevent all failures, but you can constrain what any single failure can touch. The most dangerous agent failures are not the ones that crash visibly but the ones that silently corrupt data or make unintended changes that surface hours later, so containment is about limiting the scope of the worst-case outcome, not just preventing the average one. security-safety