Isenberg Autonomous App Building Framework

// When should you use the Isenberg Autonomous App Building Framework?

Use this skill whenever you want to build a functional, persistent web app or internal tool using Codex Sites — especially when your goal is an app that agents can keep operating, updating, and populating for you without manual intervention.

// What inputs do you need before starting the Isenberg framework?

• App conceptrequired
  What the app or internal tool does — its purpose, columns, cards, fields, or core function.
• Key data entitiesrequired
  The main record types the app needs to store (e.g. ideas, tasks, entries) and the actions that should be performed on them.
• Safe actions list
  The named mutations the app should expose (e.g. add_idea, move_card, score_idea). Can be derived from Codex itself if unknown.
• Skill name
  A short, descriptive name for the Codex Skill that will serve as the reusable instruction manual for this app.

// What core principles guide the Isenberg Autonomous App Building Framework?

// How do you apply the Isenberg framework step by step?

1. 1

   Invoke Codex Sites and build the shell

   Start a new Codex project and invoke the @sites plugin. Prompt it to build your app concept using realistic sample data. Critically: instruct it to save for review, do not deploy. This forces it to build a real product/service, not a homepage. Example instruction pattern: 'Build [app concept] with [columns/structure]. Use realistic sample data. Save for review, do not deploy.'

2. 2

   Add Memory — define the data model before touching code

   Prompt Codex to add persistent storage but ask it to show you the data model and which records and actions the app needs BEFORE it writes any code. This surfaces your entities (e.g. one record per card) and the full action list (list, add, update, move, score, archive). Review and approve before proceeding. Recommended store: Cloudflare D1.

3. 3

   Create Safe Actions for all key mutations

   Using the action list surfaced in Step 2, prompt Codex to create Safe Actions for each mutation. If you are non-technical and don't know what your Safe Actions should be, just ask Codex — it will derive them from the data model. The goal is an explicit safe action boundary so the agent can only call named mutations, never arbitrary SQL.

4. 4

   Create a Codex Skill for the app

   Prompt Codex to create a Codex Skill with a clear name (e.g. 'startup ideas admin'). The Skill should explain: how to read the board/data, how to add records, how to move/update records, how to score/archive records, and include at least five example commands. This skill is the reusable instruction manual for every future chat that needs to operate this app.

5. 5

   Save Gate — checkpoint the stable version

   Prompt Codex to save the current state as a named version (e.g. 'v1 review'). Explicitly instruct: do not deploy. Ask it to confirm: build status, storage choice, access settings, and the exact version saved. Check the top-right environment panel to confirm branch, connection status, and change history.

6. 6

   Prove the Loop — verify autonomous operation in a new chat

   Open a completely new chat — this is critical. Invoke the Skill you created and issue a real operational command (e.g. 'Use [skill name] to add [real item], place it in [column], give it a first-pass score and next step'). Watch whether the agent: loads the skill, calls only the Safe Action layer (no raw SQL, no generic DB writes, no deploy), and the live app reflects the change. If it does, the loop is proven and the app is operating autonomously.

// What are real-world examples of the Isenberg framework in action?

// What common mistakes should you avoid when using the Isenberg framework?

• Not invoking @sites explicitly — the plugin must be invoked or Codex won't use the Sites building workflow.
• Letting Codex auto-deploy before you've reviewed — always instruct 'save for review, do not deploy' in your initial prompt to avoid premature deployment.
• Skipping the data model review step — asking Codex to add storage without first seeing the data model means you won't know what Safe Actions to create, especially if you're non-technical.
• Not creating Safe Actions — without them, agents fall back to arbitrary SQL or generic database writes, which is unsafe and unpredictable.
• Skipping the Skill creation step — without a Codex Skill, every new chat starts blind and can't operate the app. Skills are what make the app reusable across future chats.
• Not doing the Save Gate before deploying — Codex does not autosave, so skipping checkpoints risks losing stable versions.
• Proving the Loop in the same chat instead of a new chat — the entire point of proving the loop is that a fresh chat with no prior context can operate the app using only the Skill. Same-chat testing does not validate true autonomy.
• Expecting Codex Sites to handle everything out of the box like Replit or Lovable — Codex Sites currently requires you to explicitly prompt for memory, payments, analytics, and other integrations. It is more powerful for autonomous operation but more hands-on to configure.

// What key terms and concepts does the Isenberg framework use?

Codex Sites

The OpenAI Codex plugin (invoked via @sites) that enables building, hosting, and autonomously updating web apps and internal tools directly within the Codex ecosystem.

Autonomous Product Building

The design philosophy where agents — not humans — handle the ongoing updating, editing, and populating of a live app or website. The human sets up the structure; the agents keep it running.

Memory

Persistent storage explicitly added to a Codex Sites app so data saves between visits. Without memory, the app is just a demo. Typically implemented using Cloudflare D1.

Safe Actions

Named, approved mutations (e.g. add_idea, move_card, score_idea) that define the only operations an agent is permitted to perform on the app's data. They prevent arbitrary SQL or generic database writes and make automation safe and predictable.

Skill

A reusable instruction manual stored in Codex that tells any future chat how to operate a specific app — what data it holds, what actions are available, and example commands. Created once; invoked in any future chat.

Save Gate

A manual checkpoint — like a video game save point — where you explicitly instruct Codex to commit the current stable state as a named version without deploying, confirming build status and storage config.

Prove the Loop

The validation step where you open a brand new Codex chat, invoke the app's Skill, issue a real operational command, and confirm the live site updates using only the Safe Action layer — proving the app operates autonomously without human editing.

Safe Action Boundary

The explicit constraint that agents may only call named mutations defined as Safe Actions — never raw SQL, never generic database writes, never deploy commands. Enforced during the Prove the Loop step.

// FREQUENTLY ASKED QUESTIONS