What is an AI agent runtime? (And how it differs from a framework or a chat app)

Ask ten engineers what an "AI agent" is and you will get ten answers. Ask them how to run one for a thousand users — with history, tools, files, a Telegram bot and a monthly bill — and the answers get much shorter. That gap is what an agent runtime fills.

This article explains the three layers you will run into when building with agents — frameworks, chat apps and runtimes — what each one is responsible for, and how to tell which one you actually need.

The short version

• A framework is a library. It helps you write the loop that calls a model, parses tool calls and calls the model again. You own everything around it.
• A chat app is a product. It gives one person a conversation with a model, sometimes with plugins. You do not own the loop or the data.
• An agent runtime is a server. It runs many agents for many people, and owns the boring but hard parts: sessions, memory, tool execution, sandboxing, channels, scheduling, usage metering and an API your own software can call.

A useful comparison is the web: frameworks are like Express or Rails, chat apps are like a hosted website builder, and a runtime is closer to an application server plus database plus process manager, already wired together.

What an agent actually needs at run time

A demo agent is a loop: send messages to a model, run whatever tool it asks for, append the result, repeat. That fits in fifty lines. The moment real users show up, the list grows:

1. Identity and instructions. Each agent needs a persona and rules that survive restarts — in FastClaw that is a set of files such as SOUL.md, IDENTITY.md and AGENTS.md stored per agent.
2. Sessions. Every conversation needs its own history, keyed so that two users (or the same user on two platforms) never see each other's turns.
3. Memory. Facts worth keeping beyond one conversation — a user's timezone, a project's conventions — need to be written somewhere and recalled later.
4. Tools, executed safely. Shell commands, file writes and web fetches are what make agents useful. They are also what make them dangerous when strangers can talk to them.
5. Model plumbing. Retries on flaky APIs, prompt caching, streaming, per-agent model choice and the ability to swap providers without rewriting code.
6. Front doors. Web chat, an HTTP API, and the chat apps where people already are: Telegram, Slack, WeChat and friends.
7. Time. Agents that only respond are half as useful as agents that can also wake up on a schedule.
8. Accounting. Token usage per turn, per agent and per end-user, so someone can be billed — or at least warned.

None of this is about prompting. All of it has to exist before an agent is a product.

Frameworks: great for writing the loop

Agent frameworks give you abstractions for models, tools, chains, graphs and memory. They are the right choice when the agent logic itself is your differentiator — a novel planning strategy, a research pipeline, an evaluation harness.

What they usually do not give you is the server around it. You decide where sessions are stored, how tool calls are isolated, how a Discord message becomes a function call, how to resume after a crash, and how to deploy the whole thing on more than one machine. Teams often discover that the framework was 10% of the work and the surrounding runtime was the other 90%.

Chat apps: great for one person

Consumer and team chat apps are the fastest way to use a model. Some let you define custom assistants or add plugins. They are the right choice when a person wants help and nobody needs to integrate anything.

Their limits show up when you want the agent to be part of your system: your users, your data, your billing, your chat channels, your servers. You cannot usually call them as a backend for thousands of end-users, put them in your community's Telegram group under your own bot, or keep the data on your own hardware.

Runtimes: the layer in between

An agent runtime sits between the two. You configure agents rather than code them, and you call them through an API rather than a UI — though a good runtime has a UI too.

FastClaw is one example: a single Go binary that acts as an "agent factory". Concretely, it gives you:

• Many agents, each with its own files and settings. Create them in the console, from the CLI or over the API. See Agents.
• Any model provider. OpenAI, Anthropic, DeepSeek, Ollama, OpenRouter and other OpenAI-compatible APIs, with per-agent overrides and automatic retries. See Models.
• A sandbox for tools. Commands run in Docker or an E2B cloud sandbox, and on hosted deployments everything an untrusted chatter triggers is locked inside it. See Sandbox.
• Channels. Bind the same agent to Telegram, Discord, Slack, Feishu, WeCom, WeChat, WhatsApp, LINE or iMessage. See Channels.
• An API for your app. An OpenAI-compatible /v1/chat/completions endpoint plus agent management, end-user namespaces and usage reporting. See API.
• A scheduler. Agents can create their own cron jobs ("remind me every weekday at 9"). See Scheduler.

Because it is a runtime, the agent you chat with in the browser is the same agent that answers in Slack and the same one your backend calls over HTTP. Configure once, reach it everywhere.

How to choose

Pick a framework if:

• the reasoning strategy is the product,
• you have a team ready to build and operate the server around it,
• and you only need one or two agents with fixed behaviour.

Pick a chat app if:

• the user is you or your colleagues,
• nothing needs to be integrated into your own product,
• and you are happy with the vendor's data handling.

Pick a runtime if:

• you need several agents, or one agent for many people,
• the agent must live in chat apps or behind your own API,
• tools must run safely on behalf of strangers,
• or you want to self-host and own the data.

These choices are not exclusive. A common pattern is a runtime in production, with a framework used inside a custom tool or skill when one task needs bespoke orchestration.

Questions to ask any runtime

If you are evaluating runtimes — FastClaw or otherwise — these questions separate demos from infrastructure:

• Where do tool calls run, and who decides? Is there a hard boundary for untrusted users, or just a prompt asking the model to behave?
• How are sessions keyed? Can one API key serve thousands of end-users with isolated history and memory?
• What happens when the model API fails? Does a failed turn come back as an error you can handle, or as a polite apology billed like a success?
• Can it scale out? Single-binary simplicity is great on a laptop; can the same thing run on Postgres with several replicas?
• What is the license? Can you run it commercially, and under what conditions?

Where to go next

If you are building a product on top of agents, read how to add AI agents to your SaaS or the guide for SaaS builders. If you want a bot running tonight, follow the Telegram tutorial. And if you are deciding between self-hosting and a managed setup, the pricing page lays out both.