Why Is My AI Agent So Slow?
Most people picture a slow AI agent or workflow as one bottleneck — "the model is slow" or "the server is slow" — and go straight to switching providers or upgrading the VPS. That's rarely the actual fix. Slowness is layered: it can come from a retrying auth call that looks like latency, a context window or execution payload bloated with old data, a node or tool doing genuinely slow work (a browser session, an unpaginated API call, a Docker build), or the model/trigger choice itself being wrong for the task. Fix the wrong layer and things stay slow no matter how many times you swap providers.
This guide walks through the layers in the order you should actually check them, across OpenClaw, Hermes, and n8n.
Quick Diagnosis
| Symptom | Likely Layer |
|---|---|
| Slow from the very first run, every time | Auth/network retries, a heavyweight model, or a slow trigger type |
| Fast at first, gets progressively slower | Context or execution-data bloat |
| Slow specifically during one step (browser, HTTP call, terminal) | That node/tool's execution time, not the model or engine |
| Slow on every run regardless of content | Fixed per-call overhead (tool schemas, database writes, gateway platform) |
Step 0: Rule Out the Fakes
Before touching context, database, or model settings, check whether it's actually slow, or whether it's retrying. A 429 rate limit, an expired token, or a misconfigured API key doesn't always fail cleanly — depending on the client, it can retry silently two or three times before either succeeding or surfacing an error, and each retry adds real wall-clock time that looks exactly like latency. If you haven't already, rule out auth issues first — a 15-second "slow" response is sometimes just two failed auth attempts plus one that worked.
1. Context and Data Bloat
This is the most common cause of something that starts fast and gets slower over time, though it shows up differently depending on the tool.
OpenClaw and Hermes resend the entire conversation history with every request, not just your latest message. A session that's 25,000 tokens by message 40 means every single call — including "what time is it?" — pays that full cost.
/compact # OpenClaw: summarize history now, in any chat
/new # OpenClaw: hard reset — start a fresh session
/compress # Hermes: summarize conversation history, keep key context
/usage # Hermes: check current token consumption before deciding what to trim
To make OpenClaw compact earlier and keep per-request size bounded, tune it in ~/.openclaw/openclaw.json:
{
agents: {
defaults: {
compaction: {
mode: "safeguard",
keepRecentTokens: 8000, // keeps this much recent history verbatim after compacting
},
},
},
}
n8n has a different version of the same problem: the execution engine loads the entire dataset into memory for the run. A workflow that processes a few hundred items with several fields each can start hitting memory limits well before you'd expect, and self-hosted instances feel this as RAM pressure while n8n Cloud feels it as execution timeouts. The fix is the Split In Batches node — chunk large datasets and loop through them instead of loading everything into one execution:
[Data Source] → [Split In Batches] → [Processing Nodes] → loop back until done
2. Environment and Database Overhead
Not all slowness comes from the model or the conversation — sometimes it's the environment underneath. This is where a misconfigured environment can silently slow down every call, even before your logic runs.
Hermes loads full schemas for every enabled tool on every call by default — with 50+ tools across terminal, file, web, browser, and memory toolsets, that's routinely 3,500–5,000+ tokens of fixed overhead per request regardless of whether the turn needs any of them. It's worse over messaging gateways than the CLI: roughly 6–8k input tokens of overhead via CLI versus 15–20k via Telegram or Discord for the identical conversation. Scope toolsets to what a session actually needs:
hermes chat --toolsets "web,terminal"
OpenClaw, especially self-hosted on a VPS, can be slow for a purely infrastructural reason: memory pressure. If the container is swapping to disk, every call gets slower regardless of context size or model choice.
docker stats --no-stream # check RAM usage before blaming the model or network
n8n has its own version of this at the database layer. The default SQLite backend locks on writes, which is fine for testing but causes real slowdowns once multiple workflows execute concurrently — the difference becomes significant past roughly 500 executions/day. For any production setup:
DB_TYPE=postgresdb # switch off SQLite for concurrent workloads
EXECUTIONS_MODE=queue # run executions in separate worker processes
N8N_CONCURRENCY_PRODUCTION_LIMIT=10 # tune to your server's actual capacity
Queue mode matters specifically because the default regular mode runs everything in one process — a single long workflow can block short ones behind it, which looks like unrelated workflows "randomly" slowing down.
3. Model, Provider, and Trigger Choice
Not every model responds at the same speed, and this is often the fastest lever to pull once context and environment are ruled out. Heavier reasoning-tier models take noticeably longer per response than lighter ones; mid-tier models sit in between. The fix isn't always "use a cheaper model everywhere" — it's routing simple tasks to a fast model and reserving slow, expensive ones for genuinely hard reasoning.
If you're running an AI node inside an n8n workflow (or any setup routing through multiple LLM providers), the gateway you route through is itself a latency variable — switching your LLM gateway can significantly affect response times, independent of which model you ultimately call.
n8n also has a trigger-level speed decision that has nothing to do with any model: polling versus webhooks. A polling trigger checks for new data on an interval, which adds latency up to the length of that interval and burns executions checking when nothing's changed. Most modern platforms — Stripe, Shopify, GitHub, Slack — support webhooks, which push data the instant it happens instead of waiting to be asked. Switch to a webhook trigger anywhere the source supports it.
4. Node and Tool Execution Time (not the engine at all)
Sometimes the model or engine responds fast and the run still takes forever — because one specific step is doing something inherently slow. In OpenClaw and Hermes, that's browser automation, remote SSH commands, or Docker builds. In n8n, it's almost always an HTTP Request node hitting a slow external API, or a sequential loop making one call at a time instead of running in parallel.
For n8n specifically, check execution history first — it shows per-node timing, so you can see exactly which step is the bottleneck instead of guessing:
- If one HTTP Request node is consistently slow, the external API is the bottleneck, not n8n — raise its timeout (default 30s) or look for a faster endpoint.
- If a loop is calling an API once per item sequentially, restructure it: the Execute Workflow node runs sub-workflows in parallel by default, and batching updates (e.g., 5 parallel batches of 100 instead of 500 one at a time) can cut execution time by 4–5x on the same task.
If the slowness lines up with a specific node or tool call rather than general "thinking" time, you're debugging the wrong layer if you're looking at database settings or model tier.
Myth vs. Reality
Myth: My agent or workflow is slow because my internet connection or server is underpowered.
Reality: Bandwidth is rarely the bottleneck. Slowness usually comes from how much context or data gets carried into every run, which model or trigger is doing the work, or a single step that's genuinely slow by nature (a browser session, an unpaginated API call, a database lock). Think of it less like a pipe that's too narrow, and more like sending the same oversized package by courier every time instead of just the new page — the courier isn't slow, the package keeps growing.
Troubleshooting
| Symptom | Fix |
|---|---|
| Slow from run one, every time | Check auth/retry logs first, then confirm which model tier or trigger type is active |
| Gets progressively slower within one session | /compact (OpenClaw) or /compress (Hermes); use Split In Batches for large n8n datasets |
| High overhead on every call regardless of content | Reduce enabled toolsets (Hermes); switch n8n to PostgreSQL + queue mode past low execution volumes |
| Container or instance feels sluggish under real load | docker stats --no-stream; check n8n concurrency limits against actual server resources |
| Slowness lines up with one specific step | Check execution history for per-node timing (n8n) or confirm it's a tool call, not the model (OpenClaw/Hermes) |
Bottom Line
Slowness is rarely one thing — it's context or data size, environment and database overhead, model or trigger choice, and individual node/tool execution time stacked on top of each other, and the fix depends on which layer is actually responsible. Rule out retries first, then check context or data size, then environment, then model or trigger choice, and only then suspect the step itself. If you're running any of these as a long-lived background process rather than something you babysit, a lot of these problems compound over hours instead of minutes — which makes it worth getting your 24/7 VPS deployment set up correctly from the start, with resource limits and session hygiene built in rather than bolted on after things start lagging.