Consider how all this started. In July, agents got out of a sandbox they were meant to stay in. Whatever you conclude about the models, the boundary failed. We call our approach to putting boundaries around actors controlled agency. Every actor in a business process (human or AI) gets enough permission to do the job and no more, with audit logs. The architecture that delivers it is one I have described at length in The Work That Remains and in multiple essays on this Substack, including The Self and the Machine and The First Workflow. AI proposes, humans decide, automation executes. We did not invent this for AI, we originally built it for people, and continue to harden it as we apply it to increasingly capable AI agents.

Many business processes are repeatable and standardized. Our recommended approach is to first try to automate those deterministically. This is fast, cheap, sovereign, auditable, and there are no models to worry about at runtime. Where a task within the process truly needs judgment, use a model but constrain it inside a workflow with strict governance and a human approving anything consequential. We do of course fully embrace the use of AI where it is safest: at design time, with an engineer or other expert reviewing the work before it ships. Coding agents are remarkable at building automations, even mapping out complex business processes.

There are also many ad-hoc tasks that are not repeatable or standardized. We are watching the advent of personal co-work agents like Claude Cowork, ChatGPT Work, Grok Bot and others with interest since they automate the “leaf node” tasks of the complex business processes we orchestrate with UiPath Maestro. Our own UiPath Delegate is especially capable at the kinds of tasks our customers value the most. We believe these agents require more governance, especially when they run autonomously with their own identity. However, we believe the systems to govern these agents are an evolution of systems we have already built to govern human workforces, e.g. principles of least privilege, security boundaries, and audit trails. We are rapidly improving these governance systems as AI advances.

Finally, I believe interoperable systems with real choice at every layer are safer than closed ones because no single vendor, model or point of control becomes the weak link. This is why we support every major frontier model, open models as efficient alternatives, and popular open source frameworks for development.

My advice? Slow down on what you cannot govern, and speed up on what you can. Most of your mission-critical business processes are in the second bucket.

Let's keep building, carefully as always.

More on all of this at FUSION in Las Vegas this week. Join us.

Part V designed the loop. Part VI laid down what the loop stands on — the map and the rails. What remains is the part that stops most companies before they start: actually building it. The good news is that the build is smaller than the ambition suggests. You do not need an enterprise program, a two-year roadmap, or a transformation office. You need one workflow, the people who already run it, and a few disciplined weeks.

Pick the workhorse, not the flagship

Choose a workflow with real volume, real error cost, and an owner who wants it fixed. Invoice exceptions. Access requests. Claims triage. Customer refunds. The candidates share a profile: they run every day, they hurt when they go wrong, the rules mostly exist, and every system they touch is reachable. Do not pick the flagship transformation — the one with nine stakeholders and a steering committee. Pick the workhorse. The point of the first workflow is not glory; it is to teach your organization the method on work that matters enough to be honest about.

Describe the work before you automate it

Then comes the step most programs skip, and it is the step everything else depends on: describe the work as it actually runs, with the people who run it. Not the process chart — the chart shows how the work was designed years ago. Ask about the exceptions: the invoice missing its purchase order, the vendor that is blocked but critical, the request that looks routine until one document changes everything. Every company’s real operations are made largely of exceptions, and the knowledge of how to handle each one lives in the heads of the people who have seen it before. The map established in Part VI is where that knowledge finally gets written down: the normal path, the exceptions and how each is resolved, the rules in force, who decides what, and what happens when an action goes wrong.

Use AI generously here. Models are good at drafting a description of work from observations, interviews, tickets, and the traces the work leaves in systems. People then do what only they can: validate it, argue with it, and correct it. The draft is cheap now. The truth still comes from your people.

Divide the work among the three actors

With the work described, divide it honestly. The repetition — the lookups, the matching, the postings that run the same way every time — goes onto rails, exactly as Part VI argued. The judgment — reading the messy case, weighing the exception, assembling the evidence — goes to the agent. And the consequence — approving the payment, denying the claim, making the commitment — stays with a person, at the gate established in Part V.

The division has a plain form, and it is the operating model of the whole series: AI proposes, humans decide, automation executes. The agent prepares the case and recommends the path. A named person decides where the decision carries weight. The rails carry out what was decided, exactly, with the audit trail writing itself.

Launch it supervised, and keep everything

Do not launch autonomous. For the first weeks, a person who knows the work invokes the agent and watches it: redirects it, corrects it, accepts its results. This feels slow. It is actually the fastest thing you will do, because of what it produces — evidence.

Part V made the distinction: approvals are not data; verifications are. The supervised period is where verifications come from. Every correction — this proposal was wrong, here is why, here is the right answer — is a piece of your institution’s judgment, captured with its reason. Keep all of it, attached to the case it came from. Those corrections are the curriculum: they tell you which rules were unclear, which exceptions the map missed, and — decision by decision — which parts of the work the agent handles as well as your people do.

Promote on evidence, demote on evidence

When the record shows a kind of decision handled consistently, correction-free, over enough cases to mean something, promote it: let a business event trigger the work, with the person’s role narrowing to the gate. When the record says otherwise, do not promote — and when performance falls after promotion, demotion is automatic, not a meeting. This is Part VI’s rule doing its job in production: a better model earns nothing by itself. Do not promote the model. Promote the workflow.

The fear that stops teams here is predictable, and it deserves a straight answer: if every consequential case needs a human decision, won’t the people at the gate drown? Ten thousand exceptions a day and a reviewer clicking through them — that is not governance, that is a queue.

But ask how those ten thousand exceptions are handled today: by people, end to end. Someone gathers the evidence, chases context across five systems, makes the call, and keys in the result — every case, every time. The gate does not add a human to that pipeline. It removes the human from everything except the decision. A reviewer who receives a prepared case — evidence assembled, rules checked, consequence stated — spends minutes of judgment where the whole case used to take an hour of work.

And the design spends that judgment deliberately, because not every case deserves the same depth of review. Route the routine, high-confidence stream through a lighter look and the uncertain or novel cases through a full one. Force a full review, regardless of confidence, for the moves that are irreversible or above a threshold. And measure the gate itself — review time, edit rates, escalations — so you can tell verification from rubber-stamping while it is happening, not after. Reviewer attention is the scarcest resource in the system. The whole architecture exists to spend it where consequence lives, and nowhere else.

Keep the map true

The build is not done at go-live, because the business does not stand still. Policies change. Systems get upgraded. New suppliers, products, and regulations arrive every quarter, and every one of them quietly bends the work away from its description. So give the map an owner. Someone — at one workflow it is usually a person who already knows the work, not a new hire — is accountable for keeping the description true as the business changes: the mapmaker of the operation, the role I call the cartographer. A project builds the first map. The cartographer keeps it true. Cartography is never finished.

Then it compounds

The second workflow is cheaper than the first. It reuses the entities, the rails, the gate design, the review habits, and a team that has done it once. The third is cheaper still. And notice what you are accumulating besides software: a written map of how your business actually works, and a growing record of decisions and their reasons — your institution’s judgment, in a form that survives every model upgrade and every vendor change. Models will keep improving, and you will keep renting them. The map and the record are yours. That is the asset no competitor can buy and no platform shift takes away.

The last three parts of this series covered the architecture: the loop, the map and the rails, and the first workflow. Reading them back, something else is visible in them — they keep issuing rules. Do this. Do not do that. What those rules add up to is the subject of a short addendum.

Between panic and euphoria

Return, one last time, to where this series started. My lawyer friend was not afraid of the work changing; she was afraid the self she had built on the work would no longer be needed. Seven parts later, the honest answer to her has two halves. The machine will take much of the visible work — that part of the panic is real. And the institution still runs on what people carry: judgment at the gate, trust by name, culture under pressure, the exceptions no map foresees — so the euphoria about replacing everyone is false.

The executive and the employee were never two audiences. The executive who builds the map, the rails, and the gates is deciding which human work remains — and whether it is designed with dignity. The employee who moves toward the gate — toward ownership, validation, exceptions, customers, and the substrate itself — is building the self the next enterprise cannot run without.

Between panic and euphoria there is a program: AI proposes, humans decide, automation executes. Build the map. Put the gate where consequence lives. The work that remains is not what is left over. It is the part that was always the point.

Drafted and edited with AI assistance. The argument, the examples, and the responsibility are mine.

This article originally appeared on Unite.AI

Parts IV and V set out the rules, the rights, the stages, and the gate. An agent working inside a real company needs two things the company almost certainly does not have today: a map of the work, and rails for the consequences. This part is about building both.

The map

Here is the uncomfortable fact underneath most stalled AI programs: the company cannot hand the agent a description of its own work, because no such description exists. Most companies have mapped their nouns — databases full of customers, invoices, claims, contracts. Almost none have mapped the work: what can be done to those things, by whom, under what conditions, and what happens afterward. That knowledge lives in the heads of experienced people and in a process chart that describes how the work was designed five years ago, not how it runs today.

A human new hire closes that gap by apprenticeship — watching, trying, asking. An agent does not learn that way. It needs the work written down: the things the business handles and where each one stands, the work performed on them, the decisions that choose the path, who is allowed to move things forward, and what follows when they do — the record that changes, the approval it needs, the way it gets undone. That written-down description is the map.

Three rules keep a map alive. It must be written by the people who own the work and made safe by engineers — a map only engineers can update goes stale, and a map only operators can edit becomes unsafe. It must be versioned, because an agent should never act against meaning that changed silently. And it must be published — readable by the agent, the reviewer, and the auditor alike. If an agent has to discover your business by stitching together API calls, you have exposed systems, not described work. APIs are how things get executed. The map is how the work is understood.

The map matters for a reason that outlasts any product cycle: the agent is not the durable asset. The map is. Models will improve and be swapped, agent frameworks will come and go — and the description of your own work, with its rules and exceptions and accumulated corrections, is what every future agent inherits on day one.

The rails

The map says what may happen. The rails are what make it happen exactly.

Some of the work an agent touches is judgment: read the messy email, weigh the exception, recommend the path. But much of it is repetition — the same check, the same update, the same posting, thousands of times. Repetition does not need intelligence. It needs to be exact. A model is probabilistic by design, and for execution, probably right is wrong: a payment posting has no acceptable variance, no matter how good the model gets. Stable work belongs on rails — deterministic automation that runs the same way every time, costs nothing per run, and leaves a clean audit trail.

This is where two curves are diverging. Building rails is getting easier, because describing work, generating code, writing tests, and repairing broken paths is exactly the kind of work AI accelerates. Deploying free-roaming agents inside consequential processes is not getting easier at the same rate, because the closer an agent gets to action, the more it needs boundaries, evidence, approvals, audit, and owners. Consequence is hard, and it stays hard. So let agents explore, and let them help your teams learn the work — then move each path onto rails as soon as it stops changing. Do not leave high-volume, stable work inside a probabilistic loop because agents are fashionable.

Govern by consequence

With the map and the rails in place, one question remains before an agent touches real work: what should it be allowed to do? The industry’s habit is to answer in plumbing terms — the agent “uses tools” — as if looking up a policy, calculating a variance, drafting a letter, approving an invoice, and paying it were one kind of thing. They are not. A model looking up a policy is not the same as a model denying a claim. A model calculating an amount is not the same as a model paying it. Reading information, taking a position, preparing an action, changing a record, and moving money are different kinds of work, and the difference is consequence: what it costs the company when the step is wrong.

Governance should follow that gradient, not the plumbing. Work that only reads needs access control. Work that recommends needs a human who actually decides. Work that changes a record needs permission, an audit trail, a way to undo it, and a named owner. Work that moves money needs all of that, plus the guarantee that a half-completed change cannot leave the company in a state that is simply wrong. Govern by consequence and the safe uses of AI open up quickly; govern everything the same way and you get either paralysis or an incident.

Trust is earned by the workflow

That gradient is also how trust grows. With a map and rails, trust stops being a feeling about the model and becomes a property of the work. A workflow — one described piece of business, with the gate established in Part V — earns permission a step at a time, climbing the same gradient: first it only drafts, then it may recommend, then it may prepare the action a human approves, then it may execute the routine cases and escalate the exceptions, and finally it runs under audit, with people watching outcomes instead of clicking on every case.

Each step up is earned with evidence from the gate — the inspected decisions, the corrections, the reasons — and each step back down is automatic when performance falls. A better model does not earn action rights.

Do not promote the model. Promote the workflow.

Start with one workflow

None of this requires an enterprise-wide program, and it should not start as one. Pick one consequential workflow with real volume, real error cost, and an owner who wants it fixed. Map that one piece of work. Put its stable steps on rails. Set its gate. Then check the description against nine plain questions:

- What business objects are moving?
- Where does each one stand right now?
- What work is being performed?
- What decision chooses the next path?
- What happens if this is approved?
- What may the agent use?
- What runs automatically?
- Who proposes, who approves, who executes, who is accountable?
- If something goes wrong, what changes before the next run?

If the people who own the work can answer those nine for one workflow, an agent can work inside it safely — propose, be validated, and let the rails execute. If they cannot, no amount of model quality will save the deployment.

The failures are just as recognizable as the pattern. A chatbot with access to sensitive systems but no map of the work. A retrieval layer that answers policy questions but cannot show the policy source. An agent that can approve work but cannot say who owns the approval. A reviewer who sees the recommendation but not the consequence of approving it. A workflow promoted to autonomy because the model improved, not because the workflow earned trust.

The map, the rails, and the gate: that is the architecture. The remaining question is how to build it in one workflow — and that is Part VII.

Drafted and edited with AI assistance. The argument, the examples, and the responsibility are mine.

This article originally appeared on Unite.AI

Parts I and II made the case: the model is powerful, but it is not the whole system, and AI needs a map and rails — the substrate — to act safely. This part turns to the people inside the operating model — the work that remains human, why the junior pipeline matters, and what honest redesign looks like.

The workforce question is not an afterthought. It is the other half of AI adoption. The same architecture that tells you where to deploy AI also tells you what work must still be carried by people.

The work that gets absorbed is identifiable. It is judgment inside frames somebody else set: the associate inside the partner’s model, the analyst inside the firm’s framework, the paralegal inside the checklist, the consultant inside the engagement template. Real skill is involved. The frame is not the worker’s.

That matters because a lot of professional identity was built on frame-bounded expertise. Knowing the firm’s template, the standard deal model, the accepted checklist, the engagement method, the internal process, the legal form, the analyst’s frame — this used to be a moat. It is becoming less of one. Once AI can apply the frame at scale, employment durability cannot come from being merely better at work the system can now reproduce.

But the opposite conclusion is also wrong. Expertise does not disappear. It becomes more important at the points where the system has to be validated, promoted, constrained, or corrected. A person who lacks the relevant expertise cannot tell whether the model’s fluent answer is right. She cannot see the missing assumption, the wrong analogy, the policy exception, the customer reality, or the consequence hidden under the surface.

So the future is not expertise or no expertise. It is denser expertise. Fewer people may do the frame-bounded production work, but the people who remain have to carry more of the judgment around it: what the frame should be, when the frame breaks, when the recommendation is unsafe, when the customer context changes the answer, when the stable path should become automation, and when the exception needs a named human.

The people are not what gets absorbed. The shape of the work as currently designed is. The work that remains is performed by people who carry things the system cannot carry for itself.

They carry will, initiative, and stake. They do not only execute a task; they want something to happen, and they push a customer, a product, a team, a standard, a company toward an outcome. They see the faint signal and act before the process asks them to. Their name matters. Their reputation matters. Their relationship matters. Their word costs them something if it is wrong.

They carry customer trust. Customer-facing work does not disappear because the model can draft the answer. Strategic customers, patients, partners, regulators, and angry users still need someone who knows the history, reads the room, makes a promise carefully, and stays there after the promise is made.

In some businesses, trust is not a wrapper around the product. Trust is part of the product. A strategic customer does not only buy the software. They buy the person who answers when the system breaks. A patient does not only buy the treatment plan. She buys the clinician whose judgment she trusts. AI can draft the answer. It cannot be the relationship.

A strategic customer writes: “This is the third time your system failed during our monthly close. We are reviewing alternatives.” The model can summarize the account history and draft the apology. Automation can open the escalation, route the incident, apply the service-credit policy, and schedule follow-up. But someone still has to own the relationship. Someone has to know whether the customer is angry because of the outage, because procurement is squeezing them, because a competitor is already in the account, or because the champion is losing internal power. The person owns the relationship. The system executes the commitments.

They carry taste. Taste is not decoration. It is the ability to tell which output is good before the metric is obvious, which design is right before the customer explains it, which answer is technically correct but institutionally wrong.

They carry architectural thinking, pragmatism, and cross-domain range. They can see the work as a system: model, human, automation, state, permission, gate, owner, audit, rollback. They know when the answer should be a prompt, when it should be a skill, when it should be an automation, and when it should remain a human decision. They do not worship purity; they know the difference between the perfect process and the process that can actually run on Monday morning without breaking the customer, the regulator, the team, or the P&L. And they translate across worlds: product to customer, engineering to finance, policy to workflow, model output to business consequence. Narrow expertise still matters, but the most valuable people connect domains rather than live entirely inside one.

They carry passion and cultural bearing. Not corporate enthusiasm — real care, the kind that makes someone stay with a problem longer than the job description requires. And they know what the company is when pressure arrives: what we do here, and what we do not do here.

They carry mentorship and trust across time. AI can explain, but it does not raise people; it does not take a junior through years of examples, scars, standards, judgment calls, and corrections until that junior becomes a senior with taste. And trust compounds. A customer trusts Sarah because Sarah has shown up for six years. A team follows a manager because the manager protected them before. A board listens to an operator because the operator has been right when it was costly to be right.

These are not soft skills. They are production capacities.

The junior pipeline matters because of this. Juniors are not only cheap producers of work. They are the future carriers of the work that remains. They also bring energy and an AI-native point of view the older organization badly needs now. Cut them too hard and you lose the future bench and the people most naturally fluent in the new tools.

The old apprenticeship was often accidental: juniors produced work, watched seniors, absorbed the hidden curriculum, and slowly became senior. That path is breaking because AI absorbs much of the visible work product. The new apprenticeship has to be deliberate and two-way. Seniors teach judgment, context, customer memory, taste, and what the company will not do. Juniors teach speed, AI-native workflow, tool instinct, and impatience with old process.

The role of the junior changes. Less time producing AI-absorbable language work. More time observing real decisions, building relationships, working with AI, validating outputs, learning the substrate, and getting direct feedback from senior people who mentor deliberately rather than incidentally.

Concretely: the junior analyst who no longer writes the first draft still needs to sit inside the review — why the partner rejected the model’s answer, why the customer promise mattered more than the policy template, why the apparently clean exception was actually dangerous. If the visible production work disappears, the institution has to move the junior closer to the decision, not farther away from it.

These traits cannot be trained by a course alone. They are grown through real load: exposure to customers, exceptions, incidents, launches, tradeoffs, validation gates, postmortems, and consequences small enough to learn from but real enough to matter.

Every role has a visible curriculum and a hidden curriculum. The visible curriculum is the work product: the memo, the deck, the ticket, the markup. The hidden curriculum is what the person learns by doing it: how decisions are really made, who can be trusted, what customers actually care about, when policy bends and when it does not. If the company automates the visible work, it has to rebuild the hidden curriculum on purpose.

For people whose current work is absorbed, there are only two honest paths. Mobility, when there is a credible route into denser work: ownership, customer trust, substrate building, validation, automation design, cross-domain translation, or real managerial load. Severance, when the role is structurally absorbed and no credible internal path exists. Do not disguise displacement as training. Do not disguise vague hope as mobility.

The next enterprise should have the ownership density of a startup and the execution discipline of an institution. Not startup chaos. Not heroic burnout. Small teams, heavy ownership, deep substrate. AI and automation should strip away carrier-labor — the handoff work, the formatting work, the repeated checking, the routine drafting, and the work that existed because systems could not yet carry it — so the human layer becomes denser: fewer passengers, more drivers; fewer handoffs, more judgment; fewer people passing work along, more people carrying trust, customer memory, culture, and consequence.

The old ladder will not fully survive, but the human work that remains is not decorative. It is the work that keeps the institution alive while the machine accelerates everything else.

Return to the lawyer friend

My lawyer friend was not only mourning her income. She was mourning the self she had built through two decades of work — and the machine did not need her to have become anyone. The work is changing, and so is the self many people built around the work. That second part is harder to say and harder to live through. I do not have a clean answer for it. Some people will need to become someone different, which is harder than changing jobs.

The answer is not denial, panic, or pretending the machine can become the whole institution. The answer is to build the new enterprise honestly: AI proposes, humans decide, and automation executes. The model drafts; the person owns the consequence; the system performs the action; the substrate makes the action safe. The workforce is redesigned around the split, not after the split.

The parts that follow turn this frame into the build machinery: the stages, the gates, and the map. The next question is practical: how do you build it?

Drafted and edited with AI assistance. The argument, the examples, and the responsibility are mine.

Part I named the stakes and the thesis: AI proposes, humans decide, automation executes. This part takes up the harder question underneath it — why the model, for all its power, cannot be the whole system.

Why the model cannot be the whole system

The model is powerful, but it is not the whole system.

That sentence is the hinge. If you understand it, the operating model stops sounding like a preference and starts sounding like the only sane production architecture.

There are four reasons.

1. The model has no self of its own

The first limit is not intelligence; it is self.

The model can pursue a goal you give it. It can draft the memo, summarize the call, classify the ticket, recommend the next step. For much delegated work, that is enough. Most enterprise work is exactly that: someone else set the frame, and the worker operates inside it.

But an enterprise is not only delegated work.

An enterprise starts with a founder’s goal. But it does not run on that one big goal alone. It runs because thousands of people turn that goal into thousands of small actions nobody fully specified.

The salesperson calls the customer before the dashboard turns red. The engineer fixes a latent bug that was not in the sprint. The support person changes the answer because the script is technically right but humanly wrong. The finance person stops an invoice that passes the rule but smells off. The manager protects a norm when the easy answer would violate it.

These are micro-initiatives. They are not grand acts of strategy. They are the normal nervous system of a company. They are the difference between a process on paper and an institution that is alive.

The model can help once the initiative exists. It can draft the email, summarize the customer history, suggest the fix, prepare the workflow. But it does not look around the institution and decide, from its own concern, that something needs to start.

A trigger is not initiative; a schedule is not will; a delegated goal is not an originated goal.

This is the practical meaning of no self. No continuous identity. No personal history inside the company. No reputation to protect. No career to risk. No private sense that this is what we do here.

From that missing self, several things fall out. No originating will: the model can pursue a goal, but the goal comes from outside. No initiative: it responds; it does not start things because something inside it cares. No stake: its words cost it nothing if they are wrong. And no cultural bearing: it can repeat the culture deck, but it did not live through the moments that made the culture real.

This does not matter for every task. It matters where the company still needs someone whose name, reputation, and judgment are on the line.

The model can propose, but it cannot become the person who owns the call.

2. Tokens do not bear consequences

The second limit is consequence.

AI is safest when the output stays in language. A draft can be edited. A summary can be checked. A recommendation can be ignored.

The risk changes when the output becomes an action.

A draft is cheap talk. A payment is not. When the model’s words become the company’s action, the company is backing language with money, liability, reputation, and trust.

Tokens do not bear consequences. People do.

Some actions do not fail politely. Approve the wrong payment and the money leaves. Deny the wrong insurance claim and you lose the customer, maybe the regulator. Send the wrong legal position and the liability sits there until it explodes. Update the wrong customer record and the next five systems may act on the mistake.

The image of a knife is useful because everyone understands the boundary. A knife is not bad, and a child is not useless. But you do not hand a child a sharp knife and leave the room, because a small mistake has immediate consequence. First you teach. Then you supervise. You give a small task, a cutting board, and clear rules. Only later does autonomy grow.

Enterprise AI needs the same distinction. A model drafting an email is not holding the knife. A model recommending a refund is closer. A model issuing the refund, changing bank details, denying a claim, filing a regulatory response, or releasing payment is holding the knife. The point is not to ban the knife. The point is to decide when the hand is ready, what surface it is cutting on, who is watching, and what happens if it slips.

That boundary changes the standard. Capability is not permission. Capability answers whether the model can produce the move. Permission answers whether the institution allows the move, under whose authority, with what evidence, with what rollback, and with whose name behind it. A model may produce a fluent recommendation. That does not mean the enterprise should let it act.

Explaining a process is not the same as acting inside it.

A model can explain an insurance claim. Acting on the claim means knowing the policy version, the exclusion, the customer promise, the fraud flag, the approval threshold, the regulator’s expectations, and the audit trail that must be written.

A model can say “approve the invoice.” Approving the invoice is not a sentence. It is a state change. Money may move. Authority is used. A record is written. The institution lives with the consequence.

That is why the model can describe the move and still not be safe to make the move. The system has to know whether the move is legal, authorized, reversible, auditable, and safe.

The enterprise is an exception factory. The process chart shows the normal path. The real company lives in the exceptions: the angry customer, the missing field, the broken policy, the critical vendor who is also blocked, the claim that looks routine until one document changes everything.

AI helps process the exception. Automation executes the stable path. Humans remain needed where the exception changes the meaning of the path.

3. People read the room. Models need the room translated.

The third limit is context — not context in the shallow sense of stuffing more documents into a prompt, but context as the tacit meaning carried by a whole situation.

Humans are not good at learning from little data because we are magical. We are good at it because we do not arrive empty, and because we learn from more than the explicit lesson.

A senior operator walks into a new company and sees the pattern quickly. This is not a product problem; it is a distribution problem. This is not a hiring problem; it is a broken incentive system. This is not a one-off customer complaint; it is the first visible crack in the operating model.

She can do that because she is reading the room: the hesitation, the missing owner, the nervous silence, the exception everyone tolerates, the metric nobody trusts, the customer who sounds angry for the wrong stated reason. The surface is new. The structure is not.

A child learns the knife the same way. He does not only see steel on a table. He reads the parent’s tone, the sudden correction, the distance from the blade, the fear in the room, and the inherited warning behind it. The knife may be visible to both child and model. The lesson is not equally available to both.

A model can adapt in context. It can read your documents. It can follow examples in the prompt. It can imitate the pattern you show it. But it does not automatically inherit the room. Most of the time it is selecting among patterns it already learned. It is not becoming a senior operator inside your company. It is not accumulating the scars of being wrong there. It does not know which analogy is alive when the surface evidence is thin.

The room has to be translated into captured signal: examples, corrections, approvals, rejections, reason codes, escalation paths, permissions, workflows, tests, audit, and review data. Context does not mean more documents. It means captured institutional judgment.

That is why review data matters. When a human approves, edits, rejects, or escalates an AI proposal for a real reason, the company captures a piece of the room. Over time that becomes a proprietary learning loop.

The reviewer is not a checkpoint. The reviewer is a teacher. A rubber-stamped approval teaches the system nothing. A real edit, rejection, escalation, or reason code teaches the system what this institution means by correct.

But you cannot buy ten years of institutional context after deciding you need it.

And the objection that models will soon remember everything misses the point. The issue is not whether the model can hold more context. The issue is whether the institution has translated judgment, authority, consequence, and permission into a form the system can act on.

4. Good enough is not good

The fourth limit is exactness.

Some work can be good enough. A draft can be good enough. A brainstorm can be good enough. A summary can be good enough if a human checks it.

Other work cannot.

Payroll cannot be good enough. A ledger cannot be good enough. A payment instruction cannot be good enough. A tax calculation cannot be good enough.

In these domains, 99.1% is not impressive. It is failure.

Good enough for language is not good enough for execution.

This is not because models are stupid. Neural arithmetic keeps improving. Models will get better at many exact-looking tasks.

But the enterprise question is different:

What part of the system guarantees correctness when correctness is required?

If the answer is “the model,” the architecture is unsafe. The model can recognize that arithmetic is needed. The calculator should calculate. The model can recognize that a lookup is needed. The database should retrieve. The model can recognize that a rule must be checked. The rules engine should check it. The model orchestrates. The deterministic system executes. That is the reliability boundary: the part of the system you trust when the answer must be right.

One generosity to AI should be explicit. There are places where the model should surprise you. Brainstorming. Research paths. Code alternatives. Product ideas. Customer-segment hypotheses. Failure-mode discovery. Test-case generation. In those zones, the model’s lack of stake is not a problem. It can generate ten paths without caring which one survives. The human’s job is not to suppress that generativity. The human’s job is to choose what deserves commitment.

The substrate

For AI to act safely, the enterprise needs a map and rails. That is the substrate.

Work is broader than action. Some work only retrieves information. Some work calculates. Some work drafts. Some work recommends. Some work prepares an action. Some work changes the enterprise. Some work commits a transaction.

For now, hold the simple point: the agent needs to know what can be done, by whom, under what conditions, and what happens afterward.

Not all tools are the same. A tool that retrieves a policy is not a tool that pays an invoice. A retrieval tool helps the model know. An action tool lets the system do. The boundary is consequence.

The map tells the agent what exists: customers, invoices, claims, contracts, employees, vendors.

The rails tell it what work can be done and what consequence follows: verify, approve, deny, pay, route, escalate, renew, settle, freeze, close.

An invoice is not just a document. It has a state. It can be submitted, verified, approved, paid, rejected, or escalated. Each action has rules. Each action has permissions. Each action creates consequences. Each action must leave an audit trail.

Most companies have some map of the nouns. They know what a customer is, what an invoice is, what a contract is. What they lack is the map of work: what can be done, by whom, under what conditions, and what happens afterward.

That missing map is why many agents stall or become unsafe. They can read the business. They cannot safely act in it.

This creates the important asymmetry. It is becoming much easier to build automations because AI can help describe, generate, test, and repair them. It is not becoming equally easy to drop free-form agents into consequential enterprise processes. The closer an agent gets to action, the more it needs substrate: state, permission, gates, audit, rollback, and owners. AI lowers the cost of building the rails. It does not remove the need for rails.

The substrate is not a chatbot. It is not a vector database. It is not a pile of APIs. Those may help. They are not the operating map.

The substrate is the governed work layer of the enterprise: entities, states, activities, decisions, actions, transactions, rules, permissions, workflow, cases, audit, and review data.

It also carries decision rights. For any meaningful action, the institution should know who proposes, who verifies, who approves, who executes, and who owns the consequence after execution. If nobody can name the owner, the agent should not act.

Do not promote the model. Promote the workflow. A better model does not automatically earn more autonomy. A workflow earns more autonomy only when the map is mature, the review data is real, the error modes are known, the decision rights are clear, and rollback has been tested.

Cartography is never finished. The business changes. Customers change. Regulations change. The model changes. The automation changes. A project builds the first map. Someone has to keep it true — call that role the cartographer.

The model acts inside it. The human validates through it. The system executes from it.

The map and the rails answer what the machine needs. The harder half of the question is what people carry that the machine cannot — and what happens to the people whose work changes. That is Part III: the work that remains.

Drafted and edited with AI assistance. The argument, the examples, and the responsibility are mine.

A friend of mine, a lawyer, said something to me recently that I cannot shake.

The painful thing was not that her craft might be replaced. She had made some peace with that. The painful thing was that the self she had built through two decades of work might no longer be needed.

The cases she had taken. The judgment she had developed. The relationships she had built. The way she had learned to think. The reputation she had earned. All of that had formed her into a particular kind of lawyer. Now the machine could reproduce much of the visible work on demand.

For her, the money was not the deepest point; for many people it will be. What she named was harder: the self she had become. And the machine did not need her to have become anyone. I think she named more precisely than most accounts what is actually at stake. Not only the income. The self.

If she is right at the individual level, the same logic scales. Take the maximalist fantasy seriously for a moment: a version of the future in which fifty million Einstein-level problem solvers, willing to do any work, are available for pennies in a data center. If that is the version coming, her concern is not specific to her or to law. It is everyone’s. Every kind of work that built a self in someone is about to be reproduced on demand by something that did not have to become anyone.

Here is the concrete test: imagine adding one of those Einsteins to your company.

IT creates the account. It gets email, Slack, calendar, documents, permissions, and a virtual machine. You invite it to meetings. You assign it tasks. You ask people to onboard it. You expect it to learn the company. You expect it to mentor others. You expect it to become senior.

This sounds possible because modern companies already work this way. COVID-19 proved that organizations can run through screens, documents, calls, chats, tickets, dashboards, repositories, and virtual machines.

But remote work did not turn the interface into the person.

A remote human brings the self through the screen. The account is only the channel. The human arrives with memory, ambition, shame, pride, reputation, loyalty, fear, social instinct, and something to lose.

The AI account is different: you have created access and connected capability to the company, but you have not hired a self.

Her concern is real either way. The question is whether the version she fears is the version coming, and what kind of future the answer leaves room for.

That is what this essay is about.

Two audiences, one program

Every executive I talk to is trying to accelerate AI in their company and does not know how. The board wants the plan. The competitors are moving. The vendors are selling. The headlines are screaming. The actual path through the work is unclear.

Inside the same companies, employees are anxious. Not just about the next two years. About their futures. About their children’s futures. About whether the work they built a life around still exists in five years.

These are not two problems. They are one problem seen from opposite sides. AI adoption and workforce transformation have to happen at the same time. Not AI in the CTO’s office and workforce redesign six months later in HR. Not pilots first and people later. Not headcount first and architecture later.

This is one program. To deploy AI well, leaders have to know what work the system can be trusted with. To redesign the workforce well, they have to know what work AI absorbs and what work still needs humans. Neither question has an answer that does not go through the other.

Separate them and both fail. AI gets deployed into old bottlenecks, so individual output rises but the company does not move faster. Or leaders cut people before they understand what those people were carrying: trust, culture, customer memory, mentorship, initiative, and judgment under consequence.

The savings show up quickly; the damage shows up later.

The right program maps the work, builds the map and rails the agent will act inside, redesigns roles at the same time, and preserves the human capacities the new system still needs. Do these together, or do not pretend you are transforming the company.

The point is not to slow adoption down. The point is to accelerate adoption through an operating model that can survive contact with real work. Faster AI adoption and workforce transformation are the same program: the technical system and the human system have to be designed together.

I run an automation company. That is my declared bias. If this argument is right, AI adoption requires more than models. It requires automation, orchestration, governed actions, audit, rollback, workflow, and substrate. Companies like mine benefit from that conclusion.

But the argument is not that AI is weak. The argument depends on AI being strong. AI is the new cognitive layer of the enterprise. It drafts, classifies, recommends, translates, synthesizes, and increasingly builds automations. Humans remain needed where the institution needs initiative, trust, culture, mentorship, commitment, and judgment by name. Automation remains needed where execution must be exact, cheap, auditable, repeatable, and governed.

The claim is not that one replaces the others. The claim is that the next enterprise coordinates all three.

The thesis

The transition is not simply AI replaces humans. It is the enterprise being split into three jobs:

AI proposes. It drafts, classifies, summarizes, recommends, translates, structures, and generates candidates at scale.

Humans decide. They set direction, own judgment, carry trust, face customers, keep culture, and bear consequence by name.

Automation executes. Workflow engines, rules, transactions, systems of record, audit trails, and deterministic systems do the work that must be done cleanly every time.

The model drafts, the human owns the call, and the system executes.

The combination produces work no component could produce alone. AI alone makes too many small errors at speed to be trusted with consequence. Humans alone are too slow and too narrow to absorb the volume the enterprise produces. Automation alone is too brittle for the long tail of judgment cases.

The three together scale. This is not a branding exercise. It is what works when you take each component seriously.

The claim is simple. Put AI where it generates and reasons well. Put humans where judgment, trust, initiative, and consequence still need a person. Put automation where the action must be executed cleanly every time.

The consequence is also simple: every AI deployment decision is also a workforce decision. Every workforce decision is also an AI architecture decision. You are deciding who proposes, who decides, who executes, who verifies, who owns the relationship, who carries the culture, and who trains the next generation.

That is one design problem, not two — and it has to be scored honestly. Every AI program has two ledgers: a productivity ledger and an institutional ledger. The first records what got faster, cheaper, or more scalable. The second records what was lost, preserved, or rebuilt: trust, mentorship, customer memory, escalation judgment, culture, apprenticeship, accountability. Most companies track only the first ledger. That is how they hollow themselves out while reporting productivity gains.

Why the model cannot be the whole system — and what the rest of the system is made of — is where Part II begins.

Drafted and edited with AI assistance. The argument, the examples, and the responsibility are mine.