The Next Evolution of Agents Will Come from Smarter Tools
TL;DR
- More tools can increase the main agent’s decision-making burden.
- I expect specialized tools to take responsibility for their own decisions and validation.
Introduction
What people building or using agents do most often these days is ask what else they can attach to the main agent. They add more Skills, install plugins, and connect MCP servers. The main context keeps getting heavier, while tools are carved into forms that are convenient for that context to call.
Viewed from one step back, this picture starts to look familiar: smart pipeline, dumb edge. The central pipeline owns all the intelligence, and the tools at the edges are assumed to be better when they are simpler. It resembles a shape we encountered once before during the SOA era.
1. SOA déjà vu: today is smart pipeline, dumb edge
It reminds me of the Enterprise Service Bus (ESB) that mediated communication between services in Service-Oriented Architecture (SOA). In that arrangement, the central bus handles routing, transformations, call sequencing, and protocol conversion, while the services at the edges remain simple.
In operation, complexity grows along with the responsibilities concentrated at the center. The center’s processing capacity and the cost of changing it can become bottlenecks for the whole system.
Another choice is to leave message delivery at the center and business decisions in the services that send and receive messages. Infrastructure such as Kafka can support this design. That is what I mean here by dumb pipeline, smart edge. Using Kafka does not automatically distribute responsibility; the team still has to decide which services own the business rules.
Looking at today’s agent ecosystem, it sometimes feels as if we have returned to the stage before learning that lesson. Every tool hangs from the ESB called the main agent.
2. The next stage is dumb pipeline, smart edge
As automation scales, I think an architecture in which the tools at the edges make more decisions will become advantageous.
If the main agent decides every call sequence and interprets every result across dozens of tools, adding tools also adds context for it to process. This resembles a central ESB taking on so much responsibility that it becomes a bottleneck.
If each tool is a vertical agent specialized in a particular workflow, it can take responsibility for that workflow’s decisions and validation. The main agent focuses on which tools to call and how to combine their results.
An analogy is a shift from being CPU-bound, waiting on computation, to being I/O-bound, waiting on external work. This is not a measured performance classification; it means the main agent performs less reasoning itself.
For this delegation to work, the tools at the edges need their own context and validation systems. If they ask the main agent to choose every next action, little of the decision-making burden has been distributed.
3. The same direction in physical AI
Looking at physical AI, which operates in the physical environment, led me to imagine a similar arrangement.
I think one reason humanoids attract attention is the relative ease of using human motion data and environments built for people. But a form that is useful for training is not necessarily the form I want in my home.
When I think about my own home, space is the first concern. My wife and I currently live in a compact 1.5-room apartment. Neither of us needs much, so it is not especially uncomfortable, but small is still small.
Whatever capabilities a humanoid might offer, adding one to this home would be a problem even before considering how to move around it. I think I would feel cramped just having it stand there.
If we keep appliances as they are, though, something still needs to open doors, move objects, and press buttons for us. I think that also helps explain the appeal of a humanoid that can operate many different appliances.
This picture is essentially smart pipeline, dumb edge: a humanoid at the center plus dumb appliances at the edges.
4. A smart-edge home looks different
Once every appliance in the home can be controlled through an API, the picture may look quite different.
If appliances handle their own work, the central robot has less to operate directly. I wonder whether a child-sized robot with arms that extend when needed could handle the remaining tasks.
Let us go one step further and imagine the appliances themselves becoming true smart edges.
- A kitchen appliance with robot arms and built-in recipes and cooking methods
- A washer-dryer with robot arms that identifies fabric automatically and handles washing, drying, and folding
- A refrigerator that tracks ingredients directly and automatically orders whatever is running low
Under this assumption, the home’s orchestrator moves laundry from the washer-dryer to the closet and food from the kitchen to the table. The appliances handle the detailed decisions involved in cooking and washing.
I think it is fine to choose to do some of the work myself at home. I am interested in removing recurring human intervention from business automation,1 but at home the goal is for me to live comfortably.
For my home, I would first consider a small robot paired with smart appliances. The space a human-sized robot occupies and the movement it obstructs every day matter as much as how many tasks it performs.
5. The place for SaaS companies: headless SaaS
In software too, if domain-specific tools make their own decisions, the value SaaS companies provide could change.
When users begin and finish work inside a SaaS product’s screens, its UI and workflow matter. If a main agent completes work by calling multiple SaaS products, each service needs to make its capabilities available outside those screens.
If the main agent combines multiple services, SaaS companies can concentrate on providing smart edges specialized in their domains. This is headless SaaS: the main agent calls capabilities without requiring the user to operate the screens directly.
Alongside coordinating tools, I am interested in specialized tools that complete and validate the work they are given. A service that handles a workflow’s rules and exceptions well could become a tool the main agent chooses repeatedly, much like the smart appliances imagined above.
6. From a developer’s perspective: domain knowledge and the Forward Deployed Engineer
As a developer, I am also interested in building a smart edge for my own domain.
When teams use the same models and similar orchestration tools, I think the difference will be which workflows they can delegate and how much of each workflow they can entrust to them. That is why the ability to translate domain rules and exceptions into code, tools, and validation matters.
I am also drawn to AI Deployment Engineer and Forward Deployed Engineer roles that solve problems in the customer’s environment. They connect models to customer data and workflows, turning them into tools that can finish the work.
Conclusion
Having distributed responsibilities away from the center when moving from SOA to Kafka, I am interested in specialized agent tools taking ownership of their own decisions and validation.
Real workflows will have to show at what scale this architecture is better. Still, alongside adding instructions to the main agent, I want to spend time turning workflows I understand into tools that can complete them on their own.