[🛠] AI Orchestration #3: Dogfooding an AI Orchestrator by Giving It Only a Goal in Telegram

✨ GPT-5.6 Sol’s Summary

A record of giving Telegram only the desired outcome—without specifying a project path or Agent—and fixing each obstacle until the PDF and XLSX came back.

Natural-Language Goals in Telegram and Automatic Project Discovery

I wanted to say “make this result” in Telegram and have the AI Orchestrator find the project, divide the work, fix flawed outputs, and send the files back. If it only called Codex once and returned an answer, there was little reason to build an Orchestrator.

Permissions were the first obstacle. Even inside each employee’s Cell, system-wide Codex restrictions made it difficult to discover projects outside the Workspace opened at startup. I removed that restriction for projects owned by the same macOS user, while keeping approval immediately before actions with external impact such as pushing, deploying, or sending messages.

Topic-Specific Response and Attachment Retrieval with a Telethon CLI

I built a Telethon-based CLI that could send commands to the AI Orchestrator Bot and receive its replies and attachments. Credentials and the user Session stayed outside the repository, while each project Topic served as a unit of work.

The first version of the CLI could exit successfully after merely sending a message. The command appeared to succeed even when the Bot’s final response or file never arrived.

I changed the completion criterion from local command termination to the actual receipt of a Telegram response and attachment. Even when I submitted work to different Topics simultaneously, each OpenClaw Session kept its context separate and returned the result to the original Topic.

Dividing Responsibilities Between OpenClaw Sessions and Codex Parallel Execution

Completion events were lost in short tasks created directly by OpenClaw, while Codex native sub-agents collected parallel results reliably. A structure that finished work but failed to retrieve completion could not serve as the Orchestrator’s execution baseline.

OpenClaw’s Task Flow alone made it difficult to bind child execution and completion state to one authoritative record. I therefore stopped treating Task Flow as the sole source of truth. OpenClaw handles Telegram, Topics, Sessions, and Memory; Codex handles project discovery, work decomposition, parallel execution, integration, and revalidation.

Streaming Progress Status in Telegram

Silence during a long task made it impossible to tell whether the process had stopped, while exposing internal commands made Telegram look like a terminal dump. During execution, I updated at most four Korean status lines and deleted that message when the final result arrived.

Telegram alone now showed whether the system was gathering material or producing the deliverable.

Automatic Agent, Skill, and Tool Selection with Deliverable Revalidation

Once the individual features were connected, I deliberately tested the most inconvenient usage. I acted as the ultimate decision-maker, asked Codex to serve as acting CEO, and gave the AI Orchestrator only the desired outcome. I specified no project path, model, Agent, Skill, Tool, or execution order.

The AI Orchestrator found the relevant project, selected the necessary Skills and Tools, and ran Codex native sub-agents for planning, engineering, and validation in parallel. It divided who should do what without me providing the path or method.

The returned PDF and XLSX were not correct on the first attempt. I rerendered the PDF with a TTF font after a TTC font broke the Korean text. For the XLSX, I fixed the incorrect date display and column layout, then rechecked formulas and rendering across every sheet.

Twenty-two minutes and six seconds after the request, the CEO Pilot decision brief PDF and two-week execution-management XLSX returned to the original Telegram Topic. The SHA-256 hashes of the files downloaded again from Telegram matched the generated originals. It was not merely a completion message; the actual files had completed the round trip.

Single-User E2E Validation and the Multi-User Isolation Gap

The single-user E2E flow reached the end, but 22 minutes was still too long for small everyday tasks. The same Agent that created the final deliverables also reviewed them, so I could not call that independent verification. I had also not yet tested a controller that manages all child-task states in one Task Graph and confirms final completion exactly once, or Session isolation between employees.

The next dogfooding run needs to verify first that two employees’ Sessions never mix. After that, I need to identify the longest bottleneck in the 22-minute flow. Both must pass before this can move from personal dogfooding to a system employees use together.