When One Agent Tried to DO Everything

The second article in my Finance Agent series

My first Collection Manager Agent worked well - until I kept giving it more jobs. What started as a customer-review assistant grew to hanle automated credit-hold analysis, collection-call preparation, and customer email drafting. Each addition made sense. Together, they created a problem.

In my first article, I mentioned the importance of narrower scope. This time, I want to show you what happened when I ignored that lesson.

Watch: Why I Split One Agent Into Three

What the First Version Was Asked to Do

The first Collection Manager Agent started with a simple job.

Review a customer. Pull the aging, the credit limit, the open invoices. Tell me what to do next.

It did that well.

Then I started adding to it.

• I wanted it to react automatically when a sales order was placed on credit hold.

• I wanted it to prepare me for a collection call.

• I wanted it to review disputes and promises to pay.

• I wanted it to create a follow-up activity in Dynamics 365 Finance.

• I wanted it to draft the customer email.

• Every one of those was a good idea.

That was the problem.

The Moment I Knew Something Was Wrong

The Sales Order Hold alert was where it showed up first.

That alert runs automatically. A flow calls the agent, the agent returns the analysis, and a card appears in Teams. Nobody is chatting. Nobody is waiting to be greeted.

But the agent didn't know that.

It had been built to be conversational, so it behaved that way. Parts of the chat experience kept leaking into the automated alert:

• Welcome menus

• Working notes

• Its own Customer Review layout, instead of the structure the flow needed

Here's one real example.

Prompt sent by the automated flow

Review credit hold 000978 for sales order 010104 in legal entity USMF. Retrieve the relevant customer credit and collections information, determine whether the order should remain on hold, and return the result in the structure required for the Teams credit-hold alert.

Response from the original all-purpose agent

Welcome to the Collection Manager Agent.

I can help you with:

1. Customer account review

2. Credit-hold analysis

3. Collection-call preparation

4. Disputes and promises to pay

5. Collection activities

6. Customer communications

I’ll begin by reviewing the customer account, open invoices, aging, credit limit, disputes, promises to pay, collection activities, and related sales orders.

Working notes: I found the customer and am reviewing the account information. Next, I will check the Collections page and related transactions.

Customer Review [The agent then returned its normal conversational Customer Review format rather than the exact fields and structure required by the flow.]

The agent wasn't broken. It was doing exactly what I had told it to do.

I had given it two jobs that wanted opposite things.

The flow needed a predictable response it could turn into a Teams alert. Instead, it received a conversation.

Why More Instructions Didn't Fix It

My first reaction was to add more instructions.

Don't show the menu during an alert. Don't include working notes. Use this layout, not that one.

Each fix helped a little. Each fix also made the instructions longer, and the instructions already had a lot to carry.

The 8,000-character instruction limit also forces the issue. It wasn't why I split the agent, but it made the problem impossible to ignore: the final Collection Manager instructions came in at nearly 7,900 characters, while the alert agent needed roughly 6,700 characters of its own.

What I finally understood was this.

A fast, automated alert and a thoughtful, interactive conversation need different instructions.

When they share one set, each pulls the other off course.

The Decision to Split

After trying roughly five sets of instructions and several different approaches, I realized I needed to split the responsibilities across multiple agents.

I stopped trying to make one agent handle both the automated alert and the interactive conversation.

The Sales Order Hold Agent handles the automated alert. It is read-only, never chats, and returns one structured analysis that the flow can turn into a Teams card.

The Collection Manager Agent handles the interactive conversation: customer reviews, collection-call preparation, and follow-up questions.

Later, I added a third agent just for drafting customer emails. It runs as a subagent of the Collection Manager Agent.

Three agents. One job each.

The change was immediate.

The alert got faster. The responses got more consistent. And when something went wrong, I knew where to look.

What I Learned

Prompt engineering isn't only about writing better instructions.

It's about drawing boundaries.

If you can't describe an agent's job in a single sentence, it probably has too many jobs.

Here's the test I use now:

• Does it have one audience, a person in a chat or a flow waiting for data?

• Does it have one kind of output?

• Would a change to one feature risk breaking another?

If the answer to the last question is yes, it's probably time to split.

What's Next

The feature that got the biggest reaction wasn't the three-agent architecture.

It was the Sales Order Hold alert.

In my next article, I'll follow one credit hold from the moment it happens in Dynamics 365 Finance to the card that lands in Teams. I'll also explain why I kept the alert so narrow and what happens when the agent's response fails.

Until then, I'm curious.

Have you ever built something that tried to do everything? What made you finally split it up?