Plantillas de Despliegue de Agentes

What's in this pack

This is the stack a working engineer would assemble the week before shipping an AI agent to real users — not the heroic post-launch scramble when the first OOM kill takes the service down. Every pick here is a deployment template in the literal sense: clone a repo, set a few env vars, and you have an agent that handles concurrent requests, persists state, sandboxes untrusted code, and recovers from process death. Open-source-first, runs cheaply, and each layer plugs into the next.

Install in this order (skeleton → state → sandbox → queue → deploy target)

The order is deliberate. Don't pick a deploy target first. You'll end up rewriting the agent to fit the platform's quirks. Get the skeleton, state, and sandbox right locally; the deploy target is the last decision.

1. Pick one agent skeleton. If you want a batteries-included runtime with FastAPI serving, sessions, and tracing already wired, pick Agno. If you want a smaller, type-first surface where Pydantic models are the I/O contract and you assemble the HTTP layer yourself, pick PydanticAI. Either way, the goal is a /run endpoint that accepts a request and returns a typed response. Build this locally first.
2. Add a state store before you add tools. As soon as an agent has a session, you need somewhere to put it — pick Upstash Redis (serverless, pay-per-request, no idle cost) for session/cache and Upstash Kafka (or any managed queue) for the work queue if turns can take more than 30 seconds. Don't write "state" to local disk; the next pod restart erases it.
3. Wrap untrusted tool calls in a sandbox. The moment your agent executes generated code, runs shell commands, or browses the web, you need isolation. E2B is the lowest-friction choice — from e2b import Sandbox; sbx.run_code(...) and you're done. Daytona SDK is the alternative when you need persistent, snapshot-able dev workspaces (e.g., long-lived coding agents). Modal Sandboxes is the same primitive co-located with Modal compute, which matters if you're also deploying on Modal.
4. Pick a serverless template if requests are bursty. Modal (and modal-examples as the reference repo) gives you a Python decorator that becomes an HTTP endpoint with GPU access, scale-to-zero, and per-second billing — ideal for agents whose requests arrive in clusters. Replicate Cog packages a model + handler as one container with cog.yaml; great if you also serve a model and want a single deploy artifact.
5. For long-running or stateful flows, use LangGraph. When the agent is a multi-step graph (plan → search → reflect → answer) with branches and human-in-the-loop, LangGraph gives you explicit state + checkpoints — meaning a crashed turn can resume instead of restarting. Pair its checkpointer with your Redis from step 2.
6. Pick the deploy target last. Three realistic paths: (a) Serverless — wrap the FastAPI app in a Modal @asgi_app, or cog predict for Replicate, ship as a container. (b) PaaS — push the FastAPI app to Fly/Render/Railway behind a simple Dockerfile; cheapest for steady traffic. (c) Kubernetes — when you need multi-tenancy, gVisor isolation, or you've outgrown the PaaS box, use Agent Sandbox as the reference pattern for running agents safely on k8s (pod-per-session, sandbox per tool call, network policies that deny by default).

How the pieces fit

[client]
   │  HTTP /run
   ▼
[FastAPI agent skeleton]  ← Agno or PydanticAI
   │
   ├─ session/cache  ──▶  Upstash Redis
   │
   ├─ background work ──▶  Upstash Kafka  ──▶  worker (same image)
   │
   ├─ tool: run_code ──▶  E2B / Daytona / Modal Sandbox
   │
   ├─ graph state    ──▶  LangGraph checkpointer (Redis)
   │
   ▼
[deploy target]  ── Modal @asgi_app  /  Replicate Cog  /  k8s (Agent Sandbox)

The four-tool combo agent skeleton + state store + sandbox + deploy target is the minimum viable production agent. Skip any one and you'll feel it within a week: no state → users hate the amnesia, no sandbox → an rm -rf from a hallucinated tool call ruins your day, no skeleton → you reinvent FastAPI middleware badly, no deploy target → you can't actually serve traffic.

Tradeoffs you'll hit

• Agno vs PydanticAI — Agno is the bigger framework with sessions, FastAPI app, integrations, tracing already wired; the cost is opinions you have to live with. PydanticAI is smaller and type-first; you bring the HTTP layer. For a team shipping in two weeks: Agno. For a team that already has FastAPI conventions: PydanticAI.
• E2B vs Daytona vs Modal Sandbox — E2B is the fastest to integrate for ephemeral code execution (Python SDK, secure by default). Daytona shines when you need persistent, snapshot-able workspaces (long-lived coding agents). Modal Sandbox is the right pick if your compute already lives on Modal — same auth, same billing, lower latency to your model calls.
• Modal vs Replicate Cog vs k8s — Modal scales to zero, bills per-second, and treats Python as the deploy unit; ideal for bursty agent traffic. Replicate Cog is one container with cog.yaml; ideal when you also serve a model with the agent. Kubernetes (via Agent Sandbox patterns) is the right answer when you need real multi-tenancy, gVisor-level isolation, or you've outgrown the managed-platform box.
• LangGraph vs handwritten state machine — For one-shot agents (single LLM call + tool), don't pull in LangGraph; it's overhead. For multi-turn graphs with branches, retries, and human-in-the-loop, LangGraph's checkpointer earns its weight by making crashes resumable.
• Upstash Redis vs self-hosted Redis — Upstash is serverless and pay-per-request; great until you exceed ~10M commands/month, where a $20 Redis VM gets cheaper. The migration is one URL change. Don't optimize early.

Common pitfalls

• Writing session state to local disk or memory. The next pod restart erases it and users blame you for amnesia. State goes to Redis (or your DB) from day one, not after the first incident.
• Tool calls without a sandbox. The first time an agent hallucinates subprocess.run(['rm', '-rf', '/']) and your service runs it, you've lost the production cluster. E2B/Daytona/Modal Sandbox is not optional once tools include shell or code execution.
• Serverless for long agent turns. Most serverless platforms have a max execution time (Lambda 15min, Vercel 5min, Modal up to 24h). If your agent turn can take 30+ minutes, either pick Modal (long timeouts) or push the work to a queue and let the HTTP request return a job ID.
• No request-level timeout in the FastAPI skeleton. Without a timeout, one hung LLM call exhausts your worker pool. Set explicit timeouts at the HTTP boundary, at the LLM client, and at the tool call — three layers.
• Logging the full prompt + response. It feels useful in dev. In prod it leaks PII into log aggregators that aren't compliant. Truncate, redact, or sample before logging — and pair with LLM-observability tooling (Langfuse, Phoenix) for full traces under access control.