Alpha Omega

Inspiration

What it does

How we built it## Inspiration

Most AI products give you a fixed interface and a fixed set of tools. When your needs change, you wait for the product team, install another integration, or rebuild the application yourself.

I wanted the opposite: a workspace that can change with its user.

Alpha Omega began with a simple question:

What if you could describe the software you need, and your workspace could safely build it, test it, install it, and evolve itself?

The result is not just another chatbot. Alpha Omega is a fully customizable AI workspace and sandbox where conversation can become real tools, interfaces, automations, and persistent workspace capabilities.

What it does

Alpha Omega lets a user describe what they need in natural language.

From that request, the system can:

Design and build a workspace tool
Generate or modify an interface
Test the resulting capability
Request permission before sensitive actions
Install the tool into the current workspace
Run it inside a controlled sandbox
Track its progress through durable events
Preserve versions and recovery information
Disable, revoke, or remove capabilities later
Recover failed requests without silently repeating side effects

A user can ask for something like a tool that retrieves online content, review exactly which domain it needs to access, approve that permission, watch the build progress, and then use the installed tool directly inside the workspace.

Alpha and Omega

The project is built around two complementary responsibilities.

Alpha: trust and control

Alpha is the authority layer. It protects the workspace by enforcing:

Workspace and tenant isolation
Explicit permission approvals
Network and external-action restrictions
Scoped tool access
Authentication and recent-auth checks
Row-level database security
Revocation and uninstall rules
Sandboxed execution boundaries
Audit evidence and safe recovery paths

Alpha is designed to fail closed. A generated capability cannot simply grant itself access or bypass the user’s approval.

Omega: creation and evolution

Omega is the engineering layer. It turns a request into a durable development run that can plan, implement, test, validate, and activate workspace changes.

Omega can evolve the workspace without treating the user’s request as a disposable chat response. Runs are persisted, progress can be restored, failures remain visible, and successful changes become tracked workspace versions.

Together, Alpha and Omega make customization powerful without making it uncontrolled.

How it works

A typical Tool Forge flow looks like this:

The user describes a capability.
Omega creates a specification covering behavior, risks, permissions, tests, and budgets.
Alpha presents the exact requested access to the user.
The user approves or rejects the request.
The capability is built and tested.
Independent validation checks the result.
The tool is installed into the workspace.
Future invocations are schema-validated, permission-checked, sandboxed, and audited.

The same foundation supports broader workspace evolution, including interface changes, version history, runtime recovery, memory controls, approvals, and factory reset.

Reliability and security

A customizable AI system becomes frustrating very quickly if it fails every few minutes or loses track of its own work. A large part of this project therefore focused on durability rather than only the visible demo.

Alpha Omega includes:

Durable engineering runs and background workers
Idempotent retry handling
Conversation and request persistence
Cancellation, bounded retries, and stale-run reconciliation
Structured error and recovery states
Runtime health and readiness checks
Request IDs and structured operational logs
Scoped memory with retention controls
Version history and human-readable change evidence
Checksummed exports
Trusted factory reset
CSP, HSTS, frame protection, SSRF defenses, and origin validation
Responsive and accessible keyboard-first interaction

The production system was tested at desktop, tablet, and mobile widths.

How I built it

The application uses a full-stack TypeScript and React architecture with Next.js.

Supabase and PostgreSQL provide authentication, persistent workspace state, durable run records, and row-level security. Generated and evolving capabilities run behind controlled sandbox boundaries. Netlify hosts the production application and scheduled maintenance jobs.

The quality system includes:

Vitest application and contract tests
pgTAP database and RLS assertions
Playwright desktop and mobile browser journeys
TypeScript and ESLint checks
Sandbox type-checking
Production builds
Dependency and secret scanning
Live health, security-header, and console verification

How Codex was used

Codex was used as an engineering environment throughout the Build Week work.

I used it to inspect the repository, trace failures across the API, database, workers, and interface, implement coordinated fixes, create migrations, refactor large components, add regression tests, run browser validation, and verify production deployments.

One important example was a hidden request-size mismatch. The chat interface accepted a long request, while several downstream database and worker layers rejected it at a smaller limit. Codex helped trace every boundary, update the contracts together, add database and planner tests, deploy the migration safely, and prove the fix with a real long-running Omega request.

Codex was also used for the multi-phase reliability and interface improvement program, including tool lifecycle controls, retry idempotency, runtime recovery, responsive design, accessibility, and production verification.

How GPT-5.6 was used

GPT-5.6 powered the high-level reasoning used to analyze the system, plan multi-stage improvements, evaluate architectural risks, refine the product experience, and guide implementation across the stack.

It helped turn broad goals such as “make this a groundbreaking sandbox that just works” into concrete, testable phases covering contracts, orchestration, database authority, security, recovery, tool lifecycle, operations, and user experience.

Rather than using GPT-5.6 only for content generation, I used it as part of the engineering workflow: reasoning about failure modes, reviewing behavior, defining acceptance criteria, and coordinating changes that crossed the frontend, backend, database, runtime, and deployment layers.

Challenges

Making retries genuinely safe

Avoiding duplicate engineering runs was not enough. A retry could still duplicate a conversation or user message. I moved idempotency into the database authority layer so the entire request resolves to the original durable records.

Keeping permissions and interface state consistent

A revoked tool could previously appear enabled even though invocation would fail. I changed the lifecycle rules so revocation disables the installation atomically and the UI cannot disagree with Alpha’s authority.

Supporting large evolution requests

Different parts of the system enforced different request-size limits. A long workspace request could be accepted by chat and then rejected by the worker. I unified the limits across the API, database, RPCs, planners, workers, and Tool Forge path.

Testing real asynchronous behavior

Tool creation, installation, runtime provisioning, and reset are durable background processes. Browser tests had to wait for persisted events and prove the final state rather than treating the first successful HTTP response as completion.

Making a dense engineering product understandable

The workspace contains conversations, approvals, tools, versions, runtime state, recovery controls, and an evolving canvas. I redesigned the information hierarchy so chat and Omega remain primary while operational evidence appears when it is useful instead of occupying permanent columns.

What I learned

The largest lesson was that agentic software needs stronger product and systems engineering than a normal chat interface.

A model response is temporary. A real capability requires permissions, state, tests, versioning, observability, recovery, and a clear lifecycle.

I also learned that security and usability cannot be treated as separate phases. Permission details have to be understandable. Failures need recovery actions. Background work needs visible evidence. A sandbox is only useful when users can trust both what it can do and what it cannot do.

Accomplishments

During the final verification cycle, Alpha Omega reached:

251 passing application tests
256 passing database and RLS assertions
14 passing desktop and mobile browser journeys
Zero production dependency vulnerabilities
A healthy production readiness endpoint
Responsive verification at 1440px, 768px, and 360px
Working Tool Forge build, approval, installation, invocation, disable, and lifecycle controls
Durable Omega workspace evolution and recovery
Production deployment at alphaomega.ink

I am especially proud that the system does not hide incomplete or failed work behind a success message. It preserves evidence, explains what happened, and gives the user a controlled recovery path.

What was added during Build Week

Alpha Omega existed as an earlier concept, but the Build Week work meaningfully expanded and hardened it.

The work completed during the event included major improvements to:

Authentication and tenant isolation
Durable orchestration and worker recovery
Tool Forge generation and validation
Sandbox and network security
Memory isolation and retention
Factory reset and export integrity
Operational health and scheduled reconciliation
Tool permission and revocation lifecycle
Conversation persistence and retry idempotency
Workspace navigation and information hierarchy
Approval and progress interfaces
Responsive mobile behavior
Accessibility and keyboard interaction
Production testing and deployment verification

The repository history, Codex session, migrations, test additions, audit documents, and deployment commits provide evidence of this work.

What's next

The next stage is to make Alpha Omega a platform where users can create and share reusable workspace capabilities without sacrificing isolation or control.

Planned improvements include: