How to Give an AI Collections Agent Your Company's Policies

You give an AI agent your company's policies by storing them somewhere it can retrieve them at the moment they apply, rather than writing every scenario into its instructions ahead of time. In Monk that place is Knowledge, and it is now open to every customer.

Monk's agents have always been configurable across playbooks, tone, cadence, when to escalate and when to stop. Knowledge is a different layer. It holds the situational context your team carries about particular customers and particular situations, so the agent applies your business judgment instead of its own.

Frank, a founding engineer at Monk, walks through it in the video.

What is the difference between configuring an agent and giving it context?

Configuration covers what the agent does and when it does it. Context is the judgment it needs while working through those steps.

Configuration is the sequence and the settings: which message goes out on day 7, how firm the tone is, when an account escalates to a person, when the agent stops. Most platforms with an AR agent let you set this, and Monk always has, through playbooks.

Context is everything that does not fit in a setting. That this customer is on net 60 because of a deal signed two years ago. That your team never mentions a service hold in a first reminder. That this account disputes freight charges at the close of every quarter. None of that is a cadence or a tone. It is judgment, and until it is written down somewhere the agent can read, it stays with the people who have it.

Where does situational context usually live?

In three places, and none of them connects to the thing that sends the message.

The first is people's heads. Your collections lead carries the judgment calls, none of it written down, because writing it down was never the job. When that person takes leave or moves on, the context goes with them, which is a problem we have written about separately.

The second is a document someone wrote during onboarding. It was accurate for a quarter, nobody has opened it since, and nothing that sends an email has ever read it.

The third, for teams who have wired up their own agent on a general-purpose model, is the prompt. That one is worth examining, because it is a reasonable first answer and it holds for a while.

What breaks when context lives in a prompt?

A prompt handles a dozen instructions comfortably. Past that, three things go wrong, in order.

The prompt gets long. Forty instructions is a document nobody can navigate, and adding the forty-first means reading the other forty to check it contradicts none of them.

The instructions start to conflict. "Be firm after 60 days" and "go lighter with enterprise accounts" are both sound on their own. An agent given both will resolve the conflict itself, differently on different occasions, and nobody can see which one won.

One person owns the file. The prompt sits with whoever built the agent. The judgment belongs to whoever runs collections. Those are rarely the same person, so every change becomes a ticket, and the context most worth capturing is what someone learns right after a customer reacts badly to something. Guidance that needs engineering time to record does not get recorded. We looked at the wider version of this question in a separate piece on building a collections agent on ChatGPT or Claude.

What goes into a piece of Knowledge?

Writing one takes about a minute.

Each entry has a title, a body telling the agent how to handle the situation, and an optional line describing when it applies. Keep each entry to one instruction. Entries that try to cover three situations at once produce behavior you cannot predict.

Monk provides templates for the situations that come up most, including payment claims, disputes, renewal disputes and missed payment commitments. Most teams rewrite them against their own policy within a week.

How does the agent know which one to use?

You decide per entry. With Knowledge, you can:

• apply it across the organization or to a single customer
• pin it to a specific step in a playbook, so the right language applies to an outbound collections email or an inbound reply
• leave it unpinned, and the agent retrieves it when a customer raises something unanticipated

Pinned entries cover what should happen every time. Unpinned entries cover the long tail, which is most of collections. Scoping to a single customer is what handles the exception: terms agreed with one account stay attached to that account instead of reaching everyone else.

Can you see which one the agent used?

Every use is recorded, so you can see which guidance the agent applied and when.

When a customer forwards a message and asks why it said what it said, you can trace the wording back to the entry that produced it and fix that entry. The record also shows you what to improve. Entries that never fire usually carry a condition nothing matches. Entries that fire on everything are usually written too broadly.

Any entry can be switched off. Policies change, and the gap between a policy changing and your agent knowing about it should be measured in seconds. Controls like these are what we point to when finance leaders ask whether an AI agent can safely email their customers.

Is this training the model on our data?

No. What you write is stored and retrieved when it is relevant. It is not learned. It stays scoped to your organization, and you can delete it.

An agent retrieving your policy at the moment it needs it is a different operation from a model being trained on your customer data. Any vendor in this category should be willing to state in writing which of the two they do.

Where should you start?

With the corrections your team already makes by hand.

If someone reviews drafts before they send, every edit that reviewer makes is judgment applied manually, one message at a time, and recorded nowhere the agent can reach. Those edits are the fastest first set, because the thinking behind them has already been done.

The second source is your exception log. Any message that needed a follow-up correction or an internal escalation points to context your team now holds and has not written down. Capture those, scope them to the right accounts, and most teams have a working set inside a day.

Knowledge is in the Monk sidebar today, underneath the collections agent your team is already running. The same agents you have been running, with more of your business inside them. To see it working against your own ledger, book a demo.

Frequently Asked Questions

How do we give an AI agent our company's policies?

Store them where the agent can retrieve them at the moment they apply, rather than writing every scenario into its instructions ahead of time. In Monk that is Knowledge: each entry has a title, a body telling the agent how to handle the situation, and an optional line for when it applies. You can apply an entry across the organization or to a single customer, pin it to a playbook step, or leave it unpinned for the agent to retrieve.

Is this different from configuring the agent?

Yes. Configuration decides what the agent does: the playbook sequence, the tone, the cadence, when to escalate and when to stop. Monk has always let you set those. Knowledge holds what the agent should know while carrying any of it out, which is the situational judgment that does not fit in a setting.

Can we keep our collections context in the prompt instead?

A prompt handles about a dozen instructions comfortably. Past that it gets long, instructions start to conflict, and only the person who wrote it can safely change anything. The bigger constraint is that the context most worth capturing is learned by the collections team rather than by whoever maintains the prompt.

What is the difference between Knowledge and a playbook?

A playbook is the sequence: what happens, in what order, with what timing. Knowledge is what the agent should know while carrying out any step in it. You can pin an entry to a specific playbook step, or leave it unpinned for the agent to retrieve when a situation calls for it.

Does the agent search all of our Knowledge every time?

Entries pinned to a playbook step apply at that step. Unpinned entries are retrieved when a customer raises something unanticipated, and the line describing when an entry applies is what helps the agent pick the right one.

Can we scope a rule to one customer?

Yes. Each entry applies either across the organization or to a single customer, which is how contract exceptions and account-specific terms stay attached to the right account.

What should we put in Knowledge first?

The corrections your team already makes by hand. The edits your reviewers apply before approving a draft, plus any message that needed a follow-up correction, are the fastest starting set, because the thinking behind them has already been done.