MCP Leaves the Demo: What DwyerOmega's Akeneo Setup Shows About Governing Agents in Product Data

MCP has left the demo stage. A manufacturer now runs AI-assisted workflows on top of its PIM every day, and that turns a question that used to be theoretical into a design decision: what may an agent read from your product data, what may it write back, and which system enforces the answer. Akeneo's two-part case on DwyerOmega shows what the production setup looks like, and a Crystallize post published the day before shows how to draw the boundary. Read together, they describe the same pattern from two sides: agents get broad read access early, while writes stay behind people and system rules.

What DwyerOmega built on Akeneo MCP

DwyerOmega is an industrial and technical manufacturer with complex products, multilingual content, frequent acquisitions and, for one model, an estimated 100,000 to 200,000 possible permutations. Part 1 of Akeneo's case starts with a pipeline problem. Cyrus Grimes, Director of Product Content Management, had been pulling enrichment data from Akeneo through API connections into Microsoft Fabric to build Power BI dashboards, because not everybody wanted to open the PIM. The extraction was not stable in Fabric, and full loads grew heavier once content went multilingual. Using Akeneo MCP with Codex inside Fabric, he rebuilt the pipeline around delta updates. It runs every morning, and a full export across all languages completes in about 2.5 to 3 hours without hitting concurrency limits.

Part 2, published on 4 November 2026 and written by Samira McDonald, covers what runs on top of that foundation. Power BI dashboards show product managers and marketers where products miss their targets for images, 360-degree spins, alt text, descriptions, CAD files, cross-sell assignments and SEO metadata, filtered by product manager or model and exportable as a work list. An AI-assisted workflow built in Claude locates manuals and specification sheets from the Akeneo records, extracts their technical content with local OCR and a local language model, and builds capability-led descriptions that product managers review before loading them back into Akeneo. Grimes reports that keeping the useful parts of the old copy has helped hold organic search traffic stable and growing.

The acquisition workflow is the one Grimes rates highest. A web scrape of an acquired company's product series loads assets into SharePoint, mirrors images to AWS, creates the asset in Akeneo with the URL filled in, and builds the product series with a placeholder variant. Each series takes about 40 minutes, and the team had loaded 82 of them within a couple of weeks. Technical or expensive products land in a sales-assisted product family where the call to action is contacting a salesperson, so the information is published before every commerce decision is made.

Where the writes stop

The case is as instructive for what DwyerOmega keeps away from the agents as for what it automates. The Power BI dashboard is read-only by design. Asked whether edits there push back into the PIM, Grimes answers: "No, this is just a report." Changes still happen in Akeneo or through coordinated loading documents handled by trained PIM users. The AI descriptions go through product manager review before they are loaded. Two ideas still in early exploration follow the same line: a "policing" view comparing records across the source system, SAP Commerce Cloud and Akeneo, and a workflow that reads data issues reported in a team chat channel, checks Akeneo and proposes corrections through MCP with human approval retained. Akeneo sums up the operating model as automating repeatable discovery and preparation while people stay in control of consequential updates.

That boundary is a choice DwyerOmega made, and the protocol does not make it for you. Our Trends in PIM piece on AI governance and enrichment agents quotes Akeneo's own documentation on this: anyone with access to the MCP connection can perform the actions the underlying API key allows, including write and edit if enabled. Whoever configures that key sets the agent's real authority.

Crystallize: guardrails outside the prompt

Nebojsa Radakovic, Marketing Director at Crystallize, makes the general argument in AI Agent Governance: Govern What Agents Can Do, Not Just What They Can Say, published on 3 November 2026. His starting point is that an agent is software with delegated capabilities, so governance covers identity, permissions, data, tools, approvals, action limits, logging and revocation. The rule he proposes is simple: "The more consequential the action, the stronger the control should be." Proposing a product description, publishing it, changing a price and issuing a refund sit on different rungs of a ladder, and read-only "should often be the first production stage, not an embarrassing limitation to remove as quickly as possible."

The core of the post is where the limit lives. "'Never change prices by more than 10%' is useful context. It is not, however, a security boundary." If a change would create serious risk, the commerce system should reject it whatever the agent was told. Crystallize applies this to its own MCP implementation, where agents can discover schemas and query commerce information while writes need explicit enablement and permissions, and to its internal engineering agent, whose code changes land as draft pull requests that humans approve. On MCP itself the post is blunt: "A standardized connection is not the same as a controlled connection." The protocol makes tools easier to find and use, and the business rules still sit in the systems behind them.

The post cites an October 2026 IBM survey of more than 3,200 senior executives in Europe and the Middle East: 75% expected AI agents to have some decision autonomy by 2027, while 37% said their governance was designed to scale with agentic AI.

Product data sits on the boundary

Crystallize adds a second point that matters most for PIM teams. An agent can follow every access rule and still give a wrong answer if it works from yesterday's availability or an outdated price. Governance therefore has to cover the context agents use: "which system owns a fact, how fresh that information is, whether variants have stable identities, whether fields have explicit meanings, and whether downstream representations can be traced back to their source."

DwyerOmega's setup shows what that looks like in practice. Akeneo stays the governed source, the Fabric pipeline refreshes daily through deltas, and the planned policing view targets exactly the synchronization gaps between SAP Commerce Cloud and the PIM that would feed an agent stale facts. Part 1 also mentions that DwyerOmega is looking at making Akeneo the governed source for AI agents that need accurate product context. The quality dashboards that serve product managers today are the same checks that decide whether an agent can trust a record tomorrow. Our guides to product data quality and governance and AI-ready product data for agentic commerce cover the attribute, identity and ownership work this depends on.

What the two posts add up to

Both posts are vendor content: Akeneo describes a customer on its own MCP server, and Crystallize positions its own commerce MCP and structured data model. Taken together they still describe a consistent picture. MCP lowers the cost of connecting agents and everyday tools to the PIM, as DwyerOmega's rebuilt pipeline and 40-minute onboarding show. The authority those agents carry is set elsewhere, in API keys, roles, review steps and validation rules in the PIM and the commerce platform. A practical way to describe any MCP project is to list what each agent reads, what it may change, which of those changes need approval, and how a change can be traced and reversed. DwyerOmega's answer today is wide reads, prepared writes and human loading, which matches the first rungs of Crystallize's ladder. Our article on what AI inside a PIM actually does and where it breaks covers the staged rollout behind that approach, and the Akeneo and Crystallize profiles describe both platforms.