Every builder reaches a moment when they start to suspect their own work.
Mine came while I was adding yet another example to phero, my Go framework for multi-agent AI systems. The example looked clean. The code was elegant. The abstractions composed nicely. But there was a question I kept circling: was any of this actually modular, or had I just written boilerplate that I was too close to see?
Every decade, like clockwork, someone announces that developers are finished. The script never changes. A new technology promises to make the programmer redundant. Someone writes a triumphalist article. Decision-makers start dreaming about better margins.
4GLs promised the end of traditional programming. The finance manager would write his own reports. The sales analyst would build her own dashboard. For a while it worked, as long as the systems stayed small. Then the data grew, requirements got messier, performance began to degrade. In the end, developers were called in to rewrite everything in general-purpose languages.
Synadia published the NATS Agent Protocol last week and the core idea is blunt: AI agents are already deployed everywhere (IDE, CI, support queue, factory floor) and none of them were built to talk to each other. The model isn’t the bottleneck anymore. Coordinating the fleet you’ve already deployed is.
Their answer is a wire spec, not a framework. Two pages of contract on top of NATS micro services. An agent is a NATS service named agents with three endpoints: prompt, status, and hb. Discovery is one round-trip: nats req '$SRV.INFO.agents'. Multi-tenancy, cloud-to-edge, audit trail: all inherited from NATS, none of it written twice.
Most multi-agent examples run agents sequentially. One agent produces output, the next consumes it, and so on down the chain. This is easy to reason about but leaves performance on the table. If you need multiple independent perspectives on the same topic, there is no reason to wait for the first agent before starting the second.
The fan-out / fan-in pattern fixes this. Multiple worker agents run concurrently, each exploring the same topic from a different angle. When all workers finish, a synthesizer merges the findings into a single coherent report. The concurrency is handled by Go’s native primitives—goroutines and sync.WaitGroup—with no new framework machinery required.
Most multi-agent examples keep agents isolated. Each one gets a prompt, produces output, and hands it to the next step. That works when the data flows in one direction. But some workflows need agents to build on each other’s work incrementally, reading and writing to a shared context. This is the blackboard pattern.
The idea comes from AI research in the 1970s. Multiple knowledge sources (agents) read from and write to a shared data structure (the blackboard). A control component (the supervisor) decides which agent to activate next. Each agent contributes partial results that other agents can use. The blackboard accumulates context over time.
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.