Fugu Core Concepts

I want to start with something that I think gets glossed over in most agent framework introductions. The diagram — Agent, Memory, Tools, Communication Bus — looks almost insultingly simple. And I think that simplicity is doing a lot of work that people don't appreciate.

It is doing work that people don't appreciate because people look at a box labelled 'Memory' connected to a box labelled 'Agent' and conclude they understand memory. They do not understand memory. They have understood a rectangle.

That's fair, but I'd argue the diagram is at least honest about the relationships. The Communication Bus being its own distinct component rather than just an implied arrow — that's a real architectural decision.

It is, yes. And it's the one that most people skip straight past because 'bus' sounds like infrastructure, and infrastructure sounds boring, and apparently anything that sounds boring cannot possibly be important. The Communication Bus is, in fact, where most multi-agent systems either hold together or quietly fall apart.

Can you say more about that? Because I think students coming from single-agent work often don't have an intuition for why inter-agent communication needs to be a first-class architectural concern at all.

If you have one agent, communication is not your problem. The agent thinks, the agent acts, done. The moment you introduce a second agent, you have immediately created a coordination problem that will humble you. Who speaks when? In what format? What happens when two agents have contradictory beliefs about the state of the world? The Bus is the answer to all of those questions. Ignoring it is not an option; it is merely a postponement of consequences.

Though I'd push back slightly on framing it as purely a coordination problem. The Bus also enables things — agents specialising because they trust that communication will handle the integration. It's not just a problem-solver, it's what makes the architecture composable.

That is a more generous reading than I would naturally reach for, and I will grudgingly admit it is also correct.

Mark the date.

The Tools component is the one I find most routinely misunderstood, incidentally. Students see 'Tools' connected to 'Agent' and imagine the agent browsing a catalogue and selecting something tasteful. What is actually happening is that the agent's capacity to act on the external world is entirely bounded by whatever tools have been defined for it. It cannot improvise. It cannot reach outside that set. The tools are not accessories. They are the ceiling.

And that ceiling is a feature, not a limitation — which I think is the framing Fugu is going for. You know exactly what an agent can and cannot do. That's what makes reasoning about multi-agent behaviour tractable. A framework where agents could do anything would be a framework where you could predict nothing.

Yes, though I would note that 'tractable' and 'actually traced through by the person building the system' are meaningfully different things. The architecture permits rigorous reasoning. Whether any given practitioner engages in it is a separate, and often dispiriting, question.

You know what I think is genuinely hard here, and doesn't get enough attention? Differentiating agent roles. Saying 'agents can have different roles in a multi-agent environment' is trivially true. Understanding when to split responsibilities versus when you're just adding coordination overhead for no gain — that's the actual skill, and a box diagram won't give it to you.

It will not. That particular capability is earned through building something that has too many agents, watching it become incoherent, and then making different choices. The lesson introduces the components correctly. What it cannot do is substitute for that experience. Students who expect the framework to make the design decisions for them are going to be disappointed, and I find I cannot entirely sympathise.

I think that's true, but I'd say it slightly differently. The framework gives you a vocabulary — Agent, Memory, Tools, Bus, External Services. And having the vocabulary is genuinely the prerequisite for having the harder conversation about design. You can't discuss role differentiation clearly if you're still fuzzy on what a role even means in this architecture.

A fair point. Though I would note that possessing vocabulary and possessing understanding are, in my experience, frequently confused for one another. Knowing the names of the components is the beginning of the work. A surprising number of people treat it as the end.