Agent workloads are not web workloads
A website serves short requests and finishes. An agent holds state, waits on external APIs, and occasionally does something expensive. It spends most of its life idle with memory allocated.
That profile makes RAM and process limits the real constraint. A box with fewer, faster cores and plenty of memory beats a many-core box that caps your resident memory.
The checklist before you pick a plan
Four things decide whether an agent can live on a given host at all.
- Persistent storage that survives restarts, so memory and context are not rebuilt from scratch.
- Root or container access, because agents need long-running processes rather than short PHP requests.
- Unrestricted outbound network access to the APIs and model providers you call.
- A published uptime SLA - a scheduled agent that misses its window is worse than one that never ran.
Sizing in practice
Start by measuring resident memory at steady state, then double it for burst headroom. Add storage for logs and conversation history, which grow faster than most people expect.
Only add CPU once you have profiled and found an actual compute-bound step. In most agent stacks the slow part is somebody else's API.
Takeaway: Budget for RAM and persistent storage before you pay for extra cores.