The Agentic Mesh: Cognitive Automation at Scale - Unladen swallow - Olivier Wulveryck
owulveryck's blog
Today, we see many initiatives around the agentic paradigm. Most revolve around systems built by AI giants (Anthropic, Google, OpenAI) and often boil down to pushing natural language directives to an off-the-shelf orchestrator. One specializes an integrated system like Claude Code through markdown files, skills, and tools. Frameworks like BMAD illustrate this approach well: they transform such a system into a mixed AI/human development team. It’s useful, it’s fast, it’s a good starting point.
But to truly unlock the full value of AI, agents will need to embed themselves in business processes . Their contribution goes beyond cognitive automation: it lies in the ability to make certain decisions that allow processes to gain in effectiveness, not just efficiency. And this can only be fully achieved when we have an ecosystem of agents that communicate with each other and collaborate with humans.
Not when agents do our work, but when we have properly equipped the information system so that agents do their work, and we, humans, do ours.
This article proposes an agent mesh system (the agentic mesh) capable of delivering value at scale. Many of its principles, if not all, are borrowed from the data mesh , a paradigm whose ideas were remarkable but which unfortunately did not achieve the success it deserved. In my view, this failure does not stem from the quality of its ideas or its design. Consequently, many can be recycled here (and that is what we will do).
Note. This article was co-written with an AI. I am the pilot: I declare the intentions, the ideas, and I review the entire document. The actual writing (the pen) was done by a robot. My goal is to share these ideas to open a discussion, not to write a technical masterpiece that becomes a stylistic reference. Moreover, at the end of the document, you will find a link to the markdown source to have your favorite AI read it and discuss the various concepts.
The agent, that fundamental building block of future information systems
Let us start by establishing some vocabulary, as the confusion between two closely related concepts is at the root of many architectural mistakes.
We define:
a tool as a deterministic function: same input, same output. It programmatically executes an operation via an API or a protocol like MCP. It is idempotent, predictable, testable.
an agent as a non-deterministic entity: it works and decides autonomously, based on an intention , depending on an execution context . Its result is statistical (it depends on the context at the time of the call).
The consequences of these definitions are significant:
the tool is merely an action support (it executes, it does not interpret);
the decision an agent makes from the same tools can vary depending on the context, the state of the world, and the intention entrusted to it.
For example: calling a weather API always returns the same data for an identical request — that’s a tool. Deciding whether to postpone a delivery based on the weather, the contractual deadline, the client priority, and available resources — that’s an agent decision.
The tool is deterministic. The agent is not: its result is statistical and depends on the execution context.
This distinction is not merely academic. It has direct consequences on governance, on SLOs, on ownership, and on how to test and trust a system. You don’t govern an agent the way you govern an API. The contract is not an input/output schema (it is an intention and a decision scope ).
The dominant paradigm: the agent as an off-the-shelf directive
Today, when a company integrates AI into its IS, the dominant reflex is not so much centralization as the use of off-the-shelf agentic systems (Claude Code equipped with frameworks like BMAD, Cursor with its rules, or platforms like n8n with AI nodes). In this paradigm, the agent execution layer is not separated: agents are seen as simple natural language directives applied to generic agents to specialize them.
This approach is appealing. It promises rapid implementation, without significant engineering investment. It is sufficient for prototypes, for one-off automations, for validating that a use case can be handled by AI.
However, it quickly reaches its limits when trying to move to production on complex use cases.
What the apparent simplicity conceals
An agent is not just a prompt. An agent that works in production is a software system that must handle:
controlled parallelism between sub-agents working simultaneously;
structured feedback loops between a reviewer and producers, with retry counters and issue filtering;
programmatically validated structured outputs between each step;
prompt caching shared between invocations to control costs;
typed shared mutable state protected against concurrent access;
fine-grained observability (tokens consumed per...