Orquesta

Why I built Orquesta

I started Orquesta because I kept running into the same problem with coding agents: execution was improving faster than judgment.

An agent can write code once the task is clear. But real development starts earlier. What capabilities does the task need? Should we reuse an existing open-source project, adapt a library, build from scratch, ask the user, or stop? Who should own the work? How much context should that specialist read? And when a system says that work was dispatched or completed, what evidence proves it?

Orquesta turns that missing decision layer into a product.

The first concept is durability. This is not a short multi-agent automation demo. Orquesta is meant for one-, two-, or three-month development efforts where specialists, decisions, questions, and user intent must survive far beyond one context window.

As specialists work, they accumulate questions for the user. Those answers are curated into explicit vision, anti-vision, constraints, and decisions. The goal is to make human metacognition and tacit knowledge durable project state, then give only the relevant part back to each specialist.

What it does

Orquesta is a local-first Windows command room for Codex teams. Instead of treating every agent as a disposable chat, it keeps an orchestrator and long-lived specialists with explicit roles, scoped context, task contracts, and file-backed project state.

The Desktop application gives the user one place to understand what is happening:

• A live organization map showing both working and idle specialists
• User Tasks for questions, approvals, reviews, and manual work
• Task, error, conversation, and decision records
• Project switching and a single Composer for messaging the orchestrator or a selected specialist
• Luca, a read-only project explainer grounded in saved project records
• Temporary External Comparison and Adversarial Audit agents
• A one-screen project intake and resumable six-phase setup experience
• Capability, Acquisition, Audit, and Evidence views for V4 decisions

V4 compiles task intent into capability needs and can compare REUSE, ADAPT, BUILD, ASK, or ABANDON. When local assets are not enough, it supports bounded discovery, static audit, and a small source-bound audition before adoption.

The evidence model is deliberately strict. Dispatch acceptance, turn start, progress, artifacts, reports, and final acceptance are separate events. Repository-only fallback cannot pretend that a live Codex turn ran. Requested, applied, and observed model identity are also separate; actual_model stays unknown unless runtime observation proves it.

How it is built

The Windows app uses Electron, React, TypeScript, Vite, and Node.js.

The Renderer is sandboxed. A typed, context-isolated Preload bridge connects it to Electron Main and a separate Core utility process. Repository access and Codex communication do not run directly in the UI.

Project truth is stored under .orquesta/. Codex App Server is the primary runtime path, with a bounded SDK fallback. The packaged Windows build pins and verifies the Codex SDK, Codex package, and Windows runtime before launch.

How I used Codex and GPT-5.6

Codex was both the development environment and the workforce I was designing for.

I used GPT-5.6 Codex threads as an actual Orquesta team: architecture, implementation, independent review, user support, and orchestration were separated into persistent roles with required reading and forbidden actions.

The most important part was not automatic code generation. It was the correction loop with a human user. Several changes passed tests and still failed usability review. The Home information architecture, task and history views, organization map, setup flow, and review cost policy all changed because the user could see the real Desktop app, explain what felt wrong, and send the work back.

That is the point of Orquesta: AI should not hide its coordination cost or replace human metacognition. It should make both usable.

The same applies to token cost. When GPT-5.6 first arrived, an expensive high-reasoning choice could be multiplied across every helper. Orquesta automatically recommends Luna, Terra, or Sol from task risk signals. The orchestrator can accept or override that route, and the Desktop passes the requested model to Codex App Server. Recommended, requested, applied, and independently observed model identity remain separate, so bounded work can use Luna or Terra and difficult work can escalate toward Sol without inventing runtime evidence.

What changed during Build Week

Orquesta existed before Build Week as a Codex skill and browser dashboard. During the submission period it was meaningfully extended into the V4 Windows Desktop product submitted here.

The new work includes the Desktop shell, organization map improvements, project intake, six persisted setup phases, animated setup presentation, Home tutorial, Luca, inspection agents, a tested adaptive-organization decision engine, and packaged Codex runtime integration.

The repository includes a dated BUILD_WEEK.md file that separates prior work from these additions. A Windows x64 preview installer is attached to the GitHub release linked below.

Challenges

The hardest problem was refusing to overstate what happened.

A browser screenshot is not proof of a packaged app. A fake runtime is not proof of a real Codex session. A successful dispatch is not successful work. I had to separate those proof classes in both the code and the product.

The other challenge was information density. A multi-agent system can generate hundreds of tasks, questions, errors, and conversations. The Home screen had to show what matters now without hiding the larger organization, while detailed records remained available without turning the entire window into one endless scroll.

What I am proud of

• A complete Windows Desktop experience rather than a dashboard-only prototype
• A visible decision layer before implementation
• Scoped specialist context instead of copying the full project into every agent
• Evidence-backed execution states that do not collapse dispatch and completion
• Bounded reuse and acquisition before rebuilding existing solutions
• A user review loop that changed the product instead of serving as a ceremonial approval step

Current limits and next steps

• The current submission targets Windows x64 and is unsigned preview software. Code signing, automatic updates, and macOS/Linux packages are future work.
• V4 Phase 3 will add an Experience Ledger and Intent Graph so past outcomes can improve later decisions without turning one user reaction into a permanent global rule.

I am not claiming measured superiority over every multi-agent framework yet. The contribution I am submitting is narrower and more concrete: Orquesta makes capability decisions, scoped ownership, human review, and execution evidence part of the developer experience.

Built With

• electron
• gpt-5.6
• node.js
• openai-codex
• react
• typescript
• vite