Best tools to build AI agents.

What to build it with, and where it runs. Product names in this area change every few months, so the shape here is durable and the names are light. Verify current pricing and availability before you commit to anything.

People talk about agents as one thing. They are not, and the kind you pick decides most of the hard constraints later. This is our own way of cutting it and it has held up across every build we have done.

• Text agents. Read and write: emails, documents, records, systems. No special constraints. Start here.
• Batch agents. The same, on a schedule, while nobody is watching. Easy to build, and the one place you must sort out alerting.
• Coding agents. Work on a codebase. The most mature category by a distance, and hosting is a non-question because it runs on your machine.
• Voice agents. Live conversation, with a hard physical constraint. Below roughly 700 milliseconds of round trip it feels like a conversation; above about 900 the caller notices and disengages. That forces real-time infrastructure whatever else you do.
• Computer-use agents. Drive a screen or browser like a person would. Impressive, and the one we usually talk clients out of.

On computer-use specifically. The headline benchmarks look respectable, in the mid eighties. The spread is the problem: strong on common sites like Gmail, and roughly 50 to 70 per cent on awkward internal systems. Which is to say it works on the things that already have an API and struggles with the things that do not, and the second category is the whole reason people want it.

Names and links, grouped by the kind of agent. Verify pricing and availability before committing to anything: this part of the page has a shelf life measured in months.

Text and batch agents. Start here, and probably finish here.

• No-code, inside a chat product: ChatGPT Workspace Agents, Claude Projects and Skills, Gemini Gems, Microsoft Copilot Studio
• No-code, dedicated builders: Lindy, Zapier Agents, Relevance AI
• Low-code: n8n, Dify, Flowise, Langflow. All four are open source and free to run on your own small server
• Full code: Claude Agent SDK, OpenAI Agents SDK, Google ADK, LangGraph, CrewAI, Pydantic AI, Mastra

Picking between the frameworks, if you get that far. LangGraph for stateful production work in a regulated setting, and it has much the longest list of named enterprise deployments. CrewAI when the job splits into roles and you want something working this afternoon. Pydantic AI for Python teams who want type safety without the ceremony. Mastra or the Vercel AI SDK if you are in TypeScript.

Voice agents. Synthflow for no-code. Retell, Bland and ElevenLabs for managed, at roughly $0.07 to $0.20 a minute before model costs. Vapi if you want to assemble your own from best-of-breed parts. LiveKit or Pipecat if you are running the real-time layer yourself.

Coding agents. Claude Code in the terminal, Cursor in the editor, Codex as a cloud task runner, Replit when you want the hosting to come with it. Open-source options where you pay only for model tokens: OpenCode, Cline, Aider.

Hosting, when you need it. Trigger.dev or Inngest for long jobs with no timeout ceiling. Railway, Render or Fly.io for a persistent process. Any small VPS from about five pounds a month if you are self-hosting n8n or Dify.

Three ways to build, and they are not three levels of seriousness. They are different trade-offs.

• No-code. Write instructions in plain English, attach what it needs to know, tick the connectors. Genuinely capable now, and enough for most first agents. Either inside a chat product like Claude, ChatGPT or Gemini, or a dedicated builder such as Lindy or Zapier’s agents.
• Low-code. Assemble on a visual canvas and drop into code for the awkward parts. n8n, Dify, Flowise and Langflow are the serious options, and all four are free to run on a small server of your own, which matters more than it sounds once compliance enters the picture.
• Full code. You write the loop and own the runtime. Worth it only when you can finish this sentence: “the no-code version cannot do this specific thing.” If nobody can finish it, the answer is not code.

Choosing a low-code tool, in a line each. n8n for operations-heavy work where AI is one step in a bigger flow. Dify for chat-first work over your own documents, and the friendliest start. Flowise for prototyping on a canvas.

Lindy is the clearest illustration of why the kind of agent matters more than the tool. A single subscription puts you in three of the five categories at once.

It does text and batch work: inbox triage, scheduling, lead qualification, follow-ups, described in plain English rather than drawn on a canvas. It adds a voice agent. And on the higher tiers it adds computer-use browser automation for sites with no API.

The text work is reliable and cheap. The computer-use work carries that 50 to 70 per cent success rate on awkward interfaces. Same subscription, completely different levels of trust, and nothing in the interface tells you which one you are standing in.

Worth also knowing how it differs from Zapier, because it is the cleanest real-world example of the agent-versus-automation line. Zapier runs rigid if-then logic across a very large catalogue of integrations, and it just works. Lindy reasons and decides. So Zapier wins deterministic multi-app plumbing; Lindy wins the rules-but-judgement work where context matters.

One warning nobody advertises. Credit-priced builders charge for every attempt, and reviewers repeatedly report credits going faster than expected during setup and debugging, because you pay for the misfires while you are still learning the tool. Budget for the learning, not only the running. That applies to the whole category, not just Lindy.

No-code, low-code and full code look like rungs. They are three different buildings with no lift between them.

You do not upgrade from a no-code agent to a canvas to code. You rebuild. Plain-English instructions do not become a canvas, and a canvas does not become code.

That does not make “start simple” wrong. It makes the honest version: start simple to find out what you actually need, expect to rebuild once, and price it in from the beginning. Anyone who tells you that you can always grow into it has not done it.

What does transfer changes what you should invest in. Your understanding of the process transfers. The integrations you now know you need transfer. And the written procedure transfers, because those files are becoming a shared format across the major vendors. The method survives the rebuild even when the build does not.

People ask whether to use Claude or Lindy, or ChatGPT or n8n. Fair question, and a category error, because Lindy and n8n run on somebody’s model, usually one of those three.

The big three do not sit in a row on this page. They sit in every row at once.

The consequence that costs money: in no-code you get the vendor’s model and that is that. Choosing Workspace Agents is choosing OpenAI’s models, permanently. In low-code and full code the model becomes a swappable component, which is why Mastra advertises support for dozens of providers. If model choice or lock-in matters to you, that alone is a reason to start one tier up.

And a distinction worth separating generally: AI in the builder is not AI in the runtime. Plenty of platforms use AI to help you construct the automation. Genuinely useful, and unrelated to whether the running thing is an agent. Ask which every time.

The question nobody asks until it bites. Four answers:

• The vendor runs it. You built it no-code, so there is nothing to host. Simplest, and you have inherited someone else’s decisions.
• A managed agent runtime. You write code and the model provider supplies the environment and keeps the session state. All three major providers now offer a version, though they differ on whether they supply the compute or let you choose it.
• Your own process. A small server, a container, or a job platform built for work that takes minutes rather than milliseconds.
• Real-time infrastructure. Voice only, and not optional there.

The rule that saves the most grief: the kind of agent sets the hosting floor, not how you built it. A voice agent needs real-time infrastructure whether you clicked it together or wrote it from scratch. A batch agent runs happily on a five-pound server however clever it is.

The most common deployment failure for a first real agent, and invisible until it matters.

Most people’s instinct is a serverless function, because that is the deployment they already know. But agents run for minutes and serverless functions time out. The agent gets a hard task, works away, and dies two thirds of the way through. Cold starts break anything holding state, too.

The clearest statement of why this is hard came from OpenAI when they rebuilt their agent tooling this year: agents do work over time rather than in one call, they operate over state including files and results, they need boundaries and budgets, and they need memory that is managed deliberately rather than accumulating by accident. A serverless function gives you none of those four.

The fixes, easiest first: use a managed runtime and let the provider own it, use a job platform with no timeout ceiling, or run a persistent process.

Everything above is easier to hold once you see one real thing pulled apart. This is Agent Builder, which you can go and use. It interviews you across six phases and produces an agent requirements document you can hand to whoever is building.

By our own test it is a genuine agent, and it is the most advanced thing we run. Here is what it is actually made of, as built at the time of writing. We will rebuild parts of it and this description will drift, but the reasoning behind each choice is the part worth having anyway.

The parts. A coordinator plus six specialists, one for each phase: Discovery, Architecture, Registry exploration, Permissions, System prompts, Package. Seven agents in total. The coordinator holds the state and decides who runs next. The specialists never talk to each other.

The skills. Each specialist carries its own system prompt: what to ask, what a good answer looks like, and when its phase is finished. That is the written procedure, and it is the part that would survive if we rebuilt the whole thing on a different platform tomorrow. Everything else is plumbing.

The orchestrator. The coordinator emits a locked phase header at the top of every turn. Our site reads that header to keep the interface in step with where the conversation actually is. That header is the one handshake we can see from outside, and it is why the phases cannot silently drift.

The hosting. None of it runs on our servers. Our site opens a session, streams events back, and closes it. The agents themselves live at Anthropic as managed agents. Our entire client is a few hundred lines: create a session, post an event, stream the events back. There is no queue, no worker, no state store and nothing to keep alive.

The handshakes. Three of them. Our site opens the session. The coordinator delegates to a specialist. The specialist returns its output plus the phase marker. That is the whole contract, and it is small on purpose.

The human in the loop. The entire thing is a conversation, so a person is present at every turn. More importantly, it cannot act on anything. It reads, asks and writes a document. That is assist-level authority by design, which is why it needs almost no guardrails: there is nothing for it to break.

And the trap we fell into. The coordinator pins the version of each specialist. Update a specialist on its own and absolutely nothing changes, because the coordinator is still calling the pinned one. It fails silently and looks like the model ignoring you. That cost us a confusing afternoon, and it is the kind of thing nobody warns you about in a multi-agent setup.

We chose managed agents. That was a decision, not an obvious default, and it is worth showing the roads not taken because your answer may well differ.

Why managed won, for this specific job. It is a conversation that produces a document. It takes no actions, touches no client systems, and the data has no residency constraint. Given that, paying somebody else to own the runtime was straightforwardly the right trade.

Change any one of those and the answer changes. If it had to write into a client’s CRM, we would want the permissions in our own hands. If the data could not leave the EU, we would self-host the low-code version on a European server and accept the fixed path. If it only ever needed to run for us, the no-code version would have been enough and we would have saved a fortnight.

That is the actual method: not picking a favourite tier, but working out which constraint is binding and letting it decide.

Worth knowing if anyone quotes you for building sandbox infrastructure. As of April 2026 the OpenAI Agents SDK ships with seven sandbox providers built in, so running agent-generated code safely is now a configuration choice rather than a build.

The differences are narrow and specific. Daytona starts fastest, around 90 milliseconds, billed by the second. E2B has the strongest isolation and the best agent-focused tooling, around 150 milliseconds. Blaxel keeps the environment alive between calls for a much faster resume. Modal is the only one that puts a GPU inside the sandbox. Browserbase is a different thing entirely: hosted browser sessions rather than general compute.

People budget for the bill they can see. The bill they get looks different.

• What they expect: the subscription, the per-minute rate, or model tokens at the advertised price.
• What actually costs money: credits burned while debugging, because credit-priced tools charge for every misfire while you are still learning. The rebuild, when it comes. And the operational work: monitoring, alerting, and somebody paying attention.

On the model bill itself, the two biggest levers are design decisions rather than procurement ones. Reusing context instead of re-sending it, and caching the parts that repeat, together account for far more than which provider you picked. The vendor you choose matters less than whether you re-send the same context on every turn.

Voice is the one place with a clean published crossover: managed platforms are cheaper until roughly ten thousand minutes a month, after which running your own framework starts to win by a wide margin. Start managed, move when the bill tells you to.

The argument nobody makes, and it has had teeth since the EU AI Act’s transparency and deployer duties took effect in August 2026.

The easiest build tier is the one where you do not get to choose where your data sits. Build no-code and the region, the log retention and the compliance posture are the vendor’s, inherited rather than chosen. You cannot answer “where does our data go”, because you never decided. Self-host the low-code tool and you pick the region: that five-pound server turns out to be a data decision.

Two specifics worth knowing. Deployers are expected to keep records, and if your platform does not retain them long enough you cannot comply. And deployers are responsible for checking their provider’s compliance, so “we just use the tool” is not a defence.

Not legal advice. Read it alongside our EU AI Act guide, and if the answer matters commercially, get someone to look at your specific setup.