GPT-5.6 and ChatGPT Work: Designing a Production-Grade Agent Control Plane

Introduction

The July 2026 release of GPT-5.6 can easily be read as another model launch. Sol is the flagship route, Terra is the balanced option, and Luna is the faster, lower-cost tier. The official release includes extensive evaluations across coding, professional work, science, computer use, and security.

That interpretation is accurate, but incomplete.

The more useful way to understand GPT-5.6 is operational. OpenAI has exposed several decisions that agent builders previously had to hide inside custom orchestration code: how much reasoning to allocate, when to use parallel agents, how to coordinate tools without returning every intermediate result to the model, and how to match model capability to the value and risk of a task.

At the same time, ChatGPT Work brings the long-running task model associated with Codex into a broader workspace that includes documents, spreadsheets, slides, websites, connected applications, browser actions, computer use, and scheduled work.

These capabilities create a larger engineering responsibility. Giving a stronger model more tools does not automatically create a reliable digital worker. It creates a system that can operate for longer, across a wider data boundary, and make more consequential changes.

A production design must answer several questions before the run begins:

• Who authorized the task?
• What may the agent read?
• What may it change?
• Which actions require approval?
• How much time and money may it spend?
• What evidence proves that the result is correct?
• How does the team stop or recover the workflow when something goes wrong?

This guide presents a control-plane approach for teams building with GPT-5.6, ChatGPT Work, Codex, or custom agents. It keeps model capability separate from operational authority and provides concrete scenarios, routing rules, evaluation guidance, and a reusable policy template.

Key Takeaways

• GPT-5.6 is best treated as a capability and compute menu. Sol, Terra, and Luna are model routes, while reasoning effort and multi-agent execution are separate budget controls.
• ChatGPT Work changes the unit of delegation from a single answer to a completed outcome that may span files, connected apps, browser work, computer use, and scheduled tasks.
• A production agent needs a control plane around the model: task classification, scoped identity, tool policy, approval gates, observability, evaluation, budgets, and recovery.
• Public benchmarks are useful for discovering candidate models, but private task sets are essential for production deployment decisions.
• Teams should begin with reversible, reviewable workflows and expand autonomy only after collecting evidence.

What Actually Changed with GPT-5.6

GPT-5.6 makes three capability tiers available across ChatGPT, Codex, and the API:

• Sol: the highest-capability route.
• Terra: a balanced route for everyday work.
• Luna: the fastest and most affordable route.

OpenAI describes these names as durable capability tiers rather than temporary, date-stamped model names. That distinction is useful for production systems.

A policy such as “use the balanced tier for routine repository maintenance” can survive a future snapshot change. When reproducibility matters, the team can pin an exact snapshot separately. This is cleaner than spreading model IDs across prompts, scripts, job queues, and environment variables.

Reasoning Effort and Multi-Agent Execution

GPT-5.6 also adds more explicit compute controls.

max gives one model route more time to reason, explore alternatives, run checks, and revise its work. ultra coordinates multiple agents across parallel workstreams.

These are different controls:

• More reasoning allows one route to investigate and verify for longer.
• Multi-agent execution spends extra compute on concurrent workstreams and then synthesizes their results.

A task may benefit from one, both, or neither. Parallel execution is not automatically better, especially when subtasks share the same uncertain assumption or require the same restricted credentials.

Programmatic Tool Calling

OpenAI describes Programmatic Tool Calling as a way for a model to write and execute lightweight programs that coordinate tools, process intermediate results, and decide what information should return to the model.

This can reduce repeated context transfer. Instead of returning every database row, browser response, or tool result to the model, an in-memory program can filter and aggregate the data first.

That efficiency comes with an operational tradeoff. More logic moves into the execution layer, which means teams need clear traces, limits, and data-handling rules for those intermediate steps.

The GPT-5.6 release also introduces a multi-agent beta in the Responses API. Parallel execution is therefore becoming an API-level capability, not only an application-side orchestration pattern.

Pricing Is a Routing Input

At launch, the official prices are:

Route	Input Price per 1M Tokens	Output Price per 1M Tokens
GPT-5.6 Sol	$5.00	$30.00
GPT-5.6 Terra	$2.50	$15.00
GPT-5.6 Luna	$1.00	$6.00

These prices are inputs to a routing decision, not the decision itself.

A cheaper model may cost more per accepted result if it retries repeatedly, reads unnecessary context, or produces work that reviewers reject. A stronger model may be cheaper in practice if it completes the task once with a small, verified change.

The correct metric is not simply cost per token. It is cost per accepted outcome.

ChatGPT Work Changes the Unit of Delegation

ChatGPT Work is presented as an agent that can work across applications and files, continue for hours, break goals into smaller steps, and create finished artifacts.

OpenAI says Codex technology is built into the product, but the target is broader than software engineering. Example workflows include:

• Budget analysis
• Campaign briefs
• Lead review
• Product-launch checks
• Competitive research
• Documents
• Spreadsheets
• Presentations
• Websites

The important change is the unit of delegation.

A normal chat turn asks for an answer. A Work task asks for an outcome.

That outcome may require the system to:

1. Read several sources.
2. Change direction when new information appears.
3. Create multiple artifacts.
4. Wait for human approval.
5. Continue through a scheduled task while the user is away.
6. Use connected apps, an embedded browser, or desktop computer use.

OpenAI is also consolidating product surfaces. Chat, Work, and Codex are available within the updated desktop experience, while browser functionality is moving into the wider product environment.

This creates one permission boundary spanning local files, web pages, connected services, browser actions, and long-running tasks.

The enterprise controls are therefore as important as the interface. Administrative connector management, compliance features, and review mechanisms all point to the same problem: the agent must act with the right identity, the minimum required context, visible effects, and a recovery path.

Even when a team builds a custom API agent rather than using ChatGPT Work directly, Work is a useful reference operating model. It exposes the issues that appear when an assistant becomes a persistent worker:

• State
• Tool identity
• Approvals
• Scheduling
• Artifacts
• Governance

Terms to Understand: Model, Harness, Agent, and Control Plane

Model

A model maps input context to output and tool decisions. It has capabilities, limitations, pricing, latency, and safety behavior.

Sol, Terra, and Luna are model tiers. The model itself does not decide organizational authority.

Agent Harness

The agent harness is the software surrounding the model. It selects context, exposes tools, executes commands, stores state, retries failures, and decides when a run is complete.

Changing the harness can materially change cost and reliability, even when the model and task remain the same. A harness that repeatedly sends large context windows may cost far more than one that filters intermediate results.

For this reason, “model performance” is incomplete unless the harness is also specified.

Agent

An agent combines:

• A model
• A goal
• Tools
• State
• A harness

An agent can take multiple steps and react to tool results. A long-running agent may create subtasks or subagents, but parallel workers do not automatically form a safe multi-agent system. They still share budgets, permissions, and a final acceptance decision.

Control Plane

The control plane is the policy and operations layer that governs agent runs.

It:

• Classifies tasks
• Selects routes
• Issues scoped credentials
• Enforces approvals
• Records traces
• Evaluates results
• Stops work
• Rolls back work

The execution plane performs the task. Keeping the two separate allows a team to change models without changing who is allowed to deploy production code or send external messages.

Approval Gate

An approval gate is a decision point that an agent cannot pass without an authorized person or deterministic policy.

Approvals should be attached to a specific action and its evidence.

A useful approval request is:

Approve sending this finalized email to these 412 recipients using the attached recipient list and approved content.

A weak approval request is:

Approve the marketing task.

Acceptance Test

An acceptance test is evidence that the requested outcome is complete.

It may be:

• A unit test
• Schema validation
• A rendered-document review
• A reconciliation total
• A human scoring rubric
• A security scan
• A code-owner approval

A model saying “done” is a status claim, not an acceptance test.

The Production Agent Control Plane

A useful production control plane has eight responsibilities.

1. Classify the Task

Classification should cover:

• Domain
• Impact
• Reversibility
• Data sensitivity
• Ambiguity
• Expected value
• Verification strength

“Update a draft FAQ” and “change an authentication policy” may both involve editing text, but they belong to different routes.

2. Select a Model and Effort Budget

The cheapest eligible route is a reasonable default, but eligibility must come before price.

Examples:

• Luna for low-risk extraction
• Terra for moderate analysis with strong source checks
• Sol for architecture reviews, security reviews, or difficult repository diagnosis
• Ultra only when the task decomposes cleanly and the additional parallel cost is justified

3. Create a Scoped Execution Identity

The agent should receive short-lived credentials for the exact repositories, folders, applications, or records required by the task.

It should not inherit a developer's full browser session simply because that is convenient.

The execution identity must be visible in logs so the team can attribute every external action.

4. Apply a Tool Policy

These are separate capabilities:

• Read
• Write
• Send
• Purchase
• Delete
• Deploy
• Change permissions

A connector that can search a mailbox should not automatically be able to send email. A GitHub integration that can inspect a repository should not automatically be able to merge pull requests.

5. Enforce Approvals and Deterministic Checks

An approval gate should appear immediately before the consequential action and show a concise preview of the effect and evidence.

For software, evidence may include:

• Diff
• Unit tests
• Type checks
• Security scans
• Deployment plan

For finance, it may include:

• Source totals
• Reconciliation
• Formula validation
• Variance checks

6. Record an Event Trace

The trace should include:

• Goal changes
• Source retrieval
• Tool calls
• Approvals
• Artifacts
• Errors
• Retry reasons
• Token usage
• Elapsed time
• Final state

A short summary is useful for operations, but it is not enough for incident review.

7. Enforce Budgets and Stop Conditions

Useful limits include:

• Token budget
• Tool-call budget
• Wall-clock limit
• Retry limit
• Monetary cap
• File-count limit
• Diff-size limit

Stopping a weak or looping run is not a failure of autonomy. It is a successful application of policy.

8. Own Recovery

Recovery may include:

• Restoring a file
• Reverting a commit
• Revoking credentials
• Canceling a scheduled task
• Deleting a draft
• Opening an incident

If the system cannot explain recovery before execution, the task is not ready for unattended operation.

Routing Sol, Terra, and Luna by Task Shape

Model routing should be explicit enough for engineers, product managers, and security reviewers to read.

The following table is a starting point, not a universal ranking.

Route	Suitable Task Shape	Required Evidence	Typical Authority
Luna	Classification, extraction, formatting, low-risk summaries, narrow code search	Schema validation, sample review, source links	Read-only or draft-only
Terra	Routine repository changes, document production, known workflows, moderate analysis	Targeted tests, artifact validation, human spot-check	Scoped write, no irreversible external action
Sol	Ambiguous diagnosis, cross-system analysis, architecture work, security review, high-value research	Broad deterministic checks, reviewer-visible rationale, source provenance	Scoped write with explicit approvals
Sol max	Difficult single-thread reasoning where more exploration and revision may improve quality	Checkpoints, cost limit, final verification	Same authority as Sol
Sol ultra	High-value, parallelizable tasks with independent workstreams	Per-workstream evidence, synthesis review, total budget cap	Separate scoped identities where possible

The final column is the most important.

Model capability must not increase authority.

Switching from Luna to Sol cannot silently add write access. Raising reasoning effort cannot turn a draft into an approved external message. Ultra must not create several workers that all share unrestricted production credentials.

Evidence-Driven Escalation

A Luna route may escalate when:

• Confidence falls below a threshold.
• Required fields cannot be extracted.
• Sources conflict.
• Validation fails.

A Terra coding task may escalate when:

• A failing test remains unexplained after two bounded attempts.
• The change crosses a security boundary.
• The diff exceeds the expected number of files.

A Sol route should stop and ask a human when requirements conflict or the only remaining action is irreversible.

Downgrading Is Also Useful

Once Sol produces a plan, Terra or Luna may execute repetitive subtasks under narrow checks.

A strong model can review a sample rather than process every item. This separates judgment from volume and may reduce cost substantially.

Permission Architecture and Approval Boundaries

A permission system should begin with verbs.

read
search
create_draft
modify
send
merge
deploy
delete
purchase
grant_access

These verbs have different consequences.

Many product integrations place several actions behind one broad OAuth scope. The control plane may therefore need an application-side proxy that exposes narrower operations.

Bind Verbs to Resources

“Read Google Drive” is too broad for many workflows.

A narrower rule might be:

Read the Q3 planning folder and the approved brand-template folder until 18:00 UTC.

For repositories, access may be limited to one worktree with network access disabled. For databases, a read replica or governed view is usually safer than production credentials.

Add Conditions

Examples:

• An email draft may be created automatically, but sending requires approval.
• A pull request may be opened automatically, but merging requires green CI and a code owner.
• A scheduled task may refresh a dashboard, but changing the data source requires an administrator.

Preserve Separation of Duties

The agent that creates a change should not be the only judge of correctness.

Useful evidence can come from:

• A deterministic test runner
• A separate review model
• A human owner

A second model is not a replacement for an accountable human, but it may expose disagreement before an action becomes external.

Provider safeguards are only one layer. They cannot know whether the user is authorized to test a specific repository, whether a customer approved a change, or whether the production maintenance window is open.

Application authorization remains the builder's responsibility.

Concrete Scenarios and Failure Modes

Scenario 1: Release-Readiness Agent

A team asks ChatGPT Work or a custom agent to review:

• A launch plan
• Jira issues
• A repository
• A go-to-market document

The required artifact is a readiness report listing owners and blockers.

The agent may read all four sources and create the report. It may not edit issue status or message owners without approval.

Failure Mode: Stale Context

The report cites an issue that has already been resolved because the agent used a cached document.

The control plane should require direct source links and timestamps.

Failure Mode: False Completion

The agent declares the release ready because every checklist row contains text.

The acceptance test should instead require every blocking dependency to have a verified owner, date, and current status.

Scenario 2: Coding-Agent Dependency Upgrade

The task is to upgrade a library across a monorepo.

Terra starts because the migration is documented and the test suite is strong. It creates a branch, edits the lockfile and affected packages, and runs targeted checks.

A compiler error reveals an undocumented API change in the authentication module. This triggers escalation to Sol.

The model changes, but authority does not.

Sol receives the same worktree and no deployment token. If the diff touches authorization logic, the policy adds a security-review gate.

Completion requires:

• Unit tests
• Type checks
• Dependency audit
• Reviewer-approved migration note

A patch that appears to work but skips these checks is not accepted.

Scenario 3: Scheduled Customer-Feedback Workflow

Every morning, an agent reads new support tickets, clusters themes, and updates a product brief.

Luna may classify tickets after sensitive fields are removed. Terra may draft the brief with source links.

Neither route may:

• Close tickets
• Promise a feature
• Contact customers

Failure Mode: Gradual Scope Drift

A new instruction says the agent should “also handle obvious responses.”

This turns an internal analysis workflow into external communication.

The task classifier should detect the new send verb and require a separate policy, approved template, sampling plan, and human owner.

Scenario 4: High-Value Research Task

A company is evaluating three architecture options.

Sol ultra assigns separate workstreams to:

• Performance
• Security
• Migration cost
• Vendor risk

Parallel execution is justified because the workstreams are independent and the decision is valuable. Each worker receives source requirements and a fixed budget.

Failure Mode: Correlated Evidence

All workers cite the same vendor benchmark and appear to agree.

The synthesis gate should measure source diversity, flag shared unsupported assumptions, and require at least one counterargument for each option.

More agents can amplify a bad premise just as easily as they can improve coverage.

Why Public Coding Benchmarks Are Discovery Tools

Public benchmarks are useful, but they should not directly determine a production default.

OpenAI's audit of SWE-Bench Pro reported that a substantial share of public tasks had issues such as:

• Overly strict tests
• Underspecified prompts
• Low-coverage tests
• Prompts that pointed toward behavior inconsistent with hidden tests

This does not mean every public benchmark is useless.

It means the score inherits the measurement error of its dataset and harness.

Public evaluations are useful for:

• Discovering candidate models
• Comparing published methods
• Identifying broad capability changes
• Building an internal evaluation queue

They cannot answer whether a model will make safe changes in a specific monorepo, business workflow, or data environment.

A control plane should store benchmark provenance with each routing decision:

• Dataset version
• Task exclusions
• Harness
• Tool configuration
• Reasoning effort
• Number of trials
• Cost assumptions

Without these details, a benchmark score becomes marketing shorthand.

Building a Private Evaluation from Real Work

Databricks provides a useful example with its multi-million-line codebase evaluation.

The team built tasks from real, human-authored pull requests across:

• Python
• Go
• TypeScript
• Scala
• Rust
• Java
• Protobuf
• gRPC
• Bazel

It selected recent and representative changes with meaningful tests, rewrote task descriptions to preserve intent without revealing the solution, and manually reviewed each sample.

The team also found leakage in its initial setup. Agents could recover future commits from Git history. During evaluation runs, the worktree was isolated from repository history.

That detail matters more than the final ranking. It shows how a benchmark can accidentally measure shortcut discovery instead of engineering ability.

Building a Smaller Internal Set

A team can begin with 30 to 60 tasks.

Use accepted historical changes that have:

• A clear issue
• Meaningful tests
• Limited scope

Include a mix of:

• Routine maintenance
• Bug diagnosis
• Cross-file refactoring
• Frontend work
• Configuration
• One or two security-sensitive examples

Preserve the repository state before the change and hide the final patch.

Evaluate with Deterministic Evidence First

Use deterministic tests before human or model judging.

Then add human review for:

• Requirement fidelity
• Diff quality
• Maintainability
• Unnecessary changes

Do not let an LLM judge replace every correctness check. A judge model may reward an answer that sounds correct.

Measure Model and Harness Together

Record:

• Success rate
• Total cost
• Elapsed time
• Total context sent
• Tool calls
• Retries
• Files touched
• Reviewer corrections
• Rollback rate

The best route is the one that produces accepted work within the team's constraints, not the one with the highest public score.

A Reusable Agent Policy Template

The following YAML is a policy artifact, not an API schema. Adapt it to your identity provider, job queue, connectors, repository controls, and audit system.

policy_version: 1
workflow: release_readiness
owner: product-operations

classification:
  impact: medium
  reversibility: high
  data_sensitivity: internal
  ambiguity: medium
  verification: strong

routing:
  default:
    model_tier: terra
    reasoning_effort: medium
  escalate_to_sol_when:
    - conflicting_sources
    - unresolved_blocker_after_2_attempts
    - security_boundary_detected
  ultra:
    allowed: false

budget:
  max_wall_minutes: 45
  max_tool_calls: 120
  max_retries_per_step: 2
  max_estimated_usd: 12

access:
  jira:
    verbs: [read]
    projects: [NX]
  github:
    verbs: [read]
    repositories: [We0 AI/product]
  drive:
    verbs: [read, create_draft]
    folders: [launch-plans]
  external_send: deny
  deploy: deny
  grant_access: deny

approvals:
  - action: publish_report
    role: product-director
    evidence:
      - source_links_present
      - blockers_have_owner_and_date
      - unresolved_conflicts_listed

acceptance:
  required_checks:
    - schema_valid
    - all_sources_fresh_within_24h
    - no_unattributed_claims
    - human_approval_recorded

recovery:
  on_budget_exceeded: stop_and_notify
  on_tool_error_repeat: stop_and_attach_trace
  on_policy_violation: revoke_credentials_and_open_incident

This template makes several deliberate choices:

• Escalation changes capability, not permissions.
• Ultra remains disabled unless the workflow owner explicitly enables it.
• External sending and deployment are separate denials.
• Acceptance is expressed as checks rather than model confidence.
• Recovery is defined before execution.

For coding workflows, replace the report checks with:

• Targeted tests
• Type checks
• Lint
• Security scans
• Diff-size limits
• Code-owner review

For spreadsheet workflows, require:

• Formula validation
• Source reconciliation
• Rendered inspection

The control-plane structure remains stable while the evidence changes.

Observability, Budgets, and Recovery

Long-running agents create a new observability problem.

A traditional request log may show one API call. An agent trace may contain hundreds of decisions, tool calls, retries, and intermediate artifacts.

Teams need both:

1. A complete trace for investigation.
2. A concise run ledger for operations.

Run Ledger Fields

A useful ledger includes:

• Stable run ID
• Initiating user
• Policy version
• Goal
• Model tier and snapshot
• Reasoning effort
• Subagent count
• Tool scopes
• Approvals
• Cost
• Elapsed time
• Acceptance checks
• Final artifact links
• Final state
• Escalation reason

This makes it possible to answer questions such as:

• Did Sol improve acceptance after Terra failed?
• Which workflow consumes the most reviewer time?
• Which tool causes the most retries?
• Which route produces the highest rollback rate?

Use Multi-Dimensional Budgets

A monetary limit alone may allow a cheap model to loop for too long.

A time limit alone may allow a burst of expensive parallel work.

Useful budget dimensions include:

• Money
• Wall-clock time
• Token usage
• Tool calls
• Retries
• Number of files
• Diff size
• Number of subagents

Test Recovery

Recovery should be tested like any other feature.

Useful tests include:

1. Remove a connector midway through a run.
2. Confirm the agent does not repeat an external action after retry.
3. Expire its credentials and confirm the trace explains the failure.
4. Cancel a scheduled task and confirm future runs stop.
5. Revert a generated commit and mark related artifacts as superseded.

Incident reviews should distinguish:

• Model failure
• Harness failure
• Policy failure
• Tool failure
• Human approval failure

Blaming “the AI” hides the component that can actually be improved.

Adoption Playbook and Review Checklist

Start with one workflow that is frequent, measurable, and reversible.

Good candidates include:

• Release-readiness reports
• Issue triage
• Documentation refreshes
• Test-failure summaries
• Internal research briefs

Avoid making the first deployment:

• External communication
• Production changes
• Payments
• Access grants
• Deletion workflows

Record the Human Baseline

Measure:

• How long the workflow takes
• Which sources are used
• Which errors occur
• What evidence reviewers expect

Without a baseline, faster agent output may simply move more work into correction.

Run in Shadow Mode

Let the agent produce an artifact while a human independently completes the real workflow.

Compare the outcomes and label failure modes. Use these runs to build the private evaluation before increasing permissions.

Review Checklist

Before moving from draft-only access to scoped write access, confirm:

• Is the task definition specific enough to grade?

• Are the model tier and reasoning effort selected by policy?

• Can escalation occur without expanding authority?

• Does every tool have explicit verbs and resource scope?

• Are credentials short-lived and attributable to the run?

• Is every irreversible or externally visible action gated?

• Are acceptance checks independent of the model's completion claim?

• Does the trace include sources, actions, approvals, errors, and cost?

• Do budgets cover money, time, retries, tools, and blast radius?

• Have credential revocation, cancellation, and rollback been tested?

• Does the private evaluation include common and high-risk edge cases?

• Is a named human owner responsible for the workflow outcome?

Expand only one dimension at a time.

A team may add a new data source while keeping draft-only output, or add scoped write access while keeping the same model and task.

Changing the model, tools, permissions, and schedule together makes regressions difficult to attribute.

What Builders Should Do Now

GPT-5.6 and ChatGPT Work are evidence that agent infrastructure is becoming a product category of its own.

The model layer will continue to change. The durable work is the control plane that makes those model changes safe.

Create a Route Registry

Create a small registry for Sol, Terra, Luna, and any non-OpenAI candidates.

Store:

• Eligibility
• Data policy
• Allowed effort range
• Cost assumptions
• Known failure modes

Add a private evaluation queue so a new model cannot become the production default based only on social-media impressions.

Add an Authorization Proxy

Place an authorization proxy between agents and consequential tools.

Expose:

• Narrow verbs
• Short-lived credentials
• Approval hooks
• Idempotency keys

Keep the same boundary whether the task begins in ChatGPT Work, Codex, a custom application, or a scheduled backend job.

Define Acceptance Before Autonomy

A team that can explain how a task is verified can automate it safely in stages.

A team that cannot define verification is not ready to let an agent run for hours, regardless of its benchmark score.

Review Cost at the Outcome Level

Track dollars and human minutes per:

• Accepted artifact
• Merged change
• Resolved ticket
• Approved analysis

This aligns model routing, harness efficiency, and reviewer workload.

It also gives the team a grounded answer when the next flagship model arrives.

Boundaries and Open Questions

Several claims in release materials remain vendor-reported.

Cross-provider benchmark comparisons use different:

• Harnesses
• Reasoning settings
• Pricing assumptions
• Tool configurations
• Datasets

Treat these claims as hypotheses for internal testing.

Programmatic Tool Calling and multi-agent execution may reduce context overhead, but they can also make intermediate logic less visible when tracing is weak.

Before using these features in regulated workflows, verify:

• What the API records
• What application logs retain
• How sensitive intermediate data is handled
• Whether the workflow is compatible with the required retention policy

ChatGPT Work's connected applications and computer-use capabilities increase utility while expanding the authority boundary. Availability, administrative controls, and connector permissions may differ by plan and deployment.

A product announcement is not a substitute for a workspace-specific security review.

There is also a human-systems problem. When agents continue for hours, users may approve work they did not observe closely. Better summaries help, but approval quality depends on showing the proposed effect, uncertainty, and failed checks at the moment of decision.

Product design must protect human attention, not simply request a click.

The strongest model is therefore not the final architecture.

Production quality comes from the relationship among:

• Model
• Harness
• Policy
• Tools
• Evidence
• Accountable owner

That relationship is what an agent control plane makes explicit.

FAQ

What is GPT-5.6?

GPT-5.6 is OpenAI's July 2026 model family, organized into Sol, Terra, and Luna capability tiers. Sol is the highest-capability route, Terra balances capability and cost, and Luna prioritizes speed and affordability.

What is ChatGPT Work?

ChatGPT Work is an agentic workspace for long-running tasks across files, applications, browser actions, computer use, and scheduled work. Unlike a normal chat turn, a Work task is designed around a completed outcome or artifact.

What is an agent control plane?

An agent control plane is the policy and operations layer that governs agent runs. It classifies tasks, chooses a model route, issues scoped credentials, applies tool restrictions, enforces approvals, records traces, evaluates results, controls budgets, and manages recovery.

How is an agent harness different from a control plane?

The harness is the software that assembles context, exposes tools, stores state, executes actions, and manages retries. The control plane governs how that harness may operate, including authority, routing, budgets, approvals, evaluation, and recovery.

When should teams use Sol, Terra, or Luna?

Luna fits low-risk extraction, classification, and formatting. Terra suits routine repository work, document production, and moderate analysis with strong checks. Sol is more appropriate for ambiguous diagnosis, architecture, security review, and high-value research.

Does switching to Sol give the agent more permissions?

No. Model capability and operational authority should remain separate. Upgrading from Luna or Terra to Sol should change reasoning capability, not tool access, write permissions, deployment rights, or approval requirements.

Why are public benchmarks not enough for production selection?

Public benchmarks may contain flawed tasks, harness-specific assumptions, or leakage. They are useful for discovering candidates, but a private evaluation built from real internal work is needed to measure cost, reliability, review burden, and safety in the actual environment.

What should be logged for a long-running agent?

The log should include the goal, model route, reasoning effort, tool calls, sources, approvals, errors, retries, token usage, cost, elapsed time, artifacts, validation results, escalation reasons, and final state.

Related Tools

• ChatGPT: OpenAI's product interface for chat, Work, connected tools, and long-running tasks.
• OpenAI API: The official platform for building applications with GPT-5.6 and the Responses API.
• Codex: OpenAI's coding-agent platform for repository work, software engineering, and agent skills.
• Programmatic Tool Calling: OpenAI's official guide to coordinating tools and processing intermediate results with in-memory programs.
• NIST AI Risk Management Framework: A governance framework for identifying, measuring, and managing AI risks.
• Databricks: A data and AI platform whose engineering team published a private coding-agent evaluation based on real repository changes.

Related Links

• GPT-5.6 General Availability: OpenAI's official GPT-5.6 release, including model tiers, capability details, availability, and pricing.
• Previewing GPT-5.6 Sol: OpenAI's earlier technical preview of the Sol model.
• ChatGPT for Ambitious Work: OpenAI's official announcement describing ChatGPT Work and its long-running task model.
• Programmatic Tool Calling Documentation: Official developer documentation for programmatic coordination of tool calls.
• Separating Signal from Noise in Coding Evaluations: OpenAI's audit and discussion of reliability issues in public coding benchmarks.
• GPT-5.6 System Card: OpenAI's official safety and capability evaluation document for GPT-5.6.
• Databricks Coding-Agent Benchmark: A private evaluation built from real pull requests in a multi-million-line codebase.

Summary

GPT-5.6 gives teams a clearer menu of capability, cost, reasoning effort, and multi-agent execution. ChatGPT Work extends those capabilities into persistent tasks across files, applications, browsers, and scheduled workflows.

The production challenge is not simply selecting the strongest model. Teams also need scoped identity, narrow tool permissions, approval gates, independent acceptance checks, full traces, multi-dimensional budgets, private evaluations, and tested recovery.

Begin with one reversible workflow, record the human baseline, run in shadow mode, and increase only one dimension of authority at a time.

A production-grade agent is not just a powerful model with tools. It is a model operating inside a measurable, reversible, and accountable control plane.