We named the era in the Cloud 2.0 thesis: the shared state that humans and AI agents both work in. This piece makes that operational. Because once a term is useful, everything reaches for it, and you need a way to tell the real thing from the label.
So here are the five shifts. Each one is a default that Cloud 1.0 set and Cloud 2.0 moves. None of them is about a faster model or a slicker interface. They are about the shape of the state underneath. Hold any product up against these five and you can read which era it actually belongs to, regardless of what its homepage says.
It is worth saying why a checklist like this works at all. The first cloud transition had the same property: the winners were not the companies with the fastest servers, they were the ones that moved a default, from "data lives on your machine" to "data lives in a reachable place." The shift was architectural, not cosmetic, and you could tell who had made it by looking at the shape of their product, not their marketing. Cloud 2.0 is at that same stage now. The five below are the architectural tells. Each one ends with a concrete test you can run yourself.
Shift 1: Storage to State
Cloud 1.0 shape. The unit was the stored object. A file sat in a bucket; you fetched it, changed it, saved it back. The cloud's job was to keep the bytes reachable. Value lived in having the data somewhere durable.
Cloud 2.0 shape. The unit is live state, not a stored artifact. A workspace is not a file you open and close; it is a surface many actors change continuously, and the current state is always the truth. The job is not "keep the bytes," it is "keep the shared, changing truth that humans and agents both act on."
Why it matters. AI does not produce one file and stop. It produces a stream of changes, and the interesting thing is the current state after all of them, not any single saved version. Storage thinking makes you reconcile versions. State thinking means there is nothing to reconcile, because everyone was working the same live surface.
The tell. Look for the words "save" and "export," and look for a version history you are expected to reconcile. If the product asks you to manage saved copies, it is storage thinking. If the shared surface is simply always the current truth and there is nothing to save, it is state.
Shift 2: Sessions to Persistence
Cloud 1.0 shape (for AI). Working with a model means a session: a conversation that runs and then ends. The thinking is brilliant while it lasts and gone when the tab closes. What survives is whatever you manually copied out.
Cloud 2.0 shape. The work persists by default, independent of the run that created it. A human starts something, an agent extends it overnight, another human reviews it in the morning, and none of them had to save-and-send. The workspace is the memory.
Why it matters. Value compounds only when state outlives the session. A team cannot build on work that evaporates. Persistence is the difference between a pile of impressive one-off outputs and a body of work that grows.
The tell. Close the tab and reopen it tomorrow, ideally as a teammate. If the work is gone, or it only survived because you copied it somewhere first, it was a session. If it is exactly where it stood and someone else can already see it, it persisted.
Shift 3: Single-actor to Multi-actor
Cloud 1.0 shape. Even "collaborative" tools were mostly turn-taking: one editor at a time, or humans politely not colliding. The model assumed a single actor at the controls.
Cloud 2.0 shape. Many humans and many agents operate the same surfaces at once, safely, without overwriting one another. Concurrency is the baseline assumption, not a feature you bolt on.
Why it matters. The moment AI becomes plural, several agents plus several people, single-actor assumptions break. Every handoff turns into a copy-paste or a silent overwrite. Multi-actor state is what lets a fleet of agents and a team of humans share one room instead of trading files.
The tell. Put two agents and a person on the same surface at the same time. If they collide, queue behind a lock, or quietly overwrite one another, it is single-actor underneath. If all three work at once and nothing is lost, it is built for many actors.
Shift 4: Implicit attribution to First-class identity
Cloud 1.0 shape. Software acted as a user. An automation logged in with a human's credentials, and the record said the human did everything. Attribution was implicit and usually wrong.
Cloud 2.0 shape. An agent is its own principal, with its own keys and its own trail. Every action records who or what did it, human or a specific named agent, and who is accountable. Attribution is first-class and recorded by default.
Why it matters. When agents act with real consequence, "the user did everything" stops being a convenience and becomes a liability, the first time an action goes wrong or an auditor asks. First-class identity is what makes a shared human-and-agent space governable rather than a blur.
The tell. Have an agent take an action, then read the audit trail. If the log says a human did it, attribution is implicit and the record is lying by omission. If it names the specific agent and the human accountable for it, identity is first-class.
Shift 5: Vertical SaaS to Cross-vendor surfaces
Cloud 1.0 shape. The pattern was the vertical app: one vendor, one stack, your data locked inside it. Integration meant exporting from one silo and importing into another.
Cloud 2.0 shape. The state is a shared surface that humans and agents from different stacks meet in. An agent built on one model and a person using another tool work the same docs and tables. The surface is not owned by a single vendor's app logic.
Why it matters. No one will run their whole agent fleet on one vendor, and no team uses one tool. If the shared state is locked to a single stack, it is not the cloud layer, it is just another silo with an assistant in it. Cross-vendor reach is what makes it infrastructure.
The tell. Try to bring an agent built on a different stack into the surface. If it cannot join, or it can only participate by impersonating a human login, you are looking at a silo. If it joins as itself, with its own identity, the surface is genuinely cross-vendor.
Why these five
You might ask why these five and not, say, "smarter models" or "better interfaces." Because those are improvements within an era, not shifts between eras. A faster model makes Cloud 1.0 AI better at being local and ephemeral; it does not move any of the defaults above. The five that matter are the ones that change the shape of the state, what it is, how long it lives, who can touch it, who gets credited, and how far it reaches. Those are exactly the dimensions the first cloud moved too, which is the tell that they are the structural ones.
The other reason these five and not fifty: they reinforce each other. Persistence is not worth much without shared state to persist. Multi-actor concurrency is dangerous without first-class identity to attribute it. Cross-vendor reach is meaningless if the state underneath is single-actor and ephemeral. They are not a menu to pick from; they are a system that mostly arrives together or not at all. That is why a product can bolt on one or two and still feel like the old era, while a product built to all five feels categorically different the moment you use it.
Reading the room
Put those together and you have a quick field test for any product claiming to be part of this era. Ask:
- Does the work live as persistent shared state, or does it end when the session ends?
- Can many humans and agents touch it at once, or is it single-actor underneath?
- Are agents first-class identities with their own attribution, or are they scripts wearing a human's login?
- Does it hold whatever AI produces (docs, tables, files, code, context), or just one format?
- Is the surface reachable across vendors, or locked to one stack?
A product can score high on a couple of these and still be Cloud 1.0 with AI bolted on. The ones built for the new era clear most of the list, because the shifts reinforce each other: persistence needs shared state, multi-actor needs identity, cross-vendor needs all of it. When you see a tool that clears them together, you are looking at Cloud 2.0 in practice, not in pitch.
For the full definition these shifts come from, start at the Cloud 2.0 thesis. For what the shared state looks like as a real surface, see what a Claude AI workspace looks like. The whole canon lives at the Cloud 2.0 hub.
Last reviewed: June 2026. We update this as the Cloud 2.0 thesis develops.
FAQ
Does a product have to clear all five shifts, or is clearing most of them enough?
Most of the list is the practical bar, because the five reinforce each other and rarely arrive one at a time. A tool can bolt on one or two and still feel like Cloud 1.0 with AI attached, since persistence is thin without shared state and concurrency is dangerous without first-class identity. The honest read is structural, not a score: when a product clears them together it feels categorically different the moment you use it, which is the real test rather than counting checkmarks.
My agents already work fine logging in with my credentials, so why does first-class identity matter?
It works fine right up until an action goes wrong or an auditor asks who did it. When the log says the human did everything, the record is lying by omission, and that convenience becomes a liability the first time consequence is on the line. First-class identity gives each agent its own keys and its own trail, which is what makes a shared human-and-agent space governable instead of a blur.
If live state means there is nothing to save, what happens to history and the ability to look back?
The point is not that the past vanishes, it is that you are no longer expected to reconcile saved copies to find the truth. The current state is always the truth, and the trail of who and what changed it lives in first-class attribution rather than a pile of versions you stitch together. Storage thinking makes you manage exports and reconcile drafts; state thinking removes the reconciliation, because everyone was acting on the same live surface.
How is a cross-vendor surface different from the integrations and APIs vertical apps already ship?
Integrations move data between silos: you export from one stack and import into another, and the surface still belongs to one vendor's app logic. A cross-vendor surface is the opposite, an agent built on a different stack joins as itself, with its own identity, and works the same docs and tables directly. The tell is whether that outside agent can participate without impersonating a human login. If it can only get in by wearing someone's credentials, you are looking at a silo with an assistant, not the cloud layer.
