Ever wonder whether the architecture question is about tools or about the capability they enable? I hope to explore that question in this blog.
The more I work with AI systems, the more options exist for solving the same problem: prompts, retrieval, skills, function calling, MCP servers, agents—often several together. That abundance should simplify architecture. Too often it complicates it.
Premise: return to a single guiding question—What capability is missing, and what is the simplest reasonable way to provide it?
Why the choice gets confusing
These mechanisms overlap and blur. An MCP server can expose tools, prompts, and resources. A skill can bundle instructions, scripts, and reference material. Retrieval can be surfaced through a tool. An agent may orchestrate many of these. Rather than debate labels, ask what job each mechanism performs.
Prompt — start small
If the model already has what it needs, a well-crafted prompt can be enough. Want a model to review a Java change for error handling and resiliency? Clear criteria, output expectations, and an example often suffice. Prompts are low-friction; their limits appear when they grow into sprawling procedures or when the model lacks necessary information.
Skill — package repeatable know-how
When a procedure is worth reusing, package it. A skill can contain instructions, scripts, examples, and resources that are brought in when relevant to a task. Anthropic’s Agent Skills specification is one example of this pattern (Anthropic, 2025).
The advantage is reuse and consistency. The trade-off is maintenance since instructions can become stale, scripts acquire dependencies, and executable content deserves more scrutiny than passive guidance.
Retrieval — provide the missing facts
Retrieval is useful when the model lacks knowledge rather than instructions. In enterprise settings, that could mean internal documentation, policies, advisories, architecture records, or incident history. Retrieval-augmented generation combines model reasoning with information retrieved from an external source (Lewis et al., 2020).
If I ask, “Does this design satisfy our current resiliency standard?”, the first problem may simply be giving the model access to the current standard. Retrieval raises its own engineering questions—correctness, freshness, authorization, and traceability—but it does not automatically require an autonomous agent.
Tool — controlled external action
A tool lets the model request a structured operation, such as get_dependency_version(…) or create_remediation_ticket(…). The surrounding application can validate arguments, enforce permissions, and determine whether the operation should actually execute (OpenAI, n.d.).
I have noticed that a tool does not simply “give authority to the model.” It creates a path through which the model can request an action. Once tools can modify external systems, concerns such as validation, auditability, permissions, failure modes, and unintended side effects become part of the architecture.
MCP — standardize shared capabilities
MCP addresses a different problem. It provides a standard interface for capabilities exposed by servers, including tools, resources, and prompts (Model Context Protocol, n.d.).
It is all about standards. If one application needs to query one internal vulnerability service, a direct integration may be enough. If that same capability must be consumed by an IDE, coding assistant, vulnerability-treatment agent, and another AI application, maintaining separate integrations becomes less attractive.
A common MCP interface may now provide real value by separating the capability provider from its consumers and giving compatible clients a consistent way to discover and use what is available. The July 2026 specification also moved MCP toward stateless request/response operation and continued work around authorization and enterprise deployment (Soria Parra & Delimarsky, 2026).
That does not mean MCP should replace every direct tool integration. It introduces its own operational and security considerations, including authorization, compatibility, and lifecycle management. So the we need to ask whether interoperability and reuse justify that additional boundary.
Agent — when discretion matters
Agents introduce discretion and branching. Instead of following the same fixed sequence every time, an agent may decide which evidence to gather, which checks to run, or whether to change direction when the first result is inconclusive. I think this flexibility helps when the path genuinely depends on what is discovered along the way. It also expands the number of execution paths that need to be observed and controlled.
Recent Web3-focused research helps expose another dimension of this decision. Karanjai et al. (2026) highlight how irreversibility, signing authority, continuous autonomy, and sequences of actions can amplify the consequences of agent failures. Web3 makes these risks unusually visible because an action may directly move an asset or execute a transaction that is difficult to reverse. The same principle can matter in enterprise systems, even if the consequences look different. A service credential carries authority. A deployment changes production state. A sequence of individually reasonable tool calls can combine into an outcome that nobody intended to authorize.
The practical takeaway is that choosing a capability also means choosing how much authority the system can exercise. A prompt may shape an answer. Retrieval expands what the model can know. A tool creates a path to act. MCP can make that capability available to more consumers. An agent may decide when and how several capabilities are combined.
As we move closer to action, the architecture question is no longer only whether the mechanism solves the problem. We also have to ask what happens when it is wrong.
Conventional software — don’t ignore determinism
If a rule is reliably expressible as if severity == critical and internet_exposed == true, require_security_review, deterministic code may be the right choice. Models add value where language, ambiguity, or judgment matter. Deterministic code remains useful because some problems are deterministic. Models add the most value where language, ambiguity, incomplete information, judgment, or adaptation are actually part of the problem.
One problem, several architectures
Consider: Help an engineer assess a vulnerability finding.
- Explain the finding clearly? Prompt
- Need current advisories and internal standards? Retrieval
- Apply a repeatable assessment procedure? Skill
- Query a live dependency graph or scanner? Tool
- Share that capability across several AI clients? MCP
- Decide which evidence to collect and what to do next? Agent
- Apply a fixed threshold or policy rule? Code
The mechanisms are not competing to solve the same problem. They address different gaps. That distinction makes the growing AI toolbox easier to reason about. Instead of starting with Should we build an MCP server? or Should this be an agent?, I can start with a more useful question:
What is the system unable to do today?
Then I can add the smallest amount of capability needed to close that gap.
Part 2 will turn this into a practical playbook: how to identify the missing capability, determine when MCP is justified, and assess the authority and risk introduced when AI systems can act.
References
Anthropic. (2025, October 16). Equipping agents for the real world with Agent Skills. https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills
Karanjai, R., Lu, Y., Diallo, N., Xiong, W., Xu, L., & Shi, W. (2026). When agents act on Web3: An attack-surface survey of MCP, skills, and tool calling [Preprint]. arXiv. https://arxiv.org/abs/2608.17275
Lewis, P., Perez, E., Piktus, A., Petroni, F., Karpukhin, V., Goyal, N., Küttler, H., Lewis, M., Yih, W.-T., Rocktäschel, T., Riedel, S., & Kiela, D. (2020). Retrieval-augmented generation for knowledge-intensive NLP tasks. arXiv. https://arxiv.org/abs/2005.11401
Model Context Protocol. (n.d.). MCP TypeScript SDK. https://ts.sdk.modelcontextprotocol.io/v2/
OpenAI. (n.d.). Create a model response. OpenAI API Reference. https://developers.openai.com/api/reference/resources/responses/methods/create
Soria Parra, D., & Delimarsky, D. (2026, July 28). The 2026-07-28 specification. Model Context Protocol Blog. https://blog.modelcontextprotocol.io/posts/2026-07-28/