Opportunities in the Dawn of Conversational Infrastructure

Conversational protocols like MCP and A2A are gaining traction as standardized ways to extend agent context & capabilities (MCP) and enable agent-to-agent collaboration (A2A).

As this becomes the new standard, one question becomes critical:

What software should we build as agents will become evermore capable and conversation will be the primary interface for customers?

I believe that just as today's apps are Custom UIs which consume APIs via HTTP Methods, tomorrow's apps will be built on JSON-RPC based protocols and accessed through conversational interfaces.

JSON-RPC caters to LLMs which naturally think in terms of actions: "send email," "get weather," "calculate total." This aligns with JSON-RPC's function-based model (sendEmail(), getWeather()). JSON-RPC is also easier to implement since all requests are received by a single endpoint, and the function calls are simply JSON objects which are naturally generated by LLMs and easily parsed by JSON-RPC clients. All these advantages make JSON-RPC an organic choice over REST APIs with multiple resource-oriented endpoints (GET /users, POST /emails).

So in this new paradigm there are several types of software to build.

Let's start with the most visible: the conversational interface itself. There are multiple angles to approach this but the first level is the LLM itself, either offering the best, fastest, cheapest or the best selection of models. The second level is defining the audience your trying to cater to this also defines the range of real world problems that can be solved on your platform (either you go niche or go broad). The third level is infrastructure: what you provide to agents. This includes supporting standard protocols like MCP and A2A, but also how you handle the hard problems like managing large tool sets, context windows, and security. Most importantly, it's what you do beyond the standard: custom tools, sandbox environments for iteration, and specialized capabilities that expand what agents can actually accomplish. The fourth level is the UI (probably most important for user adoption), my hypothesis is that this will go into a direction of MCP UI where custom UIs are returned by tools and not just the data, humans love visualizations, but also how you handle user input will change it will probably shift from form fields to natural language even voice but threre are also opportunities in specialized input UIs like workflow builders or task lists, also how much personalization (visual but also logical like memory) you allow will be important.

Okay now that we have the interface out of the way lets talk about other types of products.

Let's start with platforms a type of product which we've seen in all eras of software development other than the consuming interface there will be a need for democratization of MCP server creation similar to how Zapier allows users to hand pick integrations and combine them into a MCP server. But also how Langdock enables non-technical users to create agents by combining tools and prompts giving them the ability to craft their own agents.

If we're going towards a future where data is consumed altered by agents an obvious opportunity is to build really niche domain specific MCP servers and agents preferably with proprietary data which is not publicly assessable / in model trainings sets to prevent abuse and ensure the agents are able to perform the tasks they are intended to perform lots of exsiting SaaS products now offer MCP servers to keep user interaction with their products.

The maintainers of these MCP servers & Agents will need to monetize their services, this is where the payment layer comes in. Level one here is how APIs are already doing this with API keys and usage based pricing. Beyond this there are in protocol level solutions to enable payments via Servers or Agents like AP2 Protocol which allow agents to pay for services on behalf of the user. Level three is a `convenient a payment layer for agent / mcp server usage and via agent spending think a deposit account for agents to get paid for their work or spend money on their users behalf.

Finally, there is the need for abuse protection for agents and MCP servers. Similar to how Cloudflare protects websites from bots, conversational protocols will need to identify spam or unfair use and prevent abuse, while services used by agents will need to be protected from agentic attacks.

With the innovation opportunities in the realm of CRUD apps comming to a close, LLMs supply us with new angles to solve problems, and lots of opportunities to build and innovate for and with agents.