Everything in an AI agent flows through a large language model. Before you can build an agent, you must understand what an LLM actually is, what it is good at, and — crucially — where it fails. This is not about memorising transformer architecture. It is about developing an accurate mental model of how the model reasons.

Prompt engineering is the practical expression of that understanding. In an agent context, prompts are not one-liners — they are structured system instructions that define the agent’s role, constraints, output format, and tool-use behaviour. A poorly designed system prompt produces an unreliable agent regardless of how well everything else is built.

An AI agent that cannot connect to anything is just a chatbot. The ability to integrate APIs — both the LLM API and the external services the agent will use — is the technical foundation of every real agent deployment.

This means being comfortable with REST APIs, authentication patterns (API keys, OAuth), rate limits, error handling, and structured responses. Most agent frameworks abstract some of this, but you need to understand what is happening beneath the abstraction to debug when things go wrong — and they will go wrong.

This is the single most important skill for building useful AI agents in 2025. Function calling allows the LLM to decide when to call an external tool — a web search, a database query, a code executor, a calendar API — and then incorporate the result into its next step.

Without tool use, an agent is limited to what the model knows at training time. With tool use, it becomes capable of real-time action. The agent is no longer predicting text — it is actually doing things in the world.

LLMs have no persistent memory between sessions. Every call starts from zero. For an agent that runs multi-step tasks — sometimes over hours or days — this is a fundamental constraint you need to engineer around.

Memory in AI agents is a design decision, not a given. You choose what the agent remembers, how it is stored, when it is retrieved, and how it is injected back into the context window. Get this wrong and the agent loses track of what it was doing. Get it right and the agent maintains coherent behaviour across complex, long-running workflows.

A single agent can handle a single task. Real-world workflows often require multiple agents working together — a planner that breaks down tasks, specialised agents that execute them, and a supervisor that checks the results. Orchestration is the skill of designing and managing those systems.

Modern frameworks like LangGraph, CrewAI, and Anthropic’s own multi-agent patterns provide structures for this. But the framework is not the skill — understanding when to use a single agent versus multiple agents, and how to pass state between them reliably, is the actual skill.

Most developers who build AI agents spend 80% of their time on construction and 20% on testing. In production, that ratio should be closer to the opposite. Agents that are not rigorously evaluated fail in unpredictable ways — and because LLMs are non-deterministic, a test that passes today may fail tomorrow on the same input.

Evaluation is the discipline of systematically checking whether your agent does what you intend — and whether it continues to do so as models are updated, prompts drift, or edge cases emerge. Building an eval suite is as important as building the agent itself.

An AI agent that can take actions in the world is an AI agent that can take the wrong action — sometimes at scale. Security is not a feature you add at the end of development. It is an architectural concern that shapes how you design the agent from the start.

The most critical threats are prompt injection (malicious content in the agent’s environment attempting to hijack its behaviour), excessive permissions (agents with more access than they need), and insufficient human oversight on irreversible actions. These are not hypothetical risks — they have occurred in real deployments.