Execution Is Not the Bottleneck

While redesigning Nimbus, we expected to spend most of our time on execution.

How should agents collaborate? How should tasks be distributed? How much autonomy is safe? Which models should do which work?

Like many AI builders, we assumed the hard problem was getting intelligent systems to do things.

We were wrong.

The original assumption

The first version of Nimbus was built around execution: a project enters, tasks are created, agents work, results are reviewed. Input → workflow → output. Improve execution, improve the system—better models, better agents, better orchestration, better automation.

That logic holds until the system becomes more capable. Then a different failure mode appears.

What we started seeing

Execution got better. Understanding did not.

Tasks drifted from the reason they existed. Conversations wandered. Context fragmented. Decisions were hard to trace. The system could perform work perfectly while moving in the wrong direction.

That was not a model problem, an orchestration problem, or a workflow problem. It was an understanding problem: the system often knew what to do, not always why.

Durable context beats thread-only memory when you need shared “why”—see Chat is a bad system of record and Living memory for your project.

A simple thought experiment

Two project owners give the same instruction:

Improve the onboarding experience.

The words match. The intent does not.

One wants higher conversion. One wants fewer support tickets. One wants a more premium feel. One wants less implementation complexity.

An execution-focused system sees one task. An understanding-focused system sees four different problems.

The instruction is identical. The intent is not. That distinction matters more than we expected.

What we learned

One of the first major lessons from Nimbus 2.0: execution is rarely the primary bottleneck in intelligent systems. Understanding is.

Before a system can plan, execute, coordinate, automate, or learn, it must understand enough to act appropriately. That takes more than a prompt: context, relationships, history, constraints, authority, goals, trade-offs.

Execution is downstream of understanding.

Poor inputs still stall automation—see The real bottleneck is not AI—it’s inputs. Here we are naming the layer above that: even good inputs fail when intent and situation are not held together over time.

A shift in perspective

We stopped asking only how do we make agents execute better? and started asking how do we make systems understand better?

That points to a different architecture:

• Less emphasis on workflows alone; more on interpretation
• Less emphasis on tasks alone; more on intent
• Less emphasis on raw autonomy; more on context and governance—aligned with Optimize for alignment, not autonomy

The goal is not always a system that works faster. It is a system that works on the right problem.

Why this matters beyond Nimbus

As models improve, execution commoditizes—generation, code, reasoning, task completion get cheaper every year.

Understanding stays hard. It needs context. Context needs structure. Structure needs design—in the system around the model, not inside the model weights alone.

The more capable the model, the more important that surrounding architecture becomes.

Open question

If execution is not the bottleneck, what should be the fundamental unit of an intelligent system—tasks, workflows, memory, or something else?

That is what we are exploring in Nimbus 2.0. One active experiment is What if every conversation became an object?—Work Packets as traceable intent before execution. It leads directly to the next thread: Intent before specific—why intent may matter more than the instruction alone.

The insight: optimize for understanding first; execution follows when the system knows why, not only what.