The Work That Has No Name

When organizations try to delegate operational work to agents, they tend to focus on model capability. Can it reason well enough? Handle ambiguity? Act reliably at scale? Fair questions, all of them. But underneath sits a quieter one: has the work ever been described precisely enough to hand off?

Delegation requires boundaries, boundaries require naming, and naming requires a degree of formalization that most operational work has simply never needed, because humans never needed it.

The IEEE Task Force on Process Mining established a useful threshold in its 2012 Manifesto: process mining begins when work can be represented as events, where each event refers to a named activity and relates to a particular case. This is the floor of legibility. Below it, work happens but can't be systematically observed, compared, or handed off. That sounds like a low bar, but it catches more work than you'd expect.

Consider procurement. A purchase order in SAP looks like a clean unit of work until you try to define what "a case" actually is. The BPI Challenge 2019 dataset, drawn from a multinational's purchasing activity, shows a single rent line item generating twelve goods-receipt messages and twelve cleared invoices. A logistics line item can produce hundreds. The same underlying data becomes different "work" depending on whether you track by order, by item, by delivery, or by payment. Researchers studying SAP event-log extraction found that choosing a case notion requires extensive domain-expert interaction, because the system doesn't encode what the meaningful unit of work is. The procurement specialist just knows which line items are recurring rent and which are one-time logistics. She carries that knowledge. She has never needed to formalize it, because no one was asking her to hand it off to something that couldn't absorb context by sitting next to her for six months.

The same pattern shows up in insurance claims. When researchers applied log-only process discovery to a Dutch agency's claim-handling data, the resulting model allowed activities to occur before "Receive Claim." Structurally implausible. The knowledge that made the process coherent lived in people's heads, not in the event log. That was fine when people were the ones doing the work.

Agents don't carry anything. They need the work named, bounded, sequenced. As Dirk Fahland observed in his research on event-log extraction, turning raw operational data into a usable log is itself "an act of modeling." Someone has to decide what counts as an activity, what constitutes a case, which features of the data describe which behavior of which entity. When humans were the audience, that modeling could stay informal, absorbed through proximity and experience. Agents need it made explicit.

The delegation target creates the demand for formalization. Most operational knowledge lives below the naming floor: in habit, local memory, informal convention, contextual judgment absorbed over years. Real knowledge, but never articulated. And naming work precisely enough to hand it off turns out to be its own kind of hard, with its own costs and distortions, regardless of how smart the model on the other end becomes.