Agents are the AI personas in OpenClaw that process incoming messages. Each agent has a model provider, a system prompt, optional tools, and memory configuration. OpenClaw supports multiple model providers -- Anthropic (Claude), OpenAI (GPT), Ollama (local models), OpenRouter, and any OpenAI-compatible endpoint. You can run multiple agents simultaneously, each specialized for a different task, and configure failover chains so your agents stay available even when a provider goes down.
Master openclaw agents & model providers
Take the Introduction to OpenClaw course with hands-on lessons and challenges.
This defines two agents: a coder using Claude Sonnet and a support agent using GPT-4o. Each has its own workspace and agent directory. The workspace holds bootstrap files (SOUL.md, MEMORY.md) and the agentDir stores runtime state.
If Claude is unavailable (API error, rate limit, outage), OpenClaw automatically tries GPT-4o next. If that also fails, it falls back to the local Ollama model. This three-tier failover ensures the agent is always responsive, even during provider outages.
Ollama models must be downloaded before OpenClaw can use them. The models scan command discovers all available models across configured providers. Use ollama:model-name in your agent config to reference local models.
The DevOps agent has memory disabled because each command is independent -- there is no conversational context to track. The assistant agent has memory enabled with 100 messages of context, allowing it to reference previous conversations. Tools are scoped per agent: the DevOps agent can run SSH commands and Docker operations, while the assistant can only execute code.
Any endpoint that implements the OpenAI chat completions API can be used as a provider. This includes vLLM, LiteLLM, and custom inference servers. The agent uses the vLLM-hosted model as primary and falls back to Claude if the custom server is unavailable.
Configuring a single generic agent to handle all types of messages instead of creating specialized agents
Specialized agents with focused system prompts and tools perform significantly better than one agent trying to do everything. Create a coding agent, a support agent, and a DevOps agent instead of a single 'do-everything' agent.
Referencing an Ollama model that has not been pulled yet, causing the agent to fail with a model-not-found error
Always run `ollama pull model-name` before configuring an agent to use it. Use `openclaw models scan` to verify the model is available.
Setting memory maxMessages too high, causing slow response times and high token usage as the context grows
Start with 20-30 messages for conversational agents and increase only if needed. For stateless command-response agents (DevOps, alerts), disable memory entirely.
Using the same agentId for agents that serve different purposes, creating workspace conflicts and confused behavior
Each agent needs a unique agentId. Use descriptive names like 'coder', 'support-us', or 'deploy-bot' that clearly communicate the agent's purpose.
OpenClaw agents are AI personas defined by a model, system prompt, tools, and memory. Multiple providers (Anthropic, OpenAI, Ollama, custom endpoints) can be used across agents in the same Gateway. Failover chains ensure high availability. Each agent has an isolated workspace with its own bootstrap files and session store. For production, specialize your agents by role, match model power to task complexity, configure failover, and follow least-privilege for tool access.
Interactive lessons and challenges on Stanza, practice in VS Code, Cursor, or the web.
Interactive lessons and challenges, right in your code editor.
Check the free courses. No credit card.