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_memorytool. See memory. - A code sandbox. The
run_pythontool 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:
| Framework | Entry file | Must export | Guide |
|---|---|---|---|
| ADK (Google Agent Development Kit) | agent.py | a module-level root_agent | ADK guide |
| LangGraph | graph.py | a module-level graph (compiled) | LangGraph guide |
| CrewAI | crew.py | a module-level crew | CrewAI 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
messagefield: 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 Engine | Vertex AI Agent Engine (GCP) | Bedrock AgentCore (AWS) | Foundry Agent Service (Azure) | |
|---|---|---|---|---|
| Deploy path | One documented path: platformctl deploy ./dir | Python SDK call (agent_engines.create()); API resource is still named reasoningEngines after two renames | agentcore deploy CLI; a second, older product (Bedrock Agents "Classic") is frozen but its docs are still live | azd deploy — the quickstart documents five parallel ways to do it |
| Frameworks | ADK, LangGraph, CrewAI — identical HTTP API once deployed | ADK first-class | Strands, LangGraph, CrewAI, ADK, OpenAI Agents SDK | Agent Framework, LangGraph, OpenAI Agents SDK; plus no-code "Prompt agents" |
| Sessions, memory, code execution | Built in and wired automatically by the harness | Separate sub-products, each billed on its own SKU | Separate services — AgentCore meters roughly 12 components independently | Threads built in; storage choice ("Basic" vs "Standard" setup) affects compliance and is easy to miss |
| What they have that we don't | — | Global regions, SLAs, compliance programs (VPC-SC, CMEK, HIPAA) | Global regions, SLAs, managed identity/gateway/browser services | Global 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
- Deploy an agent — directory layout, upload, status polling, redeploys, and deploy errors.
- Framework guides: ADK, LangGraph, CrewAI — each with a complete runnable example.
- Invoke an agent — the request/response shapes, streaming, and who needs credentials.
- Sessions and memory — short-term vs long-term memory.
- Tools —
run_python,search_memory, and writing your own. - Secrets and environment variables — configuration that rolls new revisions.
- Files and the editor, logs, traffic and revisions, troubleshooting.