DEV Community: Pulla Indira Keerthana

What If Your AI Agent Could Remember Why an Invoice Was Resolved?

Pulla Indira Keerthana — Tue, 29 Sep 2026 13:31:40 +0000

Accounts Payable systems are already good at telling you that an invoice doesn't match a purchase order.

The harder question is:

What actually happened, and have we seen this before?

An invoice might be ₹55,000 while the purchase order says ₹50,000. A traditional matching system can flag the ₹5,000 difference.

But someone still has to investigate.

Was there an approved contract amendment? Was the delivery partial? Has this vendor had the same issue before? Did someone resolve a similar exception differently six months ago?

That investigation is where a lot of human knowledge gets trapped.

I built Vaulty — AI Exception Intelligence to explore a different approach:

Memory guides the investigation. Current evidence decides the outcome.

Vaulty is an agentic Accounts Payable exception investigation system that investigates invoice cases, recalls organizational experience using Hindsight, verifies that experience against current evidence, proposes a resolution, keeps payment release human-gated, and learns from the outcome.

The problem isn't matching. It's investigation.

Most AP workflows already have some form of invoice, purchase order, and receipt matching.

The problem starts after a mismatch is detected.

The investigator may need to connect:

Invoice data
Purchase orders
Receipts
Contracts
Contract amendments
Vendor history
Previous exception resolutions
Previous human decisions

The information exists, but the reasoning behind previous decisions often disappears once the case is closed.

So the next similar exception starts almost from scratch.

Vaulty focuses specifically on that investigation layer.

How Vaulty works

The system is organized as a multi-agent workflow.

There are five main agents:

Triage Agent

Triage determines whether the invoice actually needs investigation and identifies the type of issue that may be present.

Investigator Agent

The Investigator gathers relevant evidence and forms a hypothesis about what happened.

It can work with purchase orders, receipts, contracts, vendor history, amendments, and previous resolutions.

Resolution Agent

Vaulty doesn't stop at saying:

"There is a discrepancy."

It determines what should happen next.

Depending on the evidence, that can mean clearing the case, requesting clarification, holding payment, or proposing another resolution.

Orchestrator

The Orchestrator controls the workflow and maintains the human gate around payment release.

Reflection Agent

After a human decision, Reflection turns the outcome into organizational learning that can be used in future investigations.

The interesting part: Hindsight

The most important part of Vaulty isn't that it has five agents.

It's that the agents can learn from previous cases.

Without memory, the workflow looks like:

New case
↓
Investigate
↓
Resolve
↓
Done

The next case starts from scratch.

With Hindsight, the loop becomes:

Previous case
↓
Human decision
↓
Reflection
↓
Hindsight
↓
New case
↓
Recall previous experience
↓
Compare with current evidence
↓
Adapt investigation
↓
Resolve
↓
Learn again

Vaulty uses Hindsight as its organizational memory layer.

Hindsight on GitHub

Hindsight documentation

Memory is not the truth

This was one of the most important design decisions in Vaulty.

We didn't want the agent to behave like:

"I've seen this before, therefore I'll do the same thing again."

That can be dangerous in financial workflows.

Instead:

Memory can guide the investigation, but current evidence decides the outcome.

For example, imagine Vaulty remembers that a vendor previously had a price increase that was legitimate because an approved contract amendment existed.

A new invoice from the same vendor arrives with another price increase.

Vaulty can recall the previous experience.

But it still checks today's evidence.

If the current evidence supports the previous lesson:

Memory: CONFIRMED

If the current evidence contradicts it:

Memory: CONTRADICTED BY CURRENT EVIDENCE

The previous experience doesn't override the current purchase order or contract.

That distinction is important because organizational memory should provide context, not become an unquestioned rule.

A concrete example

Consider a clean invoice.

Vaulty checks the available evidence:

Invoice amount ₹50,000
Purchase order ₹50,000
Receipt Matches
Contract Consistent

There is no discrepancy.

Instead of escalating the case unnecessarily, Vaulty can communicate:

No issues found. The invoice matches the available purchase order and delivery evidence.

And:

Everything looks good. You can continue with the payment.

The human still controls the final payment release.

Now consider a price mismatch.

Invoice amount ₹55,000
Purchase order ₹50,000
Difference ₹5,000

Vaulty doesn't immediately assume that the invoice is wrong.

It investigates.

It can look for an amendment, contract terms, receipts, vendor history, and relevant previous cases.

The result is an evidence-backed recommendation rather than simply a discrepancy flag.

Human decisions become learning

Payment release is intentionally human-gated.

Vaulty can investigate.

Vaulty can recall.

Vaulty can reason.

Vaulty can propose a resolution.

But the final payment release remains under human control.

Once the human makes a decision, that outcome becomes part of the learning loop.

The exact implementation is wrapped inside Vaulty's memory and agent layers, but the important behavior is the loop:

investigate → decide → learn → remember → investigate better next time.

What changed after adding memory?

Before

A recurring vendor exception would require an investigator to rediscover the context.

Same vendor
↓
New exception
↓
Start investigation again
↓
Find previous information manually
After

Vaulty can retrieve relevant organizational experience:

Same vendor
↓
New exception
↓
Recall previous experience
↓
Verify against current evidence
↓
Adapt the recommendation

The improvement isn't simply that Vaulty stores more information.

The improvement is that previous decisions can influence how the next investigation is performed.

That's the behavior we wanted from agent memory.

Building the application around a single source of truth

The operational application uses a business repository as the source of truth for cases, invoices, purchase orders, receipts, contracts, amendments, and audit events.

That matters because a human decision shouldn't only change the button on the screen.

When someone approves or holds a case, Vaulty updates the persistent case state, records the audit event, updates the operational views, and feeds the outcome back into the learning loop.

So the application has a state transition rather than a cosmetic UI change:

AWAITING APPROVAL
│
├── APPROVE ──→ RESOLVED
│
└── HOLD ─────→ ON HOLD

The Case View, Home dashboard, Approvals queue, activity history, and other operational views can then reflect that state.

Why we kept payment human-gated

There is a tempting version of this project where an agent investigates an invoice and automatically releases the payment.

We deliberately didn't build that.

The agent can automate investigation and reasoning, but payment release remains a human decision.

That gives Vaulty a clear boundary:

AI investigates and recommends. Humans control financial commitment.

This also gives the system a useful audit trail: what evidence was available, what the agent remembered, what it concluded, and what the human ultimately decided.

What we deliberately didn't build

Vaulty isn't an OCR platform.

It isn't another three-way matching engine.

It isn't a generic AP chatbot.

It also doesn't depend on a simple hardcoded rule such as:

if difference > ₹5,000:
flag_invoice()

The focus was the investigation layer after the data is available.

For the prototype, invoice ingestion uses structured simulation data rather than full production-grade PDF/image OCR.

That was a deliberate scope decision.

We wanted to spend the build on the harder question:

Once an exception exists, can an agent investigate it, remember what the organization learned, and use that experience responsibly on the next case?

What I learned building Vaulty

Memory is only useful when it changes behavior

A memory panel by itself isn't enough.

The interesting part is when recalled experience changes the investigation or recommendation.

Memory should never blindly override evidence

Previous experience is valuable context.

It isn't current truth.

The current invoice, PO, receipt, contract, and other evidence must still be verified.

Human feedback is valuable data

An approval, hold, correction, or resolution isn't just the end of a workflow.

It can become organizational knowledge for the next case.

Agents need clear responsibilities

Breaking the workflow into Triage, Investigation, Resolution, Orchestration, and Reflection made it easier to reason about where memory should enter the process and where human control should remain.

The real value of an AI agent can be what it remembers tomorrow

A stateless agent can solve a case.

A memory-enabled agent can potentially make the next case different because of what it learned from the last one.

What's next?

A production version of Vaulty could extend the same architecture with:

Real invoice/PDF ingestion
Enterprise ERP integrations
Stronger audit infrastructure
Production-grade access control
More sophisticated vendor-level organizational memory
More extensive evaluation of memory retrieval and investigation quality
Hybrid deterministic validation combined with agentic investigation

But the core idea remains the same:

Investigate. Resolve. Remember.

Vaulty started from a simple observation: businesses don't just accumulate transactions.

They accumulate decisions.

The interesting question is whether an AI system can turn those decisions into useful organizational memory — and then know when that memory should be trusted, when it should be questioned, and when today's evidence should win.

That's what I built Vaulty to explore.

Built with
Python
Streamlit
Multi-agent architecture
Groq / LLM reasoning
Hindsight for agent memory
Local business repository and persistent audit state
Learn more

Hindsight GitHub repository

Hindsight documentation

Vectorize — Agent Memory

Project GitHub: https://github.com/IndiraKeerthana/Vaulty-AI-Approval-Intelligencce

Is it really important to start DSA early?

Pulla Indira Keerthana — Fri, 03 Jul 2026 16:24:39 +0000

I Keep Restarting DSA. Am I the Only One?

I'm a Computer Science undergraduate, and I have a confession to make: I've started learning Data Structures and Algorithms more times than I can count.

Every time, the journey looks exactly the same. I begin with arrays, move on to strings, solve a handful of easy problems, get stuck, lose momentum, and eventually stop. A few weeks or months later, I convince myself that this time will be different. And somehow, I end up back at arrays and strings again.

It's become a cycle that I genuinely don't know how to break.

The frustrating part is that I don't actually dislike DSA. When I read a problem, I can usually understand what's being asked. Most of the time, I can even think of the right approach or explain the logic to someone else. But the moment I open the editor and start coding, everything seems to disappear. I miss edge cases, my implementation doesn't work the way I imagined, or I get stuck translating the idea in my head into actual code.

After looking at the solution, I often find myself thinking, "I knew the logic... so why couldn't I write it?" That's probably the most discouraging feeling I've experienced while learning programming.

What makes it even harder is looking around at everyone else online.

You open LinkedIn and see someone celebrating their 1,000th LeetCode problem. YouTube recommends videos promising to teach "Complete DSA in 30 Days." Reddit discussions revolve around Codeforces ratings, competitive programming, and how many questions you should solve before placements. Then you hear that some companies expect candidates to have competitive programming experience, and you start wondering if you've already fallen behind before you've even begun.

Honestly, one thing I've never fully understood is why competitive programming is considered so important for some companies. I understand that it develops problem-solving skills and algorithmic thinking, but sometimes it feels entirely different. Maybe I'm missing something, and I'd genuinely like to understand that perspective better.

Another challenge is the sheer number of resources available today. LeetCode, CodeChef, HackerEarth, Striver's A2Z Sheet, YouTube playlists, roadmaps, there are so many excellent resources that choosing one becomes overwhelming. Instead of feeling prepared, I often end up feeling stuck because I'm constantly wondering whether I'm following the "right" path.

Over time, I've started to realize that my biggest obstacle probably isn't DSA itself. It's the pressure I put on myself. I expect to solve problems without hints. I expect to write perfect code the first time. I expect to make steady progress without struggling. When those expectations aren't met, I convince myself that maybe I'm just not good enough and simply rely on AI.

But maybe that's not true.

Maybe understanding a solution and implementing it are two completely different skills. Maybe writing buggy code is part of learning how to write good code. Maybe revisiting arrays for the tenth time doesn't mean I've failed—it just means I'm still building a foundation.

I'm writing this because I have a feeling I'm not the only one who's experienced this.

If you've ever restarted DSA multiple times, understood the logic but struggled to implement it, or felt overwhelmed by the endless advice and resources online, I'd love to hear your story.

More importantly, if you managed to break out of that cycle, what changed?

I'm not looking for shortcuts anymore. I just want to stop restarting and keep moving forward, one problem at a time.

What Really Happens at Your First Hackathon?

Pulla Indira Keerthana — Thu, 25 Jun 2026 10:06:08 +0000

My First Hackathon Was Nothing Like I Expected

It was just one month into my college journey when an announcement came through about the internal selections for Hack4SDG, a hackathon that was going to take place at IIT Hyderabad.

At first, I almost skipped registering.

I didn't think I was ready. None of us really knew what a hackathon was like. But my friends and I paused for a moment and thought, "Why not? Let's just give it a try."

That one decision started everything.

We picked a problem statement, brainstormed ideas for a few days, came up with a possible solution, and prepared a presentation for the internal ideathon organized by our college.

The First Time I Spoke in Front of Everyone

I had never spoken in front of an audience before.
Seeing all the teams waiting for their turn made me even more nervous. Most of them were seniors, and they seemed far more experienced than us.
I couldn't focus.
My mind kept telling me that everyone knew more than I did.
Then suddenly I thought...

"I'm just explaining a solution that my team and I worked hard on."

As the team leader, I spoke last. I explained why it was important for people to understand the carbon footprints they leave behind and why awareness alone isn't enough unless we take action.

I wasn't confident because I was good at public speaking.
I was confident because I had done the research.
Once I started talking, everything else disappeared.

The Unexpected Excel Sheet

After the presentations, we honestly didn't expect much.
There were so many experienced seniors with amazing ideas that we assumed they would be selected.
While I was on my way home, I received an Excel sheet listing the selected teams. Our team's name was there. That's it.

We were going to IIT Hyderabad.
My friends and I couldn't believe it.

Reality Hit

The excitement lasted only until we realized something.

We had never participated in a hackathon before. We didn't know any tech stack well enough. We didn't know how people built complete solutions in just 24 hours. We had no experience.
But then again...

Everyone has to start somewhere.This was our starting point.

Walking Into IIT Hyderabad

The day we entered IIT Hyderabad felt magical.

Hundreds of students from different colleges had gathered with the same goal—to build something meaningful, learn new things, and meet like-minded people.

The hackathon had three evaluation rounds, one every eight hours.

We understood the problem statement, planned our work, and even used AI chatbots to help us move faster whenever we got stuck.

Everything seemed to be going well. Until the first evaluation.

Our First Reality Check

We demonstrated what we had built so far. Then we looked around.
Teams with experienced seniors had already developed polished solutions. Some had working hardware. Others already had almost complete applications. We were nowhere close.

For a few moments, it felt discouraging. But after talking as a team, we decided to stop comparing ourselves. This wasn't our competition. It was our first experience.

The Best Part of the Hackathon

Later that night, after dinner, we returned to the lab determined to make the most of the remaining hours.

That's when we met a group of seniors from another university who were building an IoT-based solution.

Instead of staying focused only on our own laptops, we walked over and started talking to them.

They explained their project.
They shared stories about their first hackathon.
They laughed about all the mistakes they had made.

Suddenly...

It felt relatable.

That's when I realized that hackathons aren't only about coding.
They're about conversations.
They're about meeting people who are just as curious as you are.

Some are beginners.
Some are experts.

But everyone started somewhere.

Winning Was Never the Best Part

By the end of the hackathon, we knew we weren't going to win.

And surprisingly...

We were okay with that.
We had learned more in 24 hours than we expected.
We had made friends.
We had built connections.
We had experienced our first real hackathon.

When the winners were announced, one of them was the IoT team we had spoken to the previous night. Instead of feeling disappointed, we were genuinely happy for them. We celebrated their win because, by then, it didn't feel like we were competing anymore.

It felt like we were all part of the same journey.

Looking Back

My first hackathon went nothing like I had imagined.

We didn't win. We weren't the most experienced team. Our solution wasn't perfect.

But I left IIT Hyderabad with something much more valuable than a certificate.

Confidence.

If you're thinking about participating in your first hackathon but keep telling yourself that you're not good enough, remember this:

You don't have to be the best person in the room. You just have to be willing to walk into it.

Whether you win or not, you'll come back with stories, friendships, lessons, and memories that stay with you long after the hackathon ends.

And for me, that was the real prize.

How Learning Git & GitHub Gave Direction to My Developer Journey

Pulla Indira Keerthana — Wed, 24 Jun 2026 17:51:45 +0000

The Git Cheat Sheet That Saved My First Year of College

When I joined college as a first-year student, I had no idea which direction I should take.

Should I focus on projects?

Should I start learning DSA?

Should I learn multiple programming languages?

Should I pick a tech stack first?

Everyone around me seemed to have a different answer. Some told me to build projects immediately, while others insisted that DSA was the only thing that mattered. A few suggested learning every new technology I came across.

The result? Confusion.

Looking back, I realize that this dilemma cost me a significant part of my first year. I spent more time wondering where to start than actually starting.

That's when I understood something important:

I didn't need to follow someone else's journey. I needed to create my own.

Before learning web development, DSA, or any framework, I decided to learn one thing that would stay useful throughout my entire journey:

Git & GitHub

Learning Git and GitHub turned out to be one of the best decisions I made as a beginner.

It helped me:

Track my projects
Manage hackathon submissions
Monitor my learning progress
Understand how real-world development works
Collaborate with others more effectively

However, learning Git wasn't easy.

I constantly forgot which command to use in different situations. Every time I opened the terminal, I found myself searching for commands again and again.

So I created something simple for myself—a Git Cheat Sheet.

Not a huge document filled with advanced commands.

Just the essential commands that a beginner needs while working on small projects and learning the Git workflow.

As I continued using it, I became more comfortable with Git, repositories, commits, branches, and project structures. Eventually, when I started teaching Git and GitHub to my friends, I shared the same cheat sheet with them.

To my surprise, they found it incredibly helpful.

That's when I realized another important lesson:

Learning becomes much easier when you have a clear starting point.

Most resources focus on the destination. They tell you what you should become, what technologies you should learn, and what achievements you should aim for.

But beginners often struggle with something much simpler:

"Where do I start?"

Once you know your starting point, you can build your own path, choose your own destination, and learn at your own pace.

This Git Cheat Sheet helped me and many of my friends understand Git without feeling overwhelmed.

I hope it helps you too.

Happy coding! 🚀