1. Running agents at scale

Your support agent works. It answers a customer's chat, looks up their account, and issues a small refund. Then product says it will launch to 10k daily users, some tasks will run for an hour, and finance asks one question: what does each task cost?

Answering that is the job of an agent platform, the shared system that runs an agent for many users at once. It accepts tasks, runs each task's steps on workers, stores session state, calls the model provider within its rate limits, hands out sandboxes, and tracks cost and health.

The basic principle is to start from one task. Use the step count, tokens per step, and prompt-cache hit rate to calculate dollars per task. Use the step count and time per step to calculate seconds per task. Combine task duration with the arrival rate to find how many tasks run at once, then use these estimates to size the quota, workers, sandbox pool, and monthly bill.

You need this when many users share one provider limit, when tasks outlive a deploy, or when several customers share one deployment. An internal agent for a handful of users does not need this platform: run it as one process that calls the provider directly, and read the invoice monthly.

"What does one run cost, and how would you cut it?" comes up in most agent design rounds. A mid-level answer does the per-task arithmetic and draws the queue, workers, and stores. A senior answer sizes quotas, protects live users from batch work, keeps tenants apart, and decides which signals should page someone. We carry one support agent's numbers from task to bill, in the order you would size them out loud. Crash recovery, sandbox security, and caching internals get one pointer each to their sibling tutorials, and serving your own models (AI Infrastructure) stays out.