The interviewer leans back and asks, “So what is an agent?” Most candidates say “an LLM that can use tools,” and the interviewer nods without writing anything down. The same thing happens on foundational AI certification exams. A question offers four options that each sound plausible, and the wrong ones are built from that half-right answer.
This article claims that a strong answer to “what is an agentic AI system made of?” covers five parts in a fixed order: the loop, tools, connection, memory and coordination. It also ends by saying when not to add more agents. Each part has one confusion that examiners and interviewers probe on purpose. Most of those confusions come from not asking what sits on each end of a connection. If you can explain the five parts and their boundaries, you can handle the follow-up questions that come after the first one.
A strong answer names the loop before any technology
Here is the opening answer a strong candidate gives.
“An agent is a system that uses a foundation model to decide which actions to take toward a goal. It takes those actions, reads what came back, and decides again. It does not produce one answer in one pass. The defining property is that loop. If nothing can come back and change its mind, it is a single model call, however good the output is.”
A foundation model is a large model trained on broad data that many applications build on. The loop is the important part of that answer. You could replace every technology in a system and it would still be an agent if the loop remained.
Think of it as the difference between a researcher with a library card and someone answering from memory. The researcher looks things up, and what they find changes their next question. Someone answering from memory can never be surprised.
An agent decides, acts, observes the result, then decides again or answers
The branch after the result is the agent: act again, or answer. The model itself gains no new ability. The new capability is that results come back in as context.
Follow-up 1: the model requests, the runtime executes
“When an agent uses a tool, what does the model actually do?”
Model answer: Tool usage means giving a model access to external functions, APIs or data sources. The model decides that a tool is needed and which arguments to pass. The runtime is the software around the model, and it makes the actual call and returns the result into context. The model then interprets that result and decides what happens next.
The weak-candidate mistake: saying “the model queries the database” or “the model books the slot.” Any answer in which the model executes something has the mechanism backwards. To an interviewer, it signals that you have never watched one run.
Think of it as a doctor ordering a blood test. The doctor does not run the lab. They order the test, the lab runs it, the result comes back, and the diagnosis may change.
The model decides and interprets; the runtime executes and returns the result
Tools are worth this machinery because they let an agent be correct about things that changed after training. Suppose a user asks for the stock level of a part. Without a tool, the model generates a plausible number. With a tool, the runtime queries the real one. In both cases the model sounds equally confident, and that is exactly why the difference matters.
Follow-up 2: MCP connects an agent to external systems
“What is the Model Context Protocol, and what problem does it remove?”
Model answer: The Model Context Protocol (MCP) is an open protocol. It standardises how an AI application connects a model to external tools and data sources, so there is one common interface instead of a custom integration for every system. The problem it removes is multiplicative. Three applications that each connect to four systems need twelve separate integrations. With a shared protocol, each side is implemented once, which makes seven. Adding a fifth system then costs one implementation instead of three.
Think of it as USB-C. Every device used to need its own cable. With one connector standard, any device can meet any peripheral, and neither side has to know about the other in advance.
Bespoke integration grows with every pair; a shared protocol needs one implementation per side
The weak-candidate mistakes, in order of how often they appear:
- “MCP lets agents talk to each other.” It does not. It connects an agent to external systems. Agent-to-agent exchange is a separate concept called communication patterns.
- “MCP is a product or managed service.” It is an open protocol. Cloud services can speak it, which is a different claim. It never belongs in a list of services to select.
- “You need MCP to use tools.” Tool usage existed before MCP and works without it. With two or three connections, custom integration is tolerable. The case for a shared protocol grows as the number of pairs grows.
One question settles most of these: what is on each end of the connection? If it is an agent and an external system, that is MCP. If it is an agent and another agent, that is a communication pattern.
Follow-up 3: memory is a decision about what survives
“How does an agent remember things?”
Model answer: The model is stateless between calls. Earlier turns are re-sent each time, so memory is never automatic and never free. Memory management means deciding what the agent carries forward, for how long, and what it discards. Working memory holds the current task, such as recent turns and the last tool result, and is discarded when the task ends. Persistent memory holds durable facts, such as a customer’s preferences or prior outcomes. It is stored outside the model and retrieved selectively.
The weak-candidate mistake: “Just give it the whole conversation history.” Everything carried forward is re-supplied and counted again on every call. Cost and latency grow, and what matters gets diluted. Retention is also a risk: a one-off verification code kept in durable storage is a liability, not a feature.
Think of it as a hospital shift handover. Not everything from the shift is passed on. What matters carries over, and the handover is a summary, not a transcript.
Durable facts go to persistent memory; task-local material stays working and is discarded
So the useful question is not “how do we remember more?” It is “what must survive, and what must not?”
Follow-up 4: arrangement and message flow are separate questions
“Name some multi-agent patterns.” Weak candidates answer this with one list. Strong candidates ask which kind of pattern is meant.
Model answer: A multi-agent system uses several specialised agents where one general agent would be stretched too thin. Two independent questions apply to it.
The system pattern is how the agents are structured:
- Supervisor: a lead agent decomposes the task, delegates to specialists and assembles the result.
- Sequential: each agent’s output is the next agent’s input.
- Parallel: independent agents work at the same time and their results are merged.
- Hierarchical: supervisors of supervisors.
The communication pattern is how the agents exchange information:
- Direct (point-to-point): one agent calls another and waits.
- Broadcast: one agent informs many at once.
- Shared state: agents read and write a common store.
- Message queue: messages are passed asynchronously.
The weak-candidate mistake: answering “supervisor” when asked how agents exchange information. That answers a different question.
Think of it as an organisation. The system pattern is the org chart. The communication pattern is how the memos move. A supervisor system can pass messages point-to-point or through shared state, and choosing one does not determine the other.
System patterns describe arrangement; communication patterns describe how information moves
Follow-up 5: orchestration owns the plan, including when to stop
“What is workflow orchestration, and who should own it?”
Model answer: Workflow orchestration is coordinating the steps of an agentic application. It covers sequencing, routing, handling failures and retries, and deciding when the task is finished. That last duty is easy to forget. The plan can be owned in one of two ways. In deterministic orchestration, the developer defines the workflow. It is predictable, testable and auditable, but it cannot adapt to the unforeseen. In model-driven orchestration, the model chooses each next step. It adapts to new situations, but its path varies between runs.
The weak-candidate mistake: treating model-driven orchestration as the sophisticated default. In a regulated or audited process, “the path varies between runs” is a defect.
Think of it as an air traffic controller. Each pilot flies their own aircraft, and the controller decides who moves, in what order, and when the sequence is complete.
Follow-up 6: one agent with good tools is the default
“When would you use several agents instead of one?”
Model answer: Use several agents only when a task spans genuinely distinct specialisms, and be able to name the reason. A task that is long but stays within one specialism is still one agent doing more steps. Every added agent multiplies four things: model calls, which each carry a cost; latency, from steps that wait on each other; failure modes, since any agent can stall or pass on a bad result; and debugging effort, because “which agent decided that?” becomes a real question.
The weak-candidate mistake: reaching for multiple agents because the scenario used the word “complex.”
Here is an illustrative case. A shipment assistant answers “where is my parcel?” by reading a tracking database. It must remember each customer’s preferred notification channel. When a shipment is disrupted, its recommendation needs pricing, customs and capacity expertise. The considered design has two paths. The plain lookup goes to one agent with tools. Only the disruption case goes to a supervisor that coordinates three specialists. Sending the simple query down the multi-agent path adds cost and latency and gains nothing.
Bounded single-specialism work stays with one agent; distinct specialisms justify several
Key takeaways
- An agent is defined by its loop. If no result can come back and change the decision, it is a single model call.
- The model requests; the runtime executes. Reject any answer in which the model itself queries, calls or books something.
- Ask what is on each end of the connection. Agent to external system is MCP. Agent to agent is a communication pattern. MCP is a protocol, not a product, and tools work without it.
- Memory is a choice about what survives. Separate working memory from persistent memory. “Keep everything” is a cost, not a safe default.
- Structure and message flow are separate questions, and orchestration owns the plan, including knowing when to stop.
- One agent with good tools is the default. Escalate only for distinct specialisms.
This article covers what the parts of an agentic system are. It does not settle what agents are for in business terms. It also does not cover how to choose between the specific managed services that implement these parts, or what each costs at scale. Those are separate questions, and exams typically test them under separate objectives.