Start here
Why we chose Go for a production agent runtime — and what to read next
Thanks for being on the list.
Production Notes is where I write about shipping enterprise AI agents, durable workflows, and SRE automation in Go — from the work we do at StackGen on Aiden and our agent runtime. Not slide-deck demos. Production bugs, trade-offs, and lessons that survived on-call.
The full archive lives at productionnotes.dev. This first issue includes a complete mini-essay below — plus links when you want the full depth on the blog.
Who this is for
Staff engineers and platform teams running agentic workflows in production
SREs who care about triage, observability, and token economics
Go engineers asking whether an agent runtime beats a Python-first stack for your constraints
If you’ve debugged a multi-stage agent pipeline at 2am, you’re in the right place.
In this email: why we chose Go (not Python)
Every agent framework you’ve heard of is Python — LangChain, LangGraph, AutoGen, CrewAI. When we started building an enterprise agent runtime at StackGen, Python was the obvious default.
We chose Go anyway. Not because Python is bad at notebooks — because our problem wasn’t a chatbot. It was software that runs on your servers, with your credentials, calling tools and sub-agents in production.
Five requirements drove the decision:
Many agents concurrently — each with its own tools, memory, and policies
Embed as a library inside Aiden (Temporal is Go-native), not a sidecar service
Ship a single binary — laptops, K8s, air-gapped boxes without “install Python + 200 packages”
Low overhead per tool call — middleware cost compounds across hundreds of calls per task
Untrusted input — prompts are attack surface; we wanted a stack we’re used to hardening
Concurrency was the first killer argument. Agents wait on LLMs, shells, vector DBs, and human approval at the same time. Python can do this with asyncio, but it colors your whole dependency tree — every library must cooperate. In Go, parallel work is normal functions and structured cancellation, not an alternate runtime mode.
Single binary was the second. Enterprise customers in regulated environments don’t want a gigabyte Python image. They want “copy this binary.”
The trade-off we accepted: LLMs return messy JSON. Go’s encoding/json is strict. We’ve since softened that with repair layers — but Go was still the right call for runtime concerns. Python may still win for research and notebook iteration.
That’s the thesis. The full post walks through embed-as-library, defense-in-depth, and when you shouldn’t follow our path:
Go vs Python for AI Agents — full post on productionnotes.dev →
Next on the blog (posts 2 and 3)
2. Bring Up Agent Workflows Like Hardware
How to debug multi-stage agent pipelines one stage at a time — the same discipline as hardware bring-up, applied to workflows that fail in opaque ways.
3. AI-Augmented Incident Triage for SREs
What actually helps on-call: parallel evidence gathering, structured handoffs to the LLM, and drafts for humans — not auto-posted RCA theater.
Then follow the series
If those resonate, the numbered arc is here:
Building an Enterprise AI Agent Platform in Go
Runtime design, memory, governance, platform split, observability, HITL — in reading order.
Topic hubs if you want to browse by theme:
AI agent workflows — bring-up, evidence-gated RCA, verification
AI agents for SRE — triage, observability, tokenomics
Go AI agents — language choice, platform architecture
What to expect from this list
Low volume. I email when a new essay is worth your inbox — usually every few weeks, not a content-mill schedule.
Each issue includes something you can read in the inbox — plus links to the full essay on productionnotes.dev when you want depth.
Prefer RSS? productionnotes.dev/feed.xml
One ask
If a colleague would find this useful, forward this email or share the series page:
https://productionnotes.dev/series/enterprise-ai-agents-go/
No referral gimmicks — just the links.
Reply if you’re working on similar problems. I read everything from practitioners and it often becomes the next post.
— Sabith
Sabith K S · Staff Engineer, StackGen
Blog: productionnotes.dev