Skip to main content

Agent Engine overview

Agent Engine turns a folder of Python agent code into a live HTTPS chat endpoint, with no servers to manage. This page gives you the 30-second mental model, explains the three supported frameworks, walks the deploy lifecycle, and compares Agent Engine honestly to the closest products on GCP, AWS, and Azure.

What Agent Engine is

You write an agent — a program that talks to a language model and can call tools. You upload the folder that contains it. The platform builds your code into a container image (a packaged, runnable copy of your app), runs it, and gives you a URL you can send messages to. When nobody is talking to your agent, the platform stops it entirely so it costs nothing to sit idle. The next message wakes it up automatically. This is called scale-to-zero.

You deploy with one command:

platformctl deploy ./my-agent

There is exactly one product and one deploy path here. We do not have a "Classic" track and a "v2" track running side by side, and we have not renamed this service. If that ever changes, the old names will keep working and this page will say so.

The 30-second mental model: the harness

Every deployed agent is really two things in one container: your code, and the harness — a small web server the platform bakes into every agent image. The harness answers HTTP, feeds each incoming message to your code, and wires in the managed services every agent needs, so you never write plumbing:

The harness gives your agent, automatically:

  • A model. An OpenAI-compatible chat model from Crusoe managed inference, reached through a helper called foundry_model(). You can swap the model with an environment variable instead of a code change.
  • Sessions. Each conversation gets a session_id. The platform stores the conversation history and replays it to the model on every turn, so turn 2 remembers turn 1. See sessions.
  • A memory bank. Long-term memory your agent writes to with an explicit "memorize" step and searches with the search_memory tool. See memory.
  • A code sandbox. The run_python tool runs Python in an isolated, single-use environment — never in your agent's own container. See tools.

Because the harness owns the HTTP surface, every agent exposes the exact same API once deployed, no matter which framework it was written in. Callers never need to know or care.

The three frameworks

A framework is the agent SDK your code is written for. You pick one per agent at deploy time, and the platform detects it from your entry file. All three are first-class:

FrameworkEntry fileMust exportGuide
ADK (Google Agent Development Kit)agent.pya module-level root_agentADK guide
LangGraphgraph.pya module-level graph (compiled)LangGraph guide
CrewAIcrew.pya module-level crewCrewAI guide

These are the real, unmodified open-source frameworks — the platform runs your ADK, LangGraph, or CrewAI code as-is. Each framework gets a small Crusoe SDK (crusoe_adk, crusoe_langchain, crusoe_crewai) that provides the model helper and the built-in tools, already installed in the base image.

The deploy lifecycle

Every deploy moves through a simple, visible lifecycle. You can watch it with platformctl status or GET /v1/agents/{name}:

  • building — the platform is turning your code into a container image and installing your requirements.txt.
  • deploying — the image is built; the platform is rolling out a new revision (an immutable snapshot of image + settings) and waiting for it to serve traffic.
  • ready — your agent is live and answering requests.
  • failed — something went wrong. The reason lands in the agent's message field: for build failures that is the tail of the actual build output, so you can read the real error without hunting for a separate build log. See deploy and troubleshooting.

How it compares

Honest comparison with the closest managed agent runtimes. They are mature products from the biggest clouds; this platform is in alpha. Both facts belong in the table.

Crusoe Agent EngineVertex AI Agent Engine (GCP)Bedrock AgentCore (AWS)Foundry Agent Service (Azure)
Deploy pathOne documented path: platformctl deploy ./dirPython SDK call (agent_engines.create()); API resource is still named reasoningEngines after two renamesagentcore deploy CLI; a second, older product (Bedrock Agents "Classic") is frozen but its docs are still liveazd deploy — the quickstart documents five parallel ways to do it
FrameworksADK, LangGraph, CrewAI — identical HTTP API once deployedADK first-classStrands, LangGraph, CrewAI, ADK, OpenAI Agents SDKAgent Framework, LangGraph, OpenAI Agents SDK; plus no-code "Prompt agents"
Sessions, memory, code executionBuilt in and wired automatically by the harnessSeparate sub-products, each billed on its own SKUSeparate services — AgentCore meters roughly 12 components independentlyThreads built in; storage choice ("Basic" vs "Standard" setup) affects compliance and is easy to miss
What they have that we don'tGlobal regions, SLAs, compliance programs (VPC-SC, CMEK, HIPAA)Global regions, SLAs, managed identity/gateway/browser servicesGlobal regions, SLAs, a no-code agent builder

What we don't have yet, stated plainly: this platform is in alpha. There is no SLA, no multi-region footprint, and no built-in content-safety/guardrails layer. There is also no public API hostname yet — the web console at https://console.codyhill.dev is the public front door, and automation reaches the API through an endpoint your administrator provides (the $CAI_API pattern you will see throughout these docs). For a full service-by-service mapping, see service mapping.

Where to go next