THEORY · 60 minutes
Explore the key components — workflow engines, AI agents, LLMs, and MCP servers — and how they work together
In the last module I introduced the support-triage assistant I first built as an internal support dashboard. Now let's open it up. Knowing the parts is like understanding the parts of a car — you don't have to be a mechanic to drive well, but knowing what each part does helps you reason about the whole.
Four components do most of the work in the assistant — and in almost every AI System you'll meet:
How to read this module: We introduce each component on its own, then show how they hand work to one another. Keep the car analogy in mind — every part has one job, and the system works because they cooperate.
When a customer message arrives at the triage assistant, several things have to happen in order: read the message, search the knowledge base, decide on an action, then either reply or escalate. The workflow engine is the part that runs that sequence reliably. Think of it like the conductor of an orchestra — it doesn't play an instrument itself, it decides who plays when.
1. Define the process — map the steps (read → search → decide → act) and which can run at the same time.
2. Manage the flow — start each step at the right moment and pass information between them, so the "decide" step actually sees what the "search" step found.
3. Track progress — know what's done, what's running, and what to do when a step fails (for the triage assistant, a failed knowledge-base search should escalate, not crash).
If the workflow engine is the conductor, AI agents are the musicians. Each agent has a focused job and the tools to do it. In the triage assistant I think in terms of small agents: one that searches the knowledge base, one that drafts a reply, one that decides on routing.
1. Understanding — an agent reads natural-language instructions and knows its own capabilities and limits.
2. Planning — it breaks a task into steps and decides which tools to use, adapting when something doesn't work.
3. Action — it actually uses those tools, watches the result, and reports back.
The key difference from a plain function: an agent can decide how to accomplish a goal, not just execute a fixed recipe. The routing agent in my assistant doesn't follow hard-coded keywords — it reasons about where a message should go.
Large Language Models are the intelligence behind the assistant. An LLM is what reads "my export keeps failing every morning" and understands it as a recurring technical issue — not just a bag of words. It's like having a very well-read colleague who can understand and produce language on demand.
1. Understand context — grasp intent, remember earlier turns in a conversation, and read nuance.
2. Generate responses — write in natural language and adapt tone, from a short answer to a full explanation.
3. Reason and analyze — break a problem down and explain the reasoning behind a decision.
In the triage assistant, the LLM is the component that turns a raw message into a classification the rest of the system can act on. It's powerful — but on its own it can't search anything or send anything. That's why it needs the other three parts.
MCP (Model Context Protocol) servers are how the assistant reaches the outside world — the knowledge base, the ticketing system, the team channels. Think of MCP like a universal adapter: instead of hand-wiring a different integration for every tool, the system speaks one standard protocol to all of them.
1. Standardization — one consistent way to connect to many services, so I don't relearn a new API for every tool the assistant touches.
2. Security — explicit control over what the system can read and do, with permissions and authentication at the boundary.
3. Flexibility — adding a new data source to the assistant becomes a matter of connecting another MCP server, not rewriting the core.
Now watch all four cooperate on a single real task: a customer writes in saying their data export is failing every morning.
No single component could do this alone. The brain understands, the connectors fetch, the agents act, and the conductor keeps it all in order.
Before the quiz, reason about a trade-off: what would happen to the triage assistant if the LLM were extremely capable but the MCP connection to the knowledge base went down? Which step above would fail first, and what should a well-designed workflow engine do about it?
1. In the export-failure walkthrough, which component is responsible for running the steps in the right order and passing results between them?
Correct Answer: B
The workflow engine orchestrates the sequence and hands each step's output to the next — the conductor role. The LLM only supplies understanding.
2. Why can't the LLM handle the customer's request entirely on its own?
Correct Answer: B
The LLM is the brain — understanding and generation. Acting on the world (search, send) requires agents and MCP connectors. Intelligence without hands can't complete the task.
3. What distinguishes an AI agent from an ordinary function that follows fixed steps?
Correct Answer: B
Agents reason about how to reach a goal and adapt. The routing agent reasons about where a message belongs instead of matching hard-coded keywords.
4. A new data source needs to be added to the triage assistant. Why does using MCP make this easier?
Correct Answer: B
MCP standardizes connections. New tools plug in through the same protocol, so the core system doesn't need custom integration code for each one.
5. If the MCP connection to the knowledge base fails mid-request, what is the best-designed behavior for the workflow engine?
Correct Answer: C
A good workflow engine handles step failure gracefully. With no reliable knowledge-base result, escalating to a person is safer than guessing or crashing.
Great job. You now know the four building blocks and, more importantly, how they cooperate inside one real system. Next we'll look at where systems like this show up in the real world.