# Hosted and self-hosted environments after the Agents API beta

The Agents API added environment choices; compare data access, dependency ownership and artifact behavior before attributing outcomes to model intelligence.

Author: Retrivium editorial team
Language: en
Analysis published: 2026-11-03
Event date: 2026-09-10
Original announcement: https://openai.com/index/introducing-the-agents-api/
Canonical URL: https://retrivium.ai/retrospectives/agents-api-environment-choice/

An agent's environment determines which evidence it can inspect and which outputs it can create. The Agents API beta offered environment choices, making that configuration part of the deployment decision rather than a detail hidden behind the selected model.

## Earlier cloud work became an explicit choice

The [May 16, 2025 Codex introduction](https://openai.com/index/introducing-codex/) described tasks in cloud environments. The [February 11, 2026 execution primitives](https://developers.openai.com/blog/skills-shell-tips) linked procedures to working containers. The [September 10, 2026 Agents API announcement](https://openai.com/index/introducing-the-agents-api/) then described hosted sandboxes and connected environments. This history supports comparing environment ownership without assuming that all supported paths have identical contents or behavior.

## A task carries hidden dependencies

Imagine a report requiring a private dataset and a native document converter. A model can understand the task while its environment lacks the dataset, converter or expected fonts. Switching the model cannot repair those missing inputs.

Write the task's environment contract separately: source locations, dependency versions, permitted operations and artifact destinations. A familiar operating-system label does not establish that contract. Two environments can run the same command name while producing different output because their data or dependencies differ.

## Ownership determines the operational work

A provider-hosted environment can reduce the setup an application performs itself. A connected environment can preserve existing data access and deployment conventions. Neither description establishes that one option is universally easier, faster or more appropriate.

The application needs to identify which party provisions dependencies, controls access, retains artifacts and handles environment changes. These responsibilities should be visible in the deployment record. Otherwise a later missing file can be misdiagnosed as a model regression even though the execution surface changed.

## Test the environment before comparing intelligence

Prepare an illustrative report job with a small source fixture and a known output requirement. First verify that each candidate environment can read the intended data and execute the required conversion. Keep the model and task instructions fixed.

Inspect the resulting artifact, including content and rendering dependencies. A command returning successfully is weaker evidence than a usable file. If one environment fails before meaningful model work begins, report the environment failure separately rather than assigning the entire outcome to model capability.

## Keep the choice reversible and attributable

Record environment identity and changes alongside the agent session. Replacing a dependency or mounting a different source revision should be a visible intervention. Preserve enough evidence to reproduce why the previous result was accepted.

The beta's architectural value was an expanded deployment surface. Its retrospective lesson is that hosted execution and application-owned execution need explicit responsibility maps. That makes environment selection a testable operating decision instead of a proxy for trust in the model vendor.

## Related reading

- [Separating resources during an environment move](/journal/cloud-gpu-region-migration-plan/)
- [Documenting a deployment contract](/journal/provider-api-contract-deprecation-migration/)