Until now, every run began when you pressed Test. An autonomous agent starts from an event, acts without someone watching, and reports to people who may rely on that report.
The agent therefore needs evidence for each claim it makes. You'll place approval and replay protection before consequential actions, define truthful terminal statuses, evaluate the results against checkable criteria, and keep publication evidence separate from what the agent does in a real host.
Events turn chat agents autonomous
A conversation-driven agent waits for a person to type. An event-driven agent starts working when another system reports a change (a record enters a "Submitted" state, say) and runs a flow without anyone watching. That single shift raises the stakes, because now the agent's report is the only thing a downstream person sees.
The discipline is to remember what an event proves: that work started. It doesn't prove the input was valid, that a required approval happened, or that a record was created. Those are separate facts, each earned at its own step. A well-built autonomous flow makes that explicit by returning one of a small set of terminal statuses, and by meaning them precisely:
- CompletedAutomatically: the amount did not need approval and the task was created.
- Approved: a human approved and the task was created.
- Rejected: a human declined. No task exists.
- InvalidInput: validation stopped processing before any action.
- Failed: an action was attempted but did not create the task.
"Approved" can never describe automatic work, and neither success status is allowed until a destination record exists. Getting these apart, in your head and in the flow, is most of what autonomous safety is.
Human approval belongs before the action
Put a human in the loop before any consequential action, not after. A common design gates on a threshold: above some amount, pause for a person's decision. At or below it, process automatically. The approval request should carry everything the approver needs to decide: the request, requester, amount, purpose, the action approval authorizes, and what rejection means.
Approval authorizes an attempt. It doesn't guarantee the outcome. If a human approves and the create step then fails, the honest status is Failed: not "Approved," not "queued," not "escalated." The agent may report only what a verified action produced. This is the single rule that keeps an autonomous agent trustworthy: never describe approval, creation, notification, or escalation unless the returned status confirms it.
Repetition is its own hazard. Systems redeliver events, and a repeated event with the same request ID must not create a second task. Put a replay guard before approval or creation: if a record with that ID already exists, request no approval, attempt no create, return a replay-specific non-success status, and leave the matching count at exactly one. Replay protection is boring to build and costly to skip. One duplicated order teaches the lesson the hard way.
Evaluate agents with checkable rubrics
Clicking through a few prompts isn't evaluation. Build a test set: named cases, each pairing an input with an expected, observable behavior. Microsoft's Copilot Agent Kit provides test types for different boundaries, such as Response Match for stable text, Topic Match for routing, and Generative Answers for knowledge answers whose wording varies, so you protect the right property for each case instead of exact-matching everything.
Keep two things separate: the acceptance criterion (the business requirement, like "states 16 weeks, full-time status, and 12 months of service") and the configured oracle (the rule the test applies). An answer can violate the real requirement while passing a loose oracle. That gap is itself a finding: the agent is incomplete and the oracle is weak.
For knowledge answers, the Kit uses an AI judge that grades from 1 to 5 against a rubric, with a documented passing threshold of 5 and support for comparing its grades to a human's.
A vague rubric, such as "give a 5 for a good answer," is useless. A checkable one, such as "give a 5 only when all three required facts appear," is a real acceptance test. When a case fails, classify it (agent behavior, oracle configuration, a missing dependency, and so on) and fix the right thing. The one move you never make is weakening a correct criterion to turn a failure green. An outcome label like "Answered," or a top AI grade, isn't proof the facts are right.
Publishing has separate checkpoints
Publishing gives you several checkpoints, each with a narrow meaning: the authoring test, the publish result, channel availability, host behavior, and identity. An authoring test says nothing about whether publishing completed. Publishing doesn't establish that a channel is available. Opening the host doesn't validate its answers, and correct answers don't validate sign-on or access controls.
Check every destination directly. After publishing, open the real host, such as Teams, Microsoft 365 Copilot, or an approved web page, and start a fresh conversation. Repeat both the grounded and unsupported questions. Unpublished edits won't reach connected channels until you publish again, and a Copilot Studio trial can't publish. Record availability, behavior, and identity separately. The agent may answer correctly while the SSO check remains blocked because you don't have configuration evidence. "Blocked" accurately describes that result.
Real-time voice has extra gates worth knowing before you promise it: it requires Dynamics 365 Contact Center with a Voice channel plus both the Omnichannel administrator and Copilot Studio maker roles, and EU Data Boundary customers can't use it because it depends on cross-geo processing they aren't permitted.
Estimate the running cost
Licensing answers two questions that people routinely merge: who is entitled to use the agent, and how is their consumption paid for. Keep them apart. A Microsoft 365 Copilot licensed user (the add-on lists at $30 per user per month, paid yearly) incurs no additional charge for the covered agent interactions. Consumption for other situations is measured in Copilot Credits.
A Copilot Credit isn't one message or one user. Different features cost different amounts. The July 2026 rate table charges, for example, 2 credits per generative answer, 5 per agent action, and 13 per 100 agent-flow actions. Forecast by operation, not by seat: list what the agent does, multiply each by its rate, and add the results. For a metered, non-licensed audience you can turn credits into a rough pay-as-you-go estimate at about $0.01 per credit: 1,630 credits works out to roughly $16.30.
Two guardrails. Separate licensed operations from metered ones so you never charge a licensed user's activity again in the worksheet, and label every number an estimate. Prepaid capacity is also an option for steady usage, but the specific pack prices and any autonomous-trigger surcharges vary by tenant. Have an administrator confirm the current quote before you commit to a billing model.
Every boundary in this module works the same way: a saved draft, a test run, an event, an approval, a publish. At each one, the agent must earn its next claim with evidence, not borrow it from the last step.
