AI That Works On Demand: Episode 5

An AI assistant that knows your expenses policy is useful. One that can take your train ticket and raise the expense claim for you? That’s a different thing altogether.

In the fifth and final episode of our AI That Works webinar series, Fraser Dear, Head of AI and Data Innovation at BCN, joined Emma Portlock, Head of New Business, to show what happens when AI agents stop simply answering questions and start taking action.

Using Microsoft Copilot Studio, Fraser built a customer service agent live on screen. It looked up real orders, checked them against policy, opened support cases and alerted the team in Microsoft Teams, all without anyone touching a keyboard on the service desk.

Watch the recording and you’ll learn:

• How Copilot Studio differs from the lighter Microsoft 365 Copilot agents covered in Episode 4.
• The five building blocks of an agent that can act: knowledge, topics, actions, triggers and channels.
• How to connect an agent to live business data and let it create records in other systems.
• Where to start, how to keep humans in control, and what it all costs.

Key Takeaways

From answers to actions

The agents we built in Episode 4 were good at one thing: knowing stuff. Give them your policies and guidance documents and they’ll answer questions about them reliably, every time.

But they stop there.

Fraser used a simple example. Ask a Microsoft 365 Copilot agent whether you can claim for a rail journey from London to Edinburgh, and it will read the policy and tell you the limit is £75. Ask a Copilot Studio agent the same question, and it can reply: upload your ticket and I’ll create the claim for you.

That gap between knowing and doing is exactly what Copilot Studio is designed to close. It adds connections into other business systems, automated flows, scheduled and event-based triggers, and the option to publish agents well beyond Copilot itself. You also get proper analytics, so you can see who’s using an agent, which topics fire most, and where people get lost along the way. (And they will. Real users rarely follow the route you planned for them.)

The five building blocks of a Copilot Studio agent

Everything Fraser built during the session came down to five components:

1) Knowledge

Still the core of every agent. Policies, rules and process documents set the boundaries it works within, and that hasn’t changed since Episode 4.

2) Topics

Designed conversation paths that kick in when certain words or situations come up. Mention the Underground in an expenses chat, for example, and a dedicated topic can explain that Tube fares aren’t covered.

3) Actions

The part that lets an agent actually do something. That means reading from and writing to systems such as SharePoint, Dynamics, ServiceNow, SAP or Salesforce, or your own systems through custom APIs.

4) Triggers

Agents can start work when an email lands or at a set time. One caveat: triggers are queued, not instant. Thousands firing at 3am won’t all finish at 3am.

5) Channels

You choose where the agent lives, whether that’s your website, Teams, Copilot or wherever your people already work.

Demo: The Order Support Agent

The main demonstration tackled a problem most customer service teams will know all too well.

“Where’s my order?” makes up around half the inbound queue. Every answer means someone opening another system, finding the order and reading the screen back to the customer. The returns policy runs to a couple of paragraphs, yet customers can wait a long time on hold just to hear it. And when something does go wrong, details get lost, because the call handler has 15 more calls waiting.

Fraser’s agent, built for Meridian (the fictional company introduced in Episode 4), was given a clear job: answer order and returns questions around the clock. Its instructions asked for a warm, plain-spoken, professional tone in UK English. It was told to answer only from policy and live order data, never to invent delivery dates, and never to ask for payment details. Its knowledge covered the returns and delivery policy plus an escalation matrix. Three actions did the heavy lifting: reading order data from a SharePoint list, creating support cases, and posting urgent alerts to a Teams channel for priority-one issues.

Then came the live test. Fraser ran three questions:

• “Where’s my order?” The agent queried SharePoint and confirmed the order was in transit with the carrier, dispatched on 5 October and due that day.
• “Can I return a custom oak desk I bought 60 days ago?” It checked the policy, explained that made-to-order items usually can’t be returned for a change of mind, and opened a case for the customer service team leader. A Teams notification arrived moments later, and the reply cited the policy it relied on.
• “My delivery arrived smashed. Again.” The agent recognised a repeat problem, logged a high-priority case and promised a response within four business hours, in line with the escalation matrix.

Over in SharePoint, both cases were waiting. Each had a priority, a summary and the full conversation transcript attached. Nothing lost, nothing retyped.

Data, people and cost

After the demo, Emma raised the obvious question. Doesn’t all this depend on the data being right?

Fraser didn’t sugar-coat it. An agent can only be as accurate as the system it reads from. If half the documents in a SharePoint library are out of date, the agent has no way of knowing that, and its answers will reflect it. The same holds for the more advanced agents built on platforms like Microsoft Fabric and Foundry.

Nor is any of this about replacing people. The agent handles the routine queries and the first-pass triage, so trained staff can spend their time on the complaints that genuinely need them. Customers get answers outside 9 to 5. The team arrives in the morning to a few well-documented cases rather than a full call queue.

So what does it cost? For internal agents used by people who already have a Microsoft 365 Copilot licence, there’s nothing extra to pay. Agents used by people without a licence, such as customers on your website, consume Copilot credits with every interaction. These can run on pay-as-you-go, and once usage reaches a certain level, prepaid credit bundles usually give better value.

Beyond customer service: HR and IT

The same pattern travels well. Fraser and Emma talked through two more functions where it fits naturally.

HR onboarding. Given a list of new starters and the relevant onboarding documents, an agent could answer joiners’ questions and update HR records as conversations happen. It’s the same build, just aimed at people rather than parcels.

IT triage. As support emails arrive, a trigger can hand each one to an agent. It reads what the user has written, assigns a priority and routes the ticket, so nobody has to sort the inbox by hand.

Emma also asked whether you need to be technical to build any of this. Not really. The build process is heavily guided, although connections and security do need IT’s input. The best ideas, Fraser argued, come from the people who live with the process every day.

Expert View

“IT is not going to come up with these use cases. They’re going to come from the business users.”

Fraser Dear, Head of AI and Data Innovation

Governance matters

The guardrails from Episode 4 still apply, with one important addition: once an agent can act, a person needs to approve the actions that carry real consequences.

Fraser’s advice:

• Treat published agents as products, and give every product an owner
• Keep a human approving any consequential action, such as issuing a refund
• Retire agents nobody uses rather than leaving them running
• Govern agents like the rest of your platform, under your existing AI governance
• Keep knowledge current as products, teams and policies change

Put simply, if you built it, it’s yours to look after.

Your blueprint for a first build

If you have a Copilot Studio licence and want to give it a go, Fraser suggested this order:

• Pick the process that hurts most, whether it’s orders, people or something transactional
• Map it out properly. If you can’t describe the job, the agent won’t be able to do it
• Start read-only, pulling data before you let the agent write anything back
• Put a human on every consequential action
• Measure from day one using the built-in monitoring, because deflection rates and time saved will form your business case

One quick win sits in plain sight. If you regularly look something up in one system only to retype it into another, that’s an agent waiting to be built.

What’s Next

That’s a wrap on series one

Across five episodes, we’ve gone from choosing the right AI tools and writing better prompts, through finding quick wins and building a first agent, to agents that take real action in your business systems.

This episode marks the end of the personal productivity journey and the start of a bigger one: turning those gains into business value. With demand for AI higher than ever among our clients, more sessions are already in the works.

Missed an episode? Every session was recorded, so you can catch up at your own pace.

Watch the full series here.

Next Steps

If this session got you thinking about which of your processes an agent could take on, we’d be glad to help you work it out.

From Copilot Studio builds and custom AI agents to the data foundations that make them reliable, explore our wider AI services.