Most agent programmes start on one cloud, and most should. The question worth asking early is not whether to go multi-cloud, but which of your workloads will eventually refuse to live in one place.
Multi-cloud has a reputation as an expensive hedge: twice the accounts, twice the networking, twice the bills, bought to avoid a lock-in that rarely bites. For a web application that reputation is often deserved. For agentic AI, and especially for agentic AI that sits beside a ledger, the trade-off looks different, because the two workloads ask opposite things of the platform underneath them.
When one cloud is enough
Be honest about this first. If your agents call one model, read data that already lives in one provider, and serve a team that can tolerate an afternoon of downtime, a second cloud adds cost and complexity without changing much. Start there, build the agent well, and keep the design portable enough that moving later is a project rather than a rewrite.
The signals that one cloud is no longer enough tend to arrive together: a task that a model on another platform handles clearly better, records that are not allowed to leave a particular environment, a process that cannot stop when a provider has a bad day, or a record that an outside party needs to trust.
Agents want reach
An agent is only as good as what it can reach. That means the right model for each task, the data it needs close by, and capacity when work arrives in bursts rather than a steady stream.
No single provider has the best model for every job. Reading a scanned form, summarising a long report and drafting a formal notice are different tasks, and the model that wins one rarely wins all three. A design that lets each agent call the model that fits, and switch when a better one appears, ages far better than one built around whatever was on the menu in the first month.
Data has gravity too. Copying regulated records to wherever a model happens to run is the quickest way to create a compliance problem. It is usually better to bring the agent to the data through a narrow, logged interface.
Ledgers want independence
A ledger earns its place by being hard to rewrite. That property is only as strong as the infrastructure under it. If every node runs in one provider’s account, the provider, or anyone who controls that account, is in a position to alter or switch off the record, and the decentralisation is mostly decorative.
Spreading nodes across providers is what makes the independence real. It also keeps the ledger readable when one provider has an incident, which is exactly when people tend to need it.
The tension in one line
Agents want to be close to everything. Ledgers want to depend on nothing. One cloud serves the first and undermines the second.
What multi-cloud actually buys
Set out plainly, there are four things, and each applies a little differently to agents and to ledgers.
Resilience
Agent workloads can fail over to a second provider, so an outage slows the work instead of halting it. Ledger nodes on several providers keep validating through the same outage.
Independence
No lock-in to one model vendor for the agents, and no single provider in control of the record.
Data placement
Records stay in the environment approved for them, and agents reach them through controlled interfaces rather than bulk copies.
Accountability
Every agent action is logged centrally, whichever cloud it ran on, and every ledger entry is permanent and tamper-evident.
What it costs
None of this is free, and the cost is not mainly compute. It is the control layer: identity, networking, logging, policy and evaluation, defined once and applied on every cloud. Teams that skip it end up with several logs, several policies and nobody who can say what an agent did last Tuesday.
If you are not prepared to build that layer, stay on one cloud. A well-governed single-cloud estate beats a poorly governed multi-cloud one every time.
Four questions before you add a second cloud
1. Is there a task where a model on another platform is clearly better, by a measure you have actually run on your own cases?
2. Are there records that must stay in a specific environment while agents still need to work with them?
3. Would an outage at your current provider stop a process that is not allowed to stop?
4. Does anyone outside your organisation need to trust a record without trusting you or your provider?
Two or more yes answers make a reasonable case for multi-cloud. None means build the agent first and revisit the question in six months.
Where Focus20 fits
We design the architecture under agent programmes, including the control layer that keeps a multi-cloud estate governable. We are currently providing multi-cloud architecture support to the Maharashtra Pollution Control Board for its agentic AI implementation, blockchain layer and dashboards.
Read about the MPCB engagement
Questions we get
Is multi-cloud more expensive?
Usually, yes, and mostly in the control layer rather than in compute. It is worth it when one of the four questions above has a clear yes; otherwise it is overhead.
Does every agent need it?
No. Most first agents should run on one cloud. Design them so the model call, the data access and the logging can move later without a rewrite.
What should move first?
Usually the ledger, if there is one, because its value depends on independence. Agents follow when a better model or a residency rule gives them a reason.
Read next
Claude on Bedrock, Vertex AI or Foundry: where should each agent run?
An audit trail for AI agents: when a ledger beats a log
AI agents for government: keeping records where they are allowed to live
Multi-cloud agents without multi-cloud chaos: one control layer