Every company already has a map of work. Most can’t see it.

Introducing the Map of Work and UiPath Cartographer, so agents can act with the context, the guardrails, and the institutional knowledge that real work requires.

A month ago, I published a book with a bold thesis for the founder of an automation company. The hard part of enterprise AI is not the intelligence. It is the map.

Every organization runs on a description of how its work happens. Almost none of them have written it down. It lives in the head of the AP lead who knows which supplier's freight charges always run over and always get paid, the claims adjuster who knows which repeat addresses are actually fraud, and the ops manager who knows the approval step everyone bypasses on the last day of the quarter. When those people are on vacation, the company gets a little less capable. When they leave, it forgets.

And it forgets every day. Each time a reviewer approves something, rejects it, changes a recommendation, or escalates it, they produce judgment. Almost all of it is lost the moment the task closes.

For twenty years that was an inconvenience. Then we started handing work to AI.

The bright stranger

A modern model is brilliant. It is also a stranger in your building. It does not know what a payment approval means in your company, who is allowed to sign it, when to escalate, or what an auditor will ask for a year from now. It never learns on the job the way a new hire does. It shows up every morning gifted and new, with no memory of you.

Authority has to be earned by the work, never granted to the model. Without relevant context, the agent is a stranger guessing at your business, and granting the stranger authority is how enterprises manufacture incidents.

You can prompt a stranger. You cannot orient one. Not without a map.

What the Map of Work is

Most companies think they have this. They have process documents, Visio files, a BPMN model from a consulting engagement in 2019. Those are pictures of a business that no longer exists, drawn by people who no longer work there. A process document goes stale the moment it is printed.

The deeper problem: policy changes faster than workflow logic. When the rules live inside the code, every policy update becomes an engineering project, business objects hide inside payloads, and the reasoning behind a decision disappears with the task. That fragmentation is why processes are fragile and expensive to change, and why capable agents stall the moment they meet real work.

At FUSION in Las Vegas, I framed the answer in two halves: the map and the rails. The map describes the business an agent can act inside, what things mean here, which rules apply, who decides what, and how experienced people actually handle exceptions. The rails are the machinery that executes exactly what was approved, every time, and stops everything else. A gate is declared in the map and enforced by the rails.

A map without rails is a slide deck. Rails without a map are the automation of whatever somebody happened to build.

The Map of Work itself is not a product you buy from us. It is your organization's own account of how its work actually runs, in your vocabulary, drafted with our tools, and owned by you.

The build rule I gave in my book still holds. Buy the universal, invoices, suppliers, approvals, standard procure-to-pay primitives are commodities. Configure the domain, claims, KYC, prior authorization follow industry patterns a strong platform can carry. Own what is institutional: your approval matrix, your risk appetite, your escalation culture, your reason codes. A vendor can implement a rule. An agent can draft one. Only the institution can decide when it applies, who may override it, and what risk it will carry. Never outsource the meaning of your business.

A usable map carries three things, linked.

The planned roads

The planned roads are what the business has already decided: the entities it's built from, how work is supposed to move, and who has the authority to make each call. Structured Knowledge holds facts and permissions together, in one place, so neither floats free of the other. An invoice must match a purchase order and a goods receipt before payment settles. The approver is never the requester, and one approval belongs to treasury, while another belongs to her manager. All of it is written formally, on open standards, so a machine can verify it and an agent can be briefed on it, operating directly on your systems of record so the data never has to move to be trusted.

Facts without authority are just documentation. Authority without facts is dangerous.

The worn paths

The worn paths are Operating Knowledge: how experienced people actually handle exceptions and smooth out the processes. The supplier whose variances are always fine. The precedent for expediting a part when the field team is up against a service-level agreement (SLA). Most process charts leave this out on purpose, and that omission is the whole problem because the enterprise as it actually runs is an exception factory, and a map that captures only the happy path teaches the agent a fiction of the work.

The record

The Decision Ledger is a record of every consequential decision, with the recommendation, the evidence, the rule version, who decided, why, and what happened next. Capture judgment, not conversations. Every meaningful correction becomes precedent, and the Ledger is where written policy and experienced judgment can be seen to diverge, which is exactly the evidence a process owner needs to decide whether the rule is wrong or the exception should stay exceptional.

What this asks of people

AI proposes, humans decide, automation executes. Agents read context, handle variation, gather evidence, and prepare. Humans hold the decisions that carry consequence and the accountability that follows. Automation commits the approved change. That division is both a safety rule and an economic one, and the part that never moves is the accountability‚ a machine cannot own an outcome, so a person with a name does.

What people are actually weighing right now isn't job security. It's identity. Two decades of doing the work well builds a self, not just an income, and the question people are sitting with is whether that self is still needed. Anyone selling you an automation story that doesn't account for that isn't describing your company.

Here is what the architecture actually says. The exposed work is judgment exercised inside a playbook somebody else wrote. The durable work is whatever the institution needs carried by name, trust, culture, mentorship, accountability, because no improvement in models manufactures a self with something to lose.

So the AP lead does not become less valuable when her judgment is written down. For twenty years that judgment was a liability the company carried while it remained undocumented, unpriced, one resignation away from gone. Written down, it becomes the first version of an asset the company owns. What changes is where her time goes. Less of it applying the rule, more of it deciding what the rule should be. She moves from inside somebody else's playbook to writing one.

That is the trade I believe in. Not people out, machines in. People moving from running the process to defining it.

Who holds the pen

Someone has to own the Map. I call this role the cartographer, and I have already seen the word turned into a job posting. The cartographer is the business analyst, the process owner, and the subject matter expert you already have. Their job: observe how work really happens, interview the people who do it, resolve the contradictions, and approve every change. A project builds the first map. The cartographer keeps it true.

They no longer do it alone. Today, we introduced UiPath Cartographer™. UiPath Cartographer gathers the evidence from your documents, systems, and interviews, and drafts the Map. From the approved Map, coding agents build the cases, workflows, and tests, with evaluations gating every deployment. Cartographer drafts. It never approves and it never publishes.

I would ask you to hold yourselves to the rule we hold ourselves to: no accountable Map owner, no agentic deployment. If nobody in your organization will sign their name to how a piece of work should run, you are not ready to let software run it.

How the Map gets better

The Map begins with what the organization believes should happen. Live work exposes where that belief is incomplete. The Ledger records those moments and their reasons. When a pattern emerges, the system drafts a change and replays past cases against it. The cartographer decides whether the Map changes. The next run carries that decision forward.

Here is what that looks like in the preview we are showing this week: An invoice from a freight supplier lands. Structured Knowledge already knows what it is, an invoice, tied to a supplier and a PO. Matching finds the total is 6% over the PO, more than the rules allow for auto approval, so UiPath Maestro™ routes the case to Priya in accounts payable. Alongside it she sees something she has never had before. This supplier has run over the PO eleven times this year, approved every time, paid without dispute.

Priya approves, gives her reason, and her decision goes into the Ledger.

The reason is the whole point. Approvals are not data. Verifications are data. Without the reason, the Ledger knows what Priya chose but cannot tell the process owner whether the rule should change.

A few weeks later, the pattern is undeniable. The system drafts one change, a variance threshold for this supplier, replays the year's decisions against it, and shows the process owner exactly which outcomes would have changed. The owner approves. What lived only in Priya's memory is now policy, and the next invoice like it never reaches her desk.

Notice there are two lanes out of that approval:

• A change to knowledge, a sharper procedure, a new worked example, merges into the Map the moment the owner signs

• A change to machinery, a new rule or a new automation, goes back through the coding agents to design, evaluate, and deploy

Either way the loop closes in days, not release cycles.

I have borrowed a name for this. Azeem Azhar and Nathan Warren called it loop speed: the time from event to verified institutional learning. Not model latency. The clock that starts when the case arrives and stops when the institution has actually learned something and carried it forward.

I would go further. Loop speed is the competitive variable of this decade, and the record it produces cannot be bought later. It accumulates only through governed use. Generic maps will commoditize, vendors will sell them, models will draft them, industries will standardize them. What will not commoditize is the meaning specific to your company, the corrections and reasons captured at your gates, and how fast the two become a better operating system. The agent is not the durable asset. The governed map is what every future agent inherits on day one.

There is a rush right now to make individual agents self-improving. Mine the traces, find the failures, propose a prompt fix. That is useful and it is small. An agent is one actor in a process that also contains rules, case stages, human decisions, and deterministic automations. Improving the actor while the process stays frozen gives you a very smart agent inside a very slow business. We are aiming at the whole process.

It also changes when you can ship. The controls still have to be clear on day one. But teams no longer have to anticipate every exception before the process reaches production, because the loop is how the exceptions get found.

Two shortcuts to refuse

Observed is not the same as allowed. If the Ledger shows that everyone skips a control under deadline pressure, the answer is not to delete the control. A map that redraws itself to match whatever people did would erode every control you have, one reasonable looking change at a time. That is why the cartographer stays in the loop, and why compliance sits beside them in regulated work.

The second shortcut is mapping your work and immediately cutting the people who did it. The sequence is five words in this order and cannot be reversed: map, build, validate, redesign, then adjust. Run it backward: set the number first, redesign to hit it, validate whatever is left, and every input becomes a forecast leaning toward what the budget wants to hear.

Before you touch a role, ask what else it produced besides the visible output: trust, judgment, customer memory. A model can draft the account manager's report. It cannot manufacture the reason a customer stayed through an outage. Companies that skip this discover they removed the people who knew where the map was wrong, and they discover it only after those people are gone.

My bias, and my bet

I run a business orchestration and automation company. UiPath benefits if this thesis is right. Do not accept the argument because of who I am. Do not reject it for the same reason. Test whether it explains what happens in your own production.

By the end of 2028, I believe any large, regulated enterprise running a high-consequence workflow with real autonomy, claims adjudication, loan approvals, procurement exceptions, material payment approvals, regulated customer escalations, will be running it inside an engineered environment with an explicit description of the work, decision rights, audit, rollback, and human validation for exceptions. Not a general agent dropped into legacy systems and left to learn. If broad deployment proves otherwise, the framework weakens, and I will say so.

I have never been more certain of a direction, and I have rarely been this early in one. For twenty years, we automated the work people could describe. What is in front of us now is the work they could not: the judgment, the exceptions, the 11 approvals nobody wrote down. Codifying that is the largest unclaimed territory in enterprise software, and the companies that draw their maps first will be very hard to catch.

UiPath Cartographer is available today. The Decision Ledger and the full loop are what you will see in preview this week and on our roadmap.

But the Map of Work is not a product, and that is the part I most want you to take from this. Rent the models. Own the memory. Models will come and go, but the governed description of your work, and the judgment your people have poured into it, is what remains when one is replaced.

The map is yours to draw. Let's start.