The agentic platform defines what needs to be provided. Team Topologies defines who provides it, and how teams interact to make it happen. This second article applies Skelton and Pais’s model to a world where agents produce and humans orchestrate.

The agentic platform defines what needs to be provided. Team Topologies defines who provides it, and how teams interact to make it happen.

---

⚠️ This article is now obsolete and is replaced by a human-reviewed version here ⚠️

EDIT: Author’s Note & Hacker News Aftermath: This article was originally written for a French audience, and I used an AI ghostwriter to translate and adapt it for English readers. As the Hacker News community rightly pointed out, this resulted in a dense, “word-salad” reading experience. However, my main goal was to share a foundational idea to spark debate—and that debate absolutely happened. I am leaving this original text unedited to preserve the context of the HN discussion, but I want to thank the community for their candor. Below is a summary of the very real, open engineering questions raised by the readers.

---

In the first article of this series, we asked the what: which systemic capabilities (context, guardrails, tooling) are needed to produce reliable applications at scale. The answer was the agentic platform, and at its core, the agentic factory: the mechanism where agents plan, code, test, and ship.

But a platform does not build itself, and more importantly, it is not consumed the same way it is built. A fundamental question remains: who does what?

Generative AI has transformed how code is produced. In just a few months, we went from autocomplete to agents capable of writing, testing, and deploying entire applications. The market is now flooded with methods for framing these agents and making them produce quality code.

But this abundance raises a question few organizations are asking yet: what happens when you are not building one app, but fifty?

An out-of-the-box code agent only sees a repo and a shell. This article lays out three invariant principles for turning a gadget into a production tool.

How I built a multi-agent system in Go to generate Google Slides presentations from pre-formatted templates (not just to present, but to convince). A hands-on account illustrating the principles of the agentic mesh.

Convictions for designing tomorrow’s agentic systems — an agent mesh system capable of delivering value at scale, borrowing principles from the data mesh.

Note: this article has been translated by an AI; original is in French Introduction I have always been fascinated by AlphaGo, then AlphaZero, and this concept of reinforcement learning. A machine that plays against itself, learns on its own, and reaches superhuman levels. There is something magical there that goes beyond mere technical prowess. When in 2016, AlphaGo defeated Lee Sedol, one of the greatest Go players of all time, it wasn’t simply a technological victory.

Since its announcement a couple of months ago, the Model Context Protocol (MCP) has gained significant attention. Initially, MCP served as a straightforward mechanism, essentially a plugin system, to grant Large Language Models (LLMs) the ability to interact seamlessly with their environment, thus enhancing AI assistants and agents. Applying Wardley’s theory to trace the protocol’s evolution, I’d argue that MCP has progressed beyond Stage I (labeled genesis in the image), establishing a certainty of solution.

This article, the first in a three-part series, introduces the Model Context Protocol (MCP), a standard designed to enable AI agents to interact with diverse digital environments beyond simple chat windows. It defines key concepts like agents, environments, and autonomy, highlighting the need for agents to access digital tools via a structured communication protocol. MCP facilitates this by defining MCP Servers (tool providers), Hosts (applications running LLMs), and MCP Clients, enabling agents to utilize resources, tools, and prompts exposed by servers. The article argues that MCP is a key enabler of the next digital revolution, where AI assistants perform complex cognitive tasks, and it sets the stage for future articles that will delve into practical implementations using Google’s VertexAI and a custom cybersecurity server.

This article details my journey in building a custom chat host for AI agents, moving away from existing solutions to gain a deeper understanding of the underlying technologies. I implement a chat engine using Google’s Vertex AI and Go, focusing on compatibility with the OpenAI API to integrate with tools like Big-AGI. The article covers the core architecture, including my use of ChatSession and GenerativeModel from the Vertex AI SDK. It delves into the implementation of the /v1/chat/completions endpoint, highlighting the challenges of streaming responses and integrating function calls. I also describe a workaround for handling function calls in a streaming context and introduce the concept of a callable interface to prepare for implementing the Model Context Protocol (MCP) in future work. The goal is to move the tools outside of the agent. This will be detailes in the last part of this series.