Connor Holly

← AI Skills

Cloud Agent Deployment

Agent Orchestration

deploymentSDKagents

What It Does

Defines a workflow for building production AI agents that run 24/7 in the cloud. Covers the Claude Agent SDK, E2B sandboxing for safe code execution, and a local-to-cloud promotion path.

The Pattern

The core principle: build locally first, promote to cloud only when proven. Most agents should start as local scripts with full development capabilities, then get translated to cloud-safe versions once they work reliably.

Agent architecture follows a Boss/Intern pattern. The primary model (expensive, capable) handles reasoning and decisions. A secondary model (cheap, fast) handles grunt work like summarization, filtering, and formatting. Custom tools connect to external services.

Cron Schedule → Agent Wrapper → Primary Model (reasoning)
                              → Secondary Model (grunt work)
                              → Custom Tools (APIs, databases)
                              → E2B Sandbox (code execution)

Three common agent patterns:

  1. Analytics + Reporting: Fetch data from APIs, summarize with the cheap model, format and send to a channel. Used for daily metrics, weekly overviews.

  2. Code Analysis + Actions: Scan a codebase, filter false positives with the cheap model, create tickets for real issues. Used for code health monitoring.

  3. Error to Fix to PR: List errors from monitoring, analyze with the primary model, generate a fix, test in a sandbox, open a draft PR if tests pass. The most autonomous pattern.

E2B sandboxing isolates code execution. Use it when agents need to run code (testing fixes, reproducing bugs, executing user-submitted code). Skip it for read-only analysis or API-only agents.

The recommended sandbox pattern:

Agent writes fix → Runs tests in sandbox → Tests pass? → Open PR
                                          → Tests fail? → Iterate

Local-to-cloud promotion requires tool translation. Local agents use native file system tools (read, write, grep). Cloud agents use API equivalents (clone + search, PR creation). The mapping is:

  • Read → code_read_file
  • Grep → code_search
  • Glob → code_file_tree
  • Bash (tests) → e2b_run_tests
  • Edit → github_create_pr (indirect, via PR workflow)

Key Decisions

Local first, cloud second. Building in the cloud is slow (deploy cycles, limited debugging). Build locally where you have full capabilities, then port. Keep both versions for complex agents.

Promote only critical agents. Cloud deployment costs money and adds complexity. Only promote agents that must run when your machine is off, monitor something critical, or where missing an alert costs real money.

Custom tools over MCP servers. For cloud agents, prefer direct tool implementations (function decorators) over MCP subprocess patterns. MCP transport can be flaky in containerized environments.

Budget and turn limits. Every cloud agent has max_turns and max_budget_usd constraints. These prevent runaway agents from burning API credits or looping forever.

When to Use It

  • Building monitoring agents that need to run on schedules (error scanning, metrics reporting)
  • Creating automated workflows that respond to events (new errors, threshold breaches)
  • Moving proven local agent workflows to 24/7 cloud operation
  • Any agent that needs to execute code safely (sandbox requirement)
← Back to skills