THE BUILDER NOTEBOOK
🤖 AI in Production

Most AI agents are just expensive for-loops

What actually works in production AI doesn't look like the demos. Three patterns from running AI in fintech, news intelligence, and operations — and the agentic pattern none of them use.

8 min read By Ahmed Kammorah

If you spent any time on X in 2025 you watched the agent demos. The browser does its own shopping. The IDE writes its own PRs. The startup pitches itself. Confident chaining of tool calls, voiceover music, “we let the LLM decide what to do next.”

Then you look at what ships to production.

I run AI in three production systems right now: Waffy’s fraud-detection subsystem (fintech, MENA, ~0.4% post-AI fraud rate against a 12% baseline), Signalia’s news-intelligence pipeline (AI for venture capital, processing thousands of headlines a day), and parts of FounderYX’s authoring loop. None of them are “agents” in the X-discourse sense. They’re orchestrated systems that put exactly enough determinism around the LLM to make it useful, and exactly enough LLM inside that determinism to make it intelligent.

The X-discourse pattern — “give the LLM the tools and let it figure out the order” — works in two places: demos, and tasks where wrong-answers are cheap. Production AI in fintech, healthtech, or anywhere a wrong answer costs real money or real trust, runs differently.

Three patterns that work, plus the one that doesn’t.

Pattern 1 — The router (Waffy’s fraud subsystem)

The simplest production pattern. The LLM doesn’t do the work; it routes incoming events to one of N specialized handlers, each of which is deterministic code.

Waffy’s fraud subsystem at v3 was structured this way. An incoming transaction event lands on the bus. A small router model — currently a fine-tuned 7B with a four-category output head — classifies it: clean | suspicious_geo | suspicious_velocity | suspicious_pattern. Each non-clean category hands off to a deterministic rules-engine specialist that asks N specific questions (“is this card seen on 6 sellers in 4 hours?”, “is the device ID known-bad?”) and produces a hold-extension recommendation. The recommendation goes to the wallet; the wallet decides whether to release on time or extend the hold by 48h.

The router itself is the only LLM call. Total cost per transaction: well under a cent. Latency: ~80 ms p50, ~180 ms p99.

The pattern works because the LLM is good at the part of the job that’s pattern-matching across noisy inputs (“does this transaction look weird?”), and the deterministic specialists are good at the part of the job where you need to defend a decision against an auditor (“we held this transaction because rule 7c fired with weight 0.83”).

The agentic alternative — give the LLM all the rules-engine tools and let it call them in any order — was the obvious approach in late 2024. We tried it. Three things broke: cost (each transaction now made 4–7 LLM calls instead of 1), latency (P99 ballooned to ~1.4s, killing the wallet’s settlement SLA), and auditability (every regulatory ask became “let me check the trace, hang on, why did it call this tool before that one?”). We rewrote to router+specialists in a weekend. Production has been quieter since.

Pattern 2 — The decoder ring (Signalia’s news pipeline)

Signalia turns thousands of news headlines a day into actionable insights for VC. Every headline goes through a pipeline that’s roughly:

  1. Ingest — RSS, Twitter API, scraped press feeds. Deterministic, idempotent, boring.
  2. Extract — LLM call #1 (the only one per headline most days): pull structured fields from the headline + first paragraph. Company name, sector, stage signal, geography, amount-if-disclosed, named participants. Output is JSON with a schema we enforce.
  3. Score — Deterministic. Match against each subscribing VC firm’s investment thesis (a vector + a few rules), produce a relevance score.
  4. Bundle — Deterministic. Group scored headlines by firm and email schedule.
  5. Send — Deterministic.

The LLM is one step in a five-step pipeline. It does one job well: extract structured data from unstructured text. Everything else is plumbing.

This is the decoder ring pattern. The LLM converts something messy (English text) into something tractable (JSON with a schema). Once it’s in the schema, you don’t need the LLM anymore — you have actual data, and you can write actual code that operates on it.

The agentic alternative — “give the LLM the user’s thesis and the day’s headlines, and let it produce the digest” — also works, in the demo. It also costs ~30x more per user per month, takes 40x longer, and surfaces ~15% more “soft hallucinations” (paraphrased facts that lose specificity). We measured. The schema-first pattern wins on every axis a VC actually cares about.

Pattern 3 — The thin wrapper (FounderYX authoring)

FounderYX has an authoring loop where founders draft launch posts, customer interviews, and outbound emails. The LLM here is the most “agentic” of the three — it suggests, drafts, refines. But the agentic part is thin. It’s a single LLM call per user action: “given this draft and this rubric, produce 3 alternative versions.” The user picks one (or none) and continues. The agent has no memory between actions, no autonomous tool calls, no “I’ll figure out what to do next.”

It’s the pattern Cursor uses, the pattern Linear’s AI uses, the pattern that ships. It feels agentic to the user; it’s a single deterministic-then-LLM-then-user loop under the hood.

This is the thin wrapper pattern. The intelligence is in the LLM call, but the agency — the decision about what to do next — sits with the user. The system never autonomously chains decisions because that’s where every production-AI tool I’ve ever seen has had its worst failure modes.

The pattern none of them use — “autonomous agent”

The pattern where the LLM is given a set of tools and asked to figure out the order, the timing, the budget, the success criteria. The X demos. The YC pitches. The “we’re an AI-first company” decks.

I have never shipped this pattern to production. I have tried it three times — once at Waffy (replaced after 11 days), once on an internal Amazon experimentation tool (cancelled at the trial gate), once on a Signalia experiment we never publicly launched.

Three things kill it every time:

  1. Cost is multiplicative. Each autonomous decision is an LLM call. Each LLM call is a chance to call another tool, which is another LLM call. The cost graph is not linear with task complexity; it’s exponential. Production budgets are linear.

  2. Latency is unforgiving. A 1-second decision feels great in a demo. A 1-second decision that makes 6 more decisions ends up as a 12-second user-facing wait. Real users tolerate sub-second; demos don’t have to.

  3. Auditability is binary. When a regulator (SAMA, CBE, GDPR, anyone) asks “why did this happen to this user?”, the answer needs to be defensible in plain language. “Because the model decided to call tool X before tool Y based on its judgment of the task state” is not defensible. “Because rule 7c fired with weight 0.83 because of inputs A, B, C” is. The two architectures are not the same product. They look the same in the demo, but only one of them ships to a regulated industry.

The agentic-autonomous pattern works somewhere — research demos, hobby projects, anything where the cost of a wrong answer is zero. It does not work in fintech, healthtech, or anywhere money or trust is on the line. Which is most of the production AI work that needs doing.

What this means if you’re shipping AI

If you’re building a real product and the AI is the differentiator:

  • Pick the pattern before you pick the model. Router, decoder ring, or thin wrapper. Decide which one your problem is. If your honest answer is “I don’t know, I want the LLM to figure it out” — your problem is the agentic-autonomous pattern, and you should reconsider whether the LLM is the right tool or whether your problem is real.
  • Measure cost per task at the start. A pattern that’s 30x more expensive per task than the alternative will not survive contact with a finance team. Pick the one that’s cheap enough to scale.
  • Architect for auditability before you architect for intelligence. If you can’t explain in plain English why a specific output happened for a specific input, you cannot ship to anyone who cares (regulators, enterprise customers, insurance underwriters).
  • Treat the LLM as one component, not the system. Most of the “AI product” is the deterministic plumbing around the LLM call. If you spend 80% of your engineering time on the deterministic part, you’re probably on the right track.

The router, the decoder ring, the thin wrapper — these don’t sound like AI demos. They sound like normal engineering with one LLM call inside. That’s what production AI actually looks like.

The demos look like agents. The shipping code looks like for-loops with one LLM call somewhere inside the loop body.

— Ahmed