Orqetra — The Execution OS for AI

orqetra-execution-os-hero
orqetra-separation-of-responsibility
orqetra Execution Lifecycle & Governance Layer
orqetra-Connection/Email Target Lock
orqetra-Verified Completion After Submission
orqetra-Final approval before submission
Build Week Sandbox：Happy Path
Build Week Sandbox：Hallucination Containment
Build Week Sandbox：Teach Once

Inspiration

AI can generate useful answers, but real work often requires something to happen outside the conversation.

A message must be prepared, a business form must be completed, a document must be saved, or an existing workflow must move forward. The moment AI begins affecting an external system, intelligence alone is no longer enough.

A fluent answer is not proof that an action is permitted, grounded, executed, or complete.

That problem inspired Orqetra.

Orqetra is a human-directed Execution OS for AI. It transforms natural-language intent into controlled, reviewable, and verifiable action.

Its foundation is a separation of responsibility:

AI reasons and proposes.
Programs enforce safety boundaries.
Humans decide.

Models can interpret information, reason about a request, and compose useful output. But a model cannot grant itself permission to act, and a convincing response cannot override a program-enforced boundary.

Between AI reasoning and real-world execution, Orqetra applies explicit contracts that define the intended outcome, supporting information, permitted scope, required authorization, and evidence needed to verify completion.

Orqetra does not claim that AI will never hallucinate. Instead, it is designed to prevent unsupported output from becoming a real-world action merely because a model produced it.

The project also began from a personal challenge.

I am the founder of Utena Inc., and I cannot read or write source code.

I built Orqetra by making product and architectural decisions in natural language while ChatGPT and Codex translated those decisions into working software. During Build Week, GPT-5.6 helped structure and evaluate the new judging experience, while Codex implemented, tested, diagnosed, and iterated on it.

What it does

Orqetra helps users move from natural-language intent to a verified outcome.

Its execution lifecycle is:

Natural intent
→ AI proposal
→ Contract checks
→ Human authorization
→ Bounded execution
→ Readback
→ Verified Completion

In the Build Week demonstrator, the user describes the outcome they want. GPT-5.6 composes a structured execution proposal inside a fictional business environment.

Orqetra then:

shows the proposed action before execution;
checks whether the proposal is supported and eligible;
binds the action to an explicit target and scope;
requests human approval at the required boundaries;
executes only the permitted action;
reads back the resulting state; and
reports completion only when the observed evidence matches the approved proposal.

A successful model response is not treated as successful execution.

If the available information does not support the requested action, Orqetra stops safely. An unsupported proposal cannot advance to approval or external execution.

This is how Orqetra contains hallucination at the execution boundary:

The AI can propose, but it does not possess execution authority.
Programs enforce scope, eligibility, and required conditions.
The human decides whether an eligible consequential action may proceed.
The result is verified after execution rather than assumed from the plan.

This is not simply “AI watching AI.” The enforcement boundary does not depend on a second model agreeing with the first model.

Why we call it an Execution OS

Orqetra is not called an OS because it replaces Windows, macOS, or a device operating system.

It is an Execution OS because it provides a common execution layer between AI reasoning and the applications, browsers, desktop environments, and business systems where work takes place.

Just as an operating system mediates access between applications and computing resources, Orqetra mediates access between AI-generated intent and real-world action.

A conventional AI application is usually built around one workflow or one application. Orqetra is designed to apply the same execution principles across different workflows and execution surfaces:

define the intended outcome;
bind the action to an explicit scope;
require evidence and authorization where necessary;
execute only through permitted capabilities;
read back the resulting state; and
distinguish a proposed result from a verified result.

The individual application or workflow can change. The execution lifecycle, authority boundaries, and verification requirements remain consistent.

Email is therefore only one execution surface. Orqetra is not a Gmail assistant; it is the governed execution layer between AI intent and the external system being operated.

Designed for systems without dedicated APIs

Orqetra does not require every target application to provide a dedicated, application-specific API.

It is designed to observe and operate through existing browser and desktop interfaces. This means the same execution model can extend beyond modern SaaS products to legacy enterprise systems, internal administration tools, and older business software that may not provide suitable APIs for AI agents.

Many important business workflows still depend on systems that were never designed for AI. Replacing all of those systems or building a custom integration for each one is often unrealistic.

Orqetra is designed to bring governed AI-assisted execution to the interfaces organizations already use.

A user-first structure

Most automation platforms begin with the tools, APIs, and schemas available to developers. The user must adapt their request to whatever integrations have already been created.

Orqetra begins with the user’s intended outcome.

The user describes what they want to accomplish in natural language. Orqetra then determines how that intent can be expressed through available, permitted capabilities while keeping authority and consequential decisions with the human.

This is a user-first rather than developer-first structure.

Developers can still create and connect capabilities, but users should not need to think in terms of APIs, tool schemas, or implementation details before they can express their goal.

Teach Once, Run Safely

Once a workflow has been reviewed and validated, Orqetra can reuse that capability for similar work with new case-specific inputs.

“Teach Once” does not mean surrendering control or replaying old data blindly. New inputs remain isolated, required approvals remain in place, and every execution must produce its own evidence.

This allows operational knowledge to be reused without rebuilding the entire workflow for every case.

Cost-conscious execution

Orqetra uses AI selectively where interpretation, reasoning, or composition creates value.

Conventional software handles repeatable checks, permissions, state transitions, and mechanical operations when model reasoning is unnecessary. The goal is not to maximize model calls, but to use intelligence where intelligence is useful and conventional software where deterministic execution is more predictable and efficient.

Potential applications include customer support, sales operations, back-office work, document workflows, and browser- or desktop-based enterprise systems.

Natural intent in. Verified action out.

How we built it

Orqetra existed before OpenAI Build Week. This submission focuses on the meaningful extension created during the Build Week submission period using GPT-5.6 and Codex.

For the challenge, we created a self-contained judging demonstrator that expresses the core Orqetra execution experience inside a controlled, fictional business environment.

It allows judges to experience:

proposal generation;
hallucination containment;
human approval;
bounded execution;
execution readback;
evidence-backed Verified Completion; and
Teach Once with new case-specific inputs.

Judges can test these concepts without installing our closed-alpha production components or connecting Orqetra to third-party business systems.

Our development process followed its own separation of responsibility:

I defined the product vision, architectural principles, priorities, safety decisions, expected behavior, and acceptance criteria.
GPT-5.6 helped structure requirements, examine risks, challenge assumptions, compose execution proposals, and evaluate the Build Week experience.
Codex inspected the project, implemented the demonstrator, created tests, investigated failures, and iterated on the software.

I did not manually write the implementation code.

My role was to make product and architectural decisions, test real behavior, identify false success, reject results that did not meet the intended contract, and direct each iteration in natural language.

This became especially important during testing. A passing test suite or healthy server did not automatically mean the product experience was correct. We compared reported success with actual user-visible behavior and continued iterating whenever the two did not match.

Orqetra is patent pending in Japan. The submitted repository contains the standalone Build Week demonstrator and its development history. It does not contain the proprietary production implementation or patent-sensitive internal mechanisms.

Challenges we ran into

The first challenge was separating intelligence from authority.

AI needs enough freedom to interpret natural language and prepare useful work, but that does not mean it should define its own permissions. We had to preserve the value of AI reasoning while ensuring that program-enforced boundaries and human judgment remained independent.

The second challenge was preventing fluent output from being mistaken for completed work.

An AI can describe an action as though it succeeded. Orqetra therefore needed to distinguish clearly between:

what the AI proposed;
what the program permitted;
what the user approved;
what the system executed; and
what the system observed afterward.

The third challenge was balancing useful automation with meaningful human control.

A system that asks for confirmation at every mechanical step becomes frustrating. A system that hides consequential decisions behind automation becomes difficult to trust. We focused human attention on the moments that grant authority while allowing conventional software to handle bounded, repeatable operations.

The fourth challenge was making the experience reproducible for judges.

The production version of Orqetra works with local browser and desktop environments. Those closed-alpha components are neither practical nor appropriate to distribute for hackathon testing. We therefore built a controlled judging environment that demonstrates the execution principles without exposing production infrastructure or proprietary implementation details.

The fifth challenge was developing software through natural language.

A non-coding founder can make engineering and architectural decisions, but those decisions must be precise. We had to translate observations such as “this result is not trustworthy” into explicit behavior, reproducible tests, and measurable acceptance conditions.

Finally, we had to distinguish the pre-existing Orqetra system from the meaningful extension completed during Build Week. The submission, repository, and development history document that boundary.

Accomplishments that we're proud of

We are proud that the Build Week demonstrator provides a complete execution experience rather than only a concept or presentation.

A user can:

describe an intended outcome;
inspect a GPT-5.6-generated proposal;
see an unsupported action contained before execution;
authorize an eligible action in stages;
observe execution readback;
receive evidence-backed Verified Completion; and
reuse a validated workflow with new case-specific inputs.

The experience demonstrates the three-part separation at the heart of Orqetra:

The AI proposes.
The program protects the boundary.
The human grants authority.

No single participant controls the complete chain from interpretation to consequential action.

We are also proud of how the project was built.

A founder who cannot read or write code directed the creation of a technically ambitious product by working in natural language with ChatGPT, GPT-5.6, and Codex while remaining responsible for product judgment, architectural decisions, and final acceptance.

The result demonstrates a different way of building software: human intent and accountability combined with AI-assisted reasoning and implementation.

We also created a judging experience that is accessible and reproducible while keeping the patent-pending production system protected.

What we learned

We learned that generating a good answer and completing real work are fundamentally different product problems.

A good answer is evaluated by its content. A real-world action must also be evaluated by its authority, scope, evidence, execution state, and observed result.

We learned that hallucination containment cannot depend only on asking an AI model to be careful or asking another model to judge it. Safety at the execution boundary requires responsibilities and constraints that a model cannot redefine through language.

We learned that human involvement should not mean manually performing every step. The human’s most valuable role is to provide intent, judgment, and authority at the moments that matter.

We learned that verification must be based on the resulting state, not on the AI’s statement that the task was completed.

We also learned that user-first design changes how AI systems should be built. The starting point should be the outcome a person wants—not the APIs, schemas, or tools a developer happened to expose in advance.

Finally, using GPT-5.6 and Codex did not remove the need for product leadership. It made precise product decisions even more important. AI can accelerate reasoning and implementation, but the human must still define the goal, recognize false success, and determine what behavior is acceptable.

Most importantly, we learned that people who cannot program can still create technically ambitious products when they can communicate intent clearly, test actual behavior, and retain responsibility for the result.

What's next for Orqetra — The Execution OS for AI

Next, we will expand the range of work Orqetra can support while preserving the same separation of responsibility across every execution surface.

We plan to improve how natural-language requests become reusable capabilities, strengthen evaluation across different business workflows, and make the system easier for organizations to test safely.

We will continue developing the production browser and desktop experience separately from the standalone Build Week demonstrator, including support for systems that rely on existing user interfaces rather than modern application-specific APIs.

Our long-term goal is to make AI useful beyond conversation without asking people to surrender control over what happens in the real world.

AI should be able to think powerfully without defining its own authority.

Programs should protect boundaries without pretending to make human judgments.

Humans should remain responsible for consequential decisions without being forced to perform every mechanical step themselves.

That is why Orqetra is an Execution OS for AI.