Dead on arrival? Pitfalls of AI agent marketplaces
Photo by Charles Chen on Unsplash
Some ideas are evergreen. Once every so often innovations are proposed and implemented by businesses without realising that what they are actually doing is a variation over a mistake they did already in the past. In this post I share my view on agent marketplaces and needed enablers in the context of my past experiences.
Old new ideas
Stock market investors have a saying: history doesn’t repeat itself, but it often rhymes. The software business is no different; since we're exposed to the same ideas and concepts, true breakthroughs are rare. When they do occur, like with the adoption of LLMs, we tend to apply old patterns to new business or technological concepts.
Sometimes it works in our favor - for example, the reuse of OAuth for securing agent communication or applying event-driven architecture patterns to agent orchestration. On the flipside, mechanically applying past business ideas may seem good at first glance, but in reality, it may turn out to be a pitfall. We should be extremely careful when the stakes are high and there’s historical evidence that a similar solution or approach led to a dead end.
Agents and MCP
An agentic approach to solving problems is definitely not a new idea. It wasn’t new even nearly twenty years ago when I was writing my master’s thesis on coalition formation. Aside from theoretical work and the wishful speeches of futurists, a few breakthroughs have occurred that make these visions and ideas feel tangible. To name a few:
- The rapid advancement of LLM technology
- A significant increase in computational power
- Virtualization (commonly referred to as cloud infrastructure)
- Ongoing developments in robotics, including:
- AGVs and autonomous cars
- Humanoids
- Autonomous drones
I hope you get the point. Machines are no longer limited to writing poems in the Dark Speech or rendering images in Studio Ghibli style. With the ability to break down tasks into subtasks (LangGraph, CrewAI, AutoGen and other libraries), delegate, use APIs, and (soon) interact with the physical world, the possibilities are expanding exponentially.
MCP (Model Context Protocol) is an emerging standard that enables LLM agents to call external tools, APIs, and services dynamically; like giving them real-time access to digital capabilities.
The community quickly discovered that efficient agentic implementations require access to services. For that reason, the Model Context Protocol (MCP) was proposed by Anthropic to allow LLM-based systems to effectively use third-party software. The bold idea is that if agents can contextually discover and invoke services - like a LangChain agent querying a weather API on the fly - we may achieve no-code solutions capable of solving problems that once required skilled professionals.
Sounds straightforward and achievable? You’re right, but there’s a catch.
Marketplace of Agents (and Services)
The agentic approach has a feature that I personally love - an agent should be dedicated to solving just one thing.
The concept of "The One Thing" comes from the excellent book by Gary Keller, The ONE Thing: The Surprisingly Simple Truth About Extraordinary Results. I highly recommend it to startup founders and software architects - especially those overwhelmed by the complexity of their solutions. It’s a true eye-opener.
But this trait has an obvious downside - our reality is complex, and our problems are non-linear and span multiple domains. In practice, we need a team of agents to handle the complexity of the real world. But we don’t exactly know what these agents are... Wouldn’t it be lovely to choose them à la carte?
Here comes our good old friend - the marketplace! Why not build a marketplace of agents that users can pick and choose from? The user wouldn’t need to know in advance which services are required; in some cases, some agents could even choose to delegate to others. And the best part? The user would only pay for the actual services used.
Obviously, all the software folks quickly noticed that the picture is incomplete. Agents also need to use services - but as mentioned above, with MCP and a complementary marketplace for services, the options are endless. Let’s make a statement here - it’s just a detail, isn’t it?
Have we found the silver bullet?
Some larger organizations (and possibly startups too) envision the endless market opening up and see opportunities to build services that help achieve their goals. While I share some of that optimism, flashbacks from the past keep me from being overly enthusiastic.
When microservice architectures became popular, there was an idea of creating - you guessed it - a marketplace of services that developers could subscribe to and use on demand in a SaaS model. While the idea itself was strong and some companies (like commercetools) built successful businesses around it, others invested in the same or similar mechanisms and failed. Why? Let’s do a post-mortem.
The feasibility trap
Do you still remember my reading recommendation a few lines above? Many companies forgot the lesson from the book: know your strengths and focus on what you do best. With abundant resources (both financial and human) they began creating hundreds of microservices and exposing them in marketplaces. Everything followed a "you build it, you run it" model. On the surface, it looked like an excellent tactic, but on closer inspection, significant issues emerged:
- Teams used different technologies
- Services were tested in isolation
- End-to-end business scenarios were never validated
- The architecture enforced isolation, but even with virtualization technologies like Docker or Kubernetes, costs remained high:
- Teams duplicated efforts
- Teams ran similar or identical services independently
- Maintenance became a nightmare, especially for those who took it seriously
Even though building the services was feasible - and many companies proved they could - their very success became their downfall. Why? Because there was no real demand for the majority of those services.
From feasibility to value
The biggest lesson from the past is to follow the good old recipe for success: listen to your actual customers and deliver real value. Expecting that this time will be different is as naïve as it’s always been. Agents will solve people’s problems - your job is to support them with the skills you truly excel at. Feasibility rarely equals value, and I’d bet it always will be that way.