The leaders in the room didn’t need to be told what was broken. Their sales, service and operations teams already knew which quote took an afternoon and which report got rewritten three times. What they had just seen was Copilot working on those problems. So the questions that followed weren’t about features. They were about who would own it, how it would stay safe, and how they’d prove it paid back.
That’s the subject of the last post in this series, which began with one story told in a single session. Over six posts we’ve followed a Copilot deployment for a pump and process-equipment distributor: personal Copilot, then shared agents, then agents that act on business systems. This post is about what leaders ask once they’ve seen it, and why the answer isn’t another feature. It’s an AI program.
The questions, and what they were really asking
Stripped of who said them, the questions fell into five groups.
“Who owns this once it exists?” Governance. Once a shared agent is published, someone has to own what it knows, who can use it, and what happens when it’s wrong.
“How do we stop ending up with two hundred of these?” Agent sprawl. Once every department can see what an agent does for its own work, demand follows, and without rules for publishing you get dozens of agents, most abandoned, some wrong, and a few quietly answering questions they shouldn’t. It’s the question most organizations ask too late.
“Can it connect to the ERP? The CRM?” Yes, with the caveat that an ERP in the middle of an upgrade is not where you start. The run-stage agents from post 4 show what it looks like once the connection exists: scoped connectors, a service account with only the permissions the task needs, and a human approval before anything is written back.
“How will we know it worked?” Proof. Something a leadership team can see on a page. That’s why post 6 ends with an adoption scorecard and baselines.
“Which agents are other companies like us actually using?” Our answer was the use-case list from the roadmap: quote drafting, spec review, service report write-ups, email triage, and capturing tribal knowledge. Each started as a problem someone in a department already had.
There was one quieter theme. The instinct in the room was for a controlled, targeted pilot rather than a broad rollout. That instinct is the best predictor we know of for whether a rollout will work.
What that tells you
A leadership team asking about sprawl and ownership before buying anything already believes AI is useful. What it doesn’t know yet is what it takes: what Copilot can actually do with their work, what it costs and what the process is to get there, and how to get their people using it. What they need is a structure they trust enough to say yes to a first step.
It also tells you who does what. The business knows the problems, so the business drives. IT’s job is to make sure AI stays aligned to the standards the business has set. A service manager knows which report gets rewritten. IT can’t see that from a dashboard, but it can give that manager a safe place to solve it: agents that inherit the user’s permissions and publish only to named groups, sensitivity labels that decide what an agent can read, Copilot interactions in the audit log, a named owner and review date on every shared agent, and the scripted test pass from post 5 before anything ships.
That’s also where the sprawl answer starts. Agent Builder agents are personal or team-scoped and easy to inventory. Copilot Studio agents go through a solution lifecycle with an owner. Above both sit the licence tiers that decide what’s available at all. Knowing which layer a problem belongs in is the first governance control, and it’s how you stop paying for capability nobody uses.
The pilot shape that follows
The session ended on a pilot, with a governance baseline in place before the first agent is shared:
- One named owner with executive backing. Nothing else works without it.
- A baseline before anything is deployed. How long the target tasks take today, from the people who do them.
- A narrow group. Ten to fifteen volunteers in one function with repetitive, text-heavy, low-confidentiality work, such as a technical sales team and its new hires.
- Two use cases, chosen by the business. Not by IT, and not by us.
- A 90-day measurement against the baseline, reported to leadership, with a decision at the end about what to expand.
That’s an AI program in miniature. The owner answers ownership. The publishing rules answer sprawl. The connector standards answer integration. The baseline and scorecard answer proof. It’s what lets the value last past the pilot.
What we’d do differently
Four things, in the order we’d fix them.
Leave more room for the questions. The discussion was the most valuable part, and it got squeezed. Next time the cut order from post 5 gets applied before the session, and twenty minutes at the end is protected.
Put the operations content first. Two of the people whose work the agents most affected had to leave early. The people who own the problem are the audience that matters most, so their part goes first, even if it breaks the narrative.
Test the capability path, not just the agent. Our image-generation problem in post 5 passed every test we’d written for the agent and still failed in the scene, because it depended on a rendering behaviour we hadn’t tested directly. Testing is a guardrail, and it has to cover everything the agent depends on.
Bring the scorecard with real data. We showed the scorecard as a concept slide, and leaders wanted the thing itself. Next time it runs against the tenant’s own usage data, with permission, so the proof conversation starts from numbers rather than a promise.
The general rule, for the series
Seven posts, one rule. Start with a problem the business already has, solve it with the right layer, and let IT keep it inside the business’s standards. The questions people ask will tell you what to build next. Here they were about ownership, sprawl, integration and proof. Yours probably will be too, and that’s the best sign you’ll get.
None of it needs anything exotic: Copilot, Agent Builder and Copilot Studio, pointed at problems a distributor’s sales, service and operations teams already knew they had.
Thanks for reading. If you want the run of show, the test approach or the training sequence in more detail, get in touch, or bring us the problem you’d start with.
CB5 Solutions helps organizations understand the layers of AI, get the most from what they buy, and build an AI program that pays back inside their IT standards. We start every engagement with one business problem and a governance baseline. Let’s pick yours.