Plan data sources, workflow, and dependencies
An agent can only be as useful as the information it draws on. Clarifying what each agent needs to know (and where that information lives) surfaces data gaps early, shapes the grounding architecture, and keeps the design grounded in actual requirements rather than platform defaults.
Identify what each agent needs to know
Most agent scenarios draw on one or more of three knowledge domains: work artifacts (email, Teams chats, SharePoint documents, meeting notes, and calendar), enterprise documents (product manuals, policy guides, and standard operating procedures), and structured business data (customer records, order history, and financial metrics). For agents that need real-time context beyond the organization, external web content is a fourth domain. The grounding table in the next section maps each domain to the right Microsoft IQ service.
For example, an agent that surfaces answers to policy questions relies primarily on enterprise documents, while an agent that needs to act on a user's actual account state grounds its outputs in structured business data. Multiple agents in a solution can share the same knowledge sources — knowing which domains each agent needs helps you size and configure those sources correctly, and reveals where data quality work is required before the agent can be trusted to act on it.
Alongside mapping knowledge domains, assess data quality for each one and treat that as a design gate, not a build-time concern. Truncated or incomplete content in your knowledge sources degrades output quality regardless of how well the agent is built. If policy documentation is outdated, a knowledge agent's answers will be unreliable. If customer records are incomplete, a workflow agent can't draft accurate responses. Weak or stale data is a signal to consider a more supervised initial rollout: more human review, a narrower scope, or a staged approach that starts with the scenarios where data quality is strongest.
Choose a grounding strategy
Microsoft's platform provides grounding as a managed service through the Microsoft IQ services. Rather than building custom retrieval pipelines for each data source, you identify the services that support your agent's data needs.
| Service | Data domain | When to use |
|---|---|---|
| Work IQ | Microsoft 365 content: email, Teams chats, SharePoint documents, calendar | Agents that surface organizational context scoped to what the requesting user is already authorized to see |
| Foundry IQ | Enterprise documents: product manuals, policy guides, knowledge bases | Enterprise knowledge bases built on Azure AI Search, supporting agentic retrieval across structured and unstructured data |
| Fabric IQ | Structured business data: customer records, order history, financial metrics | Responses that depend on live data tied to real business entities: account state, inventory counts, real-time metrics |
| Web IQ | External web content | Supplement for real-time external information scenarios |
Note
The availability of Microsoft IQ services varies. Foundry IQ and Web IQ in particular have features that are in preview or not yet broadly available. Verify current availability for each service before finalizing your architecture.
The pattern is the same for every solution: pick the right service per data domain, and make that decision during design, not during build. Each agent's information needs map to a different part of the platform, and doing so ensures your data infrastructure — ontologies, knowledge bases, index configuration — is built for the right approach from the start.
Map the workflow end to end
With information needs and grounding services identified, the team can map the full workflow from a trigger event to a resolved or escalated outcome. A useful decomposition for each step is input → transform → output:
- Input: what the agent receives: a customer message, a handoff from another agent, or a scheduled event.
- Transform: what the agent does: interpret intent, retrieve relevant knowledge, draft a response, categorize, or evaluate confidence.
- Output: what the agent produces: a reply, a categorized ticket record, a handoff, or an escalation flag.
For each transform step, ask: does this transformation require AI judgment, or would deterministic logic produce a more reliable result?
Three design patterns are available across this spectrum:
- Deterministic: every branch and action is explicitly authored. No model is in the orchestration layer. Decisions are rule-based, predictable, auditable, and repeatable every time. This pattern works best for compliance-heavy processes, exact-wording requirements, or high-frequency tasks where deviation is never acceptable. A password reset, a nightly data sync, or a compliance disclosure all fit this pattern.
- Generative: the model reasons dynamically over variable inputs, selecting tools and composing outputs at runtime. This pattern works best for knowledge-heavy domains, ambiguous or multi-intent inputs, and scenarios too broad to fully script — such as an HR benefits Q&A or an intelligent email triage agent.
- Hybrid: generative orchestration handles the parts that require reasoning. Deterministic steps govern the parts that require reliability and auditability. The transition point between the two layers (sometimes called the seam) is a deliberate design decision, not a fallback. Most enterprise production agents land in the hybrid range. A banking service agent might use generative conversation to interpret a customer's request, then deterministic steps to execute a balance transfer or submit a dispute, ensuring the open-ended part of the interaction doesn’t introduce unpredictability into the consequential action.
The hybrid pattern is the recommended starting point for most process-automation scenarios. The question isn't whether to include deterministic steps. It's where to draw the seam.
This choice also carries a cost-and-risk dimension. Every generative step introduces non-determinism: the output may vary, latency increases, and failure modes are harder to anticipate. Reserving generative reasoning for steps that genuinely require it, and using deterministic logic everywhere else, produces a workflow that’s more predictable, easier to audit, and less expensive to run.
Try it yourself: Sketch a workflow for an agent using the input → transform → output model. What triggers it? What does it read, and from which data domain? What does it produce? For each transform step, decide whether it needs generative reasoning or whether deterministic logic would be more reliable.
Design for modularity
A single agent that handles intake, knowledge retrieval, categorization, and escalation is technically possible — but it's hard to evaluate, hard to improve, and difficult to replace when requirements change. When a workflow has distinct intents or roles, dividing it across specialized agents with clear handoffs produces a design that's easier to operate and evolve.
A claims processing solution illustrates this pattern:
- Front-door agent: collects claim details and routes the request
- Policy lookup agent: handles document-grounded questions about coverage and eligibility
- Claims submission agent: handles validation, fraud checks, and escalation
Each agent has a clear input, a defined output, and a handoff condition. That separation makes it straightforward to evaluate each agent against its own success metrics, improve one without disturbing the others, and add a new specialized agent if the scope expands — and it mirrors how the organization operates through scoped roles and handoffs.
Before finalizing the design, identify the tools and external dependencies each agent requires: which connectors, Model Context Protocol (MCP) servers, or APIs it calls. For each dependency, note whether the action is destructive (writes data, sends a message, triggers a downstream process) or nondestructive (reads data), and what happens if the dependency is unavailable. Destructive actions warrant explicit confirmation steps or human approval. Unavailable dependencies need fallback paths rather than silent failure.