Multi Agent System - Hammer or Nail Gun

SaaS is rapidly shifting to incorporate agents in its offerings. And in many scenarios, it’s not just a single agent that can solve the use case. That’s where the magic of multi-agent orchestration comes into play.

Think about your recent applications. For example, imagine a building construction project. You typically connect with an architect, contractor, plumber, and electrician (let’s keep it simple with just these for now). Now, think of each of these professionals as an “agent.” Each has their own system of work, with dedicated operations, set of tools and thought processes. But when they come together and coordinate, they create the final product.

Connecting them in a way where each of their tasks can be executed sequentially or in parallel—where they can call on each other when necessary to complete their part of the work on time—is exactly where multi-agent systems and orchestration shine.

I’ve personally tested implementations using LangChain and Pydantic. I’ve found Pydantic’s approach, especially with Pydantic-AI and its multi-agent systems, to be incredibly smooth and fluid in implementation. This article is focused on the extract from pydantic which says-

I particularly liked this statement from Pydantic:

Nail guns don't make you a better builder, they make you a builder with a nail gun.

Here, don’t get confused between the example of construction we discussed earlier and the metaphor of hammers and nail guns. The point is about understanding when to choose simple tools and when complex orchestration is needed.

Why Call It Hammer and Nail Gun?

The metaphor highlights the difference between simplicity and complexity.

• A hammer represents simple, straightforward agents or workflows—easy to set up and operate.
• A nail gun represents complex and high-performance systems—they can get the job done faster but require more setup, maintenance, and can go wrong if not used correctly.

In the context of multi-agent systems, this metaphor reminds us that choosing the right tool (simple agents vs. orchestrated multi-agents) is critical. It’s not about using the flashiest tool, but the one best suited for the problem.

Available Techniques

Let's look at these different available techniques and when to use what

Agent Delegation

"Agent delegation" refers to the scenario where an agent delegates work to another agent, then takes back control when the delegate agent (the agent called from within a tool) finishes.

Following is the mermaid flow chart of our example in case of agent delegation :

This is a sledgehammer implementation, where each agent is specialized in its work, and the initiating agent calls the other agents and manages the flow with centralized control.

Programmatic agent hand-off

"Programmatic agent hand-off" refers to the scenario where multiple agents are called in succession, with application code and/or a human in the loop responsible for deciding which agent to call next.

Here a program or an app controls the navigation to agents wherever applicable. In scenarios where there is an assistant and you need inputs and these derivation of inputs will decide the execution of agents, that's where you use this another hammer technique.

Graph based control flows

Graphs and finite state machines (FSMs) are a powerful abstraction to model, execute, control and visualize complex workflows. As the documentation says, it is designed for for advanced users and makes heavy use of Python generics and type hints.

Graph holds many techniques like :

1. GraphRunContext : This holds the state of the graph and dependencies and is passed to nodes when they're run.
2. END — return value to indicate the graph run should end.
3. Node - they are the execution nodes in graph. A run method is what defines the business logic. Node manages, dependent objects, state and control return types.

If we talk about our example, in a graph-based orchestration, the "contractor" doesn’t imperatively call agents one by one. The graph itself knows the dependencies: which agents depend on others, which data flows where.

Following flow denote our example -

If you’re thinking that the above representation is similar to a simple agent delegation approach, you’re right! That’s exactly what Pydantic is highlighting: a simple delegation approach may work perfectly fine, and you don’t necessarily need the ‘nail gun’—or complex orchestration—unless the situation truly demands it.

Since graph based approach is state-driven, it is ideal :

1. Complex workflows with multiple agents interacting in non-linear paths (e.g., branching, conditional logic, loops).
2. Dynamic dependencies between tasks
3. Low human involvement, as the graph handles decision-making.

Conclusion

The decision between a simple delegation (hammer) approach and a multi-agent orchestration (nail gun) depends on the complexity and needs of your system. Simple, programmatic hand-offs between agents can effectively solve many problems without unnecessary complexity. However, when workflows involve multiple interdependent agents that need coordinated action, a graph-based orchestration system becomes essential. The key takeaway is to use the right level of complexity for the problem at hand, ensuring your solution remains efficient, maintainable, and fit for purpose.

Reference : https://ai.pydantic.dev/graph/#stateful-graphs