ChatGPT Work's Hidden Architecture: What 223 Tools and 44 Skills Reveal About Agent Execution Boundaries

OpenAI doesn't publish system prompts or tool schemas for ChatGPT Work. Simon Willison just spent weeks reverse-engineering the production agent platform anyway, exposing 223 registered tools and 44 skills that power the cloud-based Work environment. This is the first detailed technical breakdown of how OpenAI wires together browser automation, unrestricted internet-connected code execution, persistent filesystems, and sub-agent delegation in a commercial product used by millions.

The findings matter because ChatGPT Work represents a different execution model than Chat. It's not just a UI tab. It's a stateful agent runtime with fundamentally different security boundaries, state management contracts, and orchestration patterns.

Two Runtimes, One Confusing Brand

ChatGPT Work ships in two flavors:

• Work Cloud: Runs in OpenAI's infrastructure, accessible via chatgpt.com or mobile apps
• Work Local: Runs on your desktop via the ChatGPT app (formerly Codex), with direct filesystem and process access

Work Cloud is the interesting one. Work Local is mostly Codex with friendlier branding. The rest of this article focuses exclusively on Work Cloud's architecture.

Access requires a $20/month subscription minimum. Free and $8/month Go users are locked out entirely.

The Execution Boundary Differences

ChatGPT Chat and ChatGPT Work share model access but diverge sharply on capabilities:

Feature	Chat	Work Cloud
Code execution internet access	Blocked by proxy	Unrestricted (or custom allowlist)
Browser automation	None	Full headless Chrome with Playwright
Filesystem persistence	Ephemeral per session	Shared /workspace across all sessions
Sub-agent delegation	No	Yes (Sol, Luna, Terra)
Site deployment	No	Cloudflare Workers with D1/R2 state
Model selection	Sol only (5.6 Instant to Pro)	Sol, Luna, Terra (Light to Ultra)

The code execution change is the biggest shift. ChatGPT Chat's Code Interpreter has been locked down since 2023. It can run Python but cannot install arbitrary packages or reach external APIs. Claude's equivalent allows a short allowlist (PyPI, NPM, GitHub).

Work Cloud removes the guardrails. You can clone repos, install dependencies, and call any HTTP endpoint. This makes it useful for real automation work but also expands the attack surface.

Persistent State and the /workspace Contract

Every Work Cloud session gets a scratch directory like /workspace/scratch/e00a0a017944. These directories persist across sessions. Willison has 171 of them.

All active Work sessions for a user appear to mount the same /workspace volume. File edits in one session are immediately visible in another. Process spaces remain isolated (localhost servers in one session can't be reached from another), but the shared filesystem changes the state management contract.

This is different from Chat's ephemeral model. In Chat, each session starts clean. In Work, you're building on top of accumulated state. That's powerful for iterative workflows but introduces new failure modes. If a previous session corrupted a file or left a half-finished script, the next session inherits that mess.

Browser Automation Plumbing

The control-browser skill exposes headless Chrome via a browser-client runtime. Before interacting with it, agents must call await browser.documentation() to retrieve the full API surface.

Willison prompted Work to extract headings from his site. The agent ran:

await tab.playwright.evaluate(() => {
  return Array.from(
    document.querySelectorAll("h1,h2,h3,h4,h5,h6"),
    heading => ({
      level: heading.tagName.toLowerCase(),
      text: heading.innerText.trim().replace(/\s+/g, " "),
      id: heading.id || null
    })
  );
});

This is Playwright's evaluate() method running arbitrary JavaScript in the page context. The security boundary here is interesting. The agent doesn't see your passwords or 2FA codes. If a site requires authentication, the browser prompts you to take over and enter credentials manually. The model never touches them.

But the agent can still fill forms, click buttons, and scrape DOM state. If an attacker can inject a prompt that instructs the agent to exfiltrate data via a browser action, the isolation doesn't help.

Tool and Skill Layering

Willison discovered the architecture by asking Work to build a reference site listing all its tools. The result: 223 registered tools, grouped into categories.

But tools aren't the whole story. Work also uses 44 skills. Skills appear to be higher-level orchestration patterns that compose multiple tools. For example:

• control-browser: Orchestrates the web.run tool and the browser-client runtime
• data-analytics:build-dashboard: Combines data manipulation and visualization tools
• sites:sites-building: Wires together code execution, filesystem access, and Cloudflare Workers deployment

The separation suggests a two-layer agent composition pattern:

1. Tools: Low-level primitives (run code, open URL, write file)
2. Skills: Task-specific workflows that chain tools together

This layering is common in agent frameworks but rarely exposed this clearly in a commercial product. It's similar to LangChain's tool/chain distinction or AutoGPT's command/task split.

Sub-Agent Delegation

Work can spawn sub-agents running Sol, Luna, or Terra models. Chat cannot.

Willison notes that Ultra reasoning mode appears to delegate more eagerly to sub-agents. This suggests a hierarchical orchestration model where a primary agent decides when to fork work to specialists.

The mechanics aren't documented. We don't know:

• How sub-agents share state
• Whether they run in parallel or sequentially
• How the primary agent aggregates results
• What happens if a sub-agent fails

This is the kind of detail OpenAI could clarify by publishing system prompts.

ChatGPT Sites: Cloudflare Workers as Agent Output

Work can deploy full web applications to Cloudflare Workers. These sites get D1 (SQLite) and R2 (object storage) for state.

Willison built a site cataloging "pelicans in her piety" in London. The agent:

1. Researched locations
2. Generated a JSON dataset
3. Wrote HTML, CSS, and JavaScript
4. Deployed to london-pelicans-in-her-piety.simonw.chatgpt.site

Sites default to private but can be made public or shared with specific users on team plans.

The deployment shape is interesting. Cloudflare Workers are edge functions with global distribution. D1 and R2 provide cheap, durable state. This is a reasonable stack for small-scale agent-generated apps, though it's unclear how Work handles schema migrations or rollback if an agent deploys broken code.

Scheduled Automations

Work supports scheduled prompts like "run a search to see if Waymo announced a Half Moon Bay launch date every day at 8am."

These automations can update ChatGPT Sites on an hourly basis. The combination of persistent state, internet-connected code execution, and scheduled triggers makes Work a lightweight workflow automation platform.

The failure modes are predictable:

• Prompt drift (the agent's interpretation changes over time)
• API rate limits or breaking changes
• Silent failures if the agent decides "nothing interesting happened"

Observability is opaque. You don't get logs, metrics, or alerting. You just get notifications when the agent decides to tell you something.

Security Boundaries and the Lethal Trifecta

Willison's "lethal trifecta" model warns about systems that combine:

1. Access to private data
2. Exposure to untrusted content
3. A way to exfiltrate information

Work Cloud has all three. It can read your files, browse the web, and send HTTP requests.

The browser's credential isolation helps, but it doesn't cover all attack vectors. An attacker could:

• Inject a prompt via a malicious webpage that instructs the agent to POST sensitive files to an external endpoint
• Use the code execution environment to exfiltrate data via DNS queries or HTTP requests
• Manipulate the persistent filesystem to poison future sessions

OpenAI likely relies on the same auto-review mechanism as Codex, where a secondary model checks for suspicious behavior before executing tool calls. But without published system prompts or security documentation, we're guessing.

What OpenAI Isn't Telling You

The biggest frustration is opacity. OpenAI explains Work in terms of use cases ("build a brief, deck, or analysis") instead of capabilities. The documentation doesn't list tools or skills. It doesn't explain the security model. It doesn't clarify the state management contract.

Willison had to reverse-engineer all of this by prompting Work to document itself. That's absurd for a production platform.

If OpenAI published:

• The full system prompt
• Tool and skill schemas
• Security boundaries and threat model
• State persistence guarantees
• Observability and debugging interfaces

...developers could build on top of Work with confidence. Instead, we're left guessing about failure modes and trust boundaries.

Technical Verdict

Use ChatGPT Work when:

• You need internet-connected code execution for real automation (not just sandboxed demos)
• You want browser automation without managing your own Playwright infrastructure
• You're building small web apps that fit Cloudflare Workers' constraints
• You're comfortable with opaque orchestration and limited observability

Avoid ChatGPT Work when:

• You need deterministic, auditable workflows
• You require fine-grained control over agent execution
• You need to understand security boundaries for compliance
• You want to version-control your automation logic

The platform is powerful but frustrating. The capabilities are real. The documentation is inadequate. The security model is unclear. If you're building production automation, you'll spend more time reverse-engineering behavior than you should.

Source Links

• Understanding ChatGPT Work (Simon Willison)
• ChatGPT Work Tools Reference (Generated by Work)