1.1.1. What Makes an Agent an Agent
💡 First Principle: An agent is a loop, not a lookup. It perceives (reads the conversation, an event, or a schedule), reasons (interprets its instructions against what it perceived), and acts (responds, calls a tool, runs a flow, delegates) — then perceives the result and goes around again until the goal is met.
That loop is why every Copilot Studio agent, no matter how simple, is assembled from the same anatomy:
Instructions tell the agent who it is and how to behave — they are the standing orders the orchestrator consults on every turn. Knowledge gives it facts it can retrieve and cite. Tools give it the ability to change the world outside the conversation: run an agent flow, call a connector action, invoke an MCP tool, hit a REST API. Topics give you, the maker, deterministic control over specific conversational paths. Triggers determine when the agent wakes up at all — a user message is the obvious one, but agents can also fire on events and schedules, which is what makes autonomous agents possible.
What breaks without this mental model: you conflate the pieces. Knowledge and tools both "extend the agent," but knowledge is read-only retrieval for grounding answers, while tools perform actions with side effects. Exam scenarios routinely hinge on that line — "the agent must look up policy documents" points to knowledge; "the agent must create a ticket" points to a tool.
⚠️ Exam Trap: When a scenario says the agent must both retrieve information and take action, you need both a knowledge source and a tool — one component never does double duty. Distractors love to offer a single knowledge source as the answer to an action requirement.
Reflection Question: A colleague says their agent "knows how to file expense reports" because they uploaded the expense policy PDF as knowledge. What can the agent actually do, and what is still missing?
