What UCP Print will need from the supply side
The work to give print its own vertical in Google's Universal Commerce Protocol is one of the more important things happening in our industry this year. Initiative Online Print, BVDM and Intergraf started it in May, and it has since been joined by CIP4, dpsuisse, VIGC, PRINTING United Alliance and the Ghent Workgroup and, more recently, APTech. The published plan puts a formal proposal to the UCP project in the final quarter of this year, with pilot implementations among IOP members to follow in early 2027.
We want UCP Print to succeed. We need to understand what has to be true behind a UCP Print order for it to be the right job. Much of that depends on what print businesses can actually produce and whether their systems can describe it reliably.
Why we're interested
For more than 10 years, I was CTO and COO at The Printed Group, the business behind Printed.com and PrintedDirect. Much of that time was spent on exactly the problem UCP Print is now taking on: making configurable print orderable online without the order going wrong somewhere between the website and the press.
The team I assembled at Gnaww have all been there. We learned that the hard rules of a print business rarely live in one place. Some sat in our configurator, some in the MIS, some in production software, and a surprising amount sat with the people who knew which combinations were technically possible but would cause trouble in finishing. Every time we exposed more of the business to software, partners or customers, we found more of that knowledge we hadn't written down.
That experience is part of why we started building Gnaww, and why we think the supply side will set the pace for agentic print. I wrote about print becoming machine-readable in August, and UCP Print brings the supply-side question into sharper focus.
What UCP Print is taking on
UCP was built around retail, where a product can usually be represented as a known item with a price, a stock state and a route through checkout. Print doesn't work like that, and the initiative's scope reflects it. The planned vertical covers dynamic product configuration with real-time pricing, upload and automated preflight of print files, soft proofing and approval, delivery times based on machine availability and finishing, and checkout logic for EU consumer law, with further extensions planned for sustainability data, compliance, variable data and B2B pricing.
That's a serious scope, and it's well placed. The Ghent Workgroup has spent years defining what a reliable print-ready PDF looks like, and CIP4's XJDF and PrintTalk already describe a great deal of print product intent and the business conversation between buyer and producer. The vertical isn't starting from nothing, and it shouldn't have to. We also agree with the initiative's point that a well-defined print vertical could act as a reference for other agent protocols, including OpenAI's ACP. Agents are going to reach print through more than one route, and the work of describing print properly will outlast any single protocol.
What a protocol can carry but can't create
A protocol defines the shape of a valid conversation. It can say that an order needs a size, a substrate, a quantity, a file and an approval. It can't decide what a buyer meant, and it can't make a producer's published capability true. Those two jobs sit at either end of the transaction, and both are hard. On the request side, imagine somebody tells an agent something like this.
I need 5,000 good quality flyers for a launch next month. Nothing too expensive, but I don't want them to feel cheap.
A print person can start a useful conversation from that, but it isn't a production-ready requirement. Is the size fixed? Is the stock a preference or a requirement? Single or double sided? Does the launch date create a hard delivery constraint? Would a nearby material be acceptable if it gave the same result for less? An agent needs enough print knowledge to know which of those answers change the production decision, and which can safely be left open. A well-formed UCP Print payload can still describe the wrong job if those questions were answered with convenient guesses.
On the supply side, the agent needs to know what a print business can genuinely produce, and that answer usually lives in several places at once. Some is in the ecommerce catalogue, some in the MIS, some in supplier data and machine documentation, and some in web-to-print or workflow software that encodes rules nobody else can see. Plenty still lives with experienced people. The systems print businesses already run hold most of this knowledge, and they should stay the source of truth for it. The difficulty is assembling it into something an agent can rely on without asking every producer to rebuild their catalogue first.
What Gnaww is
Gnaww works on both ends of that problem. On the request side, it takes ordinary language or partial structured information, keeps what is already known, identifies the uncertainty that would change the production decision, and asks about that rather than filling it in. If something can't be resolved yet, it stays visibly unresolved.
On the supply side, Gnaww builds producer capability from the sources a business already has, such as its website, catalogue files, price lists, machine lists, MIS exports or supplier APIs. It currently reads live catalogues from several print and fulfilment networks into a single capability model alongside directly onboarded producers. Doing that makes the vocabulary problem very concrete. A buyer's "premium 32-page brochure" might be a saddle-stitched booklet to one producer and a product ID with a set of option codes to another, and both descriptions are correct in their own system.
We've learned 2 useful things from this work that apply to any print vertical. First, not all capability information carries the same certainty, so it matters where a claim came from and whether the source really supports it. If a producer's own systems already establish a fact, there's little point asking someone to approve it again. Choosing what to share is a separate decision. A business may be happy to show that it can make a class of work while keeping machine settings, internal SKUs, supplier arrangements and negotiated prices private.
The second is that capability isn't commerce. A producer can be able to make a job and have no capacity for it this week. A material can be normally supported and currently out of stock. So Gnaww's matching, which we call SpecMatch, answers whether a requirement fits a producer's capability and explains why, while current price, availability, acceptance and the order itself come from the systems that own those facts. In a UCP Print world, that live commercial state is exactly what the transaction layer should carry.
Where that leaves the pieces
We see UCP Print handling the transaction, with Gnaww working at each end of it. It's the same job, described from 2 different starting points.
buyer / agent ------------- UCP Print ------------- print business
| configure, price, files, |
| approval, order |
| |
what was meant what it can really make
| |
'------------------ Gnaww helps both -----------------'
Gnaww doesn't need to own checkout, and it shouldn't introduce another external vocabulary for the industry to adopt. Internally it needs a precise model of print so that interpretation and matching are reliable, but externally the right approach is to map to the standards people already use, including UCP Print as it develops. Storefronts, web-to-print platforms, MIS and workflow systems remain where the business actually runs. The aim is to help the knowledge inside them reach an agent intact.
A UK view
The UK has one of the more mature online print markets in Europe, and British print is represented in Intergraf through the BPIF. Even so, UK online print businesses and the software providers that serve them could usefully take a more visible part in this work, because some of the details will play out differently here.
Checkout is one example. The vertical plans checkout logic aligned with EU consumer law, and the UK's consumer contract rules have sat outside EU law for several years now. Much of the substance is similar, including how personalised goods are treated, but a UK print business selling through an agent will need the vertical to handle jurisdiction explicitly rather than assume it. That's a small point in the scheme of things, and exactly the kind that's cheaper to settle before pilots than after.
What we'd like to contribute
We've spent years building and operating online print systems, from ecommerce and product configuration to artwork, prepress, production and the MIS connecting it all. We've seen orders that look fine at checkout but need changes when the artwork is checked or the job reaches the factory. We can bring that practical experience to UCP Print as the vertical develops.
As the vertical develops, we'd be keen to review how it handles product configuration, artwork and preflight, production constraints and the information moving between ecommerce and factory systems. We'd also like to compare it with Gnaww's work on interpreting requirements and producer capability, then share what we learn about any gaps or practical implementation problems. We'd welcome the chance to bring a UK online print perspective to the group.
What print businesses can do now
Whichever protocol eventually dominates, there's a question every producer can start on today. Could authorised software understand what you can really make without reverse-engineering your website?
Start with the production facts rather than the interface. Where do your real size limits, supported materials, conditional combinations and quantity-dependent rules live? Which finishing options depend on another choice? Which parts of your capability are commercially safe to expose and which need to stay private? If the answers are spread across the storefront, MIS, spreadsheets, supplier feeds and people's heads, making the website readable by an agent only solves a small part of the problem.
That production knowledge is worth structuring regardless of where it ends up, whether that's UCP Print, ACP, an MCP client, a procurement platform or something none of us has seen yet. If UCP Print gives agents a common way to buy print, the industry's job is to make sure the print on either side of that transaction is properly understood.