Managed agent runtimes are integration partners, not Maestro

Why neither is the orchestrator

Maestro's continuations sleep for weeks, wake on arXiv RSS or sibling-publish events, fork and merge, and span both clouds. Neither vendor runtime is built for that shape of work.

Putting Maestro continuations on AgentCore or Foundry would forfeit the central architectural bet — continuations as the unit of work, the policy kernel as the control plane.

Where Maestro delegates to them

The vendor runtimes are excellent for the shape they handle: a bounded sub-task within a session, with managed memory, sandboxed tool execution, and an OTEL trace. The policy kernel may choose to delegate a tick when the sub-task is:

• a managed browser crawl (AgentCore Browser / Foundry Browser Automation),
• a code-interpreter session (both have one),
• a tool-heavy session reachable through the vendor's MCP gateway (AgentCore Gateway / Foundry Toolboxes), or
• any sub-task that fits cleanly inside the vendor's session limits.

When the kernel delegates, the worker calls Substrate.AgentRuntime.spawn_session(...), streams session events back into the continuation's event log (preserving the audit trail), and on completion collects the terminal state and resumes the continuation on the Maestro worker pool. The vendor session is one event in the continuation's history, not a new orchestrator.

The delegation rule

A continuation tick is eligible for vendor delegation when all of:

1. the kernel's route is a tier the vendor can serve, and
2. expected wall-clock for the sub-task is < vendor.session_ceiling − safety_margin, and
3. the sub-task does not need to fork, merge, or sleep on a multi-day external signal, and
4. the tenant's policy class allows external-runtime execution.

Otherwise the tick stays on the Maestro worker pool. The default is stay on Maestro — delegation is opt-in per tick, recorded in the model_call event as runtime: maestro | agentcore | foundry.

Side by side

What this changes in the Substrate

A seventh method group on Substrate — AgentRuntime — added in the architecture document's §4.3. The interface is small on purpose:

AgentRuntime {
  spawn_session(spec) -> session_id
  stream_events(session_id) -> Iterator
  signal(session_id, payload)
  terminate(session_id)
  collect_terminal_state(session_id) -> dict
}

The concrete impls are AgentCoreRuntime (Runtime + Gateway + Memory) on AWS and FoundryAgentRuntime (Hosted agents + Connected agents + Toolboxes) on Azure. Both stream events back through the substrate's EventLog so the warm store remains the single source of truth.

Sources

• AgentCore: what it is
• AgentCore GA (Oct 13, 2025)
• AgentCore pricing
• AgentCore Gateway
• AgentCore Memory
• Strands Agents
• Foundry Agent Service overview
• Foundry Agent Service GA (Mar 16, 2026)
• Foundry Hosted agents
• Foundry MCP integration
• Microsoft Agent Framework 1.0