An AI Agent should be a general-purpose brain (LLM) equipped with reusable building blocks - MCPs, Skills, and Tools - that let it autonomously explore and iterate toward any objective. The agent itself should not be specialized for one task; that is a workflow. In this post, I will break down these building blocks, how agent harnesses connect them, and why organizations should build a handful of capable agents that power many workflows - not a new "agent" for every use case.
Outline
What is an AI Agent?
To talk about what an AI Agent should be, we must first define what an AI Agent is and is not. While it can take various forms, the core concept is provided with an objective and a set of tools, it can autonomously reason and iteratively explore to achieve the objective. It is not specific to only one objective or a few variants of that objective; that is a workflow.
Building Blocks of an AI Agent
As defined above, agents are autonomous and iterative, using a provided set of tools. The set of tools is a key concept here and one that the industry has abstracted into "fancy" terms such as Model Context Protocol (MCP), Computer Use, Skills, etc. All of these have one thing in common - Function Calling.
Back when LLMs started to become mainstream with GPT 3.5, we wanted to integrate them with external tools, so we would prompt them to generate JSON that we could pass into a function and/or database. Down the line, structured output was introduced, allowing us to pass in a JSON schema to which the model would conform its output. This greatly improved reliability and is still super valuable for enrichment and any behind-the-scenes AI work that is non-agentic, where it is preferred over free-form text output.
Now what happens when the LLM needs to fetch a record from Salesforce before it generates that final JSON or output? That is where function calling comes in. It enables the LLM to request a tool (also known as a function) to be run and see its output before it provides the final output. Start chaining these together, and you have the foundation of an AI Agent. This is the foundation every subsequent layer of abstraction is built on top of.
So I titled this section "Building Blocks..." because it will cover the provided set of tools an agent has access to. We will have three primary building blocks: MCPs, Skills, and Tools. (*While they are all tools, there is some merit in the industry abstractions.)
Model Context Protocol (MCP)
An MCP is an easy way for companies to expose bundles of tools to an agent. Nothing more (*MCP Apps are also exposed but are more for a user interacting rather than pure agentic work). There are a lot of great platforms out there that make it easy to build an MCP server to create and expose tools—personally, I have really enjoyed Make.com MCP Server, which lets you create both scenarios (think an automation) and direct platforms (e.g. Salesforce SOQL, etc.). They are also fairly straightforward to build with any modern coding agent like Cursor or Claude Code.
Use an MCP Server when you have a bundle of related tools or need to connect to an external system outside your organization.
Skills
A Skill allows you to encapsulate proprietary knowledge an LLM would not know about. They should not be used for generic knowledge that can be easily found online or is likely already in its training. Most of the time, skills are iteratively explored and used by the agent as needed vs. all at once. For example, if the user asks the agent to build out a slide deck, the agent may read the brand style guidelines skill before creating the slides.
Skills are, again, "just" tools (that is a bit loose, as some context is dumped into the agent instructions), with the agent sending a tool call like activate_skill("brand_style_guidelines") to read the skill file and add its content to the agent's context. (Adding skill support)
Use a Skill when you have proprietary knowledge that an LLM would not know about.
Tools
Use tools for anything else you want your agent to be able to explore or do. A few examples from my own experience:
- File work - reading, writing, moving, etc.
- Templates - Taking a JSON file and applying it to a template (i.e. great for building structured documents where you don't want the LLM to write all the boilerplate like CSS, etc.)
- Sending emails - Grab your favorite email API and have a tool take a subject, list of recipients, and raw HTML body and send the email.
- Computer use - Some models expose computer use tools that can take a screenshot of a monitor and then return mouse coordinates and keyboard inputs.
- Anything else you can think of - the sky is the limit.
Use a Tool when you want your agent to be able to do something that is not covered by an MCP or Skill.
At this point, you have the arms and legs allowing the agent to explore and iterate to achieve its objective. And... if you structure this well, you can have a repository of building blocks your team can reuse and expand on to build out any agent needed.
I do want to note that there is one more key building block (subagents) that I did not include above. Subagents are simply full agents (LLMs with tools) that are called as tools/functions by the parent agent, which delegates a piece of work to them. They can be as simple as copies of the parent agent (like little clones), specialized for a specific task, or made to perform particular functions like researching or critiquing a piece of work independently. They are extremely powerful and can speed up your agentic runs, but I believe the specialized ones are a product of current model limitations, not where the industry will be in a few years.
Putting the Building Blocks Together
There are a million and one agentic harnesses out there—a harness being the framework that connects the LLM to the building blocks. I suggest reading one of the great guides out there, such as this one from LangChain, to get a general idea of their structure. Some notable ones out there, in no particular order, are:
- Eve from Vercel - Durable filesystem-based agent framework
- ADK from Google - Production-grade multi-agent framework
- Claude Agents SDK - Claude Code agent library
- OpenAI Agents SDK - Easy agents for OpenAI models
- Think from Cloudflare - Stateful Cloudflare agent framework
- PI - Minimalist and extensible agent SDK
- LangChain deep agents - Planning and subagent framework
I have tried a handful of these, but if you really want to understand how this all works, I suggest instead starting with simply function calling. Use Gemini Interactions API or OpenAI Responses API to connect with an LLM; both support function calling out of the box. Next, build a folder structure of building blocks that your agents can use: MCPs, Skills, and Tools. (*By building these as building blocks rather than directly in a specific agent, you can easily swap any major harness in or out down the line if needed.) I won't go into too much detail on this, but you will learn so much by building this layer yourself. It will make understanding all of the above harnesses much easier and help you see their strengths and weaknesses—how far are they abstracting away the core concepts?
Harnesses generally do a few extra things like context compaction, tracing, enforcing limits, file system, error handling, and context management. These are important, but not the core of what an AI Agent is.
Speciality vs. General Purpose
I mentioned in the intro that an AI Agent is "not specific to only one objective or a few variants of that objective; that is a workflow." The industry has really blurred this with Google's Gemini Gems and ChatGPT GPTs, where each custom "agent" was simply the base LLM with some instructions/skills added to it to accomplish a specific objective like writing copy, audits, etc. Those are not what agents should be. Custom/proprietary knowledge should be shared via a Skill, but that is not an agent! This is not specific to the big companies. Most companies rushing to slap the word "agent" on their product to see that stock ticker go up were conflating workflows with agents. (I am slightly passionate about this...)
So what about my website chat agent? Isn't that an agent? Is a human who works at a farm a farmer or a human? They are both—but the human is generic; they can do just about anything, and they have specialized knowledge in farming, making them a farmer also.
I want to mentally separate an AI Agent from a Workflow:
- AI Agents are the brain (LLM) with a set of building blocks (MCPs, Skills, Tools) to explore and iterate to achieve any objective.
- Workflows are a bundled set of building blocks (MCPs, Skills, Tools) injected into an agent to achieve a specific objective.
At an organization, we develop just a handful of AI Agents and then build out many AI workflows that run on those AI Agents. We do NOT build an agent for every aspect of the business. (Please drop your thoughts in the comments :))
Wrapping Up
So... what is an AI Agent? It is a brain (LLM) with a set of building blocks (MCPs, Skills, Tools) to explore and iterate to achieve any objective. For specific objectives, we build out bundled building blocks (MCPs, Skills, Tools) known as workflows and inject them into an agent to achieve a specific objective.
Aside: LLMs are getting smarter every month. The extra rules and guardrails you needed a year ago are no longer needed and, in some cases, can actually hinder performance. Build for the models of tomorrow.
Comments
Login to Add comments.