Behind the builder / 31 July 2026
Sixty-seven steps. Please do not add step sixty-eight.
Sixty-seven steps and eleven agents gave UBIKITOS an execution queue. The most useful instruction was smaller: finish the next steps before adding anything else.
The plan finally had a queue
By the last day of July, UBIKITOS had acquired something more useful than another ambitious diagram: a sequence. The foundation work had been translated into a sixty-seven-step roadmap, instructions for the individual steps, and a just-in-time build queue involving eleven agents. That is a lot of numbers for a company still trying to prove a complete working loop. The most useful sentence attached to them was considerably shorter: finish the next steps and add nothing else.
This is one of the less glamorous problems in building an AI system. It is easy to generate possible work. Ask for improvements and you can obtain enough suggestions to occupy several imaginary departments. Choosing the order, defining a finish line, and preventing every interesting suggestion from becoming an immediate obligation are harder. July ended with a more credible answer to that problem, even though most of the implementation was still ahead.
A roadmap is a promise about order
The point of sixty-seven steps was not to make the project sound large. Large was already available. The point was to make dependencies visible. Some work creates the conditions for later work; some work only becomes sensible once the earlier part has survived inspection. Without that distinction, an agent can deliver an impressive component that nobody can safely use yet. The output exists, but the project has not necessarily moved closer to a working service.
Think of a restaurant preparing to open. Designing the dessert menu is real work. So is installing a working refrigerator. Doing the first beautifully does not excuse forgetting the second. That is an illustration, not a new UBIKITOS customer story, but it captures what an execution roadmap should protect against. It should make the necessary sequence difficult to ignore. A plan that merely collects attractive tasks is a wish list wearing a project manager's jacket.
Eleven agents do not remove the founder
The eleven-agent queue also needed the right interpretation. Eleven agents are not eleven independent employees who understand the business and quietly handle everything. Each agent needs a bounded assignment, relevant context, a clear output, and a way for that output to be checked. Otherwise, increasing the agent count increases the number of confident answers that the founder has to reconcile. There is no productivity prize for creating eleven different versions of the same misunderstanding.
Just-in-time instructions help because the next assignment can depend on what actually happened in the previous one. A later task should not be written as though an earlier assumption has already become true. If a test fails, the queue needs to reflect that failure. If a dependency changes, the next agent needs the changed dependency. The useful intelligence is partly in deciding what work should be available now, rather than exposing every agent to the entire mountain at once.
The small finish line inside the big one
The immediate target was steps three through six and the first agent acceptance tests. That sounds modest next to a sixty-seven-step programme, which is exactly why it was useful. A small finish line makes it possible to inspect what happened. Did the required output appear? Does it match the instructions? Can the next stage use it? Is there evidence beyond the agent saying that the task is complete? Those questions are much easier to answer about four steps than about a whole imagined company.
Acceptance tests matter especially when the work is being produced by systems that are good at explanation. A fluent description of a change can feel like evidence of the change. It is not. The check needs to examine the thing being claimed. In a software project, that might mean exercising a behaviour instead of reading a summary of it. In a document workflow, it might mean checking the actual fields and destination. The principle travels well beyond code.
The temptation to improve the plan
There is a particular trap here: once a plan becomes clear, it becomes easier to see ways to improve it. A new dashboard could make it easier to follow. Another agent could handle review. A richer knowledge layer could make every instruction smarter. Each suggestion can be individually reasonable while the collection makes the immediate goal harder to reach. The phrase “add nothing else” was a direct response to that accumulation problem.
I do not read that as an argument against ideas. The project exists because of ideas. It is an argument for keeping new possibilities from borrowing time that has already been assigned to unfinished essentials. An idea can be recorded without being activated. A future improvement can remain a future improvement. That separation is surprisingly important when the tools can produce plans faster than the underlying work can be verified. The backlog should hold possibilities without turning them into promises.
What changed, and what did not
What changed on July thirty-first was the quality of the route from foundations to execution. The work had a detailed sequence and assignments that could be issued when needed. That made the programme more concrete. What did not change automatically was the operational status of UBIKITOS. A credible roadmap does not demonstrate a running mission. Agent instructions do not demonstrate that agents followed them. A queue does not demonstrate that its last item has been reached.
Keeping those distinctions visible is useful for a founder because planning creates its own sense of momentum. There is real satisfaction in finally seeing how the pieces could fit. The danger is spending that satisfaction twice: once for designing the route and again as if the journey had already happened. Today deserved credit for making the next work executable. It did not need a larger claim to justify its place in the story. Clearer work is valuable on its own terms.
Tomorrow needed fewer options
The next move was therefore deliberately narrow: complete the next four steps, pass the first acceptance tests, and let their results determine what could proceed. That is a more practical ambition than announcing that an eleven-agent organisation is ready to take over. It gives the founder somewhere specific to look and gives the agents something specific to finish. Most importantly, it creates a result that can change the plan through evidence rather than enthusiasm.
July began with the challenge of turning broad creative momentum into one governed flagship system. It ended with a queue that could, in principle, make that ambition less dependent on remembering everything at once. The interesting question for August was whether the instructions would survive contact with actual execution. Sixty-seven steps were enough to ask that question. The next breakthrough did not need to be step sixty-eight. It needed to be one of the existing steps, genuinely finished.