In the evolving landscape of enterprise data, few voices have navigated the changing tides as clearly as Eric Broda. As the author of Implementing Data Mesh and a forthcoming book on the Agentic Mesh (expected March 2026), Eric’s vast experience bridges the real-world constraints of infrastructure with the emerging potential of agentic systems. As we all continue to grapple with scale, governance, and autonomy, Eric’s dual focus on the sociotechnical roots of data mesh and the forward momentum of agent driven systems offers a timely guide. Here’s a glimpse into his thoughts in the context of the rising tide in tech that’s about to keep growing in years to come. Revolution in the making? Yes… …but let’s start with ‘other meshes,’ that can lay the foundation for the major leap, i.e. the Data Mesh. Why? Because before organizations can dream of agents acting autonomously on their behalf, they must first reckon with something more fundamental: how they work with data today. And that journey begins with the sociotechnical shift that Data Mesh demands.
Eric’s framing is clear: as companies try to balance scale, governance, and autonomy, they often misjudge where the real friction lies. This isn’t a story of silver-bullet tech stacks, it’s about making organizational change stick, and knowing what “autonomy” actually demands beneath the surface.
“Data Mesh is 90% organizational, 10% technical,” Eric says & it’s not just a catchy line, it’s a diagnostic. Many teams kick off data mesh programs as if they were microservices migrations. But when cultural dynamics are ignored, technical solutions can only go so far. Surely you’ve heard stories of data mesh deep-dives resulting in just a handful of real use cases two years down the road.
Initiatives often start from within tech departments alone. While some tech leaders understand organizational dynamics, most aren’t positioned to drive lasting change across departments. This often leaves data mesh efforts fragile, built on technical foundations, but politically unmoored. Thus, initial ‘brain grinding’ with business is a must-have. And, as much as we all know it, do we really do it without the fear of jeopardizing our projects’ kick offs?
What we really dig is Eric's subtle finding that there’s an inherent, albeit subtle, tension at the core of provisioning in a mesh architecture: the contrast between platform teams and data product teams.
Platform teams typically operate as cost centres, focused on efficiency and standardization. They manage shared resources, enforce policies, and offer infrastructure as a service – favouring optimization and predictability. In contrast, data product teams function more like business units: outcome-driven, agile, and aligned to specific value streams. They are incentivized to move quickly, experiment, and deliver measurable impact.
This juxtaposition creates friction, especially around autonomy. Data product teams crave control over their tooling and infrastructure to move fast. But platform teams must maintain guardrails and economies of scale. The sweet spot lies in a carefully negotiated balance, one where platforms provide composable services, and product teams can innovate without reinventing foundations. Where this balance is struck well, organizations see not only faster delivery but also clearer accountability and better funding alignment.
A litmus test of the friction energy coming into play appears during infrastructure provisioning. At a glance, it looks like a tooling challenge – Terraform, Crossplane, or some internal platform. But Eric’s take points to a deeper issue: behaviour. Teams want autonomy, but central platforms still control critical resources.
Provisioning isn’t just infrastructure. It’s a proxy for trust. Eric frames the healthy version as a service model, platforms provide APIs and templates, not roadblocks. But where provisioning becomes a ticket queue, the mesh loses agility and collapses into a slower, more fragmented monolith.
As cliché as it sounds in the context of data mesh, for Eric, data is not a pipeline, it’s a product. That shift isn’t about semantics, it’s about how teams operate. A real data product has a roadmap, an owner, a lifecycle, and users. But most data efforts are structured like projects, i.e. temporary, fragmented, loosely owned.
Teams that make the leap don’t look like traditional IT squads. They’re cross-functional ecosystems. A core product team owns delivery, value, and success. Supporting them are platform teams (aka infra as service), enabling groups (governance, training), and specialist floaters (mainframe, legacy). This structure isn’t accidental, it’s foundational for what comes next…
With agents, autonomy gains new teeth. Instead of dashboards and APIs that wait for action, smart data products act independently. They synthesize, notify, and in some cases, decide. That reframes the role of a data product owner. From steward to orchestrator. From managing outputs to managing behaviours, both human and machine.
It’s not just a technical jump. It’s a governance shift.
And here, data contracts reemerge not as technical schemas but as business-first artifacts. Eric likens them to real-world contracts: service levels, quality thresholds, accountability. They’re not checklists, they’re enforceable commitments. And they underpin trust.
As of mid-2025, agents are no longer theoretical. They're quietly emerging, particularly in sectors like finance, risk, and operations. Eric describes seeing small fleets of lightweight agents deployed in narrow but meaningful workflows. Elsewhere, the concept of “agent-firms” is beginning to take shape: business units managed not by teams, but by a few people overseeing dozens of automated agents performing discrete, interdependent tasks.
These aren’t science fiction scenarios. They're real-world experiments – and someone has to go first.
Still, Eric is clear: nothing scales without trust. In highly regulated environments, that trust must be earned. “Until agents can be certified – secure, explainable, traceable – they’ll remain proof-of-concept,” he says. The roadmap toward enterprise adoption looks more like product safety certification than sandbox demos. Think ISO standards for software agents (SOC will adhere 😉).
And what would an actual enterprise-ready agentic mesh look like? Eric outlines a concrete reference model:
Crucially, this isn’t just conceptual. Eric’s team is actively building this stack, and plan releasing it open source.
But, what qualifies an agent as enterprise-ready? Eric doesn’t mince words. “If it wouldn’t survive an audit, it shouldn’t run in prod.” Discoverability, observability, explainability, and zero-trust security aren’t optional. They’re the price of admission.
He also expresses concern over the current state of coordination. Tools like LangChain, LangGraph, and Autogen help spark innovation, but they don’t yet meet enterprise rigor. Especially when it comes to inter-agent communication.
“Agents shouldn’t just talk,” and we can’t agree more. Coordination needs structure, message buses, shared state, delegated goals. Without that, it’s just entropy with good intentions.
Surely a statement that echoes the growing tension between experimentation and production-readiness across the entire AI tooling landscape.
So what qualifies an agent as enterprise-ready? Discoverable. Observable. Secure. Stateful. Explainable. If it wouldn’t pass an audit, it doesn’t belong to prod. Current frameworks like LangChain and LangGraph? Useful, but as of today seem not mature enough for most enterprise demands.
Lastly, Eric pushes back on naive autonomy. Agents shouldn’t “just talk.” Coordination needs design, message buses, goal-delegation, and managed state. Otherwise, you get entropy, not intelligence. Speaks volumes of the current breeding ground for startups the AI space has come to be.
As for the emerging archetypes, here’s the list:
The real breakthrough comes when these interact, intelligently, with purpose.
And while Infra as Code remains vital, Eric foresees a new model: Agents-as-Code (AaC). A low-code way to design, run, and even spawn new agents.
Agents managing infra? It’s already in pilot. Provisioning, scaling, even mitigation workflows. All agent-driven. Those of us still having flashbacks from C++ textbooks are still digesting it.
Eric doesn’t deal in hype cycles, but he does see a timeline forming. Right now, most companies are still dabbling with AI assistants, tethered to user interfaces, reactive rather than autonomous. In the next 9–15 months, he expects to see a wave of untethered agents. Simple, standalone systems running in distributed environments with early forms of task planning and goal pursuit.
By late 2026 or early 2027, he roughly predicts that “agent fleets” will become the norm within forward-leaning organizations. These fleets, 10 to 50 agents coordinated around shared goals, will be run by small human teams focused more on governance and orchestration than execution.
The long view? Some firms are already prototyping agent-native operating models, where autonomous systems act as the operational layer and humans take the role of designers, ethicists, and overseers. In this context, the Agentic Mesh becomes more than architecture: it’s a management model.
But even in this future-facing vision, Eric grounds it in design discipline: agents must be certifiable, safe, and recoverable.
And as we wrap up, we’re left with a sharper vision of how to prepare for what’s next - anchored by one sentence that every agentic project should etch above its doorway: “Autonomy without guardrails isn’t innovation, it’s operational risk.”