Designing AI Across Dynamics 365, Power Platform, and Foundry

Many Microsoft organizations already have business processes spread across Dynamics 365, Dataverse, Power Apps, Power Automate, Microsoft 365, and Azure services before an AI initiative begins. Agentic architecture should not flatten those systems into one new “AI platform.” It should decide how AI participates in an existing application landscape: where the authoritative records remain, where deterministic workflow belongs, where model reasoning adds value, and how actions are governed across boundaries.

That cross-platform judgment is central to AB-100. Microsoft’s current role description expects solution architects to work across Dynamics 365 products, Power Platform, Copilot Studio, Microsoft Foundry, and AI services. The architecture is therefore about composition. Each platform should contribute the capability it is best positioned to own, with explicit contracts between them.

The Agentic AI Business Solutions Architect is not replacing functional and development specialists. The role defines an end-to-end design that lets those specialists work coherently. It connects business outcomes, process ownership, data, integrations, agent behavior, security, lifecycle, and operational evidence.

Keep systems of record authoritative

A customer record in Dynamics 365, a business object in Dataverse, or a finance transaction in an ERP system should not lose its authority because an agent can summarize or transform it. AI can help users navigate, classify, draft, recommend, and orchestrate, but the architecture should still know which system owns the durable state and which validations apply before that state changes.

This prevents the agent from becoming a shadow database. Conversation memory and retrieved context are useful for reasoning, but they should not silently replace controlled records. When the agent needs to update a business object, use the supported application or API path so existing permissions, validation, auditing, and downstream automation continue to apply.

Use Dynamics 365 AI where the business context already exists

Dynamics 365 applications increasingly include AI capabilities close to sales, service, finance, supply chain, and other workflows. When a built-in capability addresses the requirement, using it can preserve application context and reduce custom integration. The architect should first understand what the application already provides before creating a parallel agent that duplicates the same data and process.

The broader Dynamics 365 model matters because the application is more than a database. It carries business rules, security roles, process semantics, and user expectations. AI should extend those structures deliberately rather than bypass them.

Use Power Platform for governed business automation

Power Apps, Power Automate, Dataverse, connectors, and Copilot Studio can provide the deterministic and low-code layer around AI behavior. A model may interpret an email or classify a request, while a flow enforces required fields, approval routing, record creation, notifications, and other repeatable steps. This separation makes it easier to audit which decisions were probabilistic and which were rule-based.

Architects familiar with Power Platform solution architecture already think in terms of environment strategy, data, integration, security, and lifecycle. Agentic solutions add model behavior and autonomy, but they do not remove those platform responsibilities.

Reserve Foundry for AI engineering that deserves an engineering surface

Microsoft Foundry is appropriate when the solution needs custom models, advanced retrieval, code-first agents, complex tool use, specialized evaluations, network isolation, or engineering frameworks that would be awkward to express in a business configuration layer. It can become the AI service tier consumed by several applications rather than a replacement for those applications.

This separation is especially useful when a central AI engineering team maintains reusable capabilities. A grounded document-analysis agent, for example, might serve a service application, an internal portal, and a custom web app through stable interfaces. The applications keep their user and process context while the engineering team manages the shared AI component.

Define identity propagation across every hop

Cross-platform AI can create confusing authorization if one service calls another with a broad application identity. The architecture must decide whether an action runs as the end user, as an agent, or as a service principal, and what the downstream resource can infer from that identity. On-behalf-of patterns, managed identities, connector authentication, and application permissions each create different audit and least-privilege properties.

Identity should follow responsibility. If an agent is merely helping a user search records, the user’s existing access boundary may be the safest context. If an autonomous back-office agent performs scheduled work, a dedicated workload identity may be more appropriate. What matters is that every action can be attributed and authorized at the right layer.

Make integration semantics explicit

A connector can move data, but architecture needs to define what the data means. If an agent creates a “qualified lead,” what criteria were applied? If it updates a case priority, is that a recommendation or an authoritative classification? If an AI component returns a confidence value, what threshold changes downstream workflow? These semantics belong in interface contracts and process documentation.

This is why the PL-600 solution-architecture perspective can remain relevant beside AB-100. AI does not remove the need for requirements analysis, integration design, and application lifecycle decisions. It increases the cost of ambiguity because probabilistic components may interpret vague contracts differently over time.

Design data movement to minimize copies and privilege

Cross-platform solutions can easily duplicate customer, document, and operational data into caches, vector stores, prompts, telemetry, and temporary agent memory. Each copy creates retention, privacy, residency, and access questions. The design should identify which data must move, which can be referenced in place, how grounding respects user entitlements, and how transient context is removed.

Retrieval pipelines also need data ownership. If a Foundry component indexes content from Dynamics or SharePoint, the team must know how changes and deletions propagate, how permissions are enforced, and what happens when source data becomes stale. AI grounding is only as trustworthy as the synchronization and authorization model behind it.

Create one lifecycle across several platforms

A release may include a Copilot Studio agent, Power Automate flows, Dataverse schema, Dynamics configuration, Foundry agent code, prompt versions, model settings, connectors, and environment variables. If each component is promoted independently without dependency management, production behavior becomes hard to reproduce. The architecture needs a release sequence and version relationship across the stack.

This is where implementation depth from areas such as PL-400 and AI development becomes complementary. Developers can own component deployment mechanics while the solution architect defines the end-to-end lifecycle, compatibility expectations, rollback points, and evidence required before promotion.

Telemetry should let an operator follow one user or automated transaction from the application through the agent, model, retrieval, connector, workflow, and final record update. Separate platform logs are not enough if there is no correlation key connecting them. Cross-system traceability is essential for incident response and for explaining why a business record changed.

The same trace should support outcome measurement. An architect should be able to ask whether AI reduced handling time, improved conversion, lowered rework, or created new exceptions. A solution can be technically available and still fail its business case. End-to-end metrics keep the architecture accountable to the outcome that justified the AI work.

Existing application capabilities should be evaluated before a custom agent is introduced. Dynamics 365 and Microsoft 365 increasingly contain task-specific copilots and agents that already understand product context. Reusing a supported in-application capability can reduce duplicate data movement and custom maintenance. Custom architecture earns its cost when the process spans products, needs unique business logic, or requires control the built-in feature does not provide.

Cross-platform design also needs a shared vocabulary for customer, case, order, product, employee, and other business entities. If different systems use the same word for different concepts, an AI layer can amplify the ambiguity by confidently combining them. Data contracts and canonical identifiers help the agent connect records without inventing relationships that the enterprise architecture never defined.

Licensing and capacity are architecture inputs as well. A technically valid composition may create unexpected per-user, per-capacity, model, connector, or runtime costs at scale. Cost modeling should use realistic transaction volumes and include retries, human review, nonproduction environments, telemetry, and peak usage. The least expensive prototype is not necessarily the least expensive operating model.

Support models should be designed with the same cross-platform clarity. A frontline user should not need to know whether a bad answer came from a Dynamics feature, a Copilot Studio instruction, a Foundry retrieval component, or a Power Automate flow. First-line support needs a single intake path and enough correlation data to route the incident to the correct owner. Architecture that distributes capabilities without designing support simply moves integration complexity from developers to users.

Architecture documentation should include a responsibility matrix for the AI stack. One team may own Dynamics configuration, another Power Platform automation, another Foundry components, and another security policy. The matrix should identify who approves data access, prompt or instruction changes, connector additions, model changes, and production incidents. Without those decision rights, cross-platform flexibility turns into change-management ambiguity.

Compose the platforms instead of collapsing them

The strongest Microsoft AI architectures usually preserve useful boundaries. Dynamics 365 remains the business application and system of record; Power Platform handles governed automation and extension; Copilot Studio manages many business-facing agent experiences; Foundry provides deeper AI engineering where required. Custom services fill gaps through explicit interfaces rather than becoming an unplanned integration layer.

That composition is easier to secure, test, and change because each platform has a clear role. The AB-100 architect’s task is to make those roles coherent around one business outcome. Good architecture does not ask which Microsoft platform wins. It asks which platform should own each responsibility, how trust crosses the boundary, and how the organization will operate the complete solution after the demo is over.