Two years ago, "where do I run my agent?" had one honest answer: on a VM you maintained yourself. In 2026, the honest answer depends on who's asking. The agent platform space has fragmented into at least four distinct archetypes. Each one bakes in a different set of commitments around language, framework, pricing shape, and how much plumbing you're expected to build yourself.
This is a survey, not a ranking. If you're evaluating where to put an agent that real users will touch, the goal here is to help you recognize which archetype each platform belongs to. That recognition usually matters more than any feature list.
Four Archetypes
Every platform marketed as "for AI agents" in 2026 fits into one of four buckets. The bucket matters because it tells you what the platform was designed to do first, and what's bolted on after.
Two options sit outside the grid. Zapier Agents is a no-code automation tool with agent features, a different audience and a different shape. And self-hosting is always an option; it's just a commitment to be your own platform team, a commitment whose true costs are easy to underestimate. If EU procurement criteria drive your evaluation, see how the hyperscalers and the rest of the field score on the EU shortlist.
We maintain head-to-head comparisons for every major platform above, each with feature tables, pricing breakdowns, and honest "when to pick the other one" sections.
See all comparisonsThe Three Structural Trade-offs
Feature matrices don't help much when you're choosing between archetypes. The decisions that actually shape a platform are structural, and they're almost never on a pricing page.
1. Language Commitment
AgentKit, Mastra, Vercel's eve, and Cloudflare's Agents SDK are all TypeScript-first. Most ML-adjacent teams are Python-first. That mismatch is real, and it rarely surfaces until week three. Mastra's own tagline, "Python trains, TypeScript ships," is honest about it: the assumption is two codebases.
LangChain, Microsoft Agent Framework, CrewAI, LangSmith Deployment, Gemini Enterprise Agent Platform's Agent Runtime (which runs Python agents built with ADK), Inngest (via its Python SDK), and Connic all support Python. Mastra is TypeScript-only; eve and Cloudflare's Agents SDK are built for TypeScript. If your agent shares data-prep code with a model pipeline, the language of the runtime matters more than it looks.
2. Framework Lock-in
Framework + deployment stacks only accept agents built in their framework. LangSmith Deployment runs LangGraph agents; Mastra Cloud runs Mastra agents; eve is built for the Vercel Agent Stack; Cloudflare's Agents SDK assumes Workers and Durable Objects underneath. Leaving means rewriting. That's a legitimate trade. A tight loop between framework and runtime is genuinely ergonomic. But it is a commitment.
Agent-native runtimes and workflow engines are framework-independent: bring any agent code and run it. The cost is you lose some framework-specific niceties (LangSmith's tracing, for instance, is uniquely deep for LangChain-family projects).
3. The Connector Gap
This is the gap most teams underestimate. Agents in production almost always receive events from somewhere: a Stripe webhook, a Kafka topic, an SQS queue, a scheduled cron, an inbound email. Every framework and most runtimes leave that part to you.
With LangChain, Microsoft Agent Framework, CrewAI, Inngest + AgentKit, Trigger.dev, Mastra, LangSmith Deployment, Agentuity, eve, or Cloudflare's Agents SDK, you're building the consumer, the webhook handler, the signature validation, and the dead-letter queue yourself. On the hyperscaler runtimes, ingestion is an assembly job across each cloud's own eventing services. n8n is the partial exception: its integration catalog is one of the largest anywhere, though agents there are nodes inside workflows, not the unit the platform deploys and versions. None of that is an AI problem. It's plumbing. But it's the plumbing that turns an agent into a product. Connic ships first-party connectors for Kafka, SQS, Stripe, Email, Postgres, Telegram, Webhooks, Cron, and more, so the plumbing is a platform concern instead of your code.
Pricing Model Taxonomy
Pricing pages are hard to compare because the unit of billing is different on each one. A $50/mo plan and a $250/team/mo plan mean different things at different org sizes. Five models dominate the 2026 landscape (prices verified against each vendor's pricing page, May 2026, and re-checked July 2026):
There's no objectively correct model. The question is which shape your finance team can approve. Enterprise procurement usually prefers a predictable floor with known per-unit rates above it (subscription-as-credit or flat + usage). A solo developer running hobby volume often prefers pure metering. Most teams sit somewhere in between, and they usually find out which model their org actually tolerates after the first surprise bill.
How to Choose
Four questions cut through most of the noise when you're picking between platforms.
What language is your agent code?
If it's TypeScript and you want deep framework integration, Mastra, Trigger.dev, eve, or Cloudflare's Agents SDK fit naturally. If it's Python, rule out the TS-only platforms on day one, especially if the agent shares libraries with a model pipeline. That's a much cheaper realization on day one than on day thirty.
Do you already have a framework you love?
If you're committed to LangGraph, LangSmith Deployment is the first-party home and worth the framework tie. If your product already ships on Vercel, eve is the same first-party trade on the Vercel Agent Stack. If you use LangChain or CrewAI primarily as building blocks and don't want the deployment tied to them, a framework-independent runtime gives you the escape hatch.
What's the input shape of your agent?
If your agent responds to a user in a chat UI, an API call is enough; pick almost anything. If it reacts to Kafka events, SQS messages, Stripe webhooks, or inbound email, count the connectors you'd have to build yourself on each platform. That count, not the pricing difference, is usually the bigger cost of the choice.
How predictable does your bill need to be?
Procurement processes hate variable bills. Bootstrapped startups and hobby projects often don't. A fixed subscription is easier to defend in a budget meeting than a metered bill that might triple next month. Match the billing shape to the org shape.
Where Connic Fits
Connic is an agent-native runtime. It runs Python. It's framework-independent. It ships first-party connectors for the messy edges of production (Kafka, SQS, Stripe, Postgres, Email, Telegram, Webhooks, Cron, and more). And its subscription doubles as a usage credit at uniform per-unit rates, so no per-seat math and no per-execution surprise bills. Observability, evals, agent memory, and vector storage are included, not invoiced separately.
Where Connic isn't the right fit: if your agent is TypeScript and you're committed to Mastra, Trigger.dev, eve, or Cloudflare's stack; if you're all-in on LangGraph and want LangSmith Deployment's tracing; if the work is visual business-process automation with AI steps, where n8n is the more natural shape; if your procurement already runs through a hyperscaler agreement and the agent surface is small; if you need Apache 2.0 self-hostability on day one; or if a pure usage-based model genuinely suits your workload better than a subscription-as-credit floor. Each of those is a legitimate reason to pick a different archetype, and the comparison pages and the EU shortlist cover them in depth.
The Bottom Line
The 2026 agent platform landscape isn't one market with a dozen competitors. It's four distinct archetypes serving four different kinds of team. The mistake most evaluations make is comparing across archetypes on features. Does LangChain "have" managed hosting? No, it's a framework. Does Inngest "have" an agent SDK? Yes, AgentKit, but bolted on a workflow engine. Does n8n "run" agents? Yes, as LangChain-based nodes inside workflows. Questions like these go in circles.
The better question is: which archetype fits how your team works, and within that archetype, which platform has the trade-offs you can live with? The answer is rarely the one with the longest feature list. It's the one whose structural commitments match yours.
Start with the comparison index, read the one for the platform you're actively considering, and see whether the "when to pick the other one" bullets describe your team. If they do, pick that one. If they don't, you probably want Connic.
Either way, you'll have picked for the right reasons.