How to choose

How to choose an approach

1. Is it a known process or an open-ended task? Summarizing, classifying and translating don't need an agent, says Google Cloud. A known process is a workflow with model calls, and Microsoft calls one agent with tools often the right default for enterprise use. Multi-agent only pays when the work splits into parallel parts: in one study, a manager agent coordinating others gained about 80% on finance tasks like that, and every multi-agent setup lost 39% to 70% on step-by-step planning.
2. Which models must it run, and for how long? Retirement notice varies by lab and cloud, and a platform with several models inherits the shortest one in its catalogue. If you need more than one lab, keep state out of any single lab's stateful API.
3. Where do the data and its permissions live? If they sit in one SaaS system of record, that vendor's agents start with the data and the permission model. If they're spread out, permission-aware retrieval differs by cloud, and mapping identities between systems is where it fails.
4. What can the agent change, and can it be undone? A read-only agent is a quality problem. An agent that writes (refunds, emails, deletes) needs policy outside the model, idempotency keys, a sandbox with the network off and, for money or anything sent outside, a human.
5. Who pays if it loops or fails? On consumption pricing the customer carries the token risk. On outcome pricing the vendor does, and the arguments move to what counts as an outcome.

My defaults: a workflow with a model in a few steps before any autonomous agent; one agent with fewer than 20 tools before multi-agent; dated model snapshots in production, never aliases; state and checkpoints in our own store or a workflow engine, not only at a lab; retrieval as the end user, with permissions checked at query time where possible; every write tool behind a policy check outside the model and an idempotency key, plus a human for money and external sends; sandboxes with the network off and secrets injected at a proxy; turn and spend caps on every run; a regression suite from real failures, run several times per task, before any model or prompt change; traces and eval results exported in an open format.