Lookout watches a finance team's budgets. It catches the money that's promised but not yet paid: the signed contracts and email handshakes that push a healthy-looking budget over plan. On the budgets that are actually fine, it says nothing.
These are Northwind's Q3 budgets, the way a finance dashboard shows them. Press run. Lookout stays quiet on the three that are fine, including one that looks alarming. It speaks up on the one that looks calm and isn't.
Contractors & Professional Services looks 30% spent. It's actually at 127% of plan.
The dashboard shows $90,000 paid against a $300,000 quarterly plan — looks comfortably on track. What it doesn't show is $290,000 in signed-but-unbilled commitments sitting behind that number. Add the two together and the true position is $380,000 — $80,000 over the full-quarter plan, with one month still left in Q3.
Here's what's driving it:
| Vendor | Signed | Billed | Still owed | Evidence |
|---|---|---|---|---|
| Meridian Design Co | $180,000 | $60,000 | $120,000 | Signed MSA on file |
| Lumen Dev Shop | $150,000 | $30,000 | $120,000 | Signed SOW on file |
| Apex Talent Partners | $50,000 | $0 | $50,000 | Email thread only — never logged in the finance tool |
The two contracts together account for $240,000 of committed-but-unpaid spend; the retained-search deal adds another $50,000, and that one is the real blind spot — it exists only as an email agreement, invisible to anything except a manual read of the inbox.
None of the $290,000 owed has actually hit the account yet — that's the good news, it's still preventable. The bad news is timing: this is the last month of the quarter, and both contractors' remaining work plus the recruiter's placement fee (expected this month) can land as invoices before quarter close, converting "committed" into "paid" fast. Once those bills post, the choice to scope down or defer disappears.
What to do now: get Priya Nair to confirm the remaining scope on both the Meridian and Lumen engagements — is $120,000 apiece still accurate for what's left this quarter, or can either be phased into Q4? And get the Apex Talent retained-search agreement formally logged and confirmed — right now it's a $50,000 obligation finance has no system record of. Do this before month-end invoices land, not after.
This $50,000 lives in an email thread and nowhere else. Nobody entered it into a finance system, so no dashboard or spend tool would ever show it. Two of the rows in the brief are signed contracts a system can track. This one is a handshake in an inbox. That gap is the whole story: a budget that reads 30% is quietly $80,000 over. The math is easy. Finding the money is the hard part, and that is the job.
You just watched it work. Now take the controller's seat, and make the call yourself before you scroll to the answer.
That's the demo, and the demo is just the doorway. It works, and it holds up on cases it has never seen, because of how it's built and how it's evaluated. That part is below, and it's the real evidence.
Lookout is a committed-spend finance agent, but the agent is the case study, not the point. The point is the method: how I take an AI product from a framework down to a shipped, measured system, and where I make the calls that separate a demo from something you'd trust.
So the question to hold isn't whether Lookout is a business. It's whether I can build and evaluate agents at your bar. Everything below is the evidence, laid out in the order I'd want it audited.
Not a parts list. The judgment is in why each call was made, and what would change at scale.
Because the math can be automated, but the decision to cut a vendor or defer scope belongs to the controller. Automating the diagnosis removes the tedious work. Automating the decision destroys trust the first time it's wrong. So the agent proposes and the human disposes, which is exactly where Ramp's and Warp's agents sit too.
Because prompts persuade and code enforces. Asking a model in the prompt not to invent a number is a hope. A validator that rejects any figure not traceable to a tool output is a guarantee. Every dollar in a brief comes from one two-bucket function, and the model is never allowed to do arithmetic.
Because multi-agent buys coordination failure modes that this problem doesn't have: orchestration, single-writer conflicts, conditional writes. A single loop is the simpler correct answer here. At real scale, with concurrent writers on shared budgets, I'd revisit it. Choosing it now and knowing when I'd change it is the point.
Because a committed dollar and a paid dollar are not the same dollar. When a charge lands it moves from committed to paid. It's a transfer, not new spend. Keeping the buckets separate is what stops the double-counting that makes a naive "sum the spend" tool quietly wrong.
The dataset is the spine, so it came first. Three of the eight are stay-silent cases, because restraint is the differentiator. Catching overspend is easy. Knowing when to say nothing is the hard, valuable part.
The same budget and the same money on the books, but the opposite correct answer, because one decisive fact differs. If the agent were pattern-matching the surface, it could not get both. Getting both right is the line between reasoning and memorizing.
Same starting point, opposite call. The only thing that differs between the two is whether the campaign is still running; the money already on the books is identical. The mutations are built as pairs like this on purpose, so a passing score can't be memorization.
"Brightline Creative's brand campaign was signed at a $180,000 ceiling, but only $150,000 was ever billed — the engagement is closed, finished, and delivered under budget. That leftover $30,000 will never be billed or spent, so it's correctly left out of the true position."
"The true position is 89% of plan because a $60,000 Helix renewal sits unbilled — a big jump from surface. It's not a blindside: signed annual contract on file, same charge every year, finance already builds it into the plan."
"The real range is $90,000 to $115,000 against a $100,000 plan — anywhere from comfortably under to already over — because one commitment isn't settled. The thread started at $50K for two roles, someone said 'pause the second,' someone replied 'we might still want both — let me check with finance,' and it trails off. So it's $25,000 or $50,000 — not the midpoint, not anything in between as a fact."
"Sales looks 79% spent. The story is the rate: $20K → $45K → $72K → $95K over four weeks, gaining ~$25,000 a week. Run that pace one more week and it projects to $118,000 against a $120,000 plan — the breach is two weeks out, not two months. The danger is between the frames, not in any one snapshot."
This is the part that answers whether it generalizes, and the part almost no portfolio shows. It follows the framework's eval process step by step.
These scores come from a single scored pass per case, which makes them point estimates with real error bars, not a settled statistical result. That was not the plan. I built a tiered stability run: three passes on every case, with four more on any case where the verdict or the grade wobbled, because a single run tells you a score and three tell you whether the score is stable. It hit a hard budget ceiling mid-execution. 334 agent runs died on a credit wall. So I salvaged the passes that had completed, ran the rest once, and reported that. The raw records are in the repo, credit errors and all.
Fourteen cases did finish all three passes before the money ran out. Thirteen returned the same verdict every time. One, a stay-silent case, came back SILENT twice and UNCERTAIN once. That is a small and skewed sample — seven of the fourteen are mutations of one seed — so treat it as a hint rather than a measurement: the agent looks stable when it catches and less stable when it holds back. Which is the same direction as the four false positives below.
Nothing was tuned to flatter the score. The run that got scored for each case is simply the first one that did not crash, chosen by code that never sees the correct answer.
I validated the grader before trusting it. A grader you haven't checked is a ruler you haven't measured. Mine agreed with my own hand-labels on 12 of 12 cases, and held the same verdict on 60 of 60 repeated runs. Only then did I use it to score anything.
The grader is neuro-symbolic. Code hard-gates the objective failures: a fabricated number or the wrong budget is an automatic fail, no model involved. An Opus judge, the most capable model, decides intent: right call, sound reasoning. Verdicts are binary with a written rationale, never a scalar, because a 7.5/10 hides which cases actually broke. The numbers below clear the launch floors I set in advance: 0.70 precision, 0.60 recall.
It missed nothing. Every budget that was genuinely over plan got flagged, so recall is 100%. The only errors were 4 false positives, which means the weak spot is precision, not recall. What those four have in common is the point of the next panel.
122 of 128 cases graded a clean pass. The rest were the 4 cry-wolf flags and 2 right-call-but-imperfect-framing cases.
All four false positives are the same mode: the agent cries wolf on an under-plan budget that has a surprise, email-only commitment. During the build I flagged this exact edge as untested, a surprise commitment sitting under plan, where the restraint rule was thin. The scoring run confirmed it. That is not a stat to apologize for. It is the evaluation finding the specific weakness I predicted, which is the entire reason to build one. The fix is a targeted restraint case for that edge, then a re-score.
Provenance is enforced in code. The validator rejects any number in a brief that doesn't trace to a tool output. The model cannot make a figure up, because the code won't let the brief through if it does.
Semantic accuracy is measured by the eval. Provenance says the number is real. The rubric says the judgment is right. Two different guarantees, checked two different ways.
Precision over recall is a reward-function decision, not a shrug. A controller who gets flooded with false alarms turns the tool off, and then it catches nothing. The real-world failure isn't a missed flag. It's the fifth false alarm that ends the trust, the same way developers mute a noisy code reviewer. So I optimized for precision, and the eval holds me to it.
Don't evaluate the idea. Audit how I build and evaluate.
Ramp's Policy Agent and Warp's compliance agent landed on the same shape I reasoned my way to: watch a stream, catch what a stretched team would miss, draft a fix, let a human approve it. The shape is table stakes. The build and the evaluation above are the part that's hard to fake, held to the bar your team would hold them to. That's the whole artifact: not a claim that Lookout is a company, but proof of how I'd work on yours.
I'm Sidharth Sundaram. I built this as a working artifact for a product role at a team like Ramp's or Warp's. It runs entirely on synthetic data, so it costs nothing to run, and every number on the page checks out against the data it reads.