What are AI agents and MCP? The basics of how LLMs use tools
An AI agent is a large language model (LLM) that decides on its own when to call external tools and data sources, autonomously completing a multi-step task toward a goal. Unlike a chatbot, which only answers questions, an agent can take actions — searching, calculating, scheduling — that change the state of a system. MCP (Model Context Protocol) is the standard that emerged to let agents connect to a wide variety of tools safely and efficiently.
For executives and DX leads evaluating AI adoption, the terms “agent,” “function calling,” and “MCP” are often used interchangeably, but they refer to different layers of the same stack. Getting these definitions right is a basic piece of technical literacy for anyone making an investment or procurement call without taking a vendor’s pitch at face value. This article separates the three and maps out what can realistically be automated today, and where the risk still sits with humans.
Chat, workflow automation, and agents: three levels of autonomy
AI-driven task automation comes in three forms with different degrees of autonomy. Conflating them leads to bad deployment decisions, so it’s worth separating them first.
| Form | What it does | Who decides the next step | Typical example |
|---|---|---|---|
| Chat | Returns one response per input | A human (decides what to do next, every time) | Asking ChatGPT or Claude a question |
| Workflow automation | Executes a predetermined sequence of steps | The designer (branches are fixed in advance) | RPA-style “receive email → classify → notify” pipelines |
| Agent | Given only a goal; the LLM decides the steps at runtime | The LLM (decides the next tool call on the fly) | A single instruction like “tally this month’s inquiries and post a summary to Slack” |
The line between workflow automation and an agent comes down to whether the branching logic was written by a human in advance, or decided by the LLM at execution time. Workflows are reproducible and predictable but brittle against unexpected inputs. Agents handle novel situations better, but exactly what they will do next can’t be fully predicted until you run them. This tradeoff between predictability and flexibility is the core of the deployment risk discussed later.
How function calling works
Function calling (also called “tool use”) is the underlying mechanism that lets an agent “use tools.” It works in three steps:
- Register the tool: developers describe to the LLM what a tool does and what inputs it expects — for example, “
search_orders(customer_id)returns the order history for a given customer ID.” - Decide whether to call it: given a user’s instruction, the LLM reads the registered tool descriptions, chooses the tool and arguments needed to accomplish the goal, and generates a structured call request. At this point the LLM itself isn’t executing any code — it’s only emitting a request to call a specific tool with specific arguments.
- Execute and return the result: the surrounding application actually runs the tool and returns the result to the LLM, which then decides the next action — another tool call, or a final answer.
Repeating this loop (decide → call → receive result → decide again) as many times as needed lets an agent complete multi-step tasks that a single question-and-answer exchange can’t handle. This mechanism has historically been implemented separately by each model provider, and it connects directly to the architecture choices (API usage, RAG, fine-tuning) discussed in Architectural decision axes for embedding LLMs into your product.
What MCP (Model Context Protocol) is, and what standardization actually buys you
As the figure above shows, before MCP, connecting “which LLM” to “which tool” required a custom integration for every provider-tool pair — the “M×N problem.” With M model providers and N tools, you could end up needing as many as M×N separate integrations.
MCP is an open standard published by Anthropic in 2024 that unifies how LLM clients connect to tool and data source servers. A tool developer builds a single “MCP server” that any MCP-compatible LLM application can use; an LLM provider implements a single “MCP client” that can connect to any MCP-compatible tool. It’s a similar role to what the USB standard did for connecting peripherals to computers — one connector, many devices.
This has two business implications.
1. Lower integration cost. Connecting internal systems — a customer database, accounting software, an internal wiki — to an AI agent increasingly doesn’t require building a bespoke API integration each time. As more MCP-compatible connectors become available, the engineering effort to onboard a new system keeps falling.
2. Reduced vendor lock-in. Because integration code no longer needs to be written specifically for one LLM provider’s tool-calling format, the cost of switching to a different LLM later drops. This is the same structural argument as API and SDK standardization affecting procurement strategy, covered in API, SDK, and OSS: precise definitions and their contractual and IP implications.
Standardization, though, only guarantees ease of connection — not safe usage. The permission design discussed in the next section is necessary whether or not you use MCP.
Business impact: what can be automated, and what should stay with humans
Tasks well-suited to agent automation and tasks that should keep a human in the loop split along clear lines.
Characteristics of tasks well-suited to automation
- Decision criteria can be articulated and pattern-matched (“given this condition, apply this classification”)
- The cost of recovering from an error is low (drafting, first-pass triage, summarization)
- The task is read-oriented (search, retrieve, summarize) rather than write-oriented (modify, send, approve)
Characteristics of tasks that should keep a human decision-maker
- Errors have direct financial, contractual, or reputational consequences (invoicing, sending contracts, final answers to customers)
- The decision criteria are context-dependent and not fully codified (negotiation calls shaped by history or relationship dynamics)
- Exception handling with no precedent (a first-of-its-kind complaint that isn’t covered by any playbook)
As a practical rule of thumb, start automation with read-oriented tasks, then extend to write-oriented tasks only after adding a human approval step — this sequencing is what prevents costly mistakes. For a framework on which business processes an SME should tackle first, see Where should SMEs start with AI adoption: an executive’s roadmap.
Deployment risks: permissions, misfires, and auditability
When connecting an agent to tools that can execute changes, three risks deserve specific attention.
1. Scope of permissions. As a general principle, an agent should only be given the minimum permissions its task requires. If a “customer lookup agent” is accidentally granted permission to delete customer records, an unintended instruction or a model misfire can cause real damage. Design tools with an explicit read-only versus write-access separation.
2. Tolerance for misfires and runaway actions. Because LLMs generate output probabilistically, they will occasionally issue a tool call that doesn’t match the intent. Execution actions involving money or a destination address should require human approval above a defined threshold, or a confirmation step before execution — a safety net, not an afterthought.
3. Audit logging. Without a record of which agent called which tool, with what arguments, and when, you can’t diagnose what went wrong after an incident. For agents that chain multiple tool calls together, preserving the intermediate steps is a precondition for any post-hoc investigation.
None of these are novel risks so much as the standard principles of system access control — least privilege, approval workflows, audit trails — reapplied to a new class of actor: the AI agent. Put differently, organizations with mature access-control practices already in place will find agent deployment considerably easier.
Summary: agent autonomy trades convenience for predictability
AI agents and MCP are the foundational technologies expanding AI’s role from “something that answers” to “something that acts.” The key points:
- Chat, workflow automation, and agents differ in their degree of autonomy — conflating them leads to poor deployment decisions
- Function calling is the basic mechanism by which an LLM calls tools, using a decide → call → receive-result loop to complete multi-step tasks
- MCP standardizes how LLMs connect to tools, lowering integration cost and vendor lock-in — but it does not by itself guarantee safety
- The safe deployment order is to start with read-only tools, and extend to execution tools only after permission design, approval workflows, and audit logging are in place
Deciding which business process to automate first, and how to design permissions around it, depends heavily on the specifics of your operations and existing systems. Through embedded, on-site technical consulting, we work through these decisions together against your real operational data. If you’re evaluating adoption, get in touch; if you’re assessing a portfolio company’s or acquisition target’s AI readiness, see TiedPro for investors; and if you’re a startup embedding AI into your own product, see TiedPro for startups.
FAQ
Q. What is the difference between an AI agent and a chatbot?
A chatbot only responds within a conversation. An AI agent is given a goal and autonomously decides which tools to call, in what order, to complete a multi-step task. The dividing line is whether the system merely replies, or takes external actions (tool calls) that change state.
Q. Does adopting MCP automatically make a system safe?
No. MCP standardizes how tools are connected — it says nothing about permission management, audit logging, or safeguards against misfires. Because MCP makes connections easier to add, skipping permission design actually widens the blast radius of a mistake.
Q. What should a small or midsize business check first before deploying an AI agent?
Whether the agent is connected to read-only tools (search, summarize) or to tools that can execute changes (send, update, approve). The safe order is to start with read-only tools, then extend to execution tools only after an approval step is in place.