LoopKeeper
What it does
The problem
An overdue invoice is rarely just an overdue invoice.
After an invoice becomes overdue, a business may receive emails, payment promises, disputes, partial payments, or messages through different communication channels. The difficult part is not sending another reminder — it is understanding what happened, deciding what should happen next, and knowing when the issue is actually resolved.
Traditional systems often treat these events independently. A promise made by a customer can be forgotten, a broken commitment may not trigger the right escalation, and an invoice can be marked as resolved without sufficient evidence.
LoopKeeper turns this fragmented process into a continuously monitored "payment loop."
The solution
LoopKeeper is an agentic AI system for invoice follow-up and resolution.
Instead of simply generating reminders, the system continuously:
Observe → Reason → Plan → Act → Verify → Close
It can receive evidence from:
- 📄 Invoice PDFs/images
- ✉️ Gmail replies
- 📱 SMS
- 🖊️ Manual invoice/evidence entry
The Evidence Engine normalizes these events and maintains the state of each payment loop.
The LoopKeeper agent then reasons over:
- Invoice information
- Client relationship history
- Previous communication
- Payment promises
- Disputes
- Payment evidence
- Previous agent actions
The system also uses a deterministic policy engine to control what the AI is allowed to do.
- Tier 1: Low-risk situations can be handled autonomously.
- Tier 2: Sensitive actions require human approval.
- Tier 3: High-risk or disputed situations are escalated.
This creates an important safety boundary:
The AI can reason about what should happen, but deterministic policy controls what it is actually allowed to do.
Most importantly, LoopKeeper does not consider an invoice resolved simply because an action was taken.
Payment evidence must be received and verified before the system can safely close the loop.
How we built it
LoopKeeper is built as an agentic workflow rather than a simple chatbot.
🧠 Agent Layer
We use Google Agent Development Kit (ADK) with Gemini to build the LoopKeeper agent.
The agent follows an Observe → Reason → Plan → Act workflow and has access to tools for working with invoices, evidence, clients, approvals, and loop state.
🔎 Evidence Engine
The Evidence Engine acts as the source of truth for incoming events.
It handles:
- Incoming replies
- Payment promises
- Payment evidence
- Disputes
- Broken promises
- Evidence deduplication
- Loop history
For example, when a client promises to pay on a specific date, that promise is stored as structured state.
If the promised date passes without payment evidence, the system can deterministically detect a broken promise.
This prevents the LLM from being responsible for business-critical state transitions.
⚙️ Deterministic Policy Engine
We implemented a Python-based policy layer that evaluates:
- Invoice amount
- Urgency
- Risk
- Dispute status
- Promise status
- Previous unanswered attempts
The result is a transparent Tier 1 / Tier 2 / Tier 3 decision.
This gives us an auditable boundary between AI reasoning and business authority.
👤 Human-in-the-loop
Tier 2 actions are placed into an approval queue.
A human can:
Review → Approve/Reject → Execute
This allows us to benefit from agentic automation without giving the model unrestricted control over customer-facing actions.
🛡️ Resolution Guard
LoopKeeper includes a dedicated verification guard.
The agent cannot autonomously close a payment loop without sufficient payment evidence.
This makes:
"Action completed" ≠ "Problem resolved."
☁️ Google Cloud & Firebase
The system uses Google Cloud and Firebase services for its application infrastructure and persistent state.
Firestore provides persistent application data and relationship memory, while Firebase Authentication provides user authentication.
The frontend is built with React and provides the Command Center, Approvals, Activity Feed, Clients, Settings, and invoice workflows.
The architecture is designed so the state layer can support both sandbox development and production persistence.
Challenges we ran into
1. Giving an AI agent autonomy without giving it unlimited authority
One of our biggest challenges was deciding what the AI should control.
We didn't want an LLM to independently decide:
"This invoice is resolved."
Instead, we separated reasoning from authority.
The agent can recommend and plan actions, while deterministic Python policies decide the allowed action tier.
2. Maintaining state across conversations and events
An invoice can have many events over its lifetime:
Invoice created
↓
Reminder sent
↓
Customer promises payment
↓
Promise expires
↓
Broken promise detected
↓
Escalation
↓
Payment evidence received
↓
Verification
↓
Closed
Maintaining this state consistently across different evidence sources was a significant architectural challenge.
3. Making promises deterministic
A payment promise cannot simply be stored as text.
The system needs to understand:
- What was promised?
- When was it promised?
- When is payment expected?
- Has the deadline passed?
- Was payment evidence received?
- Was the promise kept or broken?
We therefore implemented a structured promise state machine and deterministic broken-promise detection.
4. Handling multiple communication channels
Email, SMS, WhatsApp, invoice documents, and manual input all produce different types of information.
We needed to normalize these different inputs into a common evidence model so the agent could reason over them consistently.
5. Making the system auditable
Agentic systems can be difficult to understand after an action has happened.
We therefore built activity history, decision traces, approval records, and resolution reports so that a user can understand why something happened, not just what happened.
Accomplishments that we're proud of
🧠 We built an actual agentic workflow
LoopKeeper isn't just a chatbot that answers questions.
The agent observes state, uses tools, reasons about the next step, proposes actions, and interacts with a controlled workflow.
🔐 We created a clear AI safety boundary
One of the things we're most proud of is separating:
LLM reasoning
from
deterministic business authority.
This allows us to use AI where it is strongest while keeping critical decisions predictable and auditable.
🔄 We built a complete payment-loop lifecycle
The system can demonstrate the complete journey:
Invoice
↓
Evidence
↓
Promise
↓
Broken Promise Detection
↓
Policy Evaluation
↓
Agent Action
↓
Human Approval
↓
Payment Evidence
↓
Verification
↓
Resolution
👤 Human approval is part of the architecture
Human review isn't an afterthought.
It is built directly into the agent workflow for situations where autonomous action isn't appropriate.
📊 Everything is traceable
We built activity logs and resolution reports so users can inspect the lifecycle of a loop and understand the evidence and decisions behind its resolution.
🧪 Strong deterministic testing
We tested policy decisions, promise state transitions, evidence handling, webhooks, API routes, approval flows, safety guards, and a complete invoice resolution scenario.
This helped us catch and fix several critical issues before deployment.
What we learned
AI agents need boundaries
Our biggest lesson was that building an agent isn't simply about giving an LLM more tools.
The more important question is:
What should the agent be allowed to do?
Separating reasoning from deterministic policy made the system significantly safer and easier to audit.
Evidence is more valuable than assumptions
An AI can generate a convincing explanation, but business workflows need evidence.
LoopKeeper therefore treats incoming events as structured evidence and uses that evidence to drive state transitions.
Human-in-the-loop doesn't mean "less AI"
We learned that human approval can actually make an agentic system more useful.
Instead of forcing the AI to either do everything or do nothing, we created different levels of autonomy based on risk.
Agentic systems are state machines as much as they are AI systems
The Gemini agent is only one part of LoopKeeper.
The real system combines:
AI reasoning + deterministic policies + persistent state + evidence + tools + human approval.
That combination is what makes the workflow reliable.
What's next for LoopKeeper
LoopKeeper is currently focused on invoice follow-up and resolution, but the underlying architecture can extend far beyond invoices.
🌐 More communication channels
We want to expand the evidence layer to support additional business communication channels and automatically normalize their events.
📈 Predictive payment-risk intelligence
Future versions could identify patterns such as:
- Clients repeatedly breaking promises
- Increasing payment delays
- High-risk accounts
- Recurring dispute patterns
This could allow LoopKeeper to act before an invoice becomes severely overdue.
🤖 More specialized agents
The architecture could evolve into a multi-agent system with specialized agents for:
- Invoice analysis
- Customer communication
- Risk assessment
- Dispute handling
- Payment verification
while retaining the same centralized policy and safety layer.
🔗 Deeper business integrations
Future versions could integrate with accounting and ERP systems so that LoopKeeper becomes part of the existing financial workflow rather than a separate application.
☁️ Production-scale infrastructure
We also plan to expand the Google Cloud architecture for larger organizations, stronger observability, scheduled agent execution, and higher-volume evidence processing.
LoopKeeper is an agentic AI system that doesn't just chase overdue invoices — it keeps payment loops alive until there is verified evidence that they're actually resolved.
Log in or sign up for Devpost to join the conversation.