I watched the OpenAI chemistry demo twice before something clicked. The system picks a problem, designs the experiment, runs it, reads the results, adjusts, and tries again. A roughly 50% yield improvement on a real drug-chemistry task, with humans somewhere in the loop but not anywhere near the steps.

My read is straightforward: I was not looking at a tool. I was looking at a director's chair with nobody sitting in it.

That image stuck with me through Adobe's expansion of its creative agent a few days later, where the metaphor became literal. The creative agent now orchestrates multi-step workflows across Firefly, Photoshop, Premiere, and Illustrator. The creator describes the outcome. The assistant figures out the steps. Adobe used the language openly: the human sits in the director's chair while the agent handles execution.

Two different domains, same shape. The interesting question is not whether the loop can run itself. The interesting question is what work is left for the humans who used to do the steps.

When the steps disappear, the standard becomes the work

In the old workflow, leadership was distributed across people doing the steps. A chemist's instinct showed up in the bench protocol. A copywriter's taste showed up in word choice. A designer's judgment showed up in every layer. The work and the judgment traveled together. You could review the output and reverse-engineer the standard that produced it.

In an autonomous loop, those two split apart. The agent does the work. Judgment has to be made explicit, in advance, or it does not show up at all.

This is the part I think a lot of leaders are quietly underestimating. They are still thinking about AI in terms of capacity: how much more can we ship, how many variants can we produce, how many experiments can we run. The OpenAI lab and the Adobe agent are not capacity stories, though. They are control-surface stories. The bottleneck moves from execution to the design of three things:

  • The problem the loop is allowed to pick up.
  • The constraints the loop must respect.
  • The artifacts that prove an output meets the standard you are willing to ship.

Those artifacts are the part most teams have not built. They are also the most boring sounding part of the job, which is why they tend to be skipped.

I mean specific things here, not abstractions. A decision log that captures what the system chose to try and why. A run summary that records what changed between iterations and what the agent learned. An outcome lineage that traces a finished asset, molecule, or campaign back through the choices and constraints that produced it. A constraint manifest that says, in writing, what the loop is not allowed to do.

These are not compliance documents. They are leadership documents. They are the artifacts a sharp colleague can read in ten minutes and decide whether what just came out of the machine deserves a budget, a customer, or a renewal.

The commercial failure mode

A pattern I keep coming back to in conversations with operators: teams that turn on autonomous loops, watch the throughput numbers climb, and then six months later cannot explain why the business did not move. The output volume looks like productivity. The commercial result looks like a flat line.

I have started calling this hollow usage. It is what happens when the loop runs end-to-end and no one is the human advocate for what the outcome actually has to prove. Brand integrity. Customer fit. Scientific reproducibility. Pricing power. None of these are emergent properties of the model. They are properties of the standard someone with judgment set before the loop ever started.

A public LinkedIn thread I joined recently made this sharper than I usually do. The argument was that the efficiency trap and the control trap share one root cause: you never defined working. Teams either optimize for speed in the old process or get stuck in permission loops, because no one agreed on operational success criteria. That pattern is not specific to pilots. It is the shape of any workflow where the value of the output depends on someone, somewhere, having defended what acceptable means.

When the loop is autonomous and acceptance is undefined, you are not buying advantage. You are buying motion.

What I would actually ask a team

I have stopped asking whether teams have deployed AI. The answer is always yes, and it rarely tells me anything useful. The question I have started asking instead is small: what does your workflow produce that an outsider could read and use to decide whether the output is ready to be shipped, sold, or scaled?

If the answer is the output itself, the loop has no acceptance layer. The output is its own argument, and the only argument it can make is that it exists.

If the answer is a decision log, a run summary, an outcome lineage, or something close to that, then the loop has a leadership artifact attached to it. Someone has done the work of saying: this, and not that. That artifact is what holds up in a budget review, a board meeting, a regulator's question, or a customer asking why they should renew.

This is where the work I wrote about in Integration Debt lands at the leadership level. Probabilistic execution meets deterministic acceptance, and the mismatch shows up at the decision layer every time. The fix is not a better model. It is a leader willing to define the standard in writing and refuse outputs that do not meet it. The same pressure shows up in the handoff artifact problem: the moment a human has to take responsibility for what the agent produced, whatever the agent did not write down becomes that human's liability.

This is also why the Adobe announcement matters more than its feature list suggests. Calling the human role the director's chair is not a marketing flourish. It is a job description. A director picks the project, sets the constraints, watches the rushes, and decides what gets cut. Almost none of that is execution. Almost all of it is acceptance.

The closing turn

There is a useful old discipline buried in here, and I am not going to dress it up. Withholding agreement until the standard is met is the actual job. The agent will execute whatever you let it execute. The model will improve as long as you let it iterate. The output will pile up as long as you keep the loop running. None of that is leadership. Leadership is the part where someone decides what counts.

Before turning on more autonomy, the question I would ask is small and specific: what does this workflow produce, today, that I would be willing to put on a table and defend when the budget gets tested?

If the only answer is the output, the loop is faster than your judgment, and the gap will show up in the numbers eventually.

The discipline is not in the doing. It is in the decision to say this, and not that.

Sources and further reading