The agent is the easy part

The mental model for an AI agent often looks something like this: customer data feeds the agent, the agent calls a tool, the tool produces an action.

That is enough to prove the model can reason, call tools and produce a useful result.

But enterprise collections is not a clean sequence of data, reasoning and action. It is a landscape of constraints.

Consider a £75,000 invoice that is 45 days overdue.

At first glance, the next action seems obvious: contact the customer.

But what if the invoice is already in dispute? What if the dispute relates to a service failure, the account is strategically important, there is an active promise to pay, or the customer was contacted yesterday? What if the account manager has requested a temporary hold, the customer sits in a jurisdiction with different communication requirements, a payment plan can be offered but only within an approved threshold, or the ERP says the invoice is overdue while the CRM notes that payment is already in process?

The model can still reason about this. But the enterprise cannot rely on the model to invent the rules of engagement as it goes.

The agent may decide what it thinks should happen next.

The surrounding system has to decide what the agent is allowed to know, what it is allowed to do, which policies apply, which process must be followed, whether a human needs to approve the action, what credentials can be used, what state needs to survive between interactions, how the decision is recorded, and how the behavior is evaluated later.

That surrounding architecture is what I mean by the agent harness.

The agent is inside the harness. It is not the harness.

This distinction matters because enterprise agents are not supposed to make every decision probabilistically.

Some things benefit from judgment. Others should remain deterministic.

A collections agent might reasonably use AI to interpret a customer's reply, classify the reason for non-payment, summarize an account history, choose the most relevant playbook, recommend a next action, or adapt the tone of a communication.

But it should not be left to probabilistic judgment to decide whether a user is authorized to access an account, whether a £100,000 write-off is permitted, whether a mandatory compliance step can be skipped, whether a payment plan exceeds an agreed threshold, or whether a restricted field can be sent to an external recipient.

A production flow looks less like a straight line and more like a sequence of checks:

Notice how little of this is actually the model. The agent matters, but the reliability of the system comes from everything around it.

One step deserves a second look.

Even the apparently simple question of what the agent should know becomes architectural.

A collections agent may need context from the ERP, the CRM, recent email exchanges, call transcripts, payment history, dispute records, customer segmentation, promises to pay, account ownership, policies, SOPs, collections playbooks and workflow state.

Simply exposing all of that information to the model is not a strategy. The system needs to assemble the right context for the current decision.

Too little context and the agent makes a poor decision. Too much context and you create cost, latency, noise and potentially unnecessary data exposure.

This is why retrieval-augmented generation is only a small part of the enterprise context problem.

The collections function already has rules. The agent does not remove the need for them. If anything, greater autonomy makes them more important.

Some rules come from regulation. Some come from internal risk policy. Some come from customer segmentation. Some are encoded in an SOP. Others exist as playbooks designed to guide judgment rather than enforce a hard rule.

Those concepts are different, and the harness needs to understand that difference.

There is another uncomfortable question: how do we know the agent is actually good?

Not whether the email sounded convincing. Not whether the model produced a valid tool call. Whether the system behaved correctly.

For the £75,000 disputed invoice, we might want to evaluate whether the agent identified the active dispute, used the correct playbook, avoided an inappropriate collections escalation, involved the right stakeholder, respected the approval boundary and recorded the decision correctly.

Some of those are deterministic: did it respect the approval boundary, was the decision recorded. Those can be checked without ever calling a model again. Others are a judgment call: was it the right playbook, was the escalation appropriate. Those need a model, or a person, to grade them. Treating both as the same kind of test is how evaluation becomes theater.

Those are not model benchmark questions. They are business behavior questions.

And if the model, prompt, tool, knowledge source or policy changes tomorrow, we need to know whether that behavior has regressed.

This is why evaluation cannot be something added after the agent has been built. It is part of the architecture.

The first generation of enterprise AI naturally focused on getting models to do useful things.

The next challenge is making those things safe, repeatable and operable at scale.