Existing industry processes are blueprints for AI workflows

A design pattern for local AI workflows, illustrated through a UDRP-inspired domain-risk pipeline

In 1913, at Highland Park, Ford’s engineers broke the assembly of a flywheel magneto into 29 one-man operations, each one simple, standardized, and repeatable. No single worker on that line could build a whole magneto anymore, but every worker could do his one step the same way every time. Assembly time fell from twenty minutes to thirteen; refinements to the line pushed it to about five.

A hundred and thirteen years later, everyone is asking how to design AI agent workflows. Our answer: the same way. Find the line. Cut it into stations. Fill each slot with the smallest part that does the job.

Find the line #

Every industry carries its own standard parts, processes hammered into shape long before AI arrived. In the domain name industry, one classic question is whether a registration improperly targets a trademark. For a defined class of such disputes, ICANN created a standardized process: the UDRP. Under it, a complainant must establish three conjunctive elements: confusingly similar to a trademark, no legitimate interests, bad faith. Fail one, and the case dies on the spot.

Read that as an engineer and you see an assembly line: ordered stations, a kill switch at each, only survivors move on. We did not draw the blueprint. The lawyers did, decades ago. We only fill the stations with parts.

Nothing on this line rules on infringement. The final call belongs to humans.

Put one on the line #

Hundreds of thousands of domains are registered or change hands every day. The production line proper starts earlier, in feeds and ETL, and runs longer: most of it is plumbing and rules. The judgment lives in two stations, and those are the ones we will walk. We are not talking about typos here, cl4ude dies cheaply in upstream rules, and the blatant copies need no discussion. We are talking about the ambiguous ones. Let us put one on the line: cloudebot.com.

>>> dksplit.split3("cloudebot")
[['cloud', 'ebot'], ['cloud', 'e', 'bot'], ['cloude', 'bot']]

Three ways to read one string. The judgment work begins here.

Station one: confusingly similar #

The splitter has done its work: every way to read the string is on the table. What it cannot tell you is which reading matters. A domain name is compressed meaning, someone stood in front of an infinite namespace and chose exactly these characters, and one of those three readings sits close to a name that is not theirs. Seeing that is a judgment.

That judgment is the first model’s slot. And the question is closed, not open: never “who might this resemble?” but “does any reading of this string lead to this one brand?”, the same shape as a UDRP case, which always starts from a complainant holding a specific mark. A lookup table cannot answer even that: the resemblance lives in sound, segmentation, and meaning, not in exact spelling. A pretrained model can compare both sides along those dimensions. Training does not create the task from scratch; it sharpens and stabilizes the judgment.

And it is a simple task, simple enough to probe. We handed each reading, paired with the brand, to a bare Qwen3.5-9B, no fine-tuning, no examples, plus two clean controls, cloud bot and cloudbot, that carry no trace of the brand, and the unsplit string itself, and asked one question: how strongly does this string evoke this brand, 0 to 100?

Single probe, greedy decoding, thinking off, max_new=200. For the 95 it wrote: “uses a phonetic spelling of ‘Claude’ and adds ‘bot’, directly evoking the AI assistant’s name and function.”

One reading rises. The rest fall away. A bare 9B, zero-shot, separates the brand-evoking reading from the neutral ones, and gives a reason a reviewer can check. And a 9B is already small: it fits comfortably on a single modern GPU and is fast enough for this kind of narrow probe. This is a single probe, not a benchmark. But it shows that the required judgment can emerge zero-shot in a model this size, and makes the station worth benchmarking. An earlier pilot, across 25 public dispute records and four model configurations, pointed the same way at larger scale: the knowledge is there, the job-shaped workflow is not.

Station two: observable use signals #

Cloudebot leaves station one with a mark: put to certain uses, this name could carry real risk. It rolls into the second station with a question the first never needed to answer: the name is close, but is the faith bad?

Here cloudebot shows its two faces. If the page sells cloud-connected physical robots, the name has a legitimate story of its own, and the case begins to die, the way most cases should. If the page offers an AI automation bot, then this is one to take seriously. Evidence of bad faith often shows up in what a site does. And judging what a site does is far simpler than judging malice. Station two does not decide bad faith. It extracts one of its strongest observable signals: what the domain is actually being used for.

A domain shows what it is doing on its page. And distilling a page is extraction, not invention: the answer sits in the input, not in the weights. Early evidence from one domain-specific summarization task suggests that a fine-tuned small model can be sufficient for work of this shape, though that remains to be shown here. Strip the navigation, the boilerplate, the marketing gloss, and say in one line what this site actually offers. A hardware shop. An AI assistant. A parked page holding nothing. Yes, just like your eyes landing on the page. Once again, semantic understanding.

And that is the judgment core of the line. Rules kill the cheap tricks. One small model reads the name. Another reads the page. Whatever still looks serious lands, name readings and page distilled, in front of a human who makes the call. Cloudebot is on that desk now.

What a line of small models buys you #

Data stays home. From registration feed to final call, a domain’s data never leaves the building. Inference runs on our own racks. No external API tokens are billed, and marginal inference cost becomes predictable.

Engineering stays simple. One narrow task makes data requirements easier to define, experiments cheaper to run, and failures easier to isolate.

The line stays controllable. Do not hand one large model a complex job and hope. A monolithic generalist pipeline tends to collapse several judgments into one hard-to-diagnose pass. A staged line gives each judgment its own station: a defined input, a defined output, and a benchmark that tells us whether the part is good enough. The real unit of progress is not the model but the station.

And standard parts compose. A cascade of small models, each working on its own narrow slice, offers an alternative to one large generalist handling every slice at once. The larger possibility is not merely cheaper inference, but a new enterprise architecture: specialized models as standard parts, stations as measurable units, and lines that can be replicated across workflows. If that is where enterprise AI is heading, we are in 1913. The factories of the 1920s have not arrived.

Find your magneto #

Conjunctive kill workflows are everywhere: KYC first-pass screening, visa document pre-checks, patent formality review, underwriting knockout criteria. Every process built as “check each item; one failure ends it” is a magneto waiting for its line. Ford began with the magneto and extended the same production principle to moving chassis assembly within about six months. One working line can become the blueprint for many more.

On scope: the UDRP is our worked example because it is among the most representative and most frequently invoked standards in the domain industry. Cases outside its reach simply route to other frameworks, often on the same content signals. This pipeline borrows the three elements as a screening rubric, nothing more: no adjudication, no role in any dispute procedure, no legal effect. Borrowing a standard is not performing it. Every determination belongs to humans.

This work uses models from the Qwen3.5 and Qwen3.6 families, developed by the Qwen Team at Alibaba Cloud and released under the Apache 2.0 license.

The project grew out of our first EuroHPC allocation, during which we refined DKSplit and began exploring what domain names can reveal about registration intent. We are now beginning a new round of experiments under a EuroHPC Playground allocation (EHPC-AIF-2026PG01-689), with a revised direction: exploring the capability boundaries of models at different scales.

We thank EuroHPC JU once again for its support.

*We acknowledge the European High Performance Computing Joint Undertaking (EuroHPC JU) for awarding this project ( EHPC-AIF-2026PG01-689) access to the MareNostrum *5

supercomputer, hosted by

Barcelona Supercomputing Center.Co-funded by the European Union. Views and opinions expressed are those of the authors only and do not necessarily reflect those of the European Union or the European High Performance Computing Joint Undertaking.