An AI agent platform for developers is a runtime you can deploy to, read logs from, and debug without asking support. Frameworks decide how the agent thinks. The platform decides whether you can see what it did at 3am, whether its state survives a restart, and whether moving to another model is a config change or a rewrite.
The short answer. If your agent is a graph and your team lives in Python, LangGraph Cloud. If your agent is a long-running process that needs a machine, a terminal and logs, Sokko. If it is a feature inside a Next.js product, Vercel. If your company already runs on AWS or GCP and governance decides, AgentCore or Vertex. If the hard part is a visual RAG app, Dify.
How these are ordered. By how much control a developer keeps after deployment, which is the property that separates a runtime from a black box. Sokko writes this page; the prices are the part to trust, the order is the part to discount.
Table of Contents
Why developers pick a platform, not a framework
You can build an agent with nothing but an API key and a loop. Most teams do that first, and it works until two things happen: the agent has to survive a deploy, and someone else has to debug it.
At that point the questions stop being about prompts:
Where does it run, and does it stay running? A container that restarts on crash is different from a function that sleeps between requests.
Where does state live? In memory means gone. On a disk means you have to think about what happens when the disk is replaced.
Can I get a shell? When the thing misbehaves, reading a log line is not debugging.
How do I ship a change? Editing production config through a web form is not a workflow.
What does it cost at ten agents rather than one? The unit matters more than the headline.
Frameworks answer none of these. That is not a criticism of frameworks, it is why the platform decision is separate.
The six platforms at a glance
| Platform | Programming model | State and runtime | Published price (November 2026) | Escape hatch |
|---|---|---|---|---|
| Sokko | Agent config, terminal, CLI, MCP servers, API | Always-on machine per agent, persistent workspace, files survive restarts | Jar $49 for 2 agents; Bakery $99 for 4; memory $25 per month | Bring your own keys and model endpoint; export files and config |
| LangGraph Cloud | Python or JS graph, deployed as an API | Always-on with checkpoints; state belongs to the graph | Plus $39 per seat per month, plus resource time for deployments | Your code runs elsewhere; LangGraph is open source |
| Vercel | Node or serverless functions inside a project | Request-scoped; durable state is your database | Pro $20 per month, runtime from $0.128 per hour | Standard Next.js, deploys anywhere |
| Bedrock AgentCore | AWS-native runtime on microVMs | Always-on sessions; memory and identity are services | $0.0895 per vCPU-hour plus $0.00945 per GB-hour, and gateway, memory and model meters | AWS only, but every piece is a documented API |
| Vertex AI Agent Engine | GCP-native runtime, ADK | Always-on sessions with managed memory | Metered by runtime and requests, published as SKUs | GCP only |
| Dify | Visual workflow with an API in front | Hosted or self-hosted; not built for resident loops | Professional $59, Team $159 per workspace per month on annual billing | Open source, export and self-host |
1. Sokko
Sokko's model is that an agent is a machine, not a function invocation. Each agent gets its own isolated runtime with persistent files, so a process that was running before the deploy is still running after it. That is unusual in this list and it is the reason to consider it.
What a developer gets. A CLI (npm i -g sokko), a web terminal into the running agent, readable Markdown configuration you can diff in git, 30 days of logs on Jar and 90 on Bakery, and devboxes: separate throwaway machines for testing a branch of changes before they touch the live agent. Runtimes include OpenClaw, Hermes and Cursor, so an agent built around a coding harness has a host. Custom MCP servers can be added over HTTP or stdio, which matters if your tool layer already speaks MCP.
Model portability. Bring-your-own-keys covers Claude, GPT, Gemini and a local endpoint, so switching vendor is a setting rather than a migration, and model spend stays on an account you control.
What it costs. Jar is $49 per month with two agents, 2 vCPU, 8 GB and 30 GB of storage with a built-in browser. Bakery is $99 per month for four agents, roles, SSO and custom domains. Shared memory is $25 per month for 5 GB plus $3 per GB.
Where it loses. It is not a framework. If your agent needs a DAG of typed nodes with deterministic replay, LangGraph is the right abstraction and Sokko is the wrong one. The four-agent ceiling on Bakery is a real constraint for a fleet, there is no per-agent autoscaling story to tune, and the integration catalogue is 1,500 apps against Zapier's 9,000+.
2. LangGraph Cloud
LangGraph is the most defensible choice if you are writing the agent's control flow yourself. Nodes, edges, checkpoints and a state machine you can test in isolation. Cloud adds durable execution and an API around the graph.
What it costs. Developer tier is free. Plus is $39 per seat per month, and deployments bill on resource time on top.
Where it loses. The platform is the graph. Anything outside the graph, like a persistent disk the agent can write to, is your problem. Seat pricing also means the bill grows with your team rather than with the workload, which is fine at five engineers and awkward at twenty.
3. Vercel
If the agent is a feature inside a web product, Vercel is already there and adding an agent is a route. Streaming, edge delivery and preview deployments all work the way the rest of the app does.
What it costs. Hobby is free, Pro is $20 per month, and runtime bills from $0.128 per hour once you exceed the included allowance.
Where it loses. Functions are request-scoped. An agent that should be thinking between requests, or holding a conversation across days, needs a database and a queue that you build and operate. That is a different project, not a checkbox.
4. Amazon Bedrock AgentCore
AgentCore is what an AWS-standardised company picks. MicroVM sessions, separate memory and identity services, and the option to keep models inside the same account boundary.
What it costs. $0.0895 per vCPU-hour plus $0.00945 per GB-hour for runtime, with gateway, memory and model usage metered separately. At small scale that is cheap. At twenty always-on agents it is a spreadsheet.
Where it loses. Portability. Everything is an AWS API, and an agent built against them does not move. The IAM surface is also a project of its own.
5. Google Vertex AI Agent Engine
The same argument on GCP, with Agent Development Kit for the code and managed sessions and memory underneath.
What it costs. Metered by runtime and requests, published as SKUs rather than a price list, so you model the workload before you can quote it.
Where it loses. Same as AgentCore: excellent if your data and models already live there, a migration if they do not.
6. Dify
Dify is the fast path to an agent that answers from your documents, with a visual workflow and an API in front of it.
What it costs. Sandbox is free with 200 message credits. Professional is $59 per workspace per month billed annually, Team $159.
Where it loses. It is a builder for retrieval applications. A resident process with its own state and schedule is outside its design centre, and the further you push it the more code you write around it.
The local-to-production question
Every platform promises that local development looks like production. Check three things before you believe it.
Does the agent's filesystem survive? Run something that writes a file, restart, look. If the file is gone, that is a stateless function with extra steps.
Can you reproduce a failure? You need the prompt, the tool calls and the result for the specific run that broke. Logs that show only errors are not enough.
Can you ship without a browser? If deploying a change requires clicking through a form, you cannot review it, and it will eventually drift from the repo. A CLI or an API is the minimum.
Sokko's devboxes are the answer to the first and third at once: a separate machine with the same image where a change runs before it goes live. LangGraph's checkpoint history answers the second better than most, because the graph's state is inspectable at each step.
What an agent costs at ten of them
Per-agent hosting, assuming ten always-on agents and no model spend:
| Platform | Ten agents per month | How the number moves |
|---|---|---|
| Sokko | $99 to $297 | $99 covers four; a larger fleet is a commercial conversation |
| LangGraph Plus, five seats | $195 plus runtime time | Seats, not agents |
| Vercel Pro | $20 plus runtime, about $934 at $0.128 per hour if ten agents run continuously | Metered runtime, billed while resident |
| AgentCore, 1 vCPU / 2 GB each | ~$790 at $0.0895 per vCPU-hour plus $0.00945 per GB-hour, 730 hours | Every hour the agent is alive |
| Dify Professional | $59 per workspace | Workspaces, not agents |
The shape of each line is the point. Per-agent is flat and predictable. Per-hour punishes always-on by design. Per-seat punishes hiring. Ten agents is where you find out which one you bought.
Where Sokko is the wrong choice
Complex control flow. If the agent's logic is a state machine you want to test node by node, LangGraph.
Feature inside a web app. Vercel, because the rest of the app is already there.
AWS or GCP standardised. AgentCore or Vertex, since governance will win that argument anyway.
You want to run it yourself. A container on your own Kubernetes is a legitimate answer, and the containerisation guide covers the trade.
For the buyer's view rather than the builder's, the ten-platform comparison and the hosting comparison cover the same market from the other direction.