DigitalOcean Managed Agents: How Firecracker MicroVMs and 16,000+ MCP Tools Are Reshaping Agent Infrastructure (2026)

A single AI agent session on DigitalOcean now boots in 886 milliseconds, resumes from a paused state in 305 milliseconds, and bills by the second — only for active CPU cycles. For the growing number of teams drowning in the operational complexity of running agentic workloads across six or more vendors, that number changes the economics entirely.

DigitalOcean launched Managed Agents in public preview on October 2, 2026, and it represents something more significant than another cloud product launch. It is the first purpose-built, mid-tier cloud platform designed from the ground up for AI agent workloads — combining Firecracker microVM isolation, a unified MCP tool gateway with 16,000+ integrations, and per-second active-CPU billing in a single managed service. Where AWS Bedrock AgentCore targets enterprise orchestration and Docker Cloud Sandboxes focus on developer portability, DigitalOcean is betting that the majority of agent builders need something different: infrastructure that is genuinely simple to operate, transparently priced, and secure enough to run untrusted LLM-generated code without a dedicated platform team.

This guide breaks down the architecture, benchmarks what it actually costs to run agent sessions, compares it head-to-head with the alternatives, and walks through what Agentic AI Architects need to know before choosing where to deploy their next production agent fleet.

Table of Contents

• Why Agent Infrastructure Is Its Own Category Now
• Architecture Deep Dive: Harness Runtime + Action Gateway
• Firecracker MicroVMs: Why Containers Are Not Enough for Agents
• Action Gateway: 16,000+ Tools Through a Single MCP Endpoint
• Performance Benchmarks: Sub-Second Startup, Sub-200ms Execution
• Pricing Model: Per-Second Active CPU Billing Explained
• Supported Agent Frameworks and Custom OCI Images
• DigitalOcean vs AWS AgentCore vs Docker Cloud Sandboxes vs E2B
• Deployment Walkthrough: From CLI to Production
• Real-World Use Cases and Early Adopter Results
• What This Means for the Agent Infrastructure Landscape
• FAQs
• Key Takeaways
• References

Why Agent Infrastructure Is Its Own Category Now

Running an AI agent in production in 2026 is nothing like deploying a traditional web application. An agent session is episodic — bursts of intense compute sandwiching long idle stretches while the model thinks or waits for tool responses. It generates and executes code dynamically, often code the agent itself wrote moments ago. It needs access to dozens of external tools — GitHub, Stripe, Snowflake, browsers, shell environments — each with its own credential management and rate-limiting requirements. And it needs to maintain state across those bursts: file systems, conversation history, working context that must survive pauses and resume exactly where it left off.

The traditional cloud compute model — hourly VMs, always-on containers — was designed for predictable, steady-state workloads. It bills you for 100% of provisioned capacity even when your agent is idle 75% of the time waiting for an LLM response. It gives you either bare containers (fast but shared-kernel, insufficient isolation for running untrusted code) or full VMs (secure but slow to start and expensive to keep warm).

This mismatch is why a new category of agent infrastructure platforms has emerged in 2026. E2B pioneered Firecracker-based sandboxes for code execution. Fly.io launched Sprites for short-lived agent environments. Modal and Vercel shipped their own microVM sandboxes. AWS responded with Bedrock AgentCore as an enterprise orchestration layer. Docker released Cloud Sandboxes for developer portability. Each solves a piece of the puzzle, but none of them wraps compute, tool access, inference, and billing into a single managed service designed specifically for agent workloads — until DigitalOcean’s Managed Agents.

As DigitalOcean CPTO Vinay Kumar put it: “Teams building and running agents are drowning in complexity, operating across six separate vendors held together with custom integration code.” Managed Agents is DigitalOcean’s bet that agents need a purpose-built platform, not a patchwork of generic cloud services.

Architecture Deep Dive: Harness Runtime + Action Gateway

DigitalOcean Managed Agents is built on two integrated components that work together within a single managed boundary: the Harness Runtime for compute and the Action Gateway for tool access. Understanding how they interact is essential for architects evaluating the platform.

More Read

Microsoft Decision-1 and the Rise of Decision Models: The Complete Guide for Agentic AI Architects (2026)

Alibaba Cloud Agent Native Cloud: AgentRun, AgentLoop & AgentTeams Guide (2026)

Forrester Wave Adaptive Process Orchestration Q3 2026: The Inaugural Report That Redefines How RPA Meets Agentic AI

Harness Runtime: The Compute Layer

The Harness Runtime provides isolated execution environments using Firecracker microVMs — the same open-source hypervisor technology that powers AWS Lambda. Each agent session gets its own dedicated virtual machine with a full Linux kernel, file system, and network stack. No kernel sharing, no container escape vectors, no blast radius beyond the individual session.

Key capabilities of the Harness Runtime include:

• Isolated microVM sandboxes with built-in tools like Chromium for browser-based agent tasks
• Session persistence with pause, resume, and fork — pausing stops CPU and memory charges while preserving complete session state (memory, files, running processes)
• Parallel session management for subagent workflows, enabling fan-out patterns across multiple repositories or tasks
• Structured event logging tracking tool calls, model requests, and file operations for observability
• Execution and access APIs for running commands and previewing applications inside running sessions

The session lifecycle model is particularly well-designed for agentic workloads. Unlike ephemeral serverless functions that lose all state on completion, a Managed Agents session can be paused during idle periods (automatically or manually), preserving its entire working state. When resumed, the session comes back with “memory, files, and running processes exactly as they were” — a critical requirement for long-running agent tasks that may span hours or days with intermittent activity.

Action Gateway: The Tool Access Layer

The Action Gateway is a managed MCP (Model Context Protocol) endpoint that brokers access between agents and external tools. Rather than each agent session managing its own API credentials, rate limits, and integration code, the Action Gateway centralizes all of this behind a single, governed interface.

The gateway provides:

• 16,000+ tools across 500+ providers through a single MCP endpoint
• DigitalOcean-maintained first-party tools: web search, web fetch, browser automation, and infrastructure management
• Third-party connectors: GitHub, HubSpot, Stripe, Snowflake, PagerDuty, Box, Supabase, Exa, and hundreds more
• Credential brokering that keeps secrets outside agent environments — agents never see raw API keys
• Centralized permission controls with configurable human approval requirements for sensitive operations
• Built-in rate limiting, retries, backoff, and timeout management
• Custom MCP server registration for teams’ internal tools and APIs

The credential brokering design deserves special attention. In most agent deployments today, API keys and service credentials are injected into the agent environment — meaning a compromised or misbehaving agent could exfiltrate them. The Action Gateway keeps credentials on its own side of the boundary, never passing them into the microVM. The agent makes a tool request; the gateway authenticates it, applies permission checks, and forwards the call with the appropriate credentials. This is a meaningful security improvement for any team running agents that interact with production systems.

DigitalOcean reports that the Action Gateway’s tool matching achieves 99.3% accuracy in matching agent intent to tool capabilities, based on internal testing. For the MCP protocol ecosystem, this level of integration fidelity is a strong signal that the gateway layer is production-grade rather than a thin wrapper over raw MCP connections.

Firecracker MicroVMs: Why Containers Are Not Enough for Agents

The choice of Firecracker microVMs over containers is not incidental — it reflects a fundamental security reality that every Agentic AI Architect must understand: AI agents routinely generate and execute untrusted code, making container-level isolation insufficient.

The Container Problem

Traditional Docker containers share the host operating system’s kernel. They use Linux namespaces and cgroups to create process-level isolation, but all containers on a host ultimately interact with the same kernel. A kernel vulnerability in one container can compromise all others on the same host. For a web application serving predictable, pre-written code, this risk is often acceptable. For an AI agent that dynamically generates Python scripts, shell commands, and arbitrary code — often from LLM outputs that cannot be fully predicted or audited in advance — shared-kernel isolation is a genuine security liability.

As the hyperscale cloud providers have implicitly acknowledged, none of them chose containers for their most security-sensitive compute offerings. AWS uses Firecracker for Lambda. Google uses gVisor for Search and Gmail isolation. Azure uses Hyper-V. When the stakes involve running arbitrary, untrusted code, the industry consensus points firmly toward hardware-level virtualization boundaries.

How Firecracker Solves It

Firecracker is an open-source virtual machine monitor (VMM) that uses KVM hardware virtualization to run workloads in lightweight VMs. Each microVM has its own dedicated kernel — a kernel exploit inside one microVM cannot reach the host or other microVMs. The critical advantage over traditional VMs is weight: Firecracker boots a microVM in approximately 125 milliseconds with roughly 5MB of memory overhead, compared to the multi-second startup and hundreds of megabytes required by conventional virtual machines.

This gives DigitalOcean Managed Agents three properties that matter for agent workloads:

For teams building agent safety infrastructure, the microVM boundary is a foundational layer. Runtime safety checks (prompt injection detection, output filtering, behavioral guardrails) are important, but they operate at the application level. The microVM provides the infrastructure-level guarantee that even if those application-level checks fail, the damage is contained to a single session.

What About gVisor?

Google’s gVisor takes a different approach — a user-space kernel implementation that intercepts and re-implements system calls without hardware virtualization. It is lighter than Firecracker and used by Modal and Google’s own Agent Sandbox on GKE. The trade-off is compatibility: not all syscalls are perfectly emulated, which can cause issues with complex agent workloads that depend on specific kernel behaviors. Firecracker’s full-kernel approach avoids this at the cost of slightly higher per-instance overhead — a trade-off most agent platform architects consider favorable given the relatively small number of concurrent sessions a typical team runs.

Action Gateway: 16,000+ Tools Through a Single MCP Endpoint

The Action Gateway is arguably the most architecturally distinctive feature of DigitalOcean Managed Agents. While other platforms focus primarily on the compute layer (sandbox isolation, session management), the Action Gateway addresses a pain point that compounds as agent deployments scale: tool access governance.

The Tool Integration Problem

A production AI agent rarely operates in isolation. A typical enterprise agent workflow might need to read from a GitHub repository, query a Snowflake data warehouse, create a HubSpot contact, send a Stripe invoice, and file a PagerDuty incident — all within a single task execution. Without a centralized gateway, each of these integrations requires:

• Credential provisioning and rotation
• Rate limit tracking per API
• Error handling and retry logic per provider
• Permission controls (which agents can access which tools)
• Audit logging of every external call

Multiply this by the number of agents and the number of tools, and the integration surface area becomes unmanageable without a dedicated team. The Action Gateway collapses this complexity into a single MCP endpoint that handles all of the above centrally.

How the MCP Integration Works

The Model Context Protocol (MCP) has emerged as the de facto standard for agent-tool communication in 2026. By implementing a managed MCP server, the Action Gateway ensures compatibility with any agent framework that speaks MCP — which now includes all major frameworks.

When an agent needs to use a tool:

1. The agent sends a tool-use request through the MCP protocol to the Action Gateway
2. The gateway matches the request to the appropriate tool (99.3% accuracy per DigitalOcean’s internal benchmarks)
3. Permission checks are evaluated — if the tool requires human approval, the request is held until approved
4. The gateway authenticates with the external service using its own credential store (the agent never sees the credentials)
5. Rate limiting, retries, and timeout management are applied transparently
6. The response is returned to the agent through the MCP channel

For teams that have built custom internal tools or APIs, the gateway supports custom MCP server registration, allowing you to bring your own tool endpoints into the same governed access layer as the 16,000+ pre-built integrations.

The Security Implications of Credential Brokering

The credential brokering model is a significant architectural decision. In a conventional agent deployment, you might inject environment variables containing API keys into the agent’s container or VM. If the agent is compromised — through prompt injection, a malicious tool response, or a bug in the agent framework — those credentials are exposed.

With the Action Gateway, credentials live on the gateway side of the boundary. The agent can use a tool but cannot see the credentials that authenticate the use. This reduces the blast radius of a compromised agent from “every service it has credentials for” to “only the actions it requests in real-time, subject to permission controls.” For regulated industries and any team running agents against production systems, this is a material security improvement.

Performance Benchmarks: Sub-Second Startup, Sub-200ms Execution

DigitalOcean has published specific performance numbers for the Managed Agents platform that are worth examining closely, because agent infrastructure performance directly affects user experience and cost:

The 305-millisecond resume time is particularly important for the platform’s economic model. If resume were slow — say, 5-10 seconds — teams would keep sessions running continuously to avoid the latency penalty, negating the cost savings of per-second billing. At 305ms, the pause/resume cycle is fast enough that aggressive auto-pause policies become practical: pause after 30 seconds of idle time, resume instantly when the next request arrives, and pay nothing in between.

For context, Daytona claims sub-90ms cold starts (the fastest reported in the microVM sandbox space), and E2B targets sub-second startup. DigitalOcean’s 886ms is competitive though not category-leading for raw boot time — but the 305ms resume is genuinely fast and reflects the value of their snapshot-based checkpointing system.

Pricing Model: Per-Second Active CPU Billing Explained

DigitalOcean Managed Agents uses per-second active CPU billing, which is a pricing model designed specifically for the episodic nature of agent workloads. Here is how it works in practice:

A typical agent session does not use CPU continuously. It bursts during code execution and tool calls, then idles while waiting for LLM inference responses. In DigitalOcean’s published example:

• A two-vCPU session averaging 25% CPU utilization with 4GB peak memory costs $0.060/hour in compute charges
• The same session under traditional provisioned-capacity billing would cost $0.126/hour
• That is a 52% cost reduction from billing only for active compute

When a session is paused, CPU and memory charges stop entirely. Only storage charges for the preserved session state continue — at typical cloud storage rates, this is negligible compared to compute costs.

For Action Gateway tools, the pricing splits by type:

• First-party tools (DigitalOcean-maintained: web search, browser automation, infrastructure management) use Harness Runtime rates — no additional per-call charge
• Third-party tools (GitHub, Stripe, Snowflake, etc.) follow their published per-use pricing

DigitalOcean also offers a prepaid Inference and Agents Balance option in $5–$500 increments with auto-reload, which is practical for teams wanting predictable budgets. A public preview discount is available for eligible usage during the preview period.

For architects comparing this with alternatives: AWS Bedrock AgentCore charges per invocation plus per-step pricing, which can be harder to predict for complex multi-step agent workflows. E2B charges per-second for sandbox time. Docker Cloud Sandboxes are priced as part of Docker’s subscription tiers. DigitalOcean’s model is closest to E2B’s but adds the integrated inference and tool gateway — meaning one bill instead of three.

Supported Agent Frameworks and Custom OCI Images

DigitalOcean Managed Agents supports a specific set of agent frameworks out of the box, with an escape hatch for anything else:

The custom OCI image support is the critical feature for enterprise adoption. Any agent that can be packaged as a container image — which includes essentially any agent framework — can run on the platform. Teams using Orca ADE, CrewAI, AutoGen, or proprietary agent frameworks built in-house can deploy to Managed Agents without rewriting their agent code. The platform handles the infrastructure layer; the agent code runs unmodified inside the microVM.

For RPA teams transitioning into agentic automation, this is significant. A team running Microsoft Copilot-integrated workflows or custom Python-based agents does not need to adopt a specific agent framework to use the platform. Package your existing agent as a container image, push it to DigitalOcean Container Registry, and the Harness Runtime handles isolation, session management, and tool access.

DigitalOcean vs AWS AgentCore vs Docker Cloud Sandboxes vs E2B

The agent infrastructure market has fragmented rapidly in 2026. Here is how the major platforms compare across the dimensions that matter most to Agentic AI Architects:

When to Choose Each Platform

Choose DigitalOcean Managed Agents when: You need a single platform that handles compute, tool access, inference, and billing without assembling multiple vendors. You want per-second billing and session persistence without building your own orchestration layer. You are a mid-market team or startup that does not have a dedicated platform engineering team. You want MCP-native tool access with credential brokering out of the box.

Choose AWS Bedrock AgentCore when: You are an enterprise already invested in the AWS ecosystem. You need the full Bedrock model catalog with enterprise SLAs. You want the Agent Registry for discoverability across large organizations. You need A2A protocol support for agent-to-agent communication at scale. You have the platform engineering capacity to manage the additional complexity.

Choose Docker Cloud Sandboxes when: Your team’s workflow is Docker-native and you want seamless local-to-cloud portability. You are focused on developer experience for building and testing agents. You do not need an integrated tool gateway or inference service. You want to use your existing Docker subscription.

Choose E2B when: Your primary need is secure code execution sandboxes, not full agent lifecycle management. You are building a product that embeds AI code execution (like a coding assistant). You want the simplest possible API for spinning up isolated execution environments. You do not need session persistence or integrated tool access.

Deployment Walkthrough: From CLI to Production

Getting started with DigitalOcean Managed Agents follows DigitalOcean’s characteristically simple deployment model. Here is the workflow:

Step 1: Authenticate and Launch

# Authenticate with DigitalOcean CLI
doctl auth init

# Launch a Claude Code agent session
doctl harness-runtime launch --harness claude-code --name my-first-agent

# Launch a custom OCI image agent
doctl harness-runtime launch --image registry.digitalocean.com/my-team/my-agent:latest --name custom-agent

Step 2: Configure Action Gateway Tools

Tool access is configured through the DigitalOcean control panel or via manifest-based specifications. You select which tools your agent can access, configure credential connections (once, centrally — not per agent), and set permission policies including which operations require human approval.

Step 3: Manage Session Lifecycle

Sessions can be managed via CLI, API, or control panel:

# List active sessions
doctl harness-runtime list

# Pause a session (stops billing, preserves state)
doctl harness-runtime pause --session-id abc123

# Resume a paused session (305ms to readiness)
doctl harness-runtime resume --session-id abc123

# Fork a session (branch a new session from current state)
doctl harness-runtime fork --session-id abc123 --name forked-experiment

Step 4: Monitor and Observe

Structured event logging captures tool calls, model requests, and file operations, providing observability into what agents are doing without requiring external logging infrastructure. For teams that need deeper observability, the event logs can be exported to existing monitoring stacks.

Production Considerations

For teams moving beyond experimentation to production deployments, several architectural patterns are worth noting:

• Parallel subagent fan-out: The Harness Runtime supports launching parallel sessions, enabling patterns where a coordinator agent distributes subtasks across multiple specialist agents — each in their own isolated microVM
• Session forking for A/B testing: Fork a session to create an exact copy of the current agent state, then send different instructions to each fork to compare outcomes
• Auto-pause for cost management: Configure aggressive auto-pause timeouts (as low as 30 seconds idle) to minimize costs without losing state — the 305ms resume time makes this practical
• Credential rotation: Since credentials are managed centrally in the Action Gateway, rotating API keys does not require updating individual agent sessions — a significant operational improvement at scale

Real-World Use Cases and Early Adopter Results

DigitalOcean ran a private beta with select customers before the public preview launch. The reported results provide concrete evidence of the platform’s production readiness:

Qencode: Support Triage Automation

Qencode, a video encoding platform, deployed a support-triage agent on Managed Agents that automated the assessment of incoming support requests across multiple communication channels. The results:

• 4-8 hours saved weekly on triage work that was previously manual
• Response times reduced from hours to “nearly instant” for initial triage classification
• The agent runs across Slack, email, and web chat channels, centralizing triage logic that previously required manual switching between platforms

This is a textbook agentic automation use case — a repetitive, cross-platform task that requires judgment (classifying request severity, routing to the right team) but follows learnable patterns. The kind of workflow that traditional RPA struggles with because the inputs are unstructured text, but that LLM-powered agents handle naturally.

Other Private Beta Participants

OpenHands (an open-source coding agent platform) and Amplitude (the product analytics company) also participated in the private beta, though specific results from those organizations have not been published. The involvement of OpenHands is notable because it validates the platform’s support for custom OCI images — OpenHands runs its own agent framework, not one of the pre-built options.

What This Means for the Agent Infrastructure Landscape

DigitalOcean’s entry into managed agent infrastructure carries significance beyond the product itself. Three broader implications are worth tracking:

1. Agent Infrastructure Is Becoming a Standard Cloud Primitive

When a mid-tier cloud provider like DigitalOcean — known for simplicity and developer accessibility — ships a purpose-built agent platform, it signals that agent infrastructure has crossed from “emerging category” to “expected cloud service.” Just as managed databases, object storage, and container orchestration became standard cloud offerings, managed agent runtimes are now on the same trajectory. Teams that have been building custom agent infrastructure in-house should evaluate whether that investment is still justified.

2. The MCP Protocol Is Winning the Tool Integration Standard War

DigitalOcean’s decision to build the Action Gateway entirely around MCP is a strong market signal. Combined with MCP’s adoption by Anthropic, the Agentic AI Foundation, and essentially every major agent framework, MCP has effectively won the tool integration protocol competition. For Agentic AI Architects, the practical implication is clear: invest in MCP-compatible tool interfaces. Any tool you build today that does not speak MCP will need an adapter layer tomorrow.

3. The Agent Infrastructure Market Is Stratifying

A clear market stratification is emerging:

• Enterprise tier: AWS AgentCore, Azure AI Foundry, Google Vertex AI Agent Builder — full enterprise feature sets, maximum configurability, higher complexity
• Mid-market tier: DigitalOcean Managed Agents — managed, opinionated, lower complexity, competitive pricing
• Developer/sandbox tier: E2B, Fly.io Sprites, Docker Cloud Sandboxes — focused on specific developer workflows, lighter-weight

This stratification mirrors what happened in the broader cloud market: AWS, Azure, and GCP for enterprise; DigitalOcean, Linode, and Vultr for mid-market; and Heroku, Render, and Railway for developer workflows. The same pattern is now playing out in agent infrastructure, which is a sign of market maturation.

Frequently Asked Questions

Is DigitalOcean Managed Agents production-ready?

It is currently in public preview (launched October 2, 2026), which means it is available to all DigitalOcean users but may not carry the same SLA guarantees as generally available services. DigitalOcean ran a private beta with production workloads (Qencode, OpenHands, Amplitude) before the public preview, and the published performance benchmarks suggest production-grade infrastructure. However, teams deploying mission-critical agent workloads should evaluate carefully during the preview period and plan for potential API changes.

Can I run my own custom agent framework on Managed Agents?

Yes. Beyond the pre-built support for Claude Code, Codex CLI, OpenCode, Hermes, and LangGraph, the platform accepts any agent packaged as an OCI container image. This means frameworks like CrewAI, AutoGen/AG2, Pydantic AI, or entirely custom agent implementations can run unmodified. You push your container image to DigitalOcean Container Registry and launch it as a Harness Runtime session.

How does the Action Gateway handle rate limits from third-party APIs?

The Action Gateway manages rate limiting, retries, backoff, and timeouts centrally. When a third-party API returns a rate-limit response, the gateway handles the retry logic transparently — the agent receives the eventual successful response without needing to implement its own retry logic. For tools that require human approval (configured per tool or per operation), the request is held until approved, with configurable timeout policies.

What happens to my data when a session is paused?

When a session is paused, the complete state — memory, files, running processes — is snapshotted and stored. CPU and memory charges stop; storage charges continue at standard rates. When resumed, the session returns to exactly the state it was in when paused, including any files written, environment variables set, and processes that were running. The snapshot is encrypted at rest and stored within DigitalOcean’s infrastructure.

How does this compare to running agents on my own Kubernetes cluster?

Running agents on a self-managed Kubernetes cluster gives you maximum control but requires your team to build and maintain the isolation layer (microVMs or gVisor), the tool access gateway, the session management system, the credential brokering, and the billing/monitoring infrastructure. For teams with dedicated platform engineering capacity, this may be justified. For everyone else, a managed platform like DigitalOcean Managed Agents eliminates that operational burden at the cost of some configurability.

Key Takeaways

• DigitalOcean Managed Agents launched in public preview on October 2, 2026, as the first purpose-built, mid-tier cloud platform for AI agent workloads, combining Firecracker microVM isolation, managed MCP tool access, and per-second billing.
• Firecracker microVMs provide hardware-level isolation essential for running LLM-generated code — containers’ shared-kernel model is insufficient for untrusted agent workloads.
• The Action Gateway centralizes access to 16,000+ tools through a single MCP endpoint with credential brokering, keeping API keys out of agent environments — a meaningful security improvement over credential injection.
• Performance benchmarks show 886ms to session readiness, 305ms resume from pause, and 189ms command execution round-trip — fast enough to make aggressive auto-pause policies economically practical.
• Per-second active CPU billing can reduce costs by up to 52% compared to provisioned-capacity pricing for typical agent workloads that idle while waiting for inference responses.
• Custom OCI image support means any agent framework (CrewAI, AutoGen, Pydantic AI, proprietary) can run on the platform without modification.
• The agent infrastructure market is stratifying into enterprise (AWS, Azure, GCP), mid-market (DigitalOcean), and developer/sandbox (E2B, Docker) tiers — mirroring the broader cloud market’s maturation.
• MCP as the tool integration standard is further validated by DigitalOcean’s full commitment to MCP for the Action Gateway, reinforcing that architects should invest in MCP-compatible tool interfaces.

References

1. DigitalOcean, “Managed Agents Public Preview,” DigitalOcean Blog, October 2, 2026. https://digitalocean.com/blog/managed-agents-public-preview
2. DigitalOcean, “MicroVMs for Agents,” DigitalOcean Blog, 2026. https://digitalocean.com/blog/microvms-for-agents
3. DigitalOcean, “Why We Built Managed Agents,” DigitalOcean Blog, 2026. https://www.digitalocean.com/blog/why-we-built-managed-agents
4. DigitalOcean, “Managed Agents Product Documentation,” DigitalOcean Docs, October 2026. https://docs.digitalocean.com/products/managed-agents/
5. InfoQ, “DigitalOcean Managed Agents,” InfoQ News, October 2026. https://infoq.com/news/2026/10/digitalocean-managed-agents
6. DigitalOcean, “Managed Agents Release Notes: Public Preview,” DigitalOcean Docs, 2026. https://docs.digitalocean.com/notes/2026/managed-agents-public-preview/
7. Dev.to, “How to Sandbox AI Agents in 2026: Firecracker, gVisor, Runtimes & Isolation Strategies,” 2026. https://dev.to/aiagentengineering/how-to-sandbox-ai-agents-in-2026-firecracker-gvisor-runtimes-isolation-strategies-14pk
8. Northflank, “Best Agent Cloud Platforms,” Northflank Blog, 2026. https://northflank.com/blog/best-agent-cloud-platforms
9. AI Agents Directory, “AI Agents News Brief: October 1, 2026,” AI Agents Directory, 2026. https://aiagentsdirectory.com/news/ai-agents-news-brief-october-1-2026
10. AI Agents Directory, “AI Agents News Brief: October 3, 2026,” AI Agents Directory, 2026. https://aiagentsdirectory.com/news/ai-agents-news-brief-october-3-2026