My Ideal Agent Orchestrator
My Ideal Agent Orchestrator
It’s February 2026 so like everyone else I’m thinking a lot about AI agent orchestration.
Bret Taylor recently wrote about this:

The software industry has spent 50 years failing to come up with ways to specify the details of software outside code.
It’s easy to say “just write it in English” but in practice that devolves to a pseudo-code language very quickly, and who wants a spec that has
while (something)
if (x > y) and (z != v) then
do something
else if z > v then
something else
etc
for hundreds of lines? I mean that basically is code.
Maybe that’s where we end up, but much of the time we don’t want to do that. We want the AI to derive that from our broader instructions, and we are happy to go with it.
Except when we aren’t - and then we want to specify the exact behaviour. Sometimes that is in code, sometimes it is in a specification.
At the moment there’s not a great way to tell a AI “THIS IS SOMETHING WE DON’T WANT CHANGED” outside of tests.
Tests are useful to direct behaviour. But because we need so many to keep the AI doing the correct thing we end up overwhelmed with thousands of test cases for fairly small programs, and we have to use AI to maintain them too.
And then we end up with the same problem “Yes AI Agent you can change the tests, except for the tests I don’t want you to change.”
This isn’t a solved problem, especially when you have tens or hundreds of agents writing thousands or tens of thousands of lines of code a day.
Obviously the agent orchestration layer needs to fix this. But how?
Levels and Locks
I think an agent orchestration layer should have two new concepts:
- Levels
- Locks
Levels is the idea of being able to say “for this area I want to view the current agent progress at the code level, while at this other area I want to view it at the feature completion level”.
This concept works together with the concept of Locks. A lock is a way of telling an agent “don’t do anything that changes this thing”. That thing could be a key piece of code, a key test case, or a requirement written in English that must be kept.
Here’s a rough exploration of that concept. Play with it (it’s interactive!) and let me know what you think!
