41,000 Copilot Studio credits in two days.

That got our attention.

While working with a colleague, we were building an agent in Microsoft Copilot Studio to perform lookups against data.

The agent worked. The responses were good.

The problem was the model we selected.

We were using a deep reasoning model for a workload that was primarily a lookup operation.

And that turned into an expensive architecture lesson.

The Problem

The workflow was fairly simple:

User request
     ↓
Understand request
     ↓
Find required data
     ↓
Retrieve data
     ↓
Return response

There was some natural-language understanding involved, but we weren’t asking the agent to solve a complex problem or perform sophisticated multi-step reasoning.

It was mostly:

“Find this information and give it to me.”

Yet we had selected a model designed for much deeper reasoning.

The result?

Approximately 41,000 Copilot Studio credits consumed in two days.

Nothing was broken. The agent was doing exactly what we asked it to do.

Our architecture was simply using more reasoning capability than the workload required.

---

The Lesson: More Powerful Doesn’t Mean Better

One of the easiest mistakes to make when building AI agents is choosing the most capable model available.

It feels logical:

More intelligence → better responses → better solution.

But there’s another side to the equation:

More capability → potentially more cost and latency.

Microsoft’s Copilot Studio documentation makes a similar distinction between models intended for simpler workloads and models designed for deeper reasoning.

That means model selection should be treated as an architecture decision, not just an AI configuration decision.

The question shouldn’t be:

“What’s the most powerful model we can use?”

It should be:

“What’s the appropriate level of intelligence for this workload?”

---

Use Code Where Code Makes Sense

This also reinforces a principle from traditional software architecture:

Don’t use a complex solution for a deterministic problem.

If the requirement is simply:

Get customer by ID

then an API or database query is probably the right tool.

You don’t necessarily need an AI agent to solve it.

AI becomes more useful when the input is less deterministic.

For example:

“I’m looking for information about my outstanding account and the payments I made recently.”

Now we need to interpret the request, identify the relevant information and potentially combine multiple sources.

That’s where an agent can provide real value.

The architecture might therefore look more like:

User
 ↓
AI / Intent Understanding
 ↓
Application Logic
 ↓
API / Database
 ↓
Response

Rather than allowing a reasoning model to control every step.

---

Think About Cost Per Operation

Traditional software engineers are already used to thinking about:

• CPU
• Memory
• Database performance
• Network traffic
• Infrastructure costs
• Latency

AI applications introduce another important metric:

Inference cost.

For Copilot Studio, that means understanding Copilot Credit consumption.

A development environment might look perfectly fine when you’re testing a handful of requests.

But consider what happens when the same agent handles thousands of interactions.

A small inefficiency becomes a significant operating cost.

That’s why I’d recommend monitoring:

• Credits per interaction
• Model usage
• Agent invocation frequency
• Response latency
• Retrieval operations
• Cost per business process

The goal isn’t simply to make the agent work.

It’s to make the agent work efficiently at scale.

---

The Approach I’d Take Going Forward

For new agent workloads, I’d start by categorising the operation.

Deterministic

Use:

API / database / application logic

Simple language task

Use:

Lightweight model

Retrieval and response generation

Use:

General-purpose model

Complex reasoning or planning

Use:

Reasoning model

This gives us a much better architecture than simply putting the most powerful model behind every operation.

---

The Bigger Lesson

The 41,000 credits weren’t really the problem.

They were the signal.

The important lesson was that an application can be:

• Functionally correct
• Reliable
• Producing good responses
• Technically well designed

…and still be economically inefficient.

As AI moves into enterprise applications, I think this will become an increasingly important part of software architecture.

We’re no longer only asking:

“Does it work?”

We’re also asking:

“Does it work efficiently, reliably and at the right cost?”

For us, 41,000 Copilot Studio credits in two days was an expensive reminder:

Choose the model based on the problem you’re solving — not simply the capability of the model.

Sometimes, the smartest architecture is knowing when not to use the smartest model.

#MicrosoftCopilotStudio #CopilotStudio #SoftwareArchitecture #AIEngineering #Microsoft #CloudArchitecture #SoftwareDevelopment #EnterpriseAI