The dashboard said ₹9.91 lakh left. My Hindsight agent said ₹1.94 lakh short.

Adhithi.s — Sat, 07 Nov 2026 17:52:57 +0000

The dashboard said ₹9.91 lakh left. My Hindsight agent said ₹1.94 lakh short.

How I built a cash-flow agent that never does arithmetic, and what I use Hindsight for instead.

A dashboard said Malabar Electronics would have ₹9.91 lakh left after Friday's supplier payment. The agent I built said it would be ₹1.94 lakh short. Both were working from the same books: ₹12.00 lakh in the bank and a ₹15 lakh bill due on 13 November.

Only one of those numbers accounts for the fact that customers do not pay on the due date. Some are reliably a week late, some two. Owners tend to find out on the day the supplier bill lands. This post covers how the second number gets computed, why I will not let the language model compute it, and what I use Hindsight for once the arithmetic is out of the model's hands.

The gap in one card: after paying the supplier on 13 November, a due-date dashboard says ₹9.91 L left; the forecast built from real payment habits says ₹1.94 L short.

What it does and how it hangs together

Cashwise is a cash-flow tool for small businesses that sell on credit: distributors, traders, manufacturers waiting on customers while raw-material bills arrive, and service firms with monthly invoicing and fixed rent and salaries. The owner uploads CSVs exported from Tally, Zoho Books, QuickBooks or Excel and gets a four-week forecast in best, likely and worst cases, a short weekly to-do list, alerts, management reports they can print, email or share by link, and an agent they can question in plain words.

The Cashwise landing page: the product pitch, with a live demo for anyone who wants to try the forecast first.

First-run setup: four uploads, then the forecast and the agent are ready. Customers, invoices and payments, suppliers and bills, and history for memory.

The backend is FastAPI and SQLAlchemy, with one SQLite database per business. The frontend is React and Recharts. The model runs on Groq with tool calling. Memory lives in Hindsight, one bank per business.

Three components with three jobs. The forecast engine computes, Hindsight remembers, and the model chooses what to look at and explains what it found.

Most of the design is about not letting any one of them do another's job. One detail I care about: the forecast starts from the bank's balance, not the books'. The owner types in what the bank shows and a single adjustment keeps the records consistent. Books and bank rarely agree to the rupee, and a forecast that starts from the wrong number is wrong everywhere downstream.

The overview: bank balance, four-week net cash flow in best, likely and worst cases, financial position, and the agent alongside.

The forecast is deliberately boring

For each customer, the engine takes their last eight paid invoices and measures how many days late each one was. The 20th, 50th and 90th percentiles of those delays give a best, likely and worst case for when each open invoice will actually be paid. Supplier bills, recurring expenses such as rent and salaries, and any what-if changes are layered on day by day.

Eight invoices is a small window, and I would rather say so up front. With so few points, the 90th percentile is close to "the worst delay we have seen": a defensible worst case, not a statistical guarantee. I chose the short window because payment behaviour drifts, and a customer who tightened up should not be judged on last year's habits. The interface says plainly that forecasts are estimates, not advice.

What I get in return is traceability. Alerts, runway, the financial position and every report come from the same engine. When an owner asks why it says something, the answer is a list of invoices and delays, not a paragraph of model output.

The forecast chart. On 24 November the likely line sits at ₹2.23 L; if everyone paid on the due date it would read ₹12.83 L. The blue line is a what-if, and the green band is best to worst case.

The model is not allowed to do maths

I have watched language models do arithmetic with money. They are right often enough to be trusted and wrong often enough to hurt, and the wrong answers arrive with the same confidence as the right ones. A cash tool that is confidently wrong on the morning a supplier bill is due is worse than no tool.

So the agent works through tools, and a tool call is the only way a figure can enter an answer:

cash_forecast   what_if   customer_profile   upcoming_bills   recall_memory

The model decides which to call and then explains what comes back. Answers are structured: a headline, recommended actions, evidence, patterns from memory, and assumptions and uncertainty. The what-if tool is the clearest example. "What if Mehta pays 15 days late?" does not ask the model to reason about dates. It calls the same function that drives the slider in the forecast view, and the model reads the result.

What goes into Hindsight

A forecast knows how customers pay. It does not know that a customer promised Monday and did not deliver, that a supplier once agreed to split a bill, or that phoning one particular customer achieved nothing last time. That context lives in the owner's head, and it is what turns generic advice into specific advice.

I use the open-source Hindsight memory layer for it. If you want the background on why agents need a separate memory layer at all, Vectorize's explainer on what agent memory actually is is a good primer, and the Hindsight documentation for retain and recall covers the API. Each business gets its own bank, and two kinds of content go into it.

History. During setup, owners can upload a final, optional file of past calls, disputes, extensions and decisions, with four columns:

date, entity_type, event_type, description

The description is free text on purpose: it exists to hold what a ledger cannot. The data screen has a "Send history to memory" button because memory can be set up after the records, and nobody should have to re-upload everything to do it.

Uploads are validated before anything is saved. The memory card on the right sends history to that business's own Hindsight bank.

The agent's own advice, and what happened next. For every question the agent runs one loop: recall the most relevant memories from the business's bank; reason with the model and call the tools; explain the answer with evidence and uncertainty; retain the recommendation it just made.

The last step is the one I care about most, and the easiest to skip. Because the recommendation is stored, outcomes and feedback recorded later have something to attach to:

POST /api/ask        POST /api/feedback
POST /api/outcome    GET  /api/memories

The owner can record that a customer paid on the 18th instead of the 11th, and whether the advice was useful. Both go back into Hindsight alongside the recommendation that triggered them. The next time a similar question comes up, recall returns the earlier advice together with how it turned out. There is no fine-tuning and no retraining. The agent just reads a better record.

Two more decisions. One bank per business: isolation is easy to reason about, one company's history never appears in another's answers, and recall only searches things that business said or did. And a switch, the "Memory on" control in the header, that turns memory off. That leaves a due-date-style assistant with forecast tools and no history, so I can compare the two on the same question. A memory feature you cannot turn off is one you cannot evaluate.

What an interaction looks like

Back to the opening. In the forecast view, the weekly to-do list proposes asking the supplier to take ₹12.00 L on 13 November and holding back ₹3.00 L for two weeks. That turns a likely ₹1.94 L shortfall into ₹1.06 L left on the day. That is the what-if tool's arithmetic, surfaced as an action. Then the owner asks the agent: What if Mehta pays 15 days late?

The agent as the owner first sees it: the "Online, with memory" badge and four starter questions.

The agent's answer, with recommended actions, evidence and a labelled pattern from memory. The assumptions and uncertainty section sits below the fold.

The answer, in short. The likely low point falls to −₹8.03 L on 2 December, with an ending balance after 30 days of about −₹2.68 L. Three actions: call Mehta Traders today and ask for payment within five days; send a formal reminder; and if there is no response by 12 November, offer a 2% early-payment discount for settlement within three days.

Where each part comes from.

From the what-if tool: the low point, its date and the ending balance.
From Hindsight: the note that Mehta consistently pays 13 to 15 days late, and the pattern that this habit has deepened cash shortfalls in past cycles.
From both: the recommended actions, which combine the numbers with what has worked before.

The owner can tell which part is arithmetic and which part is recollection. That is the point of keeping them apart.

I am not claiming the agent is right in any absolute sense. It reads estimates built from past habits, and it says so in the assumptions and uncertainty section. The claim I can make is narrower and checkable: every figure came from a function, and the history behind the advice comes from a bank the owner can inspect on the Memory page.

Running it

Configuration is a handful of environment variables:

GROQ_API_KEY=gsk_...
HINDSIGHT_API_KEY=hsk_...
HINDSIGHT_URL=https://api.hindsight.vectorize.io

/api/health reports whether the model and memory are configured (ai_configured, memory_configured), which is the first thing I check when the agent behaves strangely. The test suite uses a throwaway database and never calls Groq or Hindsight, so the forecast and ingestion logic are tested without a network.

What I would tell another engineer

Separate judgment from calculation in the architecture, not in the prompt. A prompt that says "do not invent numbers" is a hope. A system where the only way to produce a number is a function call is a guarantee.
Forecast ranges, not points. A single figure implies certainty the data does not contain. Three cases side by side make the owner think about the bad one.
Retain the advice, not only the facts. Most memory setups store what the user said. The more useful thing to store is what the agent recommended, because that is what later outcomes and feedback have to attach to.
Give memory an off switch. If you cannot turn it off and compare, you cannot tell whether it is helping, and neither can anyone you are trying to convince.
One memory bank per tenant. It costs a little in setup and saves a lot of reasoning about privacy and relevance.

The forecast is why the number is right. Memory is why the advice is specific. Keeping the two apart is what lets me trust either one.
download the pdf version of this article

DEV Community: Adhithi.s

The dashboard said ₹9.91 lakh left. My Hindsight agent said ₹1.94 lakh short.

The dashboard said ₹9.91 lakh left. My Hindsight agent said ₹1.94 lakh short.

What it does and how it hangs together

The forecast is deliberately boring

The model is not allowed to do maths

What goes into Hindsight

What an interaction looks like

Running it

What I would tell another engineer