The strongest zero-human company signals entering September 11, 2026 concern the machinery around the model. OpenAI has exposed its cloud agent runtime as an API, its new Data agent relies on governed business definitions as well as database permissions, and AWS has released a local-first inbox for background work and approval requests.
1. Runtime: Agent Execution Becomes Managed Infrastructure
On September 10, OpenAI introduced the Agents API in public beta. A session can specify the model, tools, environment, and multi-agent settings while OpenAI operates the Codex-derived orchestration layer.
The service includes long-session context compaction, on-demand tool discovery, programmatic tool calling, and subagent coordination. Builders can use an OpenAI-hosted sandbox, their own infrastructure, or an integrated sandbox provider. That separation leaves a useful boundary: the provider can manage the runtime while the operator still chooses where code runs and where files and secrets live.
Public beta is an availability claim, not proof of reliability for a particular workload. The performance figures in the launch post are customer statements selected by OpenAI. Production adoption still needs workload-specific failure, recovery, cost, and containment tests.
2. Data: Definitions Sit Beside Permissions
OpenAI also released a Data agent for ChatGPT Work. It connects to approved data systems, files, and BI tools. Queries inherit the connected account's table, row, and column restrictions.
Access control is only half of the design. The agent also reads metric definitions, calculations, relationships, and semantic layers from systems such as dbt, Databricks, Snowflake, GitHub, and existing dashboards. Users can inspect evidence, refine the analysis, publish dashboards, and approve connected actions through Slack or email.
For an autonomous operator, a permitted query can still produce a wrong decision when two teams define revenue, churn, or an active customer differently. Versioned definitions, source lineage, freshness, and an approval boundary belong in the execution path.
3. Operations: Background Work Needs An Attention Queue
AWS released Pizza Bot as an Apache-licensed, self-hosted application. Manual tasks, schedules, and webhooks create durable threads. Completed work enters an Unread queue; work paused for approval or an answer enters Action.
The server checkpoints messages, tool activity, and pauses to disk. It supports multiple model providers, MCP servers, and Agent Skills, stores provider credentials in the operating system's secret store, and exposes delegated-worker activity beside the main thread.
AWS says earlier internal versions reached more than 2,000 people, but that is a vendor-reported usage figure rather than external adoption evidence. The project also says its public skill and MCP ecosystem is young. The durable state model is available to inspect today; broad workflow coverage is still work in progress.
4. The Operating Pattern
These releases expose three control planes around autonomous work: a runtime plane for sessions and execution, a semantic plane for definitions and evidence, and an attention plane for completion, approval, and intervention.
Keep those planes separate enough to replace a vendor or execution environment without losing business meaning or pending decisions. Join them with stable run IDs, explicit owners, versioned inputs, approval records, and recovery state. A model response should never be the only record of what ran, what a number meant, or what still requires a person.
Related: Read the field notes on OpenAI's managed agent runtime, semantic controls for data agents, and AWS's background-agent inbox.