Create a polished prototype of Codex Loop, a proposed native Codex feature for visually orchestrating multiple Codex threads.
The prototype must reproduce the current Codex interface as faithfully as possible. Match its application shell, navigation, typography, spacing, colors, borders, controls, thread presentation, loading states, and interaction patterns.
Do not redesign Codex or create a loosely inspired agent canvas. The result should look as though the Codex team added a new experimental Loop section directly to the existing product.
The intended reaction is:
This looks like a feature that could already exist in Codex.
Codex Loop lets users:
- Arrange Codex threads as Agent nodes on a visual canvas
- Connect threads into an execution workflow
- Control which context each thread receives
- Supervise groups of threads with Observer regions
- Inspect every thread, tool call, retry, model change, and result
- Open any generated Agent node as a normal Codex thread
- Use a small virtual pet as a visible shared-context manager
Each Agent node represents a real or simulated persistent Codex thread with:
- Task
- Definition of done
- Model
- Connectors
- Context access
- Messages
- Tool calls
- File changes
- Execution history
- Final output
Edges determine how work and context move between threads.
Observer regions supervise groups of Agent nodes and may detect failures, contradictions, stalled work, or insufficient model capability.
The pet manages the workflow’s shared context while making every context change visible and auditable.
Codex Loop is not:
- A generic automation canvas
- An n8n or LangGraph clone
- A visual programming language
- A replacement for individual Codex threads
- A separate AI-agent product
It is an orchestration layer built around existing Codex concepts:
- Threads
- Tasks
- Models
- Repositories
- Tools and connectors
- Execution logs
- File changes
- Reviews
Every node must remain a first-class Codex thread that can be opened, inspected, continued, stopped, or audited independently.
Replicate the current Codex application shell as closely as practical.
The left navigation should contain the existing Codex sections, plus:
- Threads
- Local
- Remote
- Loop
- Settings
Place Loop directly below Remote.
Only Loop requires complete functionality. Other sections may use convincing static or mocked screens, but they must preserve the visual illusion of navigating the real Codex interface.
Reuse Codex-style components throughout the prototype. Agent nodes should resemble compact Codex thread cards, not generic flowchart boxes.
Selecting Loop should open a native-looking landing screen containing:
- A short explanation of Codex Loop
- Recent workflows
- Saved workflows
- Workflow templates
- A “Create Loop” action
- A text input for generating a workflow from a task
Suggested introduction:
Coordinate multiple Codex threads in a single workflow. Assign tasks, share context, supervise execution, and inspect every result.
Include templates such as:
- Investigate and fix a failing CI pipeline
- Implement and review a feature
- Refactor a subsystem safely
- Audit a repository
- Resolve pull-request feedback
- Plan, implement, test, and document a change
Keep the normal Codex sidebar visible.
Show:
- Workflow name
- Threads created by the workflow
- Node and execution status
- Previous workflow runs
- Saved Loop workflows
- Normal manually created threads
Every Agent node must create a corresponding thread entry.
Loop-created threads should have a subtle indicator for:
- Parent workflow
- Node name
- Current status
The central area becomes a visual workflow canvas containing:
- Agent nodes
- Edges
- Observer regions
- Context blocks
- Context-access indicators
- Execution status
- Approval checkpoints
Support canvas pan and zoom where appropriate.
Required interactions:
- Double-click empty canvas space to create an Agent node
- Drag from one node to another to create an edge
- Drag across empty canvas space to create an Observer region
- Select any object to edit it in the inspector
- Move and resize nodes and Observer regions
- Open an Agent node as a normal Codex thread
- Start, pause, stop, and reset a workflow
- Save and reopen workflows
Avoid interaction conflicts between canvas panning, node dragging, edge creation, and Observer creation.
Selecting an object opens a Codex-style inspector.
- Name
- Model
- Task
- Definition of done
- Connectors
- Context permissions
- Retry behavior
- Status
- Source node
- Target node
- Wait period or trigger condition
- Data or context passed
- Number of retries
- Failure behavior
- Whether user approval is required
- Name
- Instructions
- Covered nodes
- Intervention conditions
- Retry policy
- Model-upgrade policy
- Escalation behavior
- Workflow name
- Main task
- Default model
- Execution mode
- Shared connectors
- Approval policy
- Maximum retries
Add a collapsible activity panel styled like Codex execution output.
Display timestamped events for:
- Thread activity
- Tool calls
- Context updates
- Agent handoffs
- Retries
- Errors
- Model changes
- Observer interventions
- User approvals
- Workflow completion
Selecting an event should highlight or open the related node when practical.
Represent reusable shared information as visible Context Blocks.
Examples:
- Repository findings
- Acceptance criteria
- Changed files
- Test results
- Architecture decisions
- Unresolved questions
- Implementation constraints
Each block should show:
- Title
- Summary
- Source thread
- Creation time
- Agents that can access it
- Whether it was manually or automatically created
Use small node-shaped stickers or badges to show which Agent nodes can access each block.
Users must be able to inspect and edit context permissions.
The UI should make it obvious that agents do not automatically receive every message or the entire workflow history.
Integrate shared-context management into the existing Activity, Contexts, and inspector surfaces. Do not introduce a separate mascot or persistent header control.
The context system should:
- Summarize completed work
- Track unresolved questions
- Extract reusable findings
- Create Context Blocks
- Distribute context to approved agents
- Detect contradictions
- Warn when shared context is becoming too large
- Explain which agents know what
- Explain what is currently happening
Example activity messages:
The investigator found a likely race condition. I shared the finding with the implementation and review threads.
The test thread cannot access the implementation discussion. It only received the changed files and acceptance criteria.
Two agents produced conflicting explanations. The Observer is reviewing them.
The context system must not hide autonomous decisions. Every context creation, update, or permission change must appear in the activity log, and context size and recipient access should be visible in the Contexts pane.
Opening an Agent node should switch to a convincing standard Codex thread view containing:
- Assigned task
- Definition of done
- Selected model
- Available connectors
- Received shared context
- Messages
- Tool calls
- File changes
- Execution attempts
- Final output
The user should be able to:
- Add instructions
- Answer a question
- Stop execution
- Continue manually
- Review changes
- Return to the Loop canvas
Changes made inside the thread should update the corresponding canvas node.
Implement a convincing deterministic or state-machine-based workflow simulation.
The primary demo should progress through:
- User enters a repository-level task
- Codex generates a proposed workflow
- Investigation agents run in parallel
- The pet extracts findings into Context Blocks
- Context passes to implementation agents
- One implementation attempt fails
- An Observer detects the failure
- The node retries using a stronger model
- Implementation succeeds
- A test thread verifies the result
- A review thread completes the workflow
- The user opens generated threads to audit their work
Animate:
- Queued, running, waiting, failed, retrying, blocked, and completed states
- Context movement
- Edge activation
- Observer intervention
- Retry count
- Model upgrade
- Completion progress
The simulated execution should be repeatable and polished enough for a live hackathon demonstration.
Provide a backend API and persistent local storage for:
- Workflows
- Nodes
- Edges
- Observer regions
- Context Blocks
- Thread records
- Execution events
- Saved canvas positions
- Workflow runs
Use the project’s existing stack where available. Otherwise choose a simple, maintainable architecture suitable for a hackathon.
Separate the workflow domain model from the rendering layer.
Where technically possible, add an adapter for creating or associating actual Codex threads. If direct Codex integration is unavailable, implement a clean mocked adapter with the same conceptual interface so it can later be replaced.
Do not hard-code the entire demonstration into individual UI components. Model the execution as workflow state and events.
The following may be simulated:
- Codex authentication
- Real model execution
- Real repository modifications
- Real CLI execution
- Computer use
- Connector authentication
- Secure credential storage
- Multi-user collaboration
- Billing and usage metering
Mocked behavior must still look coherent and produce a complete audit trail.
- Faithful reproduction of the current Codex UI
- Responsive layout
- Smooth interactions and transitions
- Clear hover, selected, disabled, loading, error, and empty states
- Strong TypeScript typing if TypeScript is used
- Accessible controls and keyboard behavior
- Persistent workflow state
- Clean component boundaries
- No obvious placeholder styling
- No generic dashboard aesthetic
- No excessive gradients, oversized cards, or unrelated visual patterns
- No broken interactions or dead-end demo states
Use screenshots or existing Codex UI references available in the repository as the visual source of truth. Prefer fidelity over creative reinterpretation.
Use subagents throughout the task.
First, ask planning subagents to independently analyze:
- Existing repository and stack
- Current Codex interface structure
- Component architecture
- Workflow data model
- Canvas interaction design
- Execution simulation
- Backend and persistence
- Testing and verification
Consolidate their findings into one implementation plan.
Then delegate implementation to focused subagents, for example:
- Codex shell and navigation
- Loop landing screen
- Canvas and interactions
- Inspectors and settings
- Context system and pet
- Execution simulation
- Thread and audit views
- Persistence and API
- Visual polish and testing
Ensure subagents work against compatible interfaces and data models. Review and integrate their work rather than leaving disconnected implementations.
After implementation:
- Run the application.
- Test the complete demo flow.
- Check browser console and server errors.
- Verify saving and reopening workflows.
- Verify node, edge, and Observer interactions.
- Verify Agent nodes appear as normal threads.
- Verify execution logs and context permissions.
- Fix visual inconsistencies and broken states.
- Leave the repository in a runnable, documented state.
The project is complete when a presenter can:
- Open a faithful Codex replica.
- Select Loop below Remote.
- Create or generate a workflow.
- Edit Agent nodes and their settings.
- Connect nodes with edges.
- Draw an Observer region.
- Start the workflow.
- Watch parallel execution and context sharing.
- See a failure, Observer intervention, retry, and model upgrade.
- Open an Agent as a normal Codex thread.
- Return to the canvas.
- Review the final result and complete audit trail.
- Save, close, and reopen the workflow successfully.
The final prototype should communicate a technically plausible proposal for how native multi-thread orchestration could work inside Codex.