23.02 2025 · 8 min read

Part 3: Building Agent Networks

A single all-knowing agent contradicts how knowledge actually works. Your agent architecture should mirror your organizational structure, and it will evolve through three distinct phases.

In the previous articles, we established that knowledge doesn't live in a single brain. It lives in networks of people, accumulated through experience, encoded in processes, and constantly updated through collaboration. If that's true for human organizations, it should also be true for AI agents.

And yet, the first instinct of most companies building with AI is to create a single, monolithic agent. One system that knows everything, can do everything, and handles every request. It's the obvious architecture. It's also the wrong one.

Limits of a Monolith

Brex learned this the hard way. Their first attempt was a single agent with broad tools, retrieval-augmented generation, and the ability to context-switch between domains. On paper, it made sense. In practice, it broke down.

The problem wasn't technical capability. The problem was architectural. A single agent trying to hold knowledge about expense policies, accounting rules, travel booking, compliance requirements, and dozens of other domains couldn't maintain depth in any of them. Every new domain added made the existing ones slightly worse. Context windows filled up with irrelevant information. The agent became a generalist that was mediocre at everything.

This shouldn't surprise us. We don't run organizations that way either. No company puts a single person in charge of accounting, legal, HR, engineering, and customer support and expects excellence across all of them. We specialize. We create teams. We build organizational structures that let people go deep in their domain while coordinating across boundaries.

The same logic applies to agents. If knowledge is distributed across a network, an architecture that tries to collapse it into a single node will always hit a ceiling. Not because the model isn't smart enough, but because the architecture contradicts how knowledge actually functions.

Agents as Organizational Structure

Once you accept that a single agent won't scale, the question becomes: what should the architecture look like instead?

Brex's answer was to mirror their own organization. Instead of one agent that knows everything, they built specialized agents with deep domain knowledge, each one mapped to a function that already existed in the company. An expense agent that understood expense policies the way the finance team does. A travel agent that knew booking rules the way the travel operations team does. A compliance agent with the same depth as the compliance department.

These agents communicate through an orchestrator, a routing layer that understands which agent should handle which request, much like how a well-run organization routes questions to the right team. When a request spans multiple domains, agents collaborate, each contributing their specialized knowledge to a combined answer.

This pattern generalizes beyond Brex. Your agent network should mirror your organizational knowledge graph. Not because it's a neat metaphor, but because your organization already represents a tested solution to the problem of distributing and coordinating knowledge. The teams exist for a reason. The boundaries between them encode real differences in expertise, context, and decision-making authority.

Three practical layers emerge from this:

Human teams remain the source of domain expertise. They define what their agents should know, how they should behave, and what guardrails matter. Domain teams own their agents the same way they own their processes today.

Agents operate as specialized knowledge workers within those team boundaries. Each agent has deep context in its domain, clear authorization and permissions (a first-class design problem, not an afterthought), and visible reasoning that humans can inspect and correct.

Infrastructure provides the shared substrate: orchestration, routing, logging, feedback loops, and test cases that serve as executable organizational memory. When someone discovers that the expense agent handles a particular edge case wrong, the fix becomes a test case that prevents regression. Over time, these test cases encode the organization's accumulated learning about how agents should behave.

Feedback cycles matter as much as the initial architecture. Build them into the product from the start. Make reasoning visible so people can understand why an agent made a decision. Give teams the tools to evaluate and correct their agents continuously. The architecture isn't something you design once and deploy. It's something you tend.

An Evolution in Three Phases

In article 1, we introduced an automation framework. Moving from level 2 (AI assists humans) to level 3 (AI acts with human oversight) won't happen in one leap. It happens in three phases, and understanding which phase you're in determines what to build next.

Phase 1: Embedded agents. Each team develops its own agent through direct experience. A finance team works alongside a finance agent, correcting it, teaching it edge cases, building the test suite that captures institutional knowledge. This is human-machine cooperation at the team level. The agents are useful, but they're isolated. The finance agent doesn't know the compliance agent exists.

Most organizations are in this phase now, or should be. The work feels unglamorous: prompt engineering, testing, correcting errors, building evaluation frameworks. But this is where agents develop real domain depth. Skip this phase and you get agents that are superficially capable but brittle when they encounter the messy reality of actual business operations.

Phase 2: Agent networks. Agents remain team-embedded, but they gain knowledge about each other and cooperate across the organization. The expense agent can consult the compliance agent before approving an unusual request. The travel agent can check with the budget agent before booking. The network becomes more than the sum of its parts.

This is where organizational value compounds. Problems that previously required a human to coordinate across three departments can now be handled by agents collaborating in seconds. But it only works if Phase 1 built agents with genuine depth. A network of shallow generalists produces shallow answers quickly, which is worse than producing them slowly, because speed creates confidence that the answers don't deserve.

Phase 3: Agents that learn from experience. In this phase, agents don't just execute based on their training and test cases. They identify patterns, surface anomalies, and suggest process improvements. The human role moves from active cooperation to strategic oversight: setting goals, evaluating outcomes, and making judgment calls that require values and context that agents don't have.

How Phase 3 actually plays out is uncertain. Anyone who tells you otherwise is selling something. But leaders who built strong foundations in Phase 1 and 2, deep domain agents, robust evaluation frameworks, clear authorization models, visible reasoning, will be better positioned regardless of how the technology develops.

Cultural Implications

This evolution demands new roles and new skills. The people who operate agents today won't be doing the same work in two years. Execution tasks gradually move to agents. Human work gravitates toward designing agent behavior, evaluating agent output, teaching agents through feedback, and making the judgment calls that require experience and values.

Brex formalized this with AI fluency levels across their organization, a recognition that working effectively with agents is a skill that can be developed and measured. This isn't an IT project. It's a leadership priority. The organizations that treat it as a technology deployment will end up with expensive tools that underperform. The ones that treat it as an organizational evolution will build systems that compound.

Networks that Learn

Nobody has the perfect architecture yet. What works today will probably look different a year from now. The specific tools, orchestration patterns, and agent frameworks are all evolving rapidly.

But the underlying principle won't change: your agent architecture is an expression of how your organization handles knowledge.

Agents don't just need organizational knowledge to achieve tasks. They need it to learn alongside humans. When a finance team corrects their agent's handling of an edge case, that correction becomes a test case. When the test case catches a similar error three months later, the organization has learned something durable. When agent networks share these corrections across team boundaries, the learning compounds across the organization.

This is why mirroring your organizational structure matters. Not because it's the most technically elegant approach, but because it puts humans where learning happens: at the boundary between what agents can handle and what still requires judgment, experience, and context that hasn't been encoded yet.

Build your agent network that way. Mirror your teams. Distribute expertise. Keep humans at the points where knowledge is still being created. The system compounds over time. Not because you got the architecture right on day one, but because you built something that learns.