MCP, A2A, Skills, Plugins and Harnesses: How the Pieces of an AI Agent Fit Together

If you’ve spent any time around AI lately, you’ve heard the terms: agents, MCP, A2A, skills, plugins, harnesses, multi-agent systems. People use them interchangeably, or drop them into conversation without explanation.

I recently worked through the Problem-First AI course by Aishwarya Reganti and Kiriti Badam, and it finally gave me a clear mental model of how these pieces fit together. This post is my attempt to share that model, one short explanation per term.

First, what is an AI agent?

An AI agent is a language model that can use tools to work toward a goal. On its own, a model can only generate text. Three extra abilities make it agentic:

• Tools and APIs, so it can take actions like running code or calling a service
• Memory, so it can retrieve information it wasn’t trained on
• Planning, so it can choose its next steps and revise them

One detail surprised me: the model never actually runs a tool. It only proposes a tool call (“call get_order with ID 1042”). Your application executes that call and hands the result back. If your agent produces perfect tool requests but nothing happens, the problem is almost always the code that’s supposed to run them.

MCP (Model Context Protocol): connecting agents to tools

Before MCP, every AI app had to write its own integration for every tool. Three apps and four tools meant twelve separate integrations, and every new app or tool added another round of them.

MCP replaces that with a shared agreement on how apps and tools talk. Think of HTTP: no browser is built for one specific website, because browsers and websites all speak the same protocol. MCP does the same for AI apps and tools. Each app and each tool implements the protocol once, so the twelve integrations become seven.

MCP has three parts:

• Host: the AI app you use, like Claude Desktop or an IDE
• Client: the piece inside the host that talks to a server
• Server: a wrapper around a service’s API (Stripe, Slack, Gmail) that exposes its actions as tools

A server can offer three kinds of things, and each one has a different decision-maker:

Offering	What it is	Who decides to use it
Tools	Actions to run	The model
Resources	Content to read (docs, files)	The application
Prompts	Reusable templates	The user

The hidden cost: context

Every tool description and every tool result takes up space in the model’s context window. Connect a lot of tools, or pull back thousands of records when you only need twenty, and the model has less room to think. Accuracy drops.

One fix is code execution. Instead of reading every result, the model writes a small script that fetches and filters the data in a sandbox, and only the relevant results come back into its context. The model reads twenty records instead of thousands.

A security warning

Adding an MCP server is often one line of config, which makes it easy to forget that the model reads everything the server describes. A malicious tool description can quietly instruct the model to grab sensitive data and send it elsewhere. Use trusted servers, limit permissions, require approval for sensitive actions, and log everything.

A2A (Agent-to-Agent): connecting agents to other agents

MCP is for calling tools. Sometimes, though, you need to hand work to another agent, possibly one run by another company, that makes its own decisions and might take days to finish.

A2A handles that exchange in four steps:

1. Discover what the other agent can do by reading its Agent Card
2. Send a goal, not a function call (“recover these overdue invoices”)
3. Answer questions when the other agent needs input
4. Receive the result when it’s done

The other agent’s tools, prompts and memory stay hidden. You only see the task and the outcome.

The two protocols do overlap a little. MCP has been adding similar features: Tasks, a tool call that runs in the background so you can check on it later, and Elicitation, where the server pauses mid-call to ask the user a question.

A simple way to remember the difference: MCP gives an agent depth. A2A gives a system reach.

Skills: teaching agents your team’s procedures

If you’ve ever pasted the same instructions into a chat over and over (“no jargon, keep it short, cut the filler”), a skill solves that.

A skill is a folder containing a SKILL.md file that describes when to use it and what steps to follow. The folder can also include scripts and reference files.

The clever part is progressive disclosure. A skill loads in stages:

• At startup, only each skill’s name and short description load
• When a request matches, that skill’s full instructions load
• If a step runs a script, only the script’s output enters the context

That’s why you can install dozens of skills without flooding the model’s context.

Plugins: sharing the whole setup

A plugin bundles skills, MCP server configs, subagents and hooks into one installable package. Instead of every teammate maintaining a slightly different copy of the setup, everyone installs the same plugin and gets the same thing.

Multiple agents vs. a multi-agent system

The names sound alike, but they describe different setups:

• Multiple agents: separate agents doing separate jobs, with no shared dependencies
• Multi-agent system: agents working toward one shared outcome, coordinating and passing work between each other

A multi-agent system adds a job that didn’t exist before: coordinating the agents. Each agent can do its own work perfectly while the overall system still fails, for example when one agent moves ahead before another agent’s update arrives.

The advice that stuck with me most:

Always start with a single agent. Move to multiple agents only when you can show, through evals or operational needs, that one agent falls short.

Good signs you might need more than one agent:

• The agent is overloaded with too many tools or data sources and starts picking the wrong ones
• You need a second check on the output
• Work is too slow and could run in parallel
• Tasks need separate access boundaries

A common middle ground is a subagent. The main agent hands a bounded task to a helper with its own clean context and gets back a short report. The messy investigation stays out of the main agent’s context.

The harness: everything around the model

This is the term that tied it all together for me.

Agent = Model + Harness

The harness is all the software around the model that makes it useful:

• Context: prompts, retrieval and memory
• Capabilities: tools, skills, plugins and MCP
• Delegation: subagents or other agents
• Storage: files, databases and saved memory
• Execution: running tools locally or in a sandbox
• Security: permissions, approvals and audit logs

The model makes choices. The harness loads context, runs tools, checks access and records what happened. That split decides where your important rules live. A rule like “never refund over $500 without approval” belongs in the harness as deterministic code, not in a prompt the model might ignore.

Two decisions for production

1. How much of the harness do you build?

• Raw model API: full control, but you write everything
• Framework components (e.g. LangGraph, Langflow): building blocks for custom workflows
• Prebuilt agent loop: the loop is handled; you add tools and instructions
• Full harness (e.g. Deep Agents, Claude Agent SDK): context, files and approvals come built in

The more that comes assembled, the faster you ship and the less fine-grained control you keep. Larger enterprise apps often benefit from framework components; smaller, focused apps can move faster with prebuilt options when the defaults fit.

2. Where does it run?

• On your own servers
• On a platform that runs your code
• On a provider-managed harness that you only configure

These are separate choices. Deploying on a managed platform doesn’t mean the platform writes your workflow.

After you ship: learning from production

Deployment starts the next round of work:

• Measure outcomes (was the issue resolved?), quality, speed and cost.
• Read traces regularly, using random samples across request types, not just complaints. Unhappy users click thumbs-down more, so negative feedback alone gives a skewed picture.
• Turn failures into test cases so your evals improve over time.
• A/B test changes with a clear primary metric and guardrails. A better average can hide a worse experience for a whole group of users.
• Roll out gradually, and remember that rolling back code doesn’t undo actions your agent already took in the real world.

The cheat sheet

Term	What it is	Its job
MCP	Protocol	Connects an agent to tools and data
A2A	Protocol	Lets independent agents exchange tasks
Skill	Folder with SKILL.md	Packages a repeatable procedure
Plugin	Package	Ships skills and connectors together
Harness	The software around the model	Turns a model into a working agent

Going deeper

If you want to go further, I highly recommend the Problem-First AI course by Aishwarya Reganti and Kiriti Badam at LevelUp Labs. It covers all of this with hands-on assignments in LangGraph and Langflow, and it’s built around a mindset I found valuable: start with the problem, not the technology.

Which of these terms confused you most before it clicked? Let me know in the comments.