Studio sandbox and evaluation API readiness

Availability was checked against source revision 4889f4747490b94e726a4f035b5777a1db0fd181 on 2026-10-22. None of the 19 requested customer actions below has a matching route or OpenAPI operation. Existing published Studio operations cover other resources and do not supply these actions. ENG-5899 owns the missing runtime and acceptance proof; the inactive internal inventory is docs/platform-api/proposals/ENG-5856.json. This page records source reuse boundaries and requirements for future work. It is not a callable API contract, operational register, baseline, exemption, or harness-debt record. Every action has approved: false, a null route and operation ID, pending scopes and events, hidden MCP exposure, and excluded SDK exposure. No route, operation ID, scope name, role guarantee, event delivery promise, or completed test for an absent endpoint is asserted here. Safe reads and non-live writes may be considered only after P4 scope, P7 tool, and P9 governance review; they are not approved for exposure by this inventory.

Current source boundaries

AgentConfigurations::Sandbox::Origin issues a server-only origin bound to a persisted account, fresh run UUID, and immutable configuration snapshot. It has no customer-facing caller. A customer is_test flag or sandbox label does not grant authority.
AgentConfigurations::Sandbox::ActionDispatch validates the internal action registry and routes by declared mutation. Its production read and simulation ports both refuse; its only successful path is through injected synthetic test ports. This proves internal routing and validation behavior, not a customer HTTP/e2e sandbox, live provider simulation, or isolation from work a future implementation might enqueue.
AgentConfigurations::Evaluations stores account-scoped, append-only outcomes for immutable configuration versions. Its source comment says there is no result-ingest controller or route. It is not a customer case suite or customer run API.
ToolSuite dataset, scorer, report, and run-record code support repository-owned synthetic/offline evaluation harnesses. They do not provide customer-owned persisted cases, a customer run endpoint, or a customer billing policy. A harness and its specs are source references only.

These boundaries are established by source at the recorded revision. Synthetic isolation proofs do not establish customer HTTP/e2e safety, deferred-effect isolation, or customer billing policy.

Requested actions

Requested action	Current availability	Reuse boundary	Required before a callable API exists
`sandbox.session`	No matching customer route or OpenAPI operation.	The server-only AgentConfigurations::Sandbox::Origin binds an issued origin to an account, isolated run UUID, and frozen configuration snapshot. No runtime caller or customer session route exists.	Define authenticated actor and account/role authorization; prove cross-account sessions cannot be opened or observed; bind the immutable configuration revision and lifecycle; prevent access to live contacts, channels, integrations, or deferred work; refused setup leaves no success state.
`channelPreview.preview`	No matching customer route or OpenAPI operation.	AgentConfigurations::Sandbox::ActionDispatch checks the internal action registry and declared mutation, but both production ports refuse and only injected synthetic ports can succeed. This is not channel preview support.	Define providers and effects; prove every read/write uses an isolated adapter and no live contacts, channels, integration data, or deferred work; define output redaction and actor audit; refusal/failure preserves state and creates no success audit.
`evals.summary`	No matching customer route or OpenAPI operation.	AgentConfigurations::Evaluations provides account-scoped summaries for immutable configuration-version outcomes. ToolSuite has internal offline dataset, scorer, report, and run-record code; neither is a customer evaluation API.	Define account/role scope and exact aggregate meaning; exclude other-account data and unmeasured live behavior; reconcile persisted suite/run/budget/job state with ENG-3789/I-30; refusal preserves state.
`evals.list`	No matching customer route or OpenAPI operation.	The offline ToolSuite dataset loader and committed suite data are internal inputs, not customer-owned case records or an HTTP list.	Define account-owned case identity, filtering, pagination, and role access; prove no cross-account rows or live conversation data; reconcile persisted suites/runs with ENG-3789/I-30; refusal preserves state.
`evals.caseDetail`	No matching customer route or OpenAPI operation.	Internal suite dataset and scorer describe synthetic items; they do not provide a customer case-detail resource.	Define account-scoped lookup and safe fields; prove foreign-account IDs behave as missing and no live contact/channel data is returned; reconcile persisted suite/run provenance with ENG-3789/I-30.
`evals.redTeam`	No matching customer route or OpenAPI operation.	Internal synthetic/offline suites include injection and refusal scenarios, but expose no customer red-team action.	Specify permitted inputs; isolate model/tools from live contacts, channels, integration data, and deferred effects; define provider data flow under P9; add persisted budget admission/refusal and idempotency; reconcile run/job/budget state with ENG-3789/I-30.
`evals.newCase`	No matching customer route or OpenAPI operation.	Internal suite files and dataset loaders are source references only; no customer case-create API or ownership contract exists.	Define accepted fields, account ownership, validation, duplicate behavior, actor audit, and provenance; refusal preserves state and creates no success audit; reconcile suite persistence with ENG-3789/I-30.
`evals.runStatus`	No matching customer route or OpenAPI operation.	Internal run records capture suite and runner evidence; AgentConfigurations::Evaluations reads configuration-version outcomes. Neither is a customer status route.	Define account-scoped lookup, terminal/failure states, retention, and authorization; prevent cross-account disclosure; reconcile persisted run, budget, suite, and job records with ENG-3789/I-30.
`sandbox.reset`	No matching customer route or OpenAPI operation.	Origin binds a fresh run UUID but there is no transcript store/reset API or customer sandbox runtime.	Define reset state and cancellation/fencing of in-flight/deferred work; prove no live conversation, channel, contact, or integration state is touched; specify actor audit, retry, and refusal integrity.
`sandbox.send`	No matching customer route or OpenAPI operation.	ActionDispatch has no production adapter and refuses reads and simulations; synthetic test ports are not a send implementation.	If a sandbox send invokes integration test writes, require an explicit integration allowlist, ownership and consent, no live data and an isolated provider boundary. All sends must prevent deferred effects from escaping and define actor audit and refusal/state preservation.
`sandbox.saveGolden`	No matching customer route or OpenAPI operation.	AgentConfigEvaluation stores append-only outcomes for immutable configuration versions; it is not a customer golden-case/result authoring action.	Define golden artifact ownership, source/version binding, edit/delete semantics, actor audit, and customer-derived content policy; prove account isolation and no live-data leakage; refusal preserves existing state.
`evals.addCase`	No matching customer route or OpenAPI operation.	Internal suite datasets are repository-owned synthetic fixtures; no customer suite mutation route exists.	Define suite ownership, validation, duplicate/idempotency behavior, actor audit, imported-data rules; reconcile persisted suite revisions with ENG-3789/I-30; refusal preserves prior state.
`evals.rerunCase`	No matching customer route or OpenAPI operation.	Internal scorer and harness process suite items; there is no customer per-case run endpoint.	Define run identity/replay semantics; persist budget admission/refusal before work; over-budget refusal starts no work; establish actual concurrency limit from evidence; reconcile run/job/budget state with ENG-3789/I-30.
`evals.acceptCase`	No matching customer route or OpenAPI operation.	Append-only AgentConfigEvaluation outcomes and publish-gate evidence are internal version records, not customer acceptance semantics.	Define accepted immutable result, actor authority, transition/audit semantics, and effect on suite or publish gate; prove retries do not double-apply and refusal leaves state/audit unchanged.
`evals.skipCase`	No matching customer route or OpenAPI operation.	Offline harness reports blocked/unmeasured items, but does not define customer skip state or its effect on a run.	Define skip reason, actor authority, suite snapshot, and effect on completion/thresholds; prove retry idempotency, accurate audit, and refusal preservation.
`evals.importStarterSet`	No matching customer route or OpenAPI operation.	Repository-owned synthetic suite files are not a customer import endpoint or a promise about starter content.	Define source/provenance, validation, account ownership, size bounds, duplicates, and atomicity; prove no live data or external side effect; refusal preserves suite state and audit.
`sandbox.setTestMode`	No matching customer route or OpenAPI operation.	Origin issuance requires a server-issued origin and does not accept a customer is_test flag as authority. The isolation boundary has no runtime caller.	Treat as risky integration-write authorization: explicit integration allowlist, ownership and consent; no live contacts/channels/integration data or deferred work; define actor audit, expiry, and refusal integrity. A flag alone is not authority.
`evals.startRun`	No matching customer route or OpenAPI operation.	Internal offline/live harness code is not a customer run route. Existing probe-spend mechanisms and run records do not establish customer billing policy.	Require persisted Tied-paid token-budget admission/refusal before work; never bill the customer; make admission idempotent; document actual concurrency limit; prove no work starts on refusal; isolate tools/data from live effects and reconcile budget/job/run state with ENG-3789/I-30.
`evals.deleteCase`	No matching customer route or OpenAPI operation.	No customer case-delete API exists. Immutable version outcomes and repository-owned suite files have different lifecycle rules.	Define confirmation, eligible states, actor authority, retention/provenance, effects on suites and completed runs; prove account isolation and retry integrity; refusal leaves case, runs, and audit unchanged.

Shared future safety and acceptance proof

Future implementation must define account and role isolation, with the administrator and orchestration_studio feature contract settled by ENG-5899 and P4 review. Every lookup and background job must be account-scoped. Sandbox and evaluation work must be unable to reach live contacts, channels, or customer integration data, including through deferred jobs. Integration writes require an explicit integration allowlist, ownership and consent; test-mode alone is not authority. Define each state transition and effect separately. Case edit, delete, accept, skip, golden result, and run result actions cannot be treated as no-effect because of their labels. Destructive deletion needs actor, eligible-state, retry, retention, and run-reference semantics. Refused or failed writes must preserve prior state and must not create success audit entries; successful actions need actor audit evidence. Retries and concurrent commands need explicit idempotency and integrity proof. Evaluation run creation must use persisted Tied-paid token-budget admission and refusal. Over-budget admission refuses before work starts; the customer is never billed. Define idempotency and document the actual concurrency limit from implementation evidence; this page asserts no limit value. Reconcile persisted suites, runs, budgets, and jobs with ENG-3789/I-30. P4 scope review, P7 tool review, and P9 governance review remain prerequisites. No future test is claimed as already run, and no absent endpoint is described as tested. The only proposed evaluation events are eval.case_added, eval.case_deleted, and eval.run_completed; event metadata and delivery remain pending review, with no delivery promise. The requested sandbox actions propose no external events by design; this says nothing about current runtime event delivery. The three existing moves_money operations remain unchanged, and this inventory adds no billing operation.

Getting started

Conversations

Contacts

Inboxes and channels

Automation and routing

Reporting

Help Center

Account and access

Orchestration Studio

Billing

Client API

Widget API

Receiving webhooks

Studio API readiness

Knowledge and model settings

Quality review and receipts

Studio sandbox and evaluation API readiness

Current source boundaries

Requested actions

Shared future safety and acceptance proof

​Current source boundaries

​Requested actions

​Shared future safety and acceptance proof

Current source boundaries

Requested actions

Shared future safety and acceptance proof