← Writing

Before you can delegate to AI, you have to design for delegation

There is a task I want to hand off to AI.

It is not complicated. It is updating a financial forecast based on a what-if question. What if we close this customer next month instead of this one? What if hiring slips by a quarter? What if burn runs 15% higher than plan?

I get asked these constantly. And every time, my answer is the same: give me a couple of hours. I open the model, find the right inputs, trace the dependencies, update the numbers, sense-check the output, and come back with an answer.

A couple of hours for something that should take seconds. The AI to do this already exists. So why am I still the one doing it?

The model was not built to be handed off.

The assumptions are not documented anywhere. The drivers are not labelled. The logic is split between the spreadsheet and my head. It works because I am the one operating it. Someone else, or something else, would not know where to start.

This is what I have started thinking of as assumption legibility: whether the logic of your financial model is explicit enough, structured enough, and clean enough that something other than you can actually operate it. For most finance teams, and honestly for most of my own work, the answer is no. Not because the team is unsophisticated. Because the model was never designed with delegation in mind.

The design problem nobody is naming

Finance functions have always been staffed, not designed. You hire a controller when things get complex. You add an FP&A analyst when the business needs more forecasting horsepower. The org chart scales with the business and the people figure out how to make it work.

That model made sense when the unit of work was a human task. Humans are good at navigating ambiguity. They can pick up a messy spreadsheet, figure out what the original builder was thinking, and get something useful out of it. It is inefficient, but it works.

AI does not work that way. It operates on structure. It needs clean inputs, explicit logic, and defined boundaries. It can do extraordinary things inside a well-designed system and very little inside a messy one. The quality of the output is mostly a function of the quality of the system it is operating in.

So the question shifts. It is no longer what can AI do. It is what does my finance function need to look like for AI to actually be useful inside it. That is a design question. And most finance teams have not asked it yet.

What designing for delegation actually means

Think about what it would take for an AI to answer a what-if question on your forecast. It would need to know what the key drivers are. It would need to understand how those drivers connect, which assumptions feed which outputs. It would need rules for what is allowed to change and what is not. And it would need to know when to stop and ask rather than guess.

None of that is complicated. It is just good model design. Separate your assumptions from your calculations. Label your drivers. Document your logic. Make the model readable to someone who did not build it.

The irony is that these are things finance teams have always known they should do. Model documentation, assumption transparency, audit-readiness. These are old ideas. What is new is that they are now the price of admission for AI to be useful. When the reader of your model is an agent rather than a colleague, the stakes for legibility go way up.

The bottleneck is not the AI. It is that most finance functions were never designed to be handed off. Fixing that is not a technology project. It is a design project. And it is probably the most important thing a finance team can do right now.