Managed AI Agent Deployment: A Responsibility Worksheet

For a managed AI agent deployment, assign responsibility at the boundary between the service and the customer workflow. A provider may operate the agent harness—the software that coordinates model calls, tools, and execution—while the customer team still decides which data the agent can access, what actions it may take, and whether the result is acceptable.

The FDE’s practical job is to make those boundaries inspectable. Write down the component, provider scope, customer responsibility, named decision owner, evidence, and the change that would reopen the decision. An architecture diagram alone rarely answers all six.

What a managed runtime actually changes

OpenAI’s September 10 Agents API announcement describes a managed agent harness with a choice of an OpenAI-hosted environment, customer infrastructure, or a sandbox partner. That distinction matters: a managed harness does not imply that the same organization operates every execution environment.

Anthropic’s current FDE role description assigns customer production applications, deployment support, and artifacts such as MCP servers and agent skills to FDEs. This is an employer’s stated role scope, not evidence about every deployed team.

Our interpretation: reducing infrastructure work changes the implementation backlog, but the customer-specific decisions still need owners. Judge the deployment by a supported workflow with clear operating authority, not by how little infrastructure code the team wrote.

The six-row responsibility worksheet

Copy these prompts into the deployment review. For every row, record one named customer decision owner and the provider contact or documentation that establishes the other side. “Shared” is a discussion category; it is not a complete owner field.

1. Runtime and service limits

Provider scope to verify: harness operation, documented limits, version behavior, and support route. Customer/FDE work: choose supported configuration, measure representative task behavior, and decide whether limits fit the workflow. Evidence: a versioned configuration and test trace. Reopen when: the model, harness, configuration, or service limits change.

2. Execution environment

Provider scope to verify: which organization provisions compute and manages its boundaries. Customer/FDE work: inventory network routes, dependencies, file lifecycle, and environment-specific operating tasks. Evidence: an environment diagram checked against an actual execution. Reopen when: hosting, networking, packages, or storage changes. If execution is on customer infrastructure, do not assign its operation to the harness provider by assumption.

3. Data access

Provider scope to verify: available access mechanisms and documented data handling. Customer/FDE work: obtain the data owner’s approval for the intended workflow and test allowed and denied access. Evidence: an approved resource inventory plus test results. Reopen when: a resource, identity, or data classification changes.

4. Tool effects

Provider scope to verify: tool invocation and approval mechanisms available in the chosen setup. Customer/FDE work: define what may be changed, who approves consequential actions, and how repeated calls behave. Evidence: a trace showing the resulting external state, including a retry case. Reopen when: a tool gains a new action or permission. A completed agent run is insufficient evidence that a downstream change happened exactly once.

5. Acceptance

Provider scope to verify: relevant service behavior and accessible execution evidence. Customer/FDE work: have the business owner approve workflow-specific success and failure conditions. Evidence: representative cases, known failures, and an explicit launch decision. Reopen when: users, workflow rules, or model behavior change. See the evaluation contract for a deeper acceptance artifact.

6. Recovery and support

Provider scope to verify: service escalation and recovery commitments. Customer/FDE work: name who can stop customer actions, reconcile partial changes, operate a fallback, and authorize resumption. Evidence: a rehearsal with an observed external-state check. Reopen when: the support team, escalation path, or fallback changes. Use the incident ownership card for response routing.

Worked example: a support-ticket drafting agent

Fictional example: a customer wants an agent to read an approved knowledge base and support ticket, then save a suggested reply. It must not send a message to the customer. The following names and evidence are illustrative, not an account of a real deployment.

• Runtime: Maya, the FDE, records the selected configuration and tests long-ticket behavior against documented limits. A model change triggers a fresh sample review.
• Environment: Leon, the platform owner, approves the selected hosted environment after checking required connectivity and file cleanup. Moving execution into a company network reopens this row.
• Data: Priya, the support data owner, approves the knowledge-base collection. A denied-access case confirms that unrelated tickets are inaccessible. Adding a second collection requires review.
• Tool effects: Maya implements a draft-only adapter; Leon owns its credential. A repeated request updates the same draft without creating a second one. Readback confirms that no message was sent. Adding a send action requires a new authority decision.
• Acceptance: Priya reviews routine, ambiguous, and unsupported cases. Unsupported cases must be routed to a human. She records the limited launch decision and unresolved failure cases.
• Recovery: Sam, the support operations lead, rehearses disabling the adapter, locating pending drafts, and returning to manual work. Priya authorizes resumption after the team checks the affected tickets.

The review uncovers a gap: everyone assumed the provider could retract a reply after the support system sent it. The team keeps the integration draft-only until an authorized customer owner defines how sending and correction would work. The managed runtime remains useful; the external action needs its own decision.

Run a boundary review before rollout

• Choose one workflow and list its six responsibility rows.
• Replace inferred provider scope with a specific document or confirmed agreement.
• Name the customer decision owner and implementer for each row.
• Attach evidence from the configured system, including one denied action and one interrupted or repeated operation.
• Hold rollout for unresolved consequential responsibilities; record the owner and evidence needed to resolve them.
• Schedule a review when a listed change trigger occurs.

What this means for FDE teams

For an engineer, the useful portfolio artifact is a deployment boundary you can explain and test. For a team lead, assign enough authority and customer access for the FDE to resolve the worksheet. The FDE can coordinate the review without becoming the permanent owner of the customer’s data, business acceptance, and support operation.

Sources and limits

Primary sources linked above were checked September 15, 2026. The OpenAI announcement describes product scope; the Anthropic posting describes intended role responsibilities. Neither establishes universal deployment obligations, realized productivity, or customer outcomes. The worksheet and fictional example are editorial synthesis. Confirm current product documentation and agreements for your chosen service.