Open Control is a self-hosted system for teams that want the speed of coding agents without losing operational control. It turns a software objective into a tracked agent run, independent verification evidence, a human decision boundary, and a reviewable outcome.
Current status: Open Control is an actively developed private evaluation build. This repository is a public product showcase, not the application source, an installer, or a production-readiness claim.
Coding agents can write useful software, but serious team use introduces harder questions:
- What exactly is running, and what state is it in?
- Did the result actually pass checks independent of the agent?
- What happens if a worker or network connection disappears midway?
- Can a sensitive external action happen twice after an uncertain response?
- Who approved the action, and what exact proposal did they see?
- Can a reviewer reconstruct the outcome without reading an unbounded transcript?
Open Control is designed around those questions. It treats recovery, verification, approval, and evidence as product features—not afterthoughts.
- Submit an objective — an authenticated operator describes a bounded software task and selects an available coding-agent runtime.
- Track durable execution — Open Control records lifecycle state so interruptions do not turn the run into a mystery.
- Verify independently — configured checks evaluate the result separately from the agent that produced it.
- Review the evidence — operators see the timeline, checks, artifacts, and proposed consequential action.
- Approve the exact proposal — an authorized human can approve or reject the specific payload presented for review.
- Record the outcome — the system keeps the decision, external receipt, and terminal result together.
Learn more in How Open Control works.
AI-generated concept mockup using synthetic data. It is not a production screenshot.
The operator experience is centered on a small number of meaningful states: pending, running, waiting for approval, verified, failed, cancelled, and ambiguous. The goal is to make the next safe action obvious without requiring an operator to understand the orchestration engine underneath.
AI-generated concept mockup using synthetic data. It is not a production screenshot.
AI-generated concept mockup using synthetic data. It is not a production screenshot.
- Project and agent-run creation
- Durable workflow progression and lifecycle events
- Web control room and command-line operator interface
- Independent test, build, health, and policy checks
- Evidence and artifact collection with hashing and safety limits
- Human approval before protected operations
- Viewer, operator, approver, and administrator roles
- Authenticated API, browser, and command-line access
- Cancellation, failure handling, and worker-restart recovery tests
- Duplicate-action protection and blocked ambiguous outcomes
- Coding-agent adapter foundations
- GitHub action boundary foundations
- Self-hosted container deployment configuration
- Structured operational logging and request correlation
These capabilities have source and automated-test evidence in the private build. They do not establish that every live agent, deployment environment, or external integration is production-qualified.
See Current status for the evidence boundary.
Open Control is primarily:
- A self-hosted server application
- A browser-based operator console
- A background workflow and worker system
- A command-line operator tool
It is not currently a native desktop application, mobile application, browser extension, or hosted multi-tenant service.
The private implementation uses:
- TypeScript and Node.js for application services and shared domain logic
- React for the browser-based operator console
- Temporal for durable workflow orchestration
- PostgreSQL for operational, approval, evidence, and audit records
- Docker Compose for the current self-hosted deployment profile
- Vitest for automated unit, contract, security, integration, and recovery tests
- Playwright and Chromium for real-browser evaluation
- GitHub integration foundations for reviewable pull-request proposals
- PowerShell for supported Windows evaluation workflows
This list intentionally stays at the product-technology level. Private configuration, interfaces, schemas, and operational procedures are not published here.
The run lifecycle separates agent execution, verification, human decisions, and external effects. Durable workflow state allows the system to recover from process interruption without pretending that every interrupted operation is safe to replay.
An approval is tied to the exact proposal presented to the reviewer—not merely a generic “continue” signal. The design associates the decision with the operation, proposal digest, policy context, approver, and validity window.
When an external system may have accepted an action but its response was lost, Open Control blocks the outcome for reconciliation. It does not blindly retry a consequential action and hope duplication does not occur.
An agent reporting success is not sufficient. Open Control treats verification as a separate stage and records checks and artifact evidence for operator review.
Viewing evidence, launching work, approving protected actions, and administering the system are separate permissions. Accepted decisions are attributable to authenticated principals.
The private build applies path containment, file-type rejection, bounded output, artifact quotas, and hashing to reduce the risk of collecting unintended host data.
Read the conceptual architecture and security model.
AI-generated concept diagram. It deliberately omits private interfaces, configuration, and network details.
The first focused job is:
Turn a software objective into a verified pull-request proposal using a selected coding-agent runtime, durable recovery, an exact-proposal approval boundary, and a reviewable evidence bundle.
Open Control is not trying to become a generic workflow canvas, autonomous company simulator, universal model gateway, or catalogue of hundreds of integrations. Breadth should follow observed customer need rather than precede it.
See Product vision.
Before Open Control should handle valuable repositories or production credentials, the project still needs complete qualification of task isolation, restricted agent networking, live agent adapters, live GitHub delivery, operational monitoring, backup and restore, upgrades and rollback, and clean-machine acceptance.
The current build should be treated as a private evaluation system—not a supported production service.
This public repository contains explanatory documentation and original AI-generated synthetic concept images only. The application implementation remains private. Public visibility does not make the project open source or grant a license to private source code. See NOTICE and the public disclosure audit.