Where the Decision Boundary Goes When AI Can Do the Work

We are not figuring out how to deploy AI.

We are figuring out how organizations should change when machines can do increasingly consequential cognitive, creative, coordination, and decision work.

That distinction is the whole newsletter.

Most of the conversation about enterprise AI still happens at the task level:

• Where can we add a copilot?
• What can we automate?
• How much time can we save?
• Which workflow should get an agent?

Useful questions.

But every one of them quietly assumes that the organization around the task stays mostly the same.

The more consequential questions start where those stop.

If a machine can now perform work that once required a person, what happens to the surrounding system?

• Who makes the decision?
• Who is accountable for it?
• What expertise still matters?
• Which handoffs disappear?
• Where does the bottleneck move?
• What new coordination work gets created?
• What work are we preserving simply because it happens to exist today?
• What happens to the people who used to develop judgment by doing the work we just automated?

Those questions eventually force us to confront the decision boundary: what the machine may recommend, decide, or execute; what remains human judgment; and who answers for it.

But the boundary sits inside a larger problem.

We are redesigning the organization around a new set of capabilities.

The last question is the one I think about most.

I'm 44 and voluntarily back in school. Part of that is probably a little crazy. But part of it is deliberate: I don't want to outsource so much thinking to AI that I stop getting the reps that build judgment in the first place.

I suspect the answers to the second-to-last question are going to hurt.

Two sides of the same table

I spent years building data and AI products inside Dell, and the pattern I saw over and over was that it's much easier to put new technology on top of an existing process than to question the process itself.

I saw teams spend enormous energy making an existing workflow faster when the more important question was whether the workflow should exist in that form at all.

It's a much easier organizational conversation to say, "Let's add AI here," than to ask, "Why are we doing this at all?"

Before that, I was an examiner at the FDIC, where I saw the other side of the problem.

Systems can make organizations much more capable, but they can also become a crutch. Once the people responsible for an outcome stop understanding what the system is doing, why it's doing it, and when to distrust it, you have a very different kind of risk.

Banking supervisors have a useful concept for what is supposed to prevent that: effective challenge.

Someone has to understand the system well enough, have the evidence available, and possess enough authority to say:

No. That doesn't make sense.

I'm not convinced most AI deployments are being designed with much effective challenge at all.

The visible task gets automated.

The organization underneath it stays mostly intact.

You can automate the work and completely miss how the work works.

From the outside, a lot of what you missed looks like bureaucracy.

The informal coordination. The exceptions. The tacit knowledge. The incentives. The judgment. The weird workaround someone invented three years ago because two systems don't talk to each other.

Some of it is bureaucracy.

But none of it is in the clean process diagram.

And some of it may be exactly what makes the process function.

The territory

This is the ground I intend to cover, roughly in this order.

1. Understand the work. How does the outcome actually get produced, beyond the formal workflow?

2. Decide what should change. Not "Where can we use AI?"

That is a lazy question.

What should be automated, augmented, eliminated, simplified, reorganized, or deliberately left alone?

3. Redesign the work. What happens to roles, expertise, coordination, incentives, bottlenecks, and decision rights?

4. Design the human-AI system. What should software do? What should models do? What should humans do? What information and tools should each have?

5. Prove that it works. Not just whether the model gives good answers, but whether the overall system produces better decisions and better outcomes.

6. Govern the authority. A system being capable of making a decision does not mean it should be authorized to make it.

7. Operate and adapt it. None of these systems stay put once they meet real people and real organizations.

What this newsletter is now

I'm starting to treat this as a real research agenda, not just a content theme.

My graduate work at Georgia Tech gives me a reason to go deeper into the academic side of these questions.

Stanford LEAD has put me in a network with a lot of people actually trying to lead this kind of change inside organizations.

And my own work gives me enough scars to be skeptical of clean answers from either side.

So I'm reading the academic literature, studying actual transformations, talking with people doing this inside organizations, and looking for cases where I can follow what actually happens as organizations redesign work around AI.

I'm trying to turn that into something useful rather than adding to the growing pile of AI commentary.

We already have plenty of that now that everyone with ChatGPT can sound like an AI transformation expert.

The working name for what I'm building is the AI Transformation Field Guide.

Right now, it's a messy repo full of papers, field notes, half-formed frameworks, diagrams, cases, and questions I don't know the answers to yet.

That's fine.

Everything that eventually makes it into the Field Guide has to pass one test:

What should someone responsible for an AI transformation do differently on Monday because they understand this?

The seven sections above will become the next seven issues, one every two weeks.

Roughest first.

I'd rather develop them in contact with people wrestling with these problems than disappear for six months and emerge with a polished framework nobody has challenged.

An invitation

If you're:

• redesigning work around AI inside an organization
• studying organizational change, human-AI collaboration, future of work, decision-making, HCI, or related areas
• leading an AI transformation and discovering that the org chart or process map bears little resemblance to reality
• watching an AI initiative succeed or fail in a way that doesn't fit the usual story
• or you simply think this thesis is wrong in an interesting way

I'd like to talk.

I'm especially interested in evidence that makes the thesis messier.

Evidence. Scars. Research. Weird edge cases. Failed transformations. Unexpected successes. Strong disagreement.

All of that is worth more to me than agreement.

If your main reason for reaching out is to pitch me an AI platform or generic transformation services, no hard feelings, but this probably isn't the conversation you're looking for.

For everyone else:

Send me the scar, the paper, the case, or the disagreement.