Case Study · AI / LLM · 2026

A Production AI Agent That Runs on $28 a Month

RouteFlow · an in-house product at T & A Technologies, built solo in Go · Role: Lead Software Engineer

The decision in one line: the default way to build an AI agent is Python + LangGraph + a pile of heavy libraries. For a straightforward conversational agent that had to run on a cheap, low-end machine, that stack is bloat. I built it in Go, hand-rolling the few pieces I actually needed — and the entire product runs for ~$28/month.

A note on this write-up: the decisions and engineering are mine; I used AI to turn my notes into readable prose. I’m a software engineer, not a writer, and I’d rather be upfront about that.

The constraint that drove everything

RouteFlow (now branded T&A Flow) is a full multi-tenant SaaS. Businesses connect their Meta messaging channels — WhatsApp, Facebook Messenger, and Instagram — and their own customers chat with an AI agent right on the platforms they already use. The agent answers questions, quotes prices, checks service areas, and books appointments end to end — lead to booking — for home-service businesses. The client needed it to run cheaply — an absolute low-end machine, not a fleet of cloud services.

That single constraint made the usual AI stack a bad fit. Python’s agent ecosystem — LangGraph, docling, heavy SDKs — is built for complex agent graphs and assumes you have resources to spare. My agent wasn’t complex. It was a linear tool-calling loop. Paying for a framework’s weight to run a simple thing on a small box is exactly the wrong trade.

So I asked, for each heavy dependency: do I actually need this, or can I write the small version?

The reasoning

1 · Go, because the constraint was resources. Go compiles to a single static binary, uses very little memory, starts instantly, and drags in no runtime. That’s the ideal profile for a cheap VPS. Python would have meant a heavier footprint and a dependency tree to babysit. The language choice was the cost decision.

2 · No agent framework — the loop is the engine. An agent doesn’t need LangGraph to call tools. A tool-calling agent is, at its core, a for loop: ask the model, run whatever tool it asked for, feed the result back, repeat until it answers. I wrote exactly that — bounded to 10 steps so a runaway can’t spin forever. No graph library, no state-machine framework, no checkpointing engine. The loop is the workflow, and Postgres holds the state. It supports tool-calling and human-in-the-loop handoff without any of the machinery.

flowchart LR
  U[User message] --> M{LLM}
  M -->|wants a tool| T[Run tool]
  T --> M
  M -->|plain text| R[Reply]
  style M fill:#4a9eff,stroke:#4a9eff,color:#fff

3 · Write the small version instead of pulling the big library.

• Document chunking — instead of a heavyweight library like docling, I wrote a small chunker: ~1,200-character chunks with ~200 of overlap, heading-aware, with overlap disabled for spreadsheet rows (they’re self-contained facts). A few hundred lines, no Python, no gRPC service.
• No OpenAI SDK — the LLM, embedding, and moderation clients just POST raw JSON over a shared HTTP wrapper with retries. That drops a heavy transitive dependency and keeps the provider interface tiny — swapping providers is roughly one new file.
• Each of these is small on its own. Together they’re the difference between a lean binary and a bloated container.

4 · The measure of success: does it run cheap, and does it work? Both. The full product — agent, retrieval, booking, multi-channel chat — runs on a single small VPS for about $28/month all in. No Python runtime, no framework overhead, no fleet of services.

The honest costs

Rolling your own has a bill, and I want to be straight about it:

• I own more code. The loop, the chunker, the HTTP clients — they’re mine to maintain and test. A framework would have given me those (and a community) for free.
• No framework features out of the box — tracing, integrations, and niceties I’d have to add myself if I ever needed them.
• This was the right call because the agent is simple. For a genuinely complex, branching, multi-agent system, a framework like LangGraph earns its weight — I’d reach for it then. The skill isn’t “always hand-roll”; it’s matching the tool to the actual complexity and the actual budget.

Testing an agent whose output is never the same twice

Testing an AI agent is its own problem: the reply differs every run, so assert.Equal is useless. I split it in two:

• Assert everything mechanical in plain Go. Which tools it called, in what order, the classification flags — all deterministic. A normal table test pins them; no LLM needed. Don’t LLM-judge what an if can test.
• Only prose-only claims get an LLM judge — things like “tells the customer a human will call shortly” that no equality check can pin. I built that as an LLM-as-judge assertion and eventually extracted it into its own open-source Go library, agenteval (zero dependencies, bring-your-own-model). (Separate case study on it.)

And I test it under failure, not just happy paths — fault injection against the live engine: kill the agent’s own DB connection mid-conversation, rename a table so a real tool query fails, add a constraint so one write fails while the rest stays healthy — then assert the agent recovers and says the right thing. No mocks: real Postgres, real tools, real failures.

One more decision: connect, don’t rebuild

The product’s guiding rule became “we connect, we don’t rebuild” — never become the system of record. That killed a feature mid-build: a full recurring-service CRM got re-scoped down to one follow-up row and one sweep job. The best code is the code you delete before writing it.

See it live

RouteFlow is a still-evolving MVP — actively developed, not a finished product — but it’s real and running. You can see it here: flow.tandatec.com.