Agentic AI is the 2026 differentiator. Knowing how to call an LLM is no longer enough; interviewers want to know whether you understand the system around the model when you add planning, tools, memory, and supervision.
Many candidates spend months learning models. Very few spend time understanding everything around the model.
What? An LLM is a text generator. An AI Agent is a goal-driven system that uses an LLM as its reasoning layer, plans tasks, calls external tools/APIs, has memory, executes workflows, and makes decisions.
Why? Because interviewers test whether you understand the actuators (tools) and sensors (retrieval/memory) around the LLM.
How? The contrast:
| Capability | LLM | AI Agent |
|---|---|---|
| Generative text | ✓ | ✓ (via LLM) |
| Plans tasks | ✗ | ✓ |
| Calls APIs / tools | ✗ | ✓ |
| Has memory (short / long) | ✗ | ✓ |
| Executes workflows | ✗ | ✓ |
| Multi-step autonomy | ✗ | ✓ |
Scenario 1 — “Recommend a mortgage” (pure LLM use case) Ask GPT about mortgages; it gives generic copy. No checks are run on the user’s bank balance, no mortgage calculator is consulted, no email is sent. That’s an LLM.
Scenario 2 — “Help me apply for a mortgage” (Agent use)
The Agent confirms identity, fetches accounts, calculates eligibility, asks the user to upload payslips, runs an LLM-based eligibility explanation, drafts an email, sends it. That’s an Agent.
Scenario 3 — “Reply to this customer complaint, escalate if needed” (Multi-Agent) Agent 1 = Triage; Agent 2 = Compliance; Agent 3 = Response; Supervisor = decides escalation. That’s a Multi-Agent system.
What? MCP is an open protocol that standardises how AI models communicate with external tools, resources, and services. It defines a JSON-RPC-based contract so any client can connect to any compliant tool without writing custom integration glue.
Why? Because without MCP, every Agent team reinvents tool-calling adapters. With MCP, a tool built once is reusable across Claude, GPT, Gemini, any compliant model.
How? MCP has three layers:
Scenario 1 — Tool reuse across vendors
Company A builds a CRM_lookup MCP server. Claude Desktop, GPT-5 agent, LangGraph agent, and a custom app can all plug into it without rewriting. Before MCP: each frontend wrote a bespoke Python wrapper.
Scenario 2 — Compliance tooling A bank needs every tool call audited. MCP server logs every request in a tamper-evident ledger; the agent calls the tool, the call gets logged automatically. Before MCP: the agent code had to do its own logging.
Scenario 3 — Resource freshness
Doc-stores need reindexing every X minutes. An MCP resources endpoint can advertise “this cache expired, fetch again.” The agent sees the resource and refreshes. Before MCP: every agent manually polled the cache.
What? Memory is how an agent personalises, retains, and improves over conversations.
Why? Because stateless LLMs forget everything between requests; memory is what makes an agent feel intelligent.
How? Four types:
Scenario 1 — Customer-support agent Short-term: this conversation. Semantic: “user has a £12k savings account.” Episodic: “last year the user opened a credit card; rejected, needs help re-applying.” Long-term: name, address, customer ID. All four types are essential for an FCA-grade banking agent.
Scenario 2 — Trading-assistant agent Episodic memory is critical: “you sold AAPL on Feb 3, lost 8%.” Without episodic the agent cannot reference past actions. Without long-term the agent cannot apply user’s risk profile.
Scenario 3 — Coding agent (general-purpose) Short-term: current session. Semantic: “user prefers Python with FastAPI.” Episodic: 30-day history of past projects. Long-term: account-level preferences (Emoji in comments: yes).
What? Agent testing is multi-dimensional: functional, retrieval, security, tool, memory, cost, hallucination, multi-turn, end-to-end, prompt-injection, latency, performance, regression.
Why? Because agents fail in non-obvious ways. They can pass functional tests and still produce garbage in production.
How? Run a test harness that covers:
Scenario 1 — Looping bug
Agent is asked to fetch last 5 transactions but loops 47 times trying. Test: cap the iteration count; assert tool_calls_count <= 5 per agent run. Result: catches the bug before deploy.
Scenario 2 — Cross-conversation memory bleed
Agent A’s “user_name=John” leaks into Agent B’s invocation. Test: isolation spec — run two agents in parallel, assert neither reads the other’s user_name. Result: catches the shared-class-attribute bug.
Scenario 3 — Tool failure propagation Agent calls a credit-check API that returns 500. Agent retries 3 times then hallucinates a fake credit score. Test: mock the API to 500; assert agent returns “I cannot check credit score right now” rather than inventing one. Result: catches the hallucinatory-recovery failure mode.
What? A pattern where one orchestrating agent decides which sub-agent handles each task. The supervisor routes by intent, by capability, or by load.
Why? Because specialised agents are better than one mega-agent at any non-trivial workload, but you need a coordinator to dispatch.
How? Three patterns:
Scenario 1 — Customer-support multi-agent Supervisor routes to AccountAgent for balance questions, ProductAgent for sales, GeneralAgent for FAQs. Each agent specialises; supervisor is the dispatcher. The supervisor itself is just a classifier.
Scenario 2 — Research multi-agent Planner agent breaks “research X” into subtasks; each researcher agent returns a sub-report; synthesis agent merges them. Plan → execute → merge.
Scenario 3 — Trading multi-agent Risk agent, Execution agent, Compliance agent, all coordinate. Supervisor: “You can’t execute that trade without risk approval.” Peer-to-peer: Risk signals Execution to stop.