Plan interaction patterns and channels
With outcomes defined and the workflow mapped, the next planning question shifts from what agents do to how they engage: which interaction patterns fit each agent, where each agent surfaces, and what rules govern when it acts on its own versus when it hands off to a human.
Choose an interaction pattern for each agent
The interaction pattern you assign to an agent defines its relationship with the people it serves — and sets expectations about how much initiative it takes and how much oversight it requires.
Two patterns cover most agent scenarios:
Conversational agents act on demand in natural language. They always return to the user to share progress or results — whether that’s an immediate answer or the output of a longer task like research or case handling. Use this pattern when users initiate and control requests, and when clarification, reasoning, or personalized assistance is the core value.
Autonomous agents operate independently once triggered, involving humans only when needed. Use this pattern for tasks that need to run end to end without waiting for a user to initiate each step. Autonomous agents can be reactive (triggering on a form submission, a record change, or a schedule) or proactive, monitoring signals and initiating engagement at the right moment. A claims submission agent that runs end to end when triggered is autonomous. So is a contract renewal agent that monitors upcoming expirations and surfaces a spend summary to the right owner when one approaches.
Different agents in a solution often use different patterns. A front-door intake agent is conversational. A back-end processing agent triggered on each new submission is autonomous.
The pattern you choose is a commitment about initiative and oversight. The right choice isn’t the most autonomous one technically available — it’s the one that fits the stakes, the data quality you’ve validated, and the oversight model you’ve committed to. An agent operating more autonomously than users expect erodes trust. One requiring more human involvement than the task warrants adds friction without adding safety.
Define engagement rules
Choosing a pattern is the starting point. You also need to specify how the agent behaves at the moments that matter most: when it acts on its own, when it stops to ask, when it escalates, and how it handles content it shouldn’t touch. These aren’t prompt instructions — they’re decisions you make at design time.
Four questions anchor that design:
When does the agent act on its own, and when does it ask for clarification? For a customer service agent: act autonomously on requests that match a well-defined category with a high confidence score, and request clarification when intent is ambiguous or the request spans multiple categories.
When does the agent escalate to a human, and how? Three escalation patterns cover most scenarios:
- Session transfer with context: transfers the active conversation to a human agent with full context attached. Use when an active session needs to continue with a human — for example, a safety incident or high-sentiment complaint in a customer service agent.
- Flagging for human review: marks the case for review without transferring an active session. Use when the case needs attention but there's no live session to transfer — for example, an invoice that fails validation in a finance agent.
- Notification: alerts a team that something needs attention without requiring immediate action.
What does the agent do when confidence is low? Low confidence shouldn't produce a low-quality response. It should trigger a different behavior: surfacing uncertainty to the user, offering options, or routing to a human. Building this rule explicitly prevents the agent from confidently presenting a response it isn't sure about.
What does the agent do with sensitive content? The platform applies default content filtering, but those defaults may not match your agent's specific risk profile. Reviewing and configuring which content categories trigger which behaviors — refusing to respond, escalating immediately, or logging for review — is a design decision that should happen before the agent reaches production, not something left unexamined.
These rules connect directly to the identity and governance planning in the next unit. Deciding when the agent acts sets up the question of what the agent is allowed to act as: the identity and permissions it needs to carry out those actions.
Surface agents where users already work
Channel selection follows a single organizing principle: surface the agent where users already work. An agent that does its job well but appears in the wrong place doesn't get used consistently.
The planning decision is which destination fits where your users already work:
| Destination | Best for |
|---|---|
| Microsoft 365 Copilot | Internal Microsoft 365 users who need knowledge agents or productivity assistants, surfaced in the flow of existing work without requiring a context switch |
| Microsoft Teams | Agents that surface proactive updates, require team-wide shared access, or fit naturally into an existing Teams workspace |
| Custom apps and web portals | External-facing agents, audiences without Microsoft 365 licenses, or scenarios requiring full control over the interaction UX |
Beyond user-facing channels, agents designed for agent-to-agent (A2A) invocation are exposed as callable endpoints rather than user-facing surfaces. A2A-enabled agents are backend specialists that other agents invoke directly — not destinations that users navigate to. Planning for A2A exposure is covered in the next section.
Which destinations you can configure depends on the development platform. Copilot Studio and Foundry each have their own publishing paths and supported channel configurations.
A solution serving both internal employees and external customers might surface agents in two channels: Microsoft Teams for employees, where proactive messaging and shared context matter, and a web portal for customers submitting requests, where a Microsoft 365 license isn’t required. These channels have different authentication models, different UX constraints, and different handoff behaviors, so they require explicit planning rather than assuming a single deployment covers both.
Multi-channel deployment isn't free. Too many channels dilute the experience and increase the support burden. Too few starve adoption. The goal is to surface the agent where its intended users already work, and stop there.
Plan for cross-agent invocation
A pattern common in multi-agent architecture is that some agents are designed to be invoked by other agents, not by human users directly.
In a claims processing solution, for example, a policy lookup agent and a claims validation agent might not be surfaced to users as direct interaction points. Instead, a front-door agent invokes them via A2A: asking the policy agent to retrieve a relevant coverage excerpt, or handing a validated claim to the submission agent for routing and decision logic. From the user’s perspective, one agent handles their request. Behind the scenes, that agent coordinates specialists.
When you design an agent for agent-to-agent invocation, the channel design question shifts. Instead of asking where the agent surfaces for users, the team asks which agents can call it, under what conditions, and with what authentication. Foundry's incoming A2A endpoint requires Microsoft Entra ID authentication — key-based and anonymous access are not supported — so the identity of every calling agent is known and auditable. This is also why the user-facing versus agent-facing distinction matters at design time: it shapes the identity and permissions design the next unit addresses.
For details, see Enabling incoming A2A on a Foundry agent.
Apply it: Think of an agent you're designing. Which interaction pattern fits it — conversational or autonomous — and what's the one engagement rule that matters most for deciding when it hands off to a human?