Principles of Building AI Agents: 10 Design Rules That Hold Up in Production

Table of Contents

At a Glance

Core idea: An AI agent uses a language model to decide what action to take next, access tools, and repeat the process until it achieves an objective. Many effective systems need far less complexity and should be designed accordingly.
Start here: Anthropic’s engineering guidance separates workflows (predefined code paths) from agents (model-directed control flow). Begin with the simplest option that solves the problem.
Main challenges: Controlling costs, demonstrating value, managing risks, and protecting systems against prompt injection attacks.
Standards to know: The Model Context Protocol (MCP) for tool access and the Agent2Agent protocol (A2A) for agent-to-agent communication, both now under the Linux Foundation’s Agentic AI Foundation.
Reality check: Gartner has forecast that over 40% of agentic AI projects will be canceled by the end of 2027.
Ten principles covered: choosing the right use case, keeping the architecture manageable, building effective tools, handling context, planning tasks, controlling autonomy, testing results, tracking system behavior, protecting against security risks, and using multiple agents only when justified.

Why the Principles of Building AI Agents Matter Right Now

Two years ago, “agent” was mostly a research word. Today it sits in product pages, job titles, and board decks. That shift created a gap between what the word promises and what a working system looks like.

Anthropic’s engineering team emphasizes simplicity and modularity when building effective implementations. Its guide supports the same approach, recommending composable patterns over complex frameworks that can add unnecessary overhead. That observation shapes this entire article.

The market backdrop explains why discipline matters. Gartner has predicted that over 40% of agentic AI projects will be canceled by the end of 2027 because of escalating costs, unclear business value, or inadequate risk controls. Furthermore, the firm drew attention to a practice they label “agent washing,” where suppliers falsely package traditional chatbots and automation utilities as agents. They estimated that out of thousands of vendors advertising agentic products, only about 130 are real.

This certainly does not mean agents are headed nowhere. Gartner itself forecasts steady development, predicting that at least 15% of daily work decisions will occur autonomously via agentic AI by 2028, a jump from 0% in 2024. This pattern echoes previous tech waves: massive potential alongside high failure rates for groups that bypass core fundamentals.

This guide walks readers through those fundamentals by drawing upon official engineering guidance, open protocol specs, and market analytics. It contains no unverified personal experiments or fabricated results. All statistical figures derive from cited sources, and any subjective opinions are explicitly identified as such.

What an AI Agent Actually Is

A Working Definition

An AI agent is a software system in which a language model decides what to do next, takes actions through tools, observes the results, and repeats until it reaches a stopping condition. Three ingredients appear again and again in published guidance: a model, a set of tools, and instructions that define behavior. OpenAI’s agent-building guide frames it the same way.

The word “decides” is the important part. If a developer has hard-coded every step and the model only fills in text along the way, you have an automated pipeline with a model inside. That can be very valuable, but it is a different thing.

For a closer look at how autonomous systems differ from conventional conversational tools, read our guide to AI agents vs. chatbots, which compares their architecture, capabilities, and practical use cases.

Workflows vs. Agents

Anthropic draws a clear architectural line. Workflows are systems where language models and tools are orchestrated through predefined code paths. Rather than relying entirely on a fixed sequence of instructions, an agent can determine what action to take next and which tools may help. Anthropic uses the term “agentic systems” to describe this broader category of AI applications.

Dimension	Workflow	Agent
Control flow	Written in code by developers	Chosen by the model at run time
Predictability	High	Lower
Best fit	Well-defined, repeatable tasks	Open-ended tasks with unpredictable step counts
Cost and latency	Easier to estimate and cap	Vary with how many loops the model takes
Failure behavior	Fails at known points	Can fail in novel ways
Debugging	Trace a fixed path	Trace a decision history

Source basis: Anthropic’s “Building effective agents” engineering guide and its follow-up commentary.

Many production systems sit between the two columns. A workflow with one or two model-directed steps is common and often the right call. Think of it as a dial, not a switch.

To understand the broader terminology, see our comparison of generative AI, AI agents, and agentic AI, which explains how their decision-making and automation capabilities differ.

Principle 1: Start With the Problem, Not the Agent

A sound design begins with a clearly defined task, not a preference for agent-based architecture. Evaluate the problem first and select the implementation approach afterward.

A Fit Check Before You Build

Ask these questions in sequence:

Can plain code solve it? Not every workflow needs a language model. For tasks with known inputs and explicit rules, a conventional program can deliver results with less computational overhead and more straightforward auditing.
Can a single model call solve it? Classification, summarization, extraction, and drafting often need one well-written prompt, perhaps with retrieved context.
Does a fixed sequence of calls solve it? That is a workflow, and it covers a surprising share of real needs.
Is the path genuinely unpredictable? Only then is the added cost and risk of an agent loop warranted.

Anthropic’s guidance recommends exactly this ladder. Good engineering starts with the needs of the task and introduces complexity only when there is a clear reason to do so.

Developers looking for a more implementation-focused learning path can also follow our step-by-step guide to mastering agentic AI, which covers the progression from basic agent concepts to tools, memory, guardrails, and deployment.

Signals That an Agent May Be Justified

The number of steps cannot be known in advance.
The task requires choosing among many tools depending on what earlier steps reveal.
The effort required to produce an answer does not necessarily determine its review cost; a human may be able to check the finished output at minimal expense.
The cost of a wrong action is bounded or reversible.
The value per completed task is high enough to absorb extra model calls.

Software maintenance, research synthesis, and multi-step customer support are frequently cited examples in vendor documentation. Although the steps needed to complete these tasks can change considerably between cases, the outcome can still be evaluated against clear criteria.

Signals That You Should Not Build One

The workflow is the same every time.
Errors are expensive, irreversible, or legally sensitive, and no review step exists.
Latency requirements are tight.
You cannot describe what “done correctly” looks like.

That last point matters most. Evaluation depends on knowing what a correct result looks like. Without that benchmark, neither system quality nor failures can be assessed reliably.

Principle 2: Keep the Architecture as Simple as the Problem Allows

The Core Loop

Strip away the branding and nearly every agent is this loop:

Receive a goal and context.
Obtain the model’s decision about what should happen next, whether that means answering or performing an action.
If the decision involves a tool, invoke the tool that supports the requested operation.

Feed the result back to the model.
Stop when the model finishes, a limit is hit, or a human intervenes.

An agent does not necessarily require a complex architecture at the outset. Anthropic’s guide describes a model enhanced with retrieval, tools, and memory as the foundational arrangement from which more elaborate systems can be assembled.

A practical example of this model-tool-context arrangement is the Claude Agent SDK, which provides an agent loop and development tools for building autonomous coding systems.

Introducing multiple subsystems before validating this foundation can create unnecessary complexity. Planning logic, output reviewers, tool routers, and persistent memory should address demonstrated needs rather than be added by default. Each layer adds failure modes and cost. Add one only when you can name the specific problem it solves.

Five Composable Workflow Patterns

Before adopting an autonomous architecture, consider the alternatives described in Anthropic’s guide. These patterns offer different ways to organize model-driven tasks, and some can solve the problem without an agent running its own decision loop.

Pattern	What it does	Typical fit
Prompt chaining	Splits a task into sequential steps, each model call feeding the next	Drafting then checking; extract then transform
Routing	Classifies input and sends it to a specialized path	Support triage; separating simple from complex requests
Parallelization	Runs independent subtasks at once, or repeats a task for consensus	Multiple reviewers; sectioned analysis
Orchestrator-workers	A central model breaks down the task and delegates to worker calls	Tasks where subtasks are not known ahead of time
Evaluator-optimizer	One call generates, another critiques, and the loop repeats	Translation polish; iterative refinement with clear criteria

Source basis: Anthropic, “Building effective agents.”

A practical reading: each pattern gives you a different trade between predictability and flexibility. You can pick the cheapest pattern that still meets the need.

Frameworks: Helpful, With a Condition

Frameworks speed up setup, but they can hide prompts and responses behind abstractions, making problems harder to diagnose. Before selecting an agent framework, developers can test whether direct API calls are sufficient for the task. Anthropic notes that many patterns require only modest implementation effort and advises developers to understand the code a framework handles on their behalf.

Principle 3: Design Tools Like You Design Products

Models act on the world through tools. A weak tool set is the most frequent reason an otherwise capable model behaves poorly, and tool design deserves as much attention as prompt writing.

Treat the Tool Interface as a User Interface

Anthropic uses the term “agent-computer interface” for the care that goes into tool definitions. The quality of a model’s interaction with a tool depends partly on how clearly that tool is defined and exposed, making interface design important on both the human and machine sides.

Practical guidelines drawn from published vendor documentation:

Name tools by what they do. search_orders communicates more than query_v2.
Write descriptions as if for a new colleague. Include what the tool does, when to call it, what each parameter means, and an example or two.
Keep parameters few and explicit. Constrain values with enumerations where possible.
Return compact, readable results. Dumping a raw database row wastes context and confuses the model.
Write error messages the model can act on. “Expected date format: YYYY-MM-DD” does this more clearly than “Request failed.”
Make tools hard to misuse. If a path must be absolute, require it, rather than hoping the model remembers.

Fewer, Sharper Tools Beat Many Overlapping Ones

When several tools can handle the same request, the model needs clearer distinctions to choose the appropriate one reliably. Consolidating overlapping tools, or writing explicit guidance on when to use each, usually reduces confusion. A tool list is a decision surface, and every extra option is another chance to choose wrong.

Standard Connections: The Model Context Protocol

As the number of models and tools increases, individual integrations create more development and maintenance work. MCP reduces this fragmentation by defining a shared way to provide models with access to application tools, information, and prompts. Anthropic introduced it in November 2024.

Governance has since moved to a neutral home. Three projects illustrate the range of work covered by the Agentic AI Foundation, announced by the Linux Foundation on December 9, 2025. Anthropic contributed MCP, a protocol for linking agents with tools, data, and applications. AGENTS.md addresses how coding agents receive repository-specific instructions, while goose focuses on the runtime needed to execute agents. These projects form part of the foundation’s initial scope. By August 2026, it reported 247 member organizations.

For builders, the practical takeaway is straightforward: where an MCP server already exists for a system you need, prefer it over a custom wrapper, but review what it exposes. A shared interface addresses how tools connect; it does not establish whether their permissions, operations, or outputs are safe.

Principle 4: Make Context and Memory Resources Count

A model’s decisions are based on the context supplied for the current call, within the limits of its context window. Everything an agent “knows” at that moment has to be placed there. This makes context management one of the central engineering problems, not an afterthought.

Layers of Memory

Layer	What it holds	Typical mechanism
Working context	Current goal, recent messages, tool results	The prompt itself
Short-term session state	Progress within a task	Scratchpad notes, structured state objects
Long-term memory	Facts that persist across sessions	Database, files, or vector store, retrieved on demand
External knowledge	Documents, tickets, product data	Retrieval over an index or search tool

Rules That Keep Context Healthy

Load only what the current step needs. More text is not better. Irrelevant material can distract the model.
Summarize or compact long histories. When the conversation exceeds the available context, summarize previous steps without losing important information. Preserve exact technical details, decisions, and constraints that later steps may rely on.
Move durable facts out of the prompt. Write notes to a file or store and retrieve them when needed.
Trim tool outputs. Return the fields that matter.
Separate trusted from untrusted content. Instructions from the developer, content from the user, and text pulled from the web carry different levels of trust. Failing to keep them properly separated can create security risks, as discussed in Principle 9.
Retrieval Is Not Memory

A frequent confusion: retrieval brings in external documents, while memory tracks what the agent itself has learned or done. They often share infrastructure but serve different purposes. Establish whether you are using session state or persistent memory, then identify what is saved, when it is saved, and who or what performs the operation.

Principle 5: Make Planning and Reasoning Visible

Agents tend to work better when they lay out a plan, check it against results, and revise. Anthropic’s recommendations address three important areas of agent development: avoiding unnecessary architectural complexity, creating reliable tool interfaces, and allowing users to understand how an agent plans its actions.

Practical Planning Patterns

Plan first, then act. Ask the model to outline steps before calling tools. This makes behavior easier to review.
Re-plan on surprises. When a tool returns something unexpected, give the model a chance to revise rather than pushing forward.
Base subsequent actions on verified evidence. The agent should inspect the results produced by its tools or code rather than treating an attempted operation as proof of success.
Prevent uncontrolled repetition. Add predefined limits on iterations or execution time, along with a condition that tells the system when the objective has been achieved.

Why Visible Reasoning Helps People, Not Just Models

A readable plan lets a reviewer see where an agent went off course. To understand why an agent failed, examine the sequence of events behind its output. Records of its plans, actions, and observations provide more diagnostic information than the final response alone.

Principle 6: Make Autonomy Adjustable and Keep Humans in the Loop

Autonomy is not binary. The safest way to grow an agent is to widen its permissions gradually as its record justifies it.

A Graded Autonomy Model

*Level*	*Agent behavior*	*Human role*
Suggest	Offers drafts, recommendations, or possible next steps for consideration	Selects the appropriate response and takes action
Act with approval	Prepares actions and waits for sign-off	Approves each consequential step
Act within limits	Performs predefined tasks automatically under established restrictions	Audits selected activities and intervenes when unusual cases arise
Act broadly	Takes a flexible approach to achieving goals, with considerable decision-making authority	Defines the rules and supervises the outcomes

These principles are a synthesis of practices found in industry documentation and engineering guidance, not a proprietary standard or vendor-specific model.

Most teams should begin at the first or second level. Read-only actions (searching, summarizing, drafting) are low risk. Actions that spend money, send messages, delete data, or change records deserve a checkpoint.

Where Human Checkpoints Belong

Before irreversible operations.
Before anything involving payments, credentials, or personal data.
When the agent’s confidence is low or its tools return conflicting information.
After repeated failures on the same step.

OpenAI’s practical guide makes a related point: it recommends planning for human intervention, especially early in a rollout, so that failures surface and can be corrected before autonomy expands.

Principle 7: Build Evaluation Before You Build Features

Without evaluation, every change is a guess. This is the discipline that separates dependable systems from demonstrations.

What to Evaluate

Task success. Did the agent reach a correct outcome?
Reasoning and action quality. Were the intermediate decisions appropriate, regardless of whether the final result was correct?
Accuracy of tool calls. Were the selected tools relevant to the task, and were their arguments correctly specified?

Safety behavior. Did it refuse or escalate when it should?
Cost and latency per task. Both matter in production.

Build Your Own Evaluation Set

Use public benchmarks as background information, not as a substitute for application-specific testing. Develop a test collection that represents the situations your system will encounter in practice. Go beyond straightforward examples by adding incomplete requests, unusual scenarios, and inputs designed to expose weaknesses. Decide how each case should be handled before examining the results. Keep the collection consistent and use it to assess every significant change to the prompt configuration, toolset, or model.

Published Benchmark Comparison

Several public evaluation suites are commonly cited when people compare agent capability. The table below describes what each one is designed to measure.

The scores should not be treated as a fixed comparison between products. They can change over time, so check the source project’s leaderboard for up-to-date results.

Benchmark	What it measures	Why it is relevant	Limitation to keep in mind
SWE-bench (and variants)	Resolving real software issues from open-source repositories	Close to real coding-agent work	Skews toward certain languages and repositories
τ-bench (tau-bench)	Tool-using agents in simulated customer-service domains, with policy rules	Tests rule-following across multi-turn conversations	Simulated users and limited domains
GAIA	General assistant questions needing browsing, reasoning, and tool use	Tests breadth of multi-step problem solving	Question set is fixed and finite
WebArena	Task completion on realistic, self-hosted web environments	Tests browser-based agents	Does not cover the live, changing web

Source basis: each benchmark’s published description. No scores are reproduced here.

Treat any single score with caution. Benchmarks can be narrow, and a system tuned to a benchmark may behave differently on your workload.

Use Models as Judges, Carefully

Having one model grade another’s output is common and scales well, but it needs calibration.

Human reviewers should periodically examine a selection of the judge’s decisions. This helps reveal evaluation patterns that may otherwise go unnoticed, such as favoring detailed or lengthy responses regardless of their actual quality.

Principle 8: Make Everything Observable, and Watch the Cost

When an agent behaves unexpectedly, its final output may not reveal what went wrong. Keeping a detailed execution record makes it easier to trace the problem.

What to Log

Every prompt sent to the model and the corresponding response, with safeguards for confidential data.
All tool interactions, covering the inputs provided and the outputs received.

Token counts, latency, and cost per step and per task.
Final outcomes and any human interventions.

With traces, you can replay a bad run, find where it went wrong, and turn that case into a permanent evaluation example. Without them, you are debugging from anecdotes.

Cost and Latency Are Design Constraints

Each loop iteration is another model call.

Model usage can increase quickly when an agent needs multiple rounds to complete a task. Five iterations, for example, can make the task several times more expensive than a single model call. Because the number of rounds may change from one task to another, the final cost is not always easy to forecast. Gartner included escalating expenses among three reasons projects get canceled, highlighting why cost limits should be considered from the beginning.

Cost-control measures to consider:

Define an upper limit for the number of model interactions and tokens allowed per task.
Use smaller, more affordable models for routine operations and assign complex reasoning to larger models.
Cache context that remains unchanged, provided the model provider supports caching.
Improve tool documentation to reduce unnecessary tool selection and repeated calls.
Replace agent-based execution with a fixed workflow when the required steps are predictable.

Reliability Needs Engineering, Not Hope

Because model behavior is probabilistic, an agent system needs a plan for handling unsuccessful operations. This includes setting retry rules and timeouts, making tool actions safe to repeat, and providing alternative paths when an operation fails. The system should also have a defined response for unavailable tools. These practices are familiar in conventional software engineering, but they are particularly important when a nondeterministic model influences the application’s execution.

Principle 9: Build Security and Guardrails In From the Start

An agent that can read untrusted content and take actions is a new kind of attack surface.

The Core Risks

Risk	What it means	Example scenario
Prompt injection	Untrusted content contains commands intended to override the agent’s instructions	A webpage instructs the agent to disregard its safeguards
Excessive permissions	The agent’s access rights extend beyond the requirements of its role	A customer service agent can edit billing data even though its task only requires viewing it
Data leakage	Confidential data is revealed through responses or interactions with external tools	Sensitive customer records are passed to an outside application
Confused-deputy problems	An agent is tricked into using its authority on someone else’s behalf	An attacker leverages the agent’s credentials
Unsafe tool chains	A combination of individually permitted actions leads to an unintended or harmful outcome	The agent can retrieve private information and send messages outside the organization

The security community has begun cataloguing these.

OWASP has expanded its coverage of AI application security with a 2026 risk list specifically for agentic systems. This sits alongside its earlier language-model application guidance, giving development teams two relevant references to consider during security reviews.

Defensive Principles

Least privilege. Assign tools and data access according to each agent’s role rather than providing unrestricted access.
Use scoped, short-lived credentials.
Separate instructions from data. Treat anything fetched from outside as untrusted, regardless of how authoritative it sounds.
Validate inputs and outputs. Validate the inputs supplied to each tool against its defined schema, and inspect returned data before exposing it outside the system.
Layer guardrails. OpenAI’s guide describes combining several types of safeguards, including relevance checks, safety classifiers, rule-based filters, and tool-risk ratings, because no single layer is sufficient.
Require approval for high-risk actions. See Principle 6.
Isolate execution. Run code and browsing inside sandboxes with limited network and file access.
Review third-party tools. Include MCP servers and plugins in your software supply-chain reviews. They can change how an agent behaves, so assess their trustworthiness just as you would any external library or dependency.

For a broader organizational perspective, our guide to AI governance tools and platforms explains how organizations approach AI risk assessment, policy enforcement, monitoring, and oversight as their AI deployments grow.

No available defense can prevent every prompt-injection attack. Security decisions should account for the possibility that the model will follow malicious instructions. Limit its permissions and the consequences of any resulting action.

Principle 10: Earn Your Way to Multi-Agent Systems

Distributing a task among cooperating agents can offer advantages, yet the coordination overhead makes this architecture difficult to manage as the number of agents increases.

When More Than One Agent Can Help

Separation of concerns. Distinct roles with different tools and instructions can keep each prompt focused.
Parallel work. Independent subtasks can run at the same time.
Context isolation. A sub-agent can explore a large body of material and return only a summary.
Organizational boundaries. Agents owned by different teams or companies may need to talk to each other.

The Costs

Every handoff is a place where information gets lost, and coordination adds model calls and failure modes. OpenAI’s guide advises maximizing a single agent’s capabilities first, and splitting only when instructions or tool sets become too tangled. It also describes two common shapes: a manager that calls specialist agents as tools, and a decentralized arrangement where agents hand control to each other.

Agent-to-Agent Standards

A2A provides the communication standard for coordinating agents developed by different vendors. MCP covers agent-to-tool communication, while A2A covers agent-to-agent communication, and the two are complementary rather than competing. Google created A2A in April 2025. A2A’s governance evolved through several changes. Google donated the protocol to the Linux Foundation in June 2025, followed by the integration of the competing ACP effort in August that year. By August 2026, A2A had moved under the Agentic AI Foundation as a hosted project alongside MCP.

A simple way to hold the distinction in your head: MCP is how an agent reaches its tools; A2A is how one agent talks to another.

Our Analysis: How Popular Agent-Building Frameworks Compare

Choosing a framework is partly about taste and partly about constraintsRather than judging which option is superior, the table identifies the capabilities each one describes in its public documentation. It is intended as a factual feature reference, not a performance comparison or ranking. Check each project’s current docs before deciding, because these tools change quickly.

Framework	Maintainer	Documented orientation	Notable traits from public docs
LangGraph	LangChain	Graph-based orchestration for agents that maintain state across steps	Gives developers control over state transitions, branching, and workflow structure
OpenAI Agents SDK	OpenAI	Lightweight primitives: agents, handoffs, guardrails	Built-in tracing; centered on OpenAI models but documented as extensible
Claude Agent SDK	Anthropic	Agent loop and tooling extracted from Claude Code	Strong file and code-oriented tooling; MCP-aware
CrewAI	CrewAI	Role-based architecture for teams of cooperating agents	Organizes agents around specific roles and tasks, with a focus on Python
Google Agent Development Kit (ADK)	Google	Code-first development environment for AI agents	Designed to support agent communication through A2A and integration with Google Cloud
Microsoft Agent Framework	Microsoft	Successor effort combining AutoGen and Semantic Kernel concepts	Enterprise-oriented; multi-agent patterns

What the Specifications Tell Us

Looking across the published materials, three observations emerge:

Convergence on primitives. Nearly all of them center on agents, tools, handoffs, state, and tracing. The vocabulary is becoming shared.
Growing support for open protocols. Because several options can work with MCP, switching between them may require fewer integration changes.
Different bets on control. Some give you explicit graph control; others give you minimal building blocks. The right choice depends on how much structure your task needs.

Build the simplest working version with direct model API calls before choosing an agent framework. This helps distinguish essential application logic from supporting infrastructure. Use a framework selectively when its built-in features can simplify otherwise repetitive work, such as preserving state, tracing execution, or managing orchestration.

If you want to see how agentic systems are applied to software development, explore our comparison of AI coding agents and their development workflows.

How These Principles Fit Together: A Build Sequence

Here is one sensible order of work that follows from the principles above. It is a suggested process, not a guarantee of outcomes.

Define the task and success criteria. Write down what a correct result looks like.
Build the evaluation set. Include normal, edge, and adversarial cases.
Start with a single model call. Measure against your set.
Add retrieval or tools where gaps appear. Design each tool carefully.
When a single call falls short, organize the remaining work into a defined workflow.

Introduce an agent loop only where the path is unpredictable.
Add tracing and cost limits.
Add guardrails and permission boundaries.
Launch with human approval on consequential actions.
Let evaluation results determine when and how much additional independence the agent receives.

Common Failure Modes and How to Avoid Them

Failure mode	Why it happens	Mitigation
Looping without progress	No stopping rule; vague goal	Step caps; explicit completion criteria
Wrong tool choice	Overlapping or poorly described tools	Consolidate tools; improve descriptions
Context bloat	Raw tool output and long histories	Trim results; summarize; store notes externally
Silent errors	Agent assumes a call succeeded	Verify against real tool output; surface errors clearly
Cost surprises	Unbounded iterations	Budgets, caps, smaller models for easy steps
Over-engineering	Adding layers without a named problem	Start simple; add complexity only with evidence
Injection through content	Untrusted text treated as instructions	Separate data from instructions; least privilege
Unmeasurable quality	No evaluation set	Build the set first; re-run on every change

Several of these map directly to Gartner’s three cancellation drivers: cost, unclear value, and weak risk control.

Teams that account for these three concerns before deployment can prepare for them in advance instead of having to respond to unexpected problems in production.

How the Field Is Evolving

Future developments are difficult to predict with certainty. This section limits its focus to changes indicated by published evidence and observable industry developments.

Shared infrastructure. With MCP, A2A, AGENTS.md, and goose under one neutral foundation, the plumbing is becoming common property. The practical advice circulating among analysts is to build on open standards rather than a single vendor’s proprietary integration format.
More attention to security and governance. The existence of a dedicated OWASP list for agentic applications suggests the security discipline is maturing.
Registries and trust signals. MCP’s roadmap has discussed a curated registry of verified servers, which, if delivered, would help teams vet tools.
Gradual, not sudden, adoption. Gartner’s own framing pairs the cancellation forecast with expectations of steady growth by 2028. Both can be true at once.

The likely winners are not the teams with the most autonomous agents. They are the teams with clear problem definitions, honest evaluation, and sensible limits.

Frequently Asked Questions

Q: What are the main principles of building AI agents?

A: The recurring principles are: choose the simplest architecture that solves the problem, design tools carefully, manage context deliberately, make reasoning visible, grow autonomy in stages, evaluate before and after every change, record traces, secure the system against untrusted input, and add multiple agents only when a single agent falls short.

Q: What is the difference between an AI agent and a workflow?

A: The distinction comes down to how execution is managed. Developers specify the control flow for a workflow, leaving the model to complete particular stages. An agent instead uses the model to determine the next operation and select the appropriate tools as the task progresses. Anthropic describes both patterns as agentic systems but recommends the more structured workflow approach when it can accomplish the objective.

Q: Do I need a framework to build an AI agent?

A: No. Anthropic’s engineering guidance suggests starting with direct model API calls, since many patterns need little code. Frameworks can help with tracing, state, and orchestration, but you should understand what they do under the hood.

Q: What is the Model Context Protocol (MCP)?

A: Rather than requiring separate connection methods for different resources, MCP establishes a shared protocol through which AI applications can interact with tools, data, and prompts. Anthropic introduced it in November 2024, and it was donated to the Linux Foundation’s Agentic AI Foundation in December 2025.

Q: How is A2A different from MCP?

A: MCP connects an agent to tools and data. A2A, created by Google, lets independent agents communicate and delegate tasks to one another. They operate at separate levels of the architecture, with complementary roles that allow them to work together.

Q: When should I use multiple agents instead of one?

A: When a single agent’s instructions or tool list become too large to manage, when subtasks can run in parallel, when you need to isolate large context, or when agents belong to different owners. Otherwise, a single well-designed agent is easier to build, debug, and secure.

Q: How do I evaluate an AI agent?

A: Build a set of realistic cases from your own domain, define correct outcomes in advance, and measure task success, tool-use accuracy, safety behavior, cost, and latency. Re-run the set after every change. Public benchmarks such as SWE-bench, tau-bench, GAIA, and WebArena are useful context but do not replace your own set.

Q: What are the biggest security risks for AI agents?

A: Prompt injection, excessive permissions, data leakage, confused-deputy attacks, and risky combinations of tools. The OWASP Top 10 for agentic applications is a good starting reference. A secure implementation should restrict what agents can access, verify data before accepting or releasing it, isolate potentially risky operations, and require human oversight for actions with serious consequences.

Q: Why do so many agent projects struggle?

A: Gartner links anticipated cancellations to three recurring problems: costs that continue to rise, business benefits that are not clearly established, and inadequate safeguards against risk. It also highlights “agent washing” and the complexity of introducing agent technology into established legacy environments.

Q: Are AI agents ready to run fully on their own?

A: For narrow, well-bounded, reversible tasks with strong evaluation and monitoring, increasing autonomy can be reasonable. When an incorrect outcome could have significant consequences, guidance supports requiring human review at critical stages. Autonomy should expand only as evidence supports it.

Conclusion: Final Thoughts

The principles of building AI agents are less glamorous than the headlines around them. Start from the problem. Choose the simplest structure that works. Treat tools as products and context as a limited budget. Make planning visible, grow autonomy in steps, and measure everything against an evaluation set you trust. Record traces, watch costs, and assume that any content your agent reads might be hostile.

The industry is also doing something encouraging: moving its connective tissue into open, neutral standards. MCP and A2A under one foundation mean builders can invest in skills and integrations that outlast any single vendor’s roadmap.

The most honest summary of the current moment comes from combining two sources. Gartner warns that a large share of projects will be canceled, and the same analysts still expect agents to take on a meaningful share of work decisions by 2028. Those views are compatible. They describe a field where fundamentals separate durable systems from expensive experiments.

If you are starting, resist the urge to build the most autonomous agent you can imagine. Build the most reliable system you can explain, evaluate, and secure. Then widen its freedom one carefully chosen step at a time.

Principles of Building AI Agents: 10 Design Rules for Systems That Hold Up in the Real World