CHQ

The AI-native operating system for running a software company — one orchestrator that ships code, runs sales, manages finance, deploys and secures infra, with humans approving only what matters.

Comment

Inspiration

Before OpenAI Build Week, CHQ was primarily a finance and business-operations dashboard UI : a polished interface with project, invoicing, banking, and administrative screens, but without the real operational backend or AI system needed to run Cloudstech.

I had a larger vision for it.

Cloudstech’s work is spread across software repositories, servers, financial tools, documents, project boards, sales activity, and communication platforms. The repetitive work between those systems consumes time, while automating everything without controls would create unacceptable operational risk.

I designed CHQ as Cloudstech’s internal, single-tenant operating system: one place where humans and AI can understand the company, coordinate work, and automate operational toil.

The governing principle is:

Automate the toil. Human-gate the consequential.

I wrote the CHQ product requirements, architectural decisions, guardrails, and detailed R1–R7 implementation plans. During OpenAI Build Week, I worked with Codex and GPT-5.6 to turn those documents and the existing dashboard into a real, full-stack AI operating system.

What it does

CHQ is an AI-native operating system for running Cloudstech’s engineering delivery and business operations.

It combines:

  • A real PostgreSQL-backed business application.
  • A bounded GPT-5.6 orchestration loop.
  • Durable AI trajectories and audit history.
  • Versioned skills and ephemeral engineering workers.
  • Model routing, token metering, budgets, and cost controls.
  • Hybrid organizational memory.
  • GitHub webhook ingestion and automated code review.
  • Human approval for consequential actions.
  • Infrastructure monitoring and typed deployment execution.
  • Scheduled business automations.
  • Sales-signal discovery, scoring, and outreach drafting.
  • Web, API, mobile, CLI, and server-agent surfaces.

CHQ is intentionally not a general SaaS product or a multi-tenant platform. It has exactly one organizational owner: Cloudstech.

R1 — Real backend for the dashboard

Codex helped convert the existing dashboard from mock-driven UI into a real application backed by PostgreSQL.

R1 introduced:

  • Kysely migrations as the sole database-schema authority.
  • Schema-qualified PostgreSQL access.
  • Repositories for projects, tasks, clients, invoices, documents, teams, discussions, and financial data.
  • NestJS API controllers.
  • A typed @chq/sdk client boundary.
  • Invite/password authentication and JWT sessions.
  • Default-deny authorization and role gates.
  • Audited mutations.
  • Real dashboard data instead of mock imports.
  • Document storage and bank-connection foundations.

R2 — GPT-5.6 orchestrator

R2 introduced CHQ’s AI runtime.

The API publishes work through Redis to a TypeScript orchestrator. The orchestrator runs a bounded Vercel AI SDK loop with GPT-5.6 as its default reasoning model.

Every run records:

  • The originating request.
  • Model turns.
  • Tool calls.
  • Results and failures.
  • Context usage.
  • Model and provider information.
  • Token usage and latency.

The web application gained live AI chat and an Agent Runs interface for inspecting what the system actually did.

R3 — Skills and ephemeral engineering workers

R3 turned the orchestrator into an execution system.

Instead of building a permanent swarm of specialist agents, CHQ uses one orchestration loop, versioned skills, and ephemeral workers.

Codex helped implement:

  • A versioned Skill Library.
  • Skill activation and proposal-only self-improvement.
  • Ephemeral OpenCode engineering workers.
  • Isolated Git worktrees.
  • Least-privilege Docker build and test gates.
  • Delegation records and sub-trajectories.
  • Human approval for activating proposed skill changes.
  • Reusable engineering skills for scaffolding, NestJS work, Flutter work, design compliance, and code review.

This structure lets CHQ assemble a temporary specialist when required and discard it after the task.

R4 — Cost, model routing, and memory

R4 made the AI system measurable and stateful.

Codex helped implement:

  • Immutable model-price records.
  • Per-call token and cost accounting.
  • Per-run cost ledgers.
  • Provider and model profiles.
  • Task-specific model routes.
  • Ordered provider fallbacks.
  • Warning, downgrade, and halt budgets.
  • PostgreSQL full-text decision search.
  • pgvector semantic memory.
  • Fact extraction and session summaries.
  • A Model Router and Cost dashboard.
  • A Memory Browser with archival rather than destructive deletion.

GPT-5.6 became part of a controlled model-routing system rather than an unmetered black box.

R5 — Gateway and GitHub agent

R5 connected CHQ to external events.

The gateway provides a general pattern:

Signed event in → durable record → AI run → controlled action out.

Codex helped implement:

  • Signed and idempotent GitHub webhook ingestion.
  • Repository-owner allowlisting.
  • Pull-request context retrieval.
  • Automated code-review runs.
  • Structured review findings.
  • Retrying outbound GitHub jobs.
  • Short-lived GitHub App authentication.
  • Gateway provenance connected to Agent Runs.
  • A central Approvals inbox.
  • Audited approval and rejection controls.

Untrusted webhook content is stored and parsed as data; it is never interpolated into shell commands.

R6 — Infrastructure and DevOps

R6 gave CHQ a secure infrastructure control plane.

Codex helped implement:

  • The orchestrator-owned infra schema.
  • Server, metric, deployment, and incident records.
  • A static Go chq-agent.
  • Outbound mutual-TLS communication.
  • Docker metrics and container health collection.
  • Typed deployment and remediation contracts.
  • No generic remote-shell execution path.
  • Bounded log access.
  • Threshold-based incident detection.
  • GPT-assisted incident diagnosis.
  • Human-gated deployment and remediation.
  • Caddy-based TLS and routing.
  • Infrastructure and Approvals interfaces.
  • Provisioning, hardening, deployment, installation, and diagnosis skills.

During later Build Week work, this expanded into multi-project deployment: strict project manifests, exact repository-and-branch watches, approval-gated webhook redeployment, deployment history, health verification, rollback to exact Git commits, and secure CSR-based server enrollment.

R7 — Automation and sales intelligence

R7 extended CHQ into business automation.

Codex helped implement:

  • Exactly-once scheduled work.
  • Sales-signal ingestion.
  • Structured opportunity scoring.
  • Outreach drafting.
  • Automation management.
  • Sales and Market Intelligence interfaces.
  • Email gateway integration.
  • Signed and idempotent email events.
  • Append-only engagement history.
  • Consent and suppression records.
  • Dispatch-time compliance checks.
  • Human approval before external email delivery.

The AI may research, score, and draft automatically, but it cannot silently contact a prospect.

How we built it

I began with the product vision and wrote the source-of-truth documentation:

  • docs/CHQ-PRD.md
  • docs/R1-PLAN.md
  • docs/R2-PLAN.md
  • docs/R3-PLAN.md
  • docs/R4-PLAN.md
  • docs/R5-PLAN.md
  • docs/R6-PLAN.md
  • docs/R7-PLAN.md
  • AGENTS.md

These documents define the architecture, ownership boundaries, implementation order, acceptance gates, and safety rules.

Codex acted as the implementation collaborator.

For each roadmap phase, Codex inspected the documentation and existing code, proposed an implementation plan, edited the repository, generated migrations and types, built APIs and SDK methods, connected the web interface, wrote deterministic gates, ran tests, diagnosed failures, and reconciled branches.

The work used multiple Git branches and a second worktree at CHQ-r2 so independent phases could be developed and integrated without losing isolation.

The dated Git history shows the progression:

  • July 17: repository baseline and R1.
  • July 18: R2 orchestration, R3 skills, delegation, and model routing.
  • July 19: R3 reconciliation, R4 cost and memory, and R5 gateway work.
  • July 20: R6 infrastructure, R7 automation and sales intelligence, and R1–R7 integration.
  • July 21: compliance reconciliation, multi-project infrastructure, staging configuration, and authentication hardening.

The implementation was merged through PRs #1–#7, including the final R1–R7 integration branch.

Challenges we ran into

Turning a UI into an operating system

The starting dashboard contained many useful interfaces, but a real operating system requires durable data, authentication, APIs, queues, background workers, model controls, external connectors, and operational safety.

The challenge was not adding one AI feature. It was creating a coherent architecture across all those layers.

Maintaining ownership boundaries

CHQ enforces one writer per database schema. The API owns business data, while the orchestrator owns agent, memory, metering, gateway, and infrastructure data.

Convenient shortcuts would have made the system easier to implement but harder to trust. Codex had to carry requests through Redis and the typed SDK instead of bypassing ownership boundaries.

Safe agentic execution

An AI system that can review code, deploy software, send email, or remediate infrastructure needs more than tool access.

We implemented:

  • Typed contracts.
  • Input validation.
  • Idempotency.
  • Least-privilege credentials.
  • Bounded execution.
  • Audit records.
  • Cost budgets.
  • Exact deployment provenance.
  • Human approvals.

Codex caught several unsafe proposals, including direct cross-schema writes, centrally generated server private keys, automatic production deployment, and automatic mobile-store submission. We corrected each design before shipping it.

Integrating parallel work

R1–R7 touched the database, API, SDK, orchestrator, web application, Go agent, skills, Docker infrastructure, and documentation. Work was distributed across branches and the CHQ-r2 worktree.

Integration required reconciling generated database types, migrations, route contracts, queue jobs, shared types, and tests across every phase.

Real deployment constraints

The staging deployment exposed practical issues that local builds did not:

  • Environment files had to work consistently across Compose, migrations, seeds, and token-generation tools.
  • Next.js public URLs had to be embedded during image builds.
  • Deep Cloudflare hostnames required deliberate TLS handling.
  • Internal workspace packages had to be built before execution.
  • A small server could not build several Node images concurrently without exhausting memory.

Codex helped diagnose these issues and turn them into a guarded staging runbook.

Accomplishments that we're proud of

The biggest accomplishment is the scale of the transformation during Build Week.

CHQ went from a finance-oriented dashboard foundation to an integrated AI operating system spanning R1 through R7.

The Git history contains 34 dated commits between July 13 and July 21, seven merged PRs, separate integration work, real PostgreSQL migrations, deterministic system gates, and implementations across TypeScript, React, NestJS, Go, Redis, PostgreSQL, Docker, and Caddy.

We are especially proud of:

  • A real GPT-5.6 orchestration loop with durable trajectories.
  • Versioned skills and ephemeral engineering workers.
  • Full model-cost accounting and memory.
  • A general external-event gateway.
  • GitHub code review with human-gated consequential actions.
  • A typed Go infrastructure agent with no generic shell path.
  • Scheduled sales intelligence and compliant outreach drafting.
  • Multi-project deployment without weakening CHQ’s safety model.
  • Guardrails strong enough to reject our own unsafe initial ideas.

What we learned

The most important lesson was that agentic systems need constitutions, not just prompts.

Our AGENTS.md gave Codex durable rules about:

  • Schema ownership.
  • API boundaries.
  • Generated code.
  • Human approval.
  • Secrets.
  • Deployment.
  • Design consistency.
  • Verification.

Because those rules were explicit, Codex could challenge instructions that conflicted with the architecture.

We also learned that the strongest human–AI collaboration has clear roles.

I defined the product, wrote the architecture and implementation plans, made the consequential decisions, and reviewed the results. Codex accelerated implementation, cross-repository reasoning, testing, debugging, and integration. GPT-5.6 powered both the engineering collaboration and CHQ’s runtime reasoning system.

Codex was most valuable when it did more than generate code: when it preserved context across a large system, identified contradictions, and forced better technical decisions.

What's next for CHQ

The immediate priority is completing the public staging gate and providing a judge-friendly demo account.

Next, we plan to:

  • Complete live GitHub App, Resend, registry, and server-agent verification.
  • Add richer deployment provenance and artifact attestations.
  • Expand staging-specific deployment policies while keeping production human-gated.
  • Improve GPT-5.6 incident diagnosis using infrastructure history and organizational memory.
  • Add Google Workspace SSO.
  • Expand mobile release preparation without automating store-review submission.
  • Convert more Cloudstech procedures into versioned skills.
  • Continue improving model routing, cost controls, and memory quality.
  • Finally create a Multi-Access SAAS version

CHQ is not intended to remove people from running a company. It is designed to remove the repetitive work between human decisions.

Built With

Share this project:

Updates