Ask an LLM to write something once and you get a first draft. Ask it to revise based on specific feedback and the second draft is measurably better. This isn’t surprising. It’s how human writing works too. What’s interesting is that you can automate both sides: one agent writes, another evaluates, and a Go loop connects them.

This is the evaluator-optimizer pattern, described in Anthropic’s Building effective agents guide. A generator produces output. An evaluator scores it and gives feedback. If the score is below a threshold, the generator revises. The loop continues until the output is good enough or you run out of attempts.

A single LLM call gives you one perspective. Ask the same question twice with different system prompts and you’ll get meaningfully different answers, different assumptions, different blind spots, different strengths. This isn’t a bug. It’s the foundation of a useful multi-agent pattern.

The idea is old. Juries deliberate. Academic peer review works because reviewers disagree. Design reviews surface risks that the original author missed. The mechanism is always the same: independent reasoning followed by structured synthesis. LLMs are well-suited to both steps.

Large Language Models are stateless by design. Each API call starts from scratch. The model has no idea what you said thirty seconds ago unless you explicitly pass the conversation history back in. This is a fundamental constraint of the request/response paradigm: the model is a function, not a process.

But real conversations need memory. The user says “my name is Alice” in turn one, and expects the assistant to remember it in turn ten. They build on previous answers, refer back to earlier context, and assume continuity. Bridging this gap between stateless inference and stateful dialogue is one of the first problems you hit when building any conversational system.

A lot of support bots fail for the same reason. They try to do everything with one prompt.

Billing questions, outage reports, refund requests, API errors, onboarding questions. It all goes into one agent, and the prompt turns into a long list of rules, exceptions, and fallback behavior. At first it feels convenient. A few weeks later it feels fragile.

This is where multi agent systems stop being a buzzword and start being useful.

AI agents are graduating from demos to production, and the infrastructure choices you make today will shape your system’s reliability, cost, and scalability for years. The language you build on matters.

Go was designed for exactly the kind of systems that AI agents are: networked, concurrent, long-running services that need to be fast, small, and maintainable at scale. Yet most AI tooling still defaults to languages built for interactive data work, not production services.

There’s a moment every developer knows. You’re staring at a codebase you built with your own hands, something you poured months into, something that works, and you realize it’s fighting you. Not because it’s broken, but because the world around it moved somewhere your original design never anticipated.

That moment came for me with LinGoose.

A bit of history

I built LinGoose in 2023 as a Go framework for LLM-powered applications. It grew, people used it, and I was proud of it. But after a while I hit a wall I couldn’t design my way around: LinGoose was built around pipelines. A single flow, a single thread, steps executing in sequence.