Managed Agent Harnesses: The Control Boundaries You Still Own

An agent resumes after a crash and reports that a customer refund succeeded. The managed runtime has recovered the conversation. Has the application also established that the refund happened exactly once, used the correct caller’s authority, and matched the amount the customer approved?

Those are separate engineering questions. Managed execution can remove substantial operational work while leaving the application responsible for the meaning and authorization of external effects.

This article reviews primary implementation sources available through September 15, 2026 and proposes a practical acceptance process. It is an architectural analysis, not a hands-on comparison of hosted platforms. The examples use simulated business operations and do not describe a production ContextOS deployment.

What has been implemented

OpenAI’s Agents API documentation describes managed sessions, orchestration, context compaction, and recovery, with application-provided tools and a choice of execution environment. Its interface distinguishes agent configuration, environment, durable session, and events. This creates an integration surface around an operated harness rather than requiring the application to implement the whole loop.

Anthropic’s Managed Agents architecture report separates the session log, harness, and sandbox. The report also describes an earlier context-reset workaround becoming unnecessary with a different model. That is a concrete reason to prefer interfaces that permit implementation changes without entangling every application concern.

LangChain’s September 9 Connections announcement describes runtime credential resolution in Managed Deep Agents v0.7.0 and later. Ownership and credential type are separate: a credential can belong to the deployment or caller and can use a secret or OAuth. The feature is described as part of the prerelease. This does not establish that a particular account has access or that every provider supports identical semantics.

These systems have different APIs and service boundaries. The common design opportunity is to make durable work, execution infrastructure, and identity explicit. Treat that as an architectural comparison, not a feature-parity claim.

Write a responsibility map before the integration

The following map is a proposed application design checklist. Exact ownership must be confirmed against the selected service contract and deployment configuration.

An application team should be able to point to one owner for each row. “The platform handles agents” is too broad to resolve an incident involving a real external system.

A durable session is not an exactly-once transaction

Consider this illustrative sequence:

1. The application approves one refund for an eligible order.
2. The agent calls a refund tool.
3. The payment service commits the refund.
4. The response is lost before the agent records success.
5. The session resumes and considers retrying.

Replaying step two blindly can duplicate the external effect if the provider does not deduplicate it. Abandoning the operation can leave the customer refunded while the application says it failed. A durable conversation alone cannot resolve that ambiguity.

The proposed application pattern is to assign a stable identity to the logical operation before dispatch, retain the validated request, and reconcile uncertain outcomes through the provider’s actual contract. If the provider offers idempotency, verify its key scope, retention period, and response behavior. If it does not offer sufficient guarantees, use explicit reconciliation and keep the outcome unresolved until evidence is available.

Do not describe this as global exactly-once execution. A local deduplication table cannot create a provider guarantee that does not exist. It can coordinate local attempts, preserve evidence, and prevent known duplicate dispatches; the external service still determines what happened there.

This fault table is a proposed test plan. None of these tests has been run against the named hosted products for this article.

Caller identity is necessary and insufficient

A caller-specific credential can prevent every action from appearing under one shared bot account. It also makes resource visibility differ appropriately between users. But possession of a token does not establish that a particular action is within the current task.

Imagine a caller who may update many tickets but asks the agent to summarize one. A retrieved comment says to close the entire queue. The caller’s broad API permission does not make that instruction part of the user’s request. The application needs to relate the proposed effect to the trusted task, target resource, current state, and any required approval.

The proposed action check should evaluate several independent conditions:

allow only when:
  caller and workload identity are valid
  tenant and target resource match
  requested effect is within delegated scope
  current policy permits the effect
  required approval matches the normalized request
  operation and precondition checks pass

This is explanatory pseudocode, not a replacement authorization implementation. ContextOS’s existing governance model, identity foundation, and API contracts already define the relevant normative surfaces.

Credential revocation deserves its own test. Pause a session, revoke access, then resume it. Verify what happens before the next protected read and before the next write. Do not assume that a credential resolved earlier remains valid for every later step or that resuming a conversation revalidates all business conditions automatically.

Keep the evidence outside the success message

A useful completion record should link the accepted requirement to observed external state. The agent’s narrative is one artifact, but the evidence should also identify the request, permission decision, tool response, and reconciliation result where applicable.

For a simulated refund, retain the logical operation identifier, normalized order and amount, policy revision, approval reference, provider reference, and final status. Store credential references rather than secrets. Define retention and access according to the sensitivity of the underlying data.

For a coding workflow, retain the source revision, patch, exact validation commands, results, and unresolved checks. A managed session that successfully completes its turn may still have produced an unacceptable change. Application acceptance should remain a separate state.

This separation also improves portability. When the evidence schema describes business facts rather than only vendor event names, the team can compare execution providers without discarding its outcome history. Vendor traces remain useful diagnostic evidence alongside that record.

Plan for a harness that changes underneath the application

Managed services can evolve context handling, scheduling, tool selection, or recovery. First determine which versions and controls the provider actually exposes. Where exact pinning is unavailable, record the visible configuration, date, model identity, and service metadata instead of inventing a reproducibility guarantee.

Maintain a small sentinel set that tests high-value behavior: scope restriction, ambiguous outcomes, long-session continuity, and explicit failure reporting. Keep expected outcomes independent of the agent’s own response. A change in these results should trigger investigation before it becomes a larger migration decision.

The application should also define what a rollback means. Restoring an application configuration may not restore an earlier provider-side harness. An operational fallback could instead disable a tool, reduce autonomy, route a supported subset through an alternative, or require manual completion. Test the fallback that is actually available.

Evaluate the whole migration

Use the existing application workflow as the baseline. A managed candidate should receive the same task distribution, external authority, initial state, and acceptance criteria. Measure total cost, latency, completion, unauthorized effects, unresolved outcomes, and operator effort.

Separate adoption work from steady-state operation. Integration, policy mapping, evidence export, and debugging are migration costs. Session execution, tools, environments, and human recovery are operating costs. Avoid declaring a winner from model-token charges alone.

A sensible proposed sequence is:

1. Inspect the documented capabilities and configuration limits.
2. Integrate read-only tools and verify identity and evidence capture.
3. Exercise interruption and revocation in an isolated test environment.
4. Add one bounded write operation with independently checked outcomes.
5. Compare a frozen candidate with the baseline on representative cases.
6. Expand only after the declared outcome and recovery gates pass.

This sequence is deliberately measurable. It lets a team identify which operating work moved to the provider and which controls still require application code.

The next research opportunity

The valuable next comparison is an operational one: can an application preserve authority, effect accounting, and acceptance criteria while moving between a self-operated and a managed harness? Publish the failures as well as the integration code.

The research roadmap proposes that study. Its acceptance gate is evidence of correct behavior under interruption and identity changes, alongside resource and human costs. A feature checklist alone cannot answer it.

Managed harnesses can be a strong implementation choice. The enduring application responsibility is to define what work is authorized, establish what actually happened, and decide whether the result is acceptable.

Sources and evidence notes

1. OpenAI. Agents API overview. Living official documentation, reviewed September 15, 2026.
2. Anthropic. Scaling Managed Agents: Decoupling the brain from the hands. April 8, 2026. First-party architecture report.
3. Victor Moreira, LangChain. Connections: Managed credentials and per-caller identity for Managed Deep Agents. September 9, 2026. Prerelease feature report.

The series ledger records scope and limitations. Responsibility maps, fault scenarios, migration gates, and examples here are proposed engineering methods, not vendor promises or measured results.

What to read next

• September harness engineering field guide.
• Subagent context inheritance and independent review.
• Agent harness benchmark protocol.
• Research and publishing roadmap.