I wanted to see if an AI agent could learn from one customer interaction instead of just pulling in old data. So I gave PayRecall an invoice. Then I recorded a promise to pay. After that I asked it to plan the action again. The interesting thing wasn’t just that the suggestion changed. It was how the change happened—through a memory process: keep the outcome pull out the facts update the customer model and then make a new recommendation.
The Problem With a Collections Agent That Starts Over
PayRecall is a collections assistant built for B2B accounts receivable. When given an invoice it suggests who to contact, what method to use what tone to take and when to follow up.
An invoice alone doesn’t tell the full story. A customer might ignore messages in the shared accounts inbox. Respond to a phone call from the accounts-payable decision-maker. A strong payment notice might lead to a dispute. The person you contacted before might have left the company. A new contact might prefer email for documentation. Only be reachable at certain times.
These details aren’t in the invoice. They come from interactions.
That’s why PayRecall uses two paths. The memory-off path gets the invoice and a basic customer profile. The memory-on path gets the inputs plus the customer’s history from Hindsight. This keeps things fair. The baseline version can’t secretly use information.
Hindsight as the State Between Conversations
I use Hindsight as the memory layer of stuffing a long customer history into every LLM prompt.
The collection records are written like notes a real collector would take: an email, a phone call, a WhatsApp message, a payment promise or a dispute.
PayRecall sends these interactions to Hindsight along with customer and interaction metadata. Customer tags help keep the memory separate. Strict matching prevents the agent from pulling in another customer’s history.
I also keep agent actions separate from customer responses. The agent’s action becomes evidence of what was tried. The customer’s response becomes evidence of what happened. This helps the system learn whether a certain approach worked or failed.
The First Recommendation Is Not the Main Point
For the example the agent gets an invoice from Meridian Retail.
With memory off the model can still make a suggestion: contact the accounts-payable person by email keep the tone polite and ask for a payment date.
With memory on things change. Previous emails to the shared inbox were ignored. Calls to the accounts- decision-maker led to payment promises. A firm notice triggered a dispute. The old contact left the company. A new person took over.
Hindsight’s observation layer turns repeated events into patterns. The customer mental model gives context for the move. So the memory-enabled path can choose the decision-maker use a friendly tone and work within the contact’s known availability.
The exact words may change. What matters is the evidence behind the change.
Then I Recorded a New Payment Promise
The real test came after the recommendation.
The UI lets a collector record the outcome of a call. For example:
Called Kavita on Tuesday at 3:30 pm. She confirmed Meridian will pay INV-2041 in full on 3 October and requested a one-line email confirmation.
PayRecall stores two documents: one about the agent’s action and one about the customer’s response. After saving the system waits for the memories to be extracted updates the customer model clears the recommendation and runs the agent again.
The result is a recommendation built on both old history and the new information.
The Customer Playbook Can Change
The customer playbook isn’t updated by hand after each call. It’s built from accumulated memories.
Before the outcome the playbook includes known contacts, preferred channels, successful tactics and recent changes. After the payment promise is stored the new fact becomes part of that context.
The question shifts from:
“ is the invoice. What should I do?”
to:
“Here is the invoice what has happened with this customer. What have we just learned. What should I do next?”
The LLM still makes the recommendation.. Hindsight gives continuity between decisions.
What I Learned
One big lesson was that memory writes aren’t isolated. I once recorded a test outcome that said a customer email. Later recommendations began using that detail. The agent wasn’t broken. It had learned from the test data.
That means memory tests must be treated like database tests. Test data must be clear cleaned up and kept separate.
The main takeaways were simple: keep the baseline honest enforce customer-level memory boundaries, store actions and outcomes separately and treat every memory write, as a lasting change.
The Idea
Before PayRecall I thought of memory mainly as a retrieval problem: store information and get it back when needed.
The real insight was that memory changes the state of the agent.
A single customer promise can become a fact reshape the customer model and affect the next recommendation.
Memory is not retrieval. It’s a ** learning loop**—turning an assistant that starts over every time into one that carries knowledge from one interaction into the next decision.
Hindsight GitHub:
documentation:
Vectorize agent memory:
