I Built an Accounts Payable Agent That Knows When to Ask a Human

Every invoice can look like a new problem.

A vendor sends an invoice, the system checks it, and a human may have to review it. Then the next invoice from the same vendor arrives, and the process starts again.

But what if the system could remember what happened before?

That was the idea behind VendorSense — an AI-powered Accounts Payable agent that uses Hindsight to remember previous vendor experiences and use that context when evaluating future invoices.

The goal wasn't to replace the human completely.

It was to make the agent better at recognizing what is normal and, more importantly, knowing when something needs a human.

---

What VendorSense Does

VendorSense is a Streamlit-based application that processes supplier invoices and decides whether they can be handled automatically or should be sent for human review.

The overall flow is:

Invoice → Hindsight Recall → AI Decision → Auto-process / Exception → Human Review → Hindsight Retain

The application extracts important invoice information such as:

• Vendor
• Invoice ID
• Amount
• Purchase order
• Payment terms
• Bank account information

It then combines the current invoice with relevant vendor history before making a decision.

The important difference is that the agent isn't looking at the invoice in isolation.

It can also ask:

"What do I already know about this vendor?"

---

Our VendorSense interface

The interface lets us see the invoice workflow, exceptions, vendor memory, and the learning process.

---

Why Memory Matters

Imagine that we receive an invoice from:

Apex Industrial Supplies

The invoice contains:

• Amount: ₹52,100
• Purchase Order: AIS-2419
• Payment Terms: Net 30
• Bank account ending: 7821

Looking only at the current invoice doesn't tell us whether these details are normal.

But suppose the system already remembers that:

• Previous Apex invoices were generally within a similar amount range.
• Their purchase orders followed the same format.
• Their payment terms were usually Net 30.
• Their bank account ending in 7821 had previously been verified.
• Previous invoices had been approved by a human.

Now the current invoice has context.

This is where Hindsight becomes important.

Before making its decision, VendorSense retrieves relevant experiences from Hindsight and gives that information to the reasoning agent.

Instead of asking:

"Is this invoice okay?"

the agent can reason about something closer to:

"Does this invoice match the history we have for this vendor?"

That small difference is what makes memory useful.

---

Memory Is Evidence, Not Truth

One of the most important ideas in our project is:

Memory is evidence, not truth.

We didn't want the agent to blindly trust everything it remembered.

Imagine the system remembers:

Verified bank account: XXXX7821

Then a new invoice arrives with:

Bank account: XXXX9143

Even if everything else looks normal, the changed bank account should matter.

The system should not think:

"I've seen this vendor before, so I'll approve it."

Instead, the change should result in:

EXCEPTION → Human verification required

This is particularly important for financial workflows because a system becoming too comfortable with a familiar vendor can be dangerous.

Our idea was therefore to use memory to understand normal behavior, while still treating significant changes as reasons to slow down and involve a person.

---

The Human Is Part of the Learning Loop

Another important part of VendorSense is what happens after an invoice reaches the human-review queue.

The human reviewer can look at the invoice, decide whether it should be approved or rejected, and add a note explaining the decision.

For example:

"Invoice approved after checking the purchase order and confirming the vendor details."

That decision and explanation are then stored in Hindsight as a new experience.

So the workflow becomes:

Agent evaluates invoice

↓

Human reviews when necessary

↓

Human makes a decision

↓

Decision and reasoning become memory

↓

Future invoices can use that experience

This means the human isn't simply correcting the agent.

The human is also helping create better context for future decisions.

---

Before and After Memory

The difference becomes clearer when we look at the same vendor over multiple invoices.

First time seeing a vendor

If there is no useful history, the agent has very little evidence to work with.

For a new vendor, the safer behavior is to send the invoice for human review.

The human checks it and makes a decision.

That decision then becomes part of the vendor's history.

Later invoice from the same vendor

Now another invoice arrives.

The agent can recall the previous experience and compare the new invoice against it.

If the amount, purchase-order pattern, payment terms, and verified details are consistent, the invoice can be treated as a routine case.

What the Agent Remembers

We also didn't want to remember only a simple label such as:

"Approved."

The reason behind the decision can be just as important.

For example:

Approved

is useful.

But:

Approved after checking the purchase order and confirming the vendor's updated details

contains much more context.

That context can help the agent understand why something was approved or rejected when it encounters a similar situation later.

This is one of the reasons Hindsight fits the problem well. The agent can retain experiences rather than forcing every previous decision into a rigid vendor-history table.

---

Vendor Memory

This part of the application makes the idea of persistent memory easier to understand.

Instead of the agent forgetting everything after processing an invoice, previous experiences can become part of the context for future work.

---

Keeping User Memory Separate

Accounts Payable information can contain sensitive business data.

Because of that, we didn't want all users to share one giant memory bank.

VendorSense creates a separate Hindsight memory bank for each user.

Conceptually:

User A → User A's memory → User A's vendor experiences

User B → User B's memory → User B's vendor experiences

This keeps the memory boundary tied to the user rather than treating all vendor experiences as one global collection.

That became an important architectural decision because an agent that remembers everything isn't useful if it remembers the wrong user's information.

---

What We Learned

1. Memory should influence the decision

Simply adding memory to an agent isn't enough.

The useful part is retrieving relevant experience at the right point in the workflow and giving the agent enough context to use it.

2. Human decisions are valuable learning signals

The human review isn't just an exception-handling step.

It can also become a source of future knowledge.

3. Familiar vendors can still have unusual invoices

A good history shouldn't mean automatic trust forever.

The current invoice still matters.

4. The agent should know when to stop

For an Accounts Payable system, automation isn't the only goal.

Knowing when to say "a human should check this" is equally important.

5. Memory needs boundaries

Using separate memory banks for users gave us a simple way to keep different users' experiences isolated.

---

The Bigger Idea

Although we built VendorSense for Accounts Payable, the pattern goes beyond invoices.

The basic idea is:

Remember the past

↓

Understand the current situation

↓

Use previous experience as context

↓

Ask a human when necessary

↓

Learn from the confirmed outcome

↓

Use that experience next time

That is what we wanted to explore with VendorSense.

An ordinary AI workflow can process a document and produce an answer.

An agent with memory can use what happened before to approach the next task with more context.

For us, the interesting part wasn't simply making an AI read invoices.

It was creating a system where past experience, current information, AI reasoning, and human judgment work together.

And that is what Hindsight allowed us to build into VendorSense.