[🛠] AI Orchestration #4: Cutting Telegram Follow-Up Work from 22 Minutes to 9

✨ GPT-5.6 Sol’s Summary

A record of finding a same-Session self-deadlock, repeated discovery, and one-off verification in a real work canary, then cutting Telegram file-return time by 57.6% through existing generators, verifiers, and partial rework.

A Self-Deadlock Caused by a Canary in the Same Session

In the previous day’s dogfooding, I gave only a goal through Telegram and received a PDF and XLSX in return. The flow covered project discovery, role decomposition, parallel execution, rework, and file delivery, but it took 22 minutes and 6 seconds. If every small follow-up took that long, the system would be frustrating to use in practice.

I did not build a separate benchmark. I sent another goal in the same Telegram Topic: “keep the quality, but reduce the 22-minute turnaround.” I wanted to see whether the AI Orchestrator could locate the actual bottlenecks, improve the shared Workflow, and finish the follow-up file task itself.

The first validation immediately deadlocked. While handling the current request, the AI Orchestrator sent a canary into the same Session and then waited for its reply. The new request could not start until the current turn finished, while the parent could not finish because it was waiting for that new request.

I stopped only the waiting CLI and separated the product-change Topic from the canary Topic. This was not a model failing to do the work. It was an execution-boundary problem: an Orchestrator must not wait for the next task inside a Session it currently occupies.

Reusing Existing Generators and Verifiers for Partial Rework

The first canary in an independent Topic returned the files in 17 minutes and 35 seconds. It was faster, but the output incorrectly marked an already approved Pilot as awaiting approval again. A shorter runtime was not enough to call it a pass.

Following the actual execution showed repeated evidence discovery, polling of child work, and dependency checks that happened only after artifact generation had begun. There was also a significant cost from creating verification paths similar to ones that already existed instead of reusing the validated PDF and XLSX generators and verifiers.

I kept only the following rules in the shared Workflow:

• Fix the required evidence in one bounded snapshot.
• Collect child results through completion events instead of repeated polling.
• Reuse an existing generator or verifier instead of building another implementation.
• Apply only the latest decision and metric deltas, and rework only the defective scope.
• Run one final validation over the whole artifact and align its source provenance.

I corrected only the wrong approval state and wording in the first result, then reran the full render and independent reopen-and-save checks. The new flow did not rebuild everything from scratch. It changed only what had become semantically stale and then rechecked the integrity of the entire output.

A 9-Minute-23-Second Telegram Return with the Quality Gate Intact

The rework canary returned the PDF and XLSX through Telegram in 9 minutes and 23 seconds without user intervention. That was 57.6% faster than the original 22 minutes and 6 seconds, while orchestration tool calls fell from 56 to 21.

The result was not faster by skipping checks. I rechecked the rendering, structure, content, formulas, and independent open-and-save behavior of the two-page PDF and four-sheet XLSX. The files downloaded again from Telegram also had the same hashes as the generated originals. Finally, the system found that the Workflow provenance embedded in the files still pointed to an older hash and corrected only that value without disturbing the content or structure.

The most important decision was not counting the first 17-minute result as a success. If the latest decision is wrong, reducing the runtime only produces the wrong result faster. This improvement passed because the actual return time fell while the quality gate remained intact.

The Boundary Between Single-User v0.1 and a Multi-User Pilot

The current single-user v0.1 can take a natural-language goal, find the project, divide the work, verify the outputs, and return them through Telegram. It is still too early to call this fully unattended operation. I still had to stop the same-Session self-deadlock as the CEO, point out the semantic error in the first result, and request the missing local commit.

The next step is not another benchmark. I need to keep assigning real, non-sensitive work under the same quality boundary, accumulate turnaround times, and watch their distribution and regressions. Once connecting another user is approved, I also need to verify that two Cells can run concurrently without mixing Sessions, Memory, or files. A complete Task Flow controller is not the critical bottleneck on the current user path, so it remains a separate long-term track.