What Changes When an Accounts Payable Agent Remembers Its Previous Work?

Hamsika Nagalla — Tue, 29 Sep 2026 14:51:49 +0000

What Changes When an Accounts Payable Agent Remembers Its Previous Work?
The first invoice is a transaction.
The tenth invoice from the same vendor is a pattern.
That difference is what led me to explore persistent memory while building our Accounts Payable Agent.
A conventional workflow processes an invoice and finishes.
An agent with memory has another option: it can turn useful outcomes from previous interactions into context for future ones.
For an AP workflow, this creates an interesting loop:
Invoice
↓
Agent processes it
↓
Decision
↓
Outcome
↓
Memory
↓
Future invoice
The agent doesn't simply process transactions.
It can accumulate relevant experience.
The problem with starting from zero
Consider a vendor that sends invoices every month.
On the first invoice, the agent discovers an unusual situation:
Vendor: ABC Supplies

Problem:
PO amount doesn't match invoice amount.

Action:
Escalate for human review.

Resolution:
Additional delivery confirmed.

Final decision:
Invoice approved.
Now another invoice arrives from the same vendor.
A stateless application starts from the current invoice.
A memory-enabled agent can retrieve the previous situation.
That doesn't mean the previous answer should be copied.
It means the agent has more context before making the new decision.
The architecture
I think of the system as five layers:

Input The invoice enters the workflow.
Understanding The relevant information is extracted.
Context The agent retrieves relevant historical information.
Decision The agent evaluates the current invoice.
Learning The useful outcome is stored for future interactions. That gives us: ┌──────────────┐ │ Invoice │ └──────┬───────┘ ↓ ┌──────────────┐ │ Extraction │ └──────┬───────┘ ↓ ┌──────────────┐ │ Validation │ └──────┬───────┘ ↓ ┌────────────────────┐ │ Hindsight Memory │ │ Relevant context │ └─────────┬──────────┘ ↓ ┌────────────────────┐ │ AP Agent │ │ Current decision │ └─────────┬──────────┘ ↓ ┌────┴────┐ ↓ ↓ Process Escalate ↓ ↓ └────┬────┘ ↓ Store outcome This architecture keeps current information and historical information separate. What should the agent remember? This was one of the more important design questions. A raw event isn't necessarily useful memory. For example: Invoice INV-1005 was processed. doesn't tell a future agent much. A richer memory is: Vendor ABC Supplies previously had a PO mismatch. The invoice was escalated, the additional delivery was confirmed, and the invoice was approved. That contains information about: the vendor the problem the action the resolution the final outcome Those details can be useful when a similar case appears. Using Hindsight for persistent memory I used Hindsight as the memory component because the AP Agent needs more than temporary conversation context. Conceptually, the application can store the result of an interaction: memory.store({ "vendor": vendor, "issue": issue, "decision": decision, "resolution": resolution }) Then, during a future interaction: previous_context = memory.retrieve( current_invoice ) The agent can combine that context with the current invoice. The exact implementation should use the actual functions and data structures from the project. The technology is documented in the Hindsight GitHub repository⁠� and the Hindsight documentation⁠�. The behavior change The easiest way to understand the value of memory is through a before-and-after comparison. Before memory Invoice arrives ↓ Agent processes invoice ↓ Decision ↓ Workflow ends After memory Invoice arrives ↓ Retrieve relevant previous context ↓ Agent processes invoice ↓ Decision ↓ Store useful outcome ↓ Future interactions can use it The important change is continuity. The agent isn't forced to forget everything when the current workflow ends. Memory should not override the current invoice There is an important limitation. Suppose the previous invoice from a vendor was approved. It would be dangerous to implement: Previous invoice approved ↓ Approve new invoice Instead: Previous invoice ↓ Relevant memory ↓ Current invoice ↓ Current validation ↓ Current decision The current invoice always needs to be evaluated. Historical context is supporting information. This keeps the memory layer from becoming an uncontrolled decision rule. What happens when memory is wrong? This is another important consideration. Historical information can become outdated. A vendor may change payment terms. A workflow may change. A previous exception may no longer apply. That's why the agent should not blindly trust retrieved memory. The system should consider: Is this memory relevant? Is it consistent with the current invoice? Does current validation support the same conclusion? If the answer is unclear, escalation is still available. Human feedback can become useful memory One of the most interesting parts of this design is the role of human review. Suppose the agent encounters an unfamiliar invoice and escalates it. A human then provides the resolution. Instead of allowing that knowledge to disappear, the system can preserve the useful outcome. The next time a similar case occurs, the agent has additional context. That gives us: Agent ↓ Uncertain case ↓ Human review ↓ Resolution ↓ Memory ↓ Future agent This is one of the clearest ways that persistent memory can change an agent workflow. What I would change in a future version Building this system also highlighted areas that need careful engineering. Better memory selection The system should retrieve the most relevant experiences rather than simply returning large amounts of historical information. Better outcome tracking A decision should ideally include enough context to understand why it happened. Stronger boundaries The agent should have explicit conditions for automatic processing versus human review. Better testing The most interesting tests are not just: Can the agent process an invoice? They are: Does the agent behave differently when relevant historical context exists? That is the behavior that demonstrates whether memory is actually helping. Three lessons from the project
Memory should answer future questions Instead of asking what can be stored, ask what information the agent will need later.
Store decisions together with context A decision without its reason is much less useful as future memory.
Measure behavior, not memory size Having thousands of stored memories doesn't prove that the agent is better. The useful question is whether the right memory is retrieved at the right time and changes the workflow appropriately. Final thought An Accounts Payable Agent doesn't become interesting simply because it can read an invoice. The interesting question is what happens when it encounters the same kind of situation again. A stateless automation system sees another invoice. An agent with persistent memory can see another invoice plus relevant experience. That is the core idea behind the architecture I built: use Hindsight to give the AP Agentcontinuity while keeping current validation and human review in control of the final workflow.

DEV Community: Hamsika Nagalla

What Changes When an Accounts Payable Agent Remembers Its Previous Work?