Print is becoming machine-readable. Now machines need to understand print.

Last Wednesday, Maddy Alcala published The Product Data Problem in Print On Demand, a fairly brutal list of the ways print product data stops being tidy once it meets real production. A couple of days later I was catching up on Eric Vessels' conversation with Bernd Zipper about Agentic Print on Morten Reitoft's Inkish.tv, where the customer looking for a printer may increasingly be software rather than a person.

The two discussions come at the problem from different directions, but they meet in much the same place. If software is going to find, compare and buy print, the products and production capabilities behind it have to be machine-readable in the first place.

That work is already happening. Initiative Online Print, BVDM and Intergraf started work on a print vertical for Google's Universal Commerce Protocol (UCP), with PRINTING United Alliance, Ghent Workgroup, CIP4 and others now involved. The aim is to deal with things ordinary retail protocols don't naturally understand, including configurable print products, file handling, preflight and approvals.

There are already individual print businesses making their own production services directly consumable by software. Printstudios, for example, exposes its textile catalogue, pricing, decoration methods, artwork upload, ordering and tracking through an API it explicitly makes discoverable to AI agents. PrintKit exposes its photo-print catalogue and variants as structured JSON, provides agent-readable documentation and can hand a configured order into checkout through an API.

The same problem is starting to show up in workflow discussions too. In DPS Magazine's Print, Personalized with AI, Piet DePauw at Enfocus describes an agentic workflow where agents can interpret customer requests, extract production intent, gather missing information, trigger preflight and route work through production. That gets much closer to the awkward part of the problem. Production intent isn't always sitting neatly in the customer's words, and the customer often doesn't know which information is missing in the first place.

The DPS piece also talks about QR codes and personalised URLs, or PURLs, as a way of connecting a physical item to a digital response and measuring what happens next. That overlaps with another part of what we've been building at Jawwws. Bytes works on exactly that boundary between offline and online. It turns a printed asset, a QR code or a link into a measurable signal, so a business can see what happens when someone moves from the physical item to a digital response, along with the campaign context around it. Gnaww's Recipe ID answers a different question: what physical manufacturing definition is this? The same printed thing can keep one manufacturing identity while being used with different measurable destinations, campaigns or customer contexts. Those two identities become useful together once print is expected to be both machine-understandable before production and measurable afterwards.

All of this is good progress. It also exposes the next problem fairly quickly.

The catalogue is only part of the job

From experience, a customer rarely arrives with a perfect print specification. Sometimes they don't even know what the product should be.

Say somebody runs a couple of coffee shops and asks for 3,000 loyalty cards, the kind that get an ink stamp each time a customer visits. A print person can start working with that straight away, but it isn't a complete production specification. What size are they? How long do they need to last? Is the card printed on one side or both? What surface will take the stamp reliably? Is there an existing brand colour that matters? Is the customer fixed on a particular material, or do they simply want something that feels decent and works?

A catalogue can tell an agent which products exist. It can describe sizes, materials, decoration methods, quantities and prices. None of that removes the need to work out what the customer actually means, which details matter and which questions still need answering.

An agent can read a catalogue perfectly and still not know what the customer needs.

Print product data has always been awkward

Maddy's article is a good description of why this gets difficult so quickly. She covers preview fidelity, print locations, product parity between suppliers, flat SKUs versus rules-driven configurable products, quantity breaks and inconsistent units. Those aren't edge cases. They're normal parts of integrating print businesses.

The same apparent product can be represented very differently by two producers. One supplier might expose a flat set of variants. Another might start with a product family and apply rules as choices are made. Quantity can change the production method, which can then change artwork requirements, turnaround and price. A finishing option can disappear because of page count, stock thickness or something else selected three steps earlier.

Even product identity is messy. Two producers may both sell something called a premium flyer without using the same stock, weight, coating, tolerances, quantity range or production process. Calling them both flyers is useful to a person browsing a website. It isn't enough information for software deciding whether one is a sensible substitute for the other.

The print industry has been dealing with this for years because integrations force the issue. Once two systems have to agree on what a product actually is, all the assumptions hidden behind the product name become visible.

The configurator hides a lot of intelligence

Online print has spent years making complicated products easier to buy, and rightly so. A good configurator stops customers needing to understand the factory before they can order a booklet, sign, garment or box.

Behind the interface, though, there can be a lot of conditional logic. Choose one stock and a finishing option becomes unavailable. Increase the quantity and a different production method becomes viable. Change the page count and the binding choices change. Select a different garment and the available decoration areas move with it.

People experience that as dropdowns, defaults, warnings and disabled options. If the rules only exist inside the configurator, an agent has to discover them by operating the interface or somebody has to expose them in a form software can consume directly. The second route is a much better basis for reliable commerce.

This is why the UCP Print work matters. A common way to describe configurable print and move a valid job through discovery, configuration and transaction would remove a lot of avoidable integration work. It also gives the industry a chance to influence a commerce protocol while the requirements are still being shaped.

The protocol still needs a sufficiently complete job to work with. Before an agent can compare producers, it has to understand the request well enough to know what it is comparing.

Reading the data and understanding the job are different jobs

There are several decisions between somebody saying what they want and a print order reaching production. The original request has to be interpreted. Missing production detail has to be completed or explicitly left unresolved. The resulting requirement has to be compared with real producer capability. Current price, availability, delivery and other commercial facts then have to be checked before the transaction can happen.

Those steps can share data, but they shouldn't be collapsed into one big AI decision. A language model may be useful when somebody describes a requirement in ordinary language, but that doesn't make the model a reliable source of substrate data, machine limits, current capacity or price. Equally, a perfect producer API can't decide whether a customer's vague preference is mandatory, flexible or simply something they said because it was the only option on the last website they used.

Print people make these distinctions all day without necessarily writing them down. They know when to ask another question, when a nearby stock is a sensible alternative, when a finishing choice changes the production route and when a customer requirement really is fixed. Turning more of that judgement into structured, explainable data is a much bigger job than making a catalogue available as JSON.

This is a large part of what we're working on with Gnaww

We've deliberately separated interpretation from production matching in Gnaww. A request can start in ordinary language, retain product intent that is already known, ask controlled questions where production detail is missing and become a structured print specification once enough has been confirmed. Only then does it make sense to move towards SpecMatch and compare the demand with producer capability.

Where semantic help is useful, it stays controlled. A suggested interpretation doesn't silently become a production fact, and the system can leave something unresolved when there isn't enough evidence to make the decision safely. Live price, availability and producer acceptance remain separate again because capability matching doesn't prove any of those things.

That separation has become more important as we've worked through real print examples. The easiest systems to build are the ones that pretend uncertainty doesn't exist. Print has a habit of finding that uncertainty later, usually when a job reaches somebody who actually has to make it.

Legacy systems will probably set the pace

Even if agents get much better at understanding what people ask for, producers still have to make their capability accessible. For many print businesses, that information doesn't live in one clean catalogue.

Some of it is in an MIS. Some is in web-to-print configuration. Some is in estimating rules, supplier catalogues, spreadsheets, machine specifications or workflow software. Quite a lot still lives with the people who know that a particular job can run on one device but is better routed somewhere else at a certain quantity, or that a technically valid stock creates a finishing problem nobody bothered to encode in the old system.

Putting an API in front of one of those systems is useful, but it doesn't make the whole production operation self-describing. The agent needs enough reliable information to understand capability and constraints, and the producer needs a way to keep that information current without creating another catalogue that slowly drifts away from reality.

The pace of Agentic Print will probably be set by manufacturers and their legacy systems as much as by the agents themselves. The technology to call an API is already the easy part in a lot of cases. Exposing decades of production knowledge in a form that other software can trust is harder.

Print as infrastructure

Bernd describes this as print becoming infrastructure, and I think he's right about the direction. If print is going to behave like infrastructure, the route from an initial requirement to something manufacturable has to work without relying on every buyer knowing the vocabulary of the factory.

Machine-readable catalogues, common protocols and better APIs are necessary pieces of that. The difficult work is carrying enough meaning through them to preserve the judgement print people apply every day: what the customer is actually trying to achieve, which parts of the specification are fixed, which can move, what a producer can really make and when another question or a human decision is still required.

If the industry gets that right, an agent can do more than find a printer and call an API. It can arrive with a job the printer can sensibly produce. The alternative is an agent that can discover the supplier, complete the transaction and still order the wrong thing.