QuestorOS: AI Command Center

Inspiration

Founders operate their companies across disconnected systems: source code in GitHub, deployments in Vercel, data in Supabase, cloud services, AI providers, OAuth integrations, billing systems, and monitoring tools.

Understanding what is happening often requires opening multiple dashboards, interpreting technical logs, and manually connecting information from different services. I wanted founders to have one trusted AI command center where they could understand what is happening across their business and technology stack and receive clear, traceable results.

QuestorOS is my broader vision for an AI operating system designed to unlock human potential. I believe people spend too much of their ability managing fragmented software, searching for information, repeating administrative work, and translating ideas between disconnected systems.

The purpose of QuestorOS is not to replace human judgment or creativity. It is to remove operational friction so people can spend more time creating, learning, solving meaningful problems, and turning their ideas into reality.

OpenAI Build Week gave me the opportunity to advance that vision by building the Control Plane: a secure foundation that helps people understand and eventually coordinate the systems supporting their work.

What it does

QuestorOS is an AI Command Center for understanding and operating a connected business and technology stack. Its new Control Plane provides system inventory, connection visibility, and bounded, read-only operational checks.

The Build Week version focuses on:

  • Inventorying supported infrastructure, source-control, AI-provider, and productivity connections
  • Showing configured, connected, healthy, degraded, and unauthorized states separately
  • Running explicit, bounded, read-only health checks
  • Returning traceable results with the source, status, explanation, response time, and trace ID
  • Keeping API keys, OAuth tokens, and infrastructure credentials server-side
  • Containing provider errors without exposing sensitive response data
  • Requiring user approval before checks are performed
  • Recording administrative checks in an audit trail
  • Establishing the foundation for natural-language questions about connected systems

The longer-term objective is to let a founder ask questions such as:

  • “Why did my latest deployment fail?”
  • “Which AI provider is currently unavailable?”
  • “Is my database approaching its usage limit?”
  • “What changed in the latest repository update?”
  • “Run a health check across my complete stack.”

How I built it

QuestorOS existed before this hackathon and already included foundational chat, voice, memory, tools, AI-provider routing, and administrative capabilities.

The Control Plane is the new Build Week capability. The repository history, pull request, and Codex task identify the functionality created or substantially extended during the submission period.

I entered Build Week as a first-time Codex user. I used Codex with GPT-5.6 to inspect the existing repository, understand unfamiliar parts of the architecture, develop implementation specifications, make scoped code changes, investigate failures, write tests, and verify the application through a Vercel preview before merging the work.

The application uses Next.js, TypeScript, React, Node.js, Tailwind CSS, shadcn/ui, Supabase, PostgreSQL, Prisma, and Vercel.

The Control Plane uses server-side adapters to inspect configured services. Credentials remain on the server and are never returned to the browser. Opening the Control Plane only displays passive inventory; it does not automatically call AI models or consume provider credits.

When a user explicitly authorizes a health check, QuestorOS performs bounded, read-only probes and returns a traceable result for each supported connection.

Challenges I ran into

The largest challenge was adding a unified operations layer without breaking an existing production application.

Important engineering problems included:

  • Keeping server credentials out of client bundles
  • Reconciling current and legacy connection records
  • Distinguishing a configured connection from a healthy operational route
  • Preventing unauthorized or destructive operations
  • Preserving existing chat, voice, memory, and tool behavior
  • Containing infrastructure and provider errors safely
  • Turning technical failures into understandable explanations
  • Maintaining exact provider, credential, and plan identities across the application
  • Testing preview behavior without changing production credentials
  • Integrating a new capability into an already active product

The distinction between “connected” and “healthy” became especially important. A credential can exist while its authorization has expired or its operational route is unavailable. The Control Plane reports these states independently instead of presenting every stored connection as healthy.

Accomplishments I’m proud of

I am proud of transforming a broad idea—understanding an entire technology stack through one AI workspace—into a focused capability that can be demonstrated and tested.

The submitted version can:

  • Inventory infrastructure, source control, AI providers, and productivity applications
  • Detect configured services without exposing credentials
  • Run explicitly authorized, read-only checks
  • Distinguish healthy, degraded, unauthorized, and not-connected states
  • Return a trace ID and timing information for each check
  • Keep provider failures contained and understandable
  • Preserve an audit trail for administrative operations

I am also proud that security is part of the product design rather than an afterthought. Credentials remain server-side, checks are intentionally bounded, and destructive actions are outside this workflow.

Most importantly, I progressed from having no previous Codex experience to using Codex as an active implementation, testing, and debugging partner inside a production application.

What I learned

I learned that Codex is most effective when it receives:

  • A clearly defined finish line
  • Known facts and exact current errors
  • Strict security and feature-preservation boundaries
  • Small, verifiable implementation stages
  • An explicit test-and-repair loop
  • Clear instructions about what it must not change

Codex helped me inspect unfamiliar code, trace behavior across the application, implement changes, add tests, review diffs, and prepare a pull request.

I also learned that AI-assisted development still requires human judgment. I had to decide the product direction, define the security boundaries, verify the claims, review the changes, and determine when the result was safe to merge.

Codex allowed me to work as an AI-assisted founder-engineer while keeping the product, architecture, security, and business decisions in my hands.

What’s next

I plan to expand the connection-adapter registry to support additional infrastructure, developer, productivity, and business services.

Future work includes:

  • Secure GitHub and Vercel management connections
  • Additional cloud and database adapters
  • Stronger approval workflows
  • Configurable organization policies
  • Expanded audit and observability tools
  • Natural-language questions grounded in live Control Plane results
  • Safe multi-step operational workflows
  • Clear separation between read-only inspection and approved mutations
  • Workspace-level access controls for teams and enterprises

The long-term goal is for QuestorOS to become a secure AI operating system that helps people understand and operate their business, technology, knowledge, and workflows from one place.

Ultimately, QuestorOS is about more than managing software. It is about unlocking human potential by giving individuals and teams the clarity, tools, and intelligent assistance needed to turn ideas into action.

Built With

Share this project:

Updates