AOS Project Architect

AOS Project Architect turns real-world problems into structured human–AI projects, assigning tasks, risks, approvals, and reusable knowledge to help teams move from idea to action.

Comment

Inspiration

Many founders, small teams, and organizations have valuable ideas but struggle to turn an unclear problem into a structured and executable project.

Responsibilities become unclear, risks are discovered too late, important decisions are not documented, and lessons from completed work are often lost.

AOS Project Architect was inspired by one core principle:

Every solution begins with a problem, every problem becomes a project, every project creates knowledge, and every piece of knowledge strengthens AOS.

What it does

AOS Project Architect turns a real-world organizational problem into a structured human–AI project.

The user provides four inputs:

  • the problem they are trying to solve;
  • the people or communities affected;
  • the desired outcome;
  • the known constraints and limitations.

GPT-5.6 then generates five structured sections:

  1. Project Brief

    • problem statement;
    • affected people;
    • desired outcome;
    • success measures;
    • constraints.

  2. Partner Assignments

    • Atlas handles strategy, priorities, and milestones;
    • The Librarian records assumptions, decisions, and reusable knowledge;
    • Guardian identifies risks, privacy concerns, and human-approval boundaries;
    • the Human Collaborator remains accountable for important decisions and external actions.

  3. Action Plan

    • workstreams;
    • objectives;
    • tasks;
    • owners;
    • priorities;
    • milestones.

  4. Risks and Human Approvals

    • risks and mitigations;
    • assumptions requiring verification;
    • decisions that cannot be delegated to AI.

  5. Knowledge Card

    • lessons;
    • reusable organizational knowledge;
    • unanswered questions;
    • possible future use.

How we built it

The application was built during OpenAI Build Week using:

  • Codex CLI;
  • GPT-5.6;
  • OpenAI Responses API;
  • Structured Outputs;
  • Next.js App Router;
  • React;
  • TypeScript;
  • Zod;
  • plain CSS;
  • Vercel;
  • Git and GitHub.

The browser sends the four validated project inputs to a protected Next.js server route.

The server uses the official OpenAI JavaScript SDK and the Responses API with GPT-5.6. Structured Outputs and a Zod schema ensure the generated response follows the expected project format.

The API key remains server-side and is never exposed to the browser.

How Codex was used

Codex CLI supported the main development workflow.

Codex helped:

  • create the initial project and Build Week scope documentation;
  • build the responsive Next.js interface;
  • implement the structured Zod schema;
  • create the protected Responses API route;
  • add input validation and safe error handling;
  • implement timeout, output-length, and prototype rate-limit controls;
  • diagnose and correct a CSS build issue;
  • diagnose the first API timeout;
  • increase the timeout from 45 seconds to 120 seconds;
  • reduce the maximum output from 4,000 to 3,000 tokens;
  • run production builds and TypeScript checks;
  • prepare the project documentation.

The major product and design decisions remained human-led.

Key human decisions

I personally defined:

  • the original AOS concept and core principle;
  • the product scope;
  • the Work & Productivity use case;
  • the Atlas, Librarian, Guardian, and Human Collaborator roles;
  • the human-approval model;
  • the visual and product direction;
  • which features to exclude so the prototype remained focused;
  • the final acceptance of the generated workflow.

Challenges

The main challenge was reducing a broad organizational operating-system vision into one clear and demonstrable product.

A second challenge was generating a large structured response reliably. The first live request exceeded the original 45-second timeout. We increased the application timeout to 120 seconds, reduced the output ceiling, rebuilt the application, and completed a successful live test.

Other challenges included:

  • keeping the API key private;
  • producing predictable structured results;
  • limiting unnecessary API usage;
  • making detailed project information readable;
  • preserving human accountability.

Accomplishments that we are proud of

We created and deployed a functioning AI application rather than only presenting a future concept.

The public application successfully:

  • sends a real request to GPT-5.6;
  • returns all five structured project sections;
  • assigns distinct human and AI responsibilities;
  • identifies risks and approval boundaries;
  • transforms project experience into reusable knowledge.

What we learned

AI products are more useful when they do not attempt to automate every decision.

A strong human–AI workflow should:

  • clarify the problem;
  • structure the work;
  • expose assumptions;
  • identify risks;
  • preserve human accountability;
  • convert completed work into reusable knowledge.

We also learned that one complete workflow is more valuable than many unfinished features.

What's next

Future development may include:

  • saved project workspaces;
  • persistent organizational knowledge;
  • controlled collaboration between team members;
  • stronger distributed rate limiting;
  • exportable project documents;
  • organization-specific policies and templates;
  • additional specialized AI Partners.

The current Build Week version intentionally remains a focused prototype. Generated plans require human review and should not be treated as verified professional advice.

Built With

Share this project:

Updates