The short answer
Building a custom Copilot agent for CMiC, Viewpoint Vista or Plex takes six phases: pick one workflow, expose the ERP data through an API or a data layer, ground the agent in Copilot Studio or Microsoft Foundry, give it a governed identity, pilot it read-only with a named reviewer, then measure resolution and escalation before adding a second workflow.
Most of the work happens before anyone opens Copilot Studio. It sits in deciding which single workflow the agent owns and proving the underlying records can be read at all. Teams that skip that ordering spend month three defending a stalled pilot to the people who sat in the kickoff.
If you run IT for a contractor or a manufacturer, the request usually arrives fully formed. Someone saw a demo and wants an agent that answers questions about open RFIs, or one that explains why a line went down on second shift. The pressure is real, and so is the exposure. The model is rarely what breaks. Job-cost and submittal records live inside an ERP scoped for transactions, and most projects get funded before anyone checks what that system exposes. The build order below puts that check in week one, where a few days of discovery replaces a quarter of rework.
Where each platform fits an ERP agent
Copilot Studio is the maker and developer surface inside Power Platform, built for multistep logic and business-system integration through connectors (Microsoft Learn). Microsoft Foundry is the managed agent platform: it hosts the agent runtime and carries a swappable model catalog, with observability through tracing and evaluators (Microsoft Learn).
| Copilot Studio | Microsoft Foundry | |
|---|---|---|
| How it reaches the ERP | Power Platform connectors, REST API tools from an OpenAPI specification, HTTP request nodes | Shared toolboxes, hosted tools, custom functions |
| Governance surface | Power Platform admin center: DLP, connector policies, environment roles | Microsoft Entra identity, RBAC, content filters, network isolation |
| Measurement | Built-in analytics: engagement, resolution, escalation and abandon rates | Evaluators, tracing, continuous evaluation through Application Insights |
| Reach for it when | A person is asking a question or starting an approval | The agent needs a specific model or its own runtime |
These compose. A Foundry agent connects into a Copilot Studio agent as an external agent, so the reasoning lives in Foundry while the conversation and the governance stay in Copilot Studio (Microsoft Learn).
Which workflow should the first agent own?
Pick the workflow a person already performs by reading two screens and applying a rule they can say out loud. In construction that tends to be RFI triage or change-order review. On the plant floor it tends to be shift-report summarization or a work-order lookup. One workflow, one system of record, one reviewer.
The temptation runs the other way. Leadership asks for a list of everything an agent might do. The list reaches sixty items and prioritization becomes the project. Volume of ideas is never the constraint. One ArchitectNow AI Day workshop surfaced 131 AI use cases, consolidated them into 18 thematic opportunity areas and 5 ranked should-do initiatives, with two lighthouse use cases live by month six. The ranking mattered more than the count.
Three questions do most of the sorting. How often does someone perform this in a week? How long do they spend reading before they answer? And can a person check the answer in under a minute? A superintendent asking what changed on a submittal scores well on all three. A request to forecast next quarter's labor variance scores badly, because nobody checks it quickly and the mistakes compound quietly.
One more filter saves the most time: the first agent reads and never writes. Anything that posts a change order or releases a work order drags in approval workflows and a rollback plan. Those are solvable. They just don't belong in the engagement that has to prove the idea works.
How do you expose ERP data to an agent?
Three routes cover almost every case. The agent calls a documented API through a Power Platform connector or a REST tool. Or the records land in Microsoft Fabric through mirroring or a OneLake shortcut. Or Dataverse virtual tables surface the external records in place. What the source supports decides which.
The connector route is the shortest when the ERP publishes a documented API. Copilot Studio builds a REST API tool from an OpenAPI specification plus authentication details and a description telling the model when to call it (Microsoft Learn). Where no prebuilt connector exists, a custom connector wraps the API once and is reused across agents. Microsoft's integration guidance flags one trap up front: returning hundreds of results causes a significant delay in the agent's response, so the query has to return an answer (Microsoft Learn).
Dataverse virtual tables handle the case where external data has to look native to Power Platform without being copied. They represent that data as Dataverse tables with no replication, using virtual connector providers for SQL Server, SharePoint, Microsoft Fabric, Oracle Database, Snowflake and Azure Databricks (Microsoft Learn).
Fabric carries the heavier reads. A OneLake shortcut references a table or a folder without copying the data, and database mirroring replicates an operational database into OneLake as analytics-ready Delta tables, with changes published as fast as every 15 seconds (Microsoft Learn). Microsoft is blunt about the constraint: if a source stores data in a proprietary format, "mirroring is your only option" (Microsoft Learn, accessed September 2026).
Which ERPs expose usable APIs today?
ArchitectNow sorts candidate systems into three buckets before design starts: reachable directly, reachable through a data layer, and reachable only through a project. The bucket depends on version, hosting model and licensed modules in that specific tenant, so it gets verified against the customer's own environment rather than a vendor datasheet.
The verification is mechanical and takes about a week. Request the API documentation for the exact objects the workflow needs; the product's general API page will not settle it. Authenticate a service account against the customer's own instance and read one real record. Then read a hundred, watching paging and rate limits. Check whether the objects are exposed at all.
Whether the target is an AI agent CMIC users ask about job cost, an AI agent Viewpoint Vista users query for change orders, an AI agent Procore users point at documents, an AI agent Plex users ask about downtime, or a Copilot agent Epicor users run against work orders, the same test governs the budget.
Bucket one finishes the test in a day and the connector route works. Bucket two returns partial answers: an API exists but doesn't cover the objects, or the deployment is on-premises, or customization has moved the data past the documented surface. That is where Fabric mirroring or Dataverse virtual tables carry the read path, and it adds a data-layer phase. Bucket three has no supported programmatic read, and the honest answer is that the agent sits behind a data project. Publishing the assignment before the build starts converts an open-ended AI project into a scoped one.
How do you govern what the agent can see?
Governance for an ERP agent runs on two surfaces. Microsoft Entra Agent ID gives the agent its own identity with an accountable human sponsor, and Microsoft Purview handles sensitivity labels and data loss prevention on the content it reads. Power Platform DLP policies decide which connectors the agent is allowed to call at all.
Entra Agent ID treats agents as first-class identities governed the way people are. Every agent identity requires a human sponsor accountable for its purpose and its access reviews, and if that sponsor leaves, sponsorship transfers automatically to their manager (Microsoft Learn). Agent identity blueprints apply Conditional Access rules once, and every current and future instance inherits them, letting an administrator disable a whole class of agents in one operation. Microsoft's best practice is to register every agent in Entra whatever platform built it, so the tenant keeps one inventory (Microsoft Learn).
Purview covers the content side. For agents built in Copilot Studio, sensitivity label support applies when the knowledge source is SharePoint, which includes OneDrive, or Dataverse with auto-labeling policies. A DLP policy scoped to the Microsoft 365 Copilot location can stop those agents from processing content carrying a given label (Microsoft Learn).
Label the sensitive material before the agent exists and it inherits the boundary. Skip that step on a bid folder and the agent becomes the fastest way to find unit pricing.
How do you pilot it without a six-month project?
Run the first pilot read-only, on one workflow, with a named reviewer and a fixed end date. The agent answers and a person still acts. Taking out the write path removes the approval cycles and risk reviews that add months, and it still produces a usage record within weeks.
Ship it to ten to twenty people who perform that workflow daily. A pilot spread across forty occasional users generates opinions. One concentrated on the people who do the work generates transcripts worth reading, and the reviewer makes a weekly pass, grading answers against what the ERP actually holds.
Write the escalation path before the first prompt. In Copilot Studio that route is an actual construct: sessions that hand off through the Escalate topic or a Transfer conversation node get counted as escalations, which keeps them out of the abandon rate (Microsoft Learn). Instrument on day one. In Foundry that means tracing and pre-production evaluation against a curated dataset before the agent meets a user, then continuous evaluation on sampled production traffic (Microsoft Learn).
Write-back comes later and inherits the trust the read agent earned. When it arrives, a Power Automate flow or a Copilot Studio agent flow carries the deterministic action while the agent keeps the judgment step. That sequencing costs one extra release. It buys four weeks of graded answers to point at when somebody asks whether the thing can be trusted with a change order.
How do you measure whether the agent worked?
Measure the agent on its own numbers and on the workflow's. Copilot Studio reports engagement, resolution, escalation and abandon rates per agent, plus thumbs feedback and CSAT. Foundry adds evaluators for groundedness and tool-call accuracy with continuous evaluation on live traffic. Pair both with the operational baseline captured before go-live.
Capture that baseline first, because it stops existing the day the agent ships. Median time to answer an RFI status question. Calls per shift to the person who knows the schedule. An afternoon of collection, and these are the numbers that convince a CFO.
The agent-side metrics are defined precisely enough to hold up in a review. Resolution rate is the share of engaged sessions that ended resolved, confirmed by the user or implied by the flow. Escalation rate is the share handed off to a human. Abandon rate is the share that ended after 60 minutes of inactivity (Microsoft Learn).
Read them in pairs. High engagement with low resolution points at topic coverage, which is a content problem with a content fix. High escalation on one topic and low escalation elsewhere usually means a missing data source. A quiet agent with good scores means the workflow was too rare to matter.
On the Foundry side, treat evaluation as a release gate. Evaluators run in the deployment pipeline. Continuous evaluation samples production traffic at a set rate, and alerts fire when outputs fall below a quality threshold (Microsoft Learn). An agent nobody grades drifts quietly, and the first person to notice is a superintendent who stopped trusting it three weeks ago.
The six-phase build, in order
- Pick the workflow. One workflow, one system of record, one reviewer. Read-only, high frequency, checkable in under a minute.
- Prove the data path. Authenticate against the customer's own instance and read real records. Sort the source into one of the three buckets. Publish that assignment before design starts.
- Ground the agent. Copilot Studio for the conversation and the approval shape. Microsoft Foundry when the agent needs a specific model or its own runtime.
- Give it an identity and a boundary. Entra Agent ID with a named sponsor, Purview labels on the source content, Power Platform DLP on the connectors.
- Pilot read-only. Ten to twenty daily users, a named reviewer grading transcripts weekly, an escalation path defined before launch, a fixed end date.
- Measure and decide. Operational baseline plus agent analytics plus evaluators. Promote to write-back only when the read agent's answers hold up against the ERP.
Phase 2 is the one that gets skipped, and skipping it turns a six-week build into a two-quarter data project discovered halfway through. An AI Solution Day puts phase 2 to the test in one day: bring one workflow, and leave with a working solution (in your tenant or ours) plus the design and plan to scale it.
ArchitectNow designs and delivers AI, data, and cloud solutions on the Microsoft stack. It is a Microsoft Solutions Partner for Data & AI (Azure) and for Digital & App Innovation (Azure), and holds the AI Apps on Microsoft Azure Specialization.
Sources and references
Microsoft Learn, Choose between Microsoft 365 Copilot and Copilot Studio to build your agent: https://learn.microsoft.com/microsoft-365/copilot/extensibility/copilot-studio-experience (accessed September 1, 2026)
Microsoft Learn, Agents in Microsoft Foundry: https://learn.microsoft.com/azure/foundry/agents/overview (accessed September 1, 2026)
Microsoft Learn, Connect to a Microsoft Foundry agent (preview): https://learn.microsoft.com/microsoft-copilot-studio/add-agent-foundry-agent (accessed September 1, 2026)
Microsoft Learn, Extend your agent with tools from a REST API (preview): https://learn.microsoft.com/microsoft-copilot-studio/agent-extend-action-rest-api (accessed September 1, 2026)
Microsoft Learn, Plan and design integration strategies for Copilot Studio: https://learn.microsoft.com/microsoft-copilot-studio/guidance/integrations (accessed September 1, 2026)
Microsoft Learn, Create virtual tables using the virtual connector provider: https://learn.microsoft.com/power-apps/maker/data-platform/create-virtual-tables-using-connectors (accessed September 1, 2026)
Microsoft Learn, What is Mirroring in Fabric: https://learn.microsoft.com/fabric/mirroring/overview (accessed September 1, 2026)
Microsoft Learn, Unify data with OneLake shortcuts and mirroring: https://learn.microsoft.com/fabric/onelake/unify-data (accessed September 1, 2026)
Microsoft Learn, Governing agent identities: https://learn.microsoft.com/entra/id-governance/agent-id-governance-overview (accessed September 1, 2026)
Microsoft Learn, Best practices for Microsoft Entra Agent ID: https://learn.microsoft.com/entra/agent-id/best-practices-agent-id (accessed September 1, 2026)
Microsoft Learn, Use Microsoft Purview to manage data security and compliance for Microsoft Copilot Studio: https://learn.microsoft.com/purview/ai-copilot-studio (accessed September 1, 2026)
Microsoft Learn, Measure and improve agent performance with KPIs and analytics: https://learn.microsoft.com/microsoft-copilot-studio/guidance/analytics (accessed September 1, 2026)
Microsoft Learn, Agent metrics reference: https://learn.microsoft.com/microsoft-copilot-studio/guidance/agent-business-value-metrics-reference (accessed September 1, 2026)
Microsoft Learn, Observability in generative AI: https://learn.microsoft.com/azure/foundry/concepts/observability (accessed September 1, 2026)
Microsoft Learn, Evaluate your AI agents: https://learn.microsoft.com/azure/foundry/observability/how-to/evaluate-agent (accessed September 1, 2026)
ArchitectNow AI Day workshop output, anonymized (131 use cases, 18 opportunity areas, 5 ranked initiatives, two lighthouse use cases live by month six), claims library entry stat-ai-day-outputs, approved for anonymized marketing use August 26, 2026