Choosing an Agent Type

What it does

Picks the right agent shape before you build. "Agent" covers a no-code chat helper a business user knocks up in an afternoon and a fully hosted custom-model system with its own orchestration. Getting this wrong means either hitting a ceiling or over-engineering.

Key facts

Agent Builder (no-code in Copilot) — the in-Copilot maker experience. Produces a declarative agent. For business users, single-purpose, SharePoint and connector knowledge, no code.
Declarative agent — runs on Copilot's own orchestrator and foundation model, no hosting to run. You supply instructions, knowledge and actions. Lives inside M365 Copilot and the Office apps. Needs an M365 Copilot licence to run there.
Custom-engine agent — you own the orchestration, the model and the data plumbing. Hosted outside M365 (typically Azure, at extra cost). Runs anywhere — M365, a website, a portal — and does agent-to-agent work.
Copilot Studio agent — the Copilot Studio build surface. Low-code but far more capable than Agent Builder: topics, triggers, multiple channels, ALM, autonomous behaviour. Consumption-priced in Copilot Credits.
Autonomous agent — not a separate product so much as a mode: a Copilot Studio agent that fires on an event or schedule and runs unattended, no person in the chat.

When to use / skip

Default low and climb only when something forces you up. A business user who wants a Q&A bot over a SharePoint site — Agent Builder, done. Need it inside M365 Copilot with a bit more control but still no hosting — a declarative agent built in the Agents Toolkit.

Reach for Copilot Studio when you need multiple channels (web, Teams, voice), real conversation design, triggers, environments and ALM, or grounding on Dataverse and line-of-business connectors. Go autonomous when the work should happen without a human prompting it — a nightly reconciliation, an inbound-email handler. Only build a custom-engine agent when a non-negotiable forces it: your own model, orchestration Copilot can't express, deployment outside Microsoft, or agent-to-agent coordination. It's the most work and the most cost — don't start there.

Configuration decisions

Who owns it — a business user or a dev team? That splits Agent Builder/declarative from Copilot Studio/custom-engine.
Where does it run — only inside M365 Copilot, or external channels and portals too?
Do you need your own model or orchestration logic, or is Copilot's orchestrator fine? Own model means custom-engine.
Person-in-the-loop or unattended? Unattended means an autonomous Copilot Studio agent with triggers.
Do you need ALM, environments and source control? That rules out Agent Builder and points at Copilot Studio or pro-code.

Gotchas

Agent Builder's ceiling is deliberate. People build there, hit a wall on actions or logic, and have to rebuild in Copilot Studio. Set that expectation up front.
Declarative agents need M365 Copilot licences to run inside Copilot — "no hosting cost" isn't "no cost".
Custom-engine agents carry Azure hosting and model bills that people forget when comparing to a declarative agent's flat licence.
Autonomous runs consume credits without anyone watching. A bad trigger or loop can rack up a bill quietly.
Declarative and custom-engine are convertible one way in effort but not casually — pick with the end state in mind, not just the demo.

Consultant notes

Nine times out of ten the right answer is declarative or a Copilot Studio agent. Custom-engine is a minority sport — treat "we need custom-engine" as a claim to test, not accept.
Price the hosting and model cost of custom-engine explicitly; it's where fixed-price agent projects bleed.
For citizen-maker sprawl, standardise on Agent Builder with tenant guardrails rather than banning it — you'll lose the ban.
Design the autonomous trigger and its stop conditions before the happy path. Unattended agents fail expensively.

If a client says "custom-engine", ask which specific requirement rules out a declarative or Copilot Studio agent — usually none does.