Skip to content
duarteclemente
Go back

When Copilot Studio is over-engineering

Last month someone asked me to build a Copilot Studio agent so employees could “request access to internal systems through natural conversation.” I asked what the requests actually looked like. There were four systems, three access levels, and a mandatory approval from the system owner. That’s not a conversation. That’s a form with two dropdowns and a Power Automate approval. The whole thing fits in an afternoon.

I said no to the agent, and I want to unpack why, because I keep having this conversation in 2026 and I suspect you do too.

The suspension bridge over a stream

I spent years as a civil engineer before I moved into the Power Platform, and one habit survived the career change: you size the structure to the load, not to the portfolio photo. Nobody builds a suspension bridge over a stream. Not because suspension bridges are bad — they’re magnificent — but because a concrete slab carries that load for a fraction of the cost, and you can inspect every part of it standing up.

Use the simplest structure that carries the load. Everything beyond that is decoration you’ll have to maintain.

Copilot Studio is the suspension bridge. It’s the right structure when the span genuinely demands it. But right now it’s being reached for by default, because it’s the shiny thing in every roadmap deck, and “we built an AI agent” sounds better in a steering meeting than “we built a form.”

What the simple structure actually looks like

For that access-request scenario, the boring architecture is: a canvas app (or even just a Dataverse form) collecting structured input, a flow handling routing, and an adaptive card for the approver. The entire decision surface of the approval step is this:

{
  "type": "AdaptiveCard",
  "version": "1.5",
  "body": [
    {
      "type": "TextBlock",
      "text": "New access request",
      "weight": "Bolder"
    },
    {
      "type": "Input.ChoiceSet",
      "id": "decision",
      "choices": [
        { "title": "Approve", "value": "approve" },
        { "title": "Reject", "value": "reject" }
      ]
    }
  ],
  "actions": [
    { "type": "Action.Submit", "title": "Submit" }
  ]
}

That’s the whole thing. It’s deterministic: the same input produces the same output, every time. It’s testable: you can write down the five paths through it and verify each one before go-live. It’s cheap to run and cheap to reason about. When it breaks, the flow run history tells you exactly which action failed and why. Try getting that failure story out of a generative orchestration trace at 5 p.m. on a Friday.

The part nobody puts in the demo

An agent version of the same requirement needs everything the flow needs — the connectors, the approval logic, the Dataverse writes — plus topic design or generative orchestration on top, plus testing against phrasing variance, plus a plan for what happens when the model interprets “read access to the finance system” creatively. You haven’t removed complexity. You’ve added a probabilistic layer in front of a deterministic process and made the deterministic part harder to reach.

The checklist I actually use

Before any agent conversation goes further, I run the requirement through four questions:

If the answer to all four is “simple,” then a Power Fx formula and a When a row is added, modified or deleted trigger will outlast any agent you build, and the next consultant to inherit it will thank you.

When the suspension bridge earns its cables

Here’s the honest counter-case, because this isn’t an anti-Copilot-Studio post. The product is genuinely good at the thing it was built for: open-ended, high-variance conversational intake.

If users arrive with unstructured requests — “my laptop is doing the weird thing again, also I think I need the VPN cert renewed?” — a form fails immediately, because you can’t enumerate the fields. If there are dozens of intents that would otherwise become dozens of apps and flows, an agent consolidates the front door. And if the answers live in messy sources — SharePoint sprawl, PDFs, a wiki nobody has gardened since 2022 — knowledge grounding does something no flow can: it reads the mess so a human doesn’t have to.

That’s a wide river. Build the bridge. Wire it to Power Automate agent flows for the deterministic parts, keep the probabilistic layer where variance actually lives, and you’ve got an architecture that earns its complexity.

The failure mode I’m arguing against is narrower and much more common: bounded intents, structured inputs, a process someone can describe completely in two sentences — routed through an LLM anyway, because the LLM was the point rather than the tool.

Span first. Structure second. Same rule as always; the materials just got more exciting.

What’s the most over-engineered “agent” you’ve been asked to build this year — and did you manage to talk them down to a form?


Share this post:

Previous Post
Building a 3M-File Document Management System on Power Apps Code Apps: What the SharePoint Connector Doesn't Tell You