Trade notes
AI lab
08Agent Setup· 8 min read

Configuring agents: scope, tools, exit conditions

Most agents that fail in production fail at configuration, not capability. Here's the unglamorous starter pack: what to set, what to default, and what to instrument before you let an agent loose in your tenant.

The fastest way to get an agent into production is to write a clever prompt and wire up a few tools. The fastest way to take it out of production is to discover, at 2 a.m., that it has no exit condition and is now sitting at 14,000 tool calls and counting.

Almost every agent failure I've debugged in the last year was a configuration failure, not a capability failure. The model was fine. The prompt was fine. The wiring underneath was sloppy.

This is the brief on the unglamorous part: what an agent's config actually is, what each piece does, and what defaults will save you a Tuesday.

What a configured agent is, structurally

Strip the marketing and a deployable agent has six load-bearing pieces:

  1. Identity: who the agent runs as and what it can authenticate as elsewhere.
  2. Scope: the goal, expressed precisely enough to know when it's done.
  3. Grounding: the data sources it's allowed to read.
  4. Tools: the actions it's allowed to take.
  5. Exit conditions: the rules that stop the loop.
  6. Observability: what gets logged, where, and who's watching.

If any of these is "we'll figure that out later," your agent is not configured. It is a prototype.

1. Identity

In M365, an agent is either acting as the user (delegated permissions) or acting as itself (workload identity / service principal). The choice has consequences:

  • Acting as the user. Inherits the user's permissions and sensitivity-label access automatically. Easy. The risk is that an agent can do anything the user can, including things the user wouldn't manually do at scale. Mitigation: scope the agent's tools narrower than the user's full permission surface.
  • Acting as itself. A service principal in Entra with explicit Graph permissions. More setup, but the permission surface is auditable and constrained. This is the right default for any agent doing tenant-wide or scheduled work.

For Copilot Studio agents, this maps to whether the agent runs in the user's context or as a connection. Pick deliberately. Document the choice.

2. Scope

The most common configuration mistake is a vague scope. "Help with customer support tickets" is not a scope. It's a hope.

A real scope reads more like: "For tickets in queue X with priority normal or low, generated less than 4 hours ago, draft a first-response reply that addresses Y and includes Z. Surface to a human for approval before sending. Stop after one draft per ticket."

The five questions a scope must answer:

  • Trigger: what makes this agent start running?
  • Inputs: what data does it operate on?
  • Output: what artifact is it producing?
  • Boundary: what is explicitly out of scope?
  • Done: what state means "this run is complete"?

Write these down. Show the user. Refuse to ship the agent without them.

3. Grounding

Grounding decisions are where governance lives. You're answering: what can the agent read?

Patterns that work:

  • Allowlist over denylist. Specify the exact data sources the agent can reach. Don't try to enumerate what to exclude. You'll miss something.
  • Sensitivity labels as hard fences. If you've labeled documents Confidential or higher, configure the agent to skip them by default. Surface the skip in the audit log.
  • Site-scoped, not tenant-scoped. A Copilot Studio agent grounded in all of SharePoint is doing the wrong thing. Scope to specific sites, libraries, or folders.
  • Test grounding with a "least surprising" set. Before production, run the agent against a curated set of inputs and check what it surfaces. If it's reaching for documents you didn't expect, your grounding is too loose.

The shortcut here is to use the existing M365 information-protection model (Purview, sensitivity labels, SharePoint permissions) as your grounding boundary. You don't have to build a new control plane. You have to configure to the one you already have.

4. Tools

Each tool is a permission. Each permission is a thing the agent can do without asking. Treat them that way:

  • Minimum tool set. Start with the fewest tools that let the agent succeed at the scope. Adding a tool is a config change with a review.
  • Read-then-write separation. An agent that can read freely and write narrowly is much safer than one with symmetric permissions. Most workflows can be designed this way.
  • Sandbox writes. Where possible, tools that write should write to a staging area (a draft folder, a pending queue), not to the live system. A human promotes.
  • Tool descriptions. Already covered in the prompting brief, but worth repeating: tool descriptions are part of the agent's prompt. Vague descriptions get vague tool selection. Write them like they matter.

5. Exit conditions

This is the section that most teams skip. An agent without explicit exit conditions runs until it crashes, runs out of money, or makes a mess.

The minimum exit conditions:

  • Budget cap. Stop after N tool calls or N tokens. Pick numbers that allow normal completion with margin, not numbers that require optimal play.
  • Time cap. Stop after T seconds of wall-clock time. Useful primarily as a safety net for runaway loops.
  • Goal achieved. The "done" signal from the scope definition. The agent should detect this and stop voluntarily.
  • User interrupt. Any human action that cancels the run. Especially important for long-running agents.
  • Confidence threshold. If the agent's self-reported confidence drops below X, escalate to a human and stop.

These should be configurable, logged when triggered, and reviewed weekly during the early life of the agent.

6. Observability

A configured agent without observability is a prototype that can hurt you. The minimum:

  • Log every loop. Inputs, model decision, tool called, tool result, time, cost.
  • Aggregate by run. A "session" view that shows the full trace of a single agent execution. Not raw lines you have to grep.
  • Alert on the unusual. Loop counts above N. Cost above $X per run. A previously rare exit condition firing repeatedly. A document being touched outside business hours.
  • Make the audit trail human-readable. When something goes wrong, the first question is what happened. The audit trail is the answer. If a non-engineer can't read it, it's not done.

In M365, Purview and the agent-specific audit log give you most of this for free if you turn on the right categories. Turn them on.

In your environment

If you take one thing from this brief: before you put an agent in front of users, write down the six pieces above on one page and have someone who isn't you read it back. Half the production incidents I've seen would have been caught at that step.

The good news: configuration discipline scales. Once you have a "starter agent" template that hits all six, every subsequent agent is a fork-and-modify, not a rebuild. The teams that ship many agents quickly are the teams that built the boring template first.

Sources: Best practices for building agentic systems: InfoWorld · Best Practices for AI Agent Implementations 2026 · Anthropic: Building agents with the Claude Agent SDK