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 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.

Why it’s a good story

Everyone shows off AI features. Almost nobody talks about margins — what it actually costs to run the thing in production. Building an agent that’s genuinely useful and runs for the price of a couple of coffees a month is, to me, the more interesting engineering problem: restraint, knowing which dependencies to refuse, and writing the small version well.

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.