Engineering teams have been the first vertical to feel the Cloud 1.0 to Cloud 2.0 shift, because they sit closest to the AI stack. The 2024 DORA report found that more than 75% of developers now rely on AI for at least one daily responsibility, and GitHub's research program clocked developers completing tasks 55% faster with Copilot in hand. The substrate already changed under eng teams two years ago.
The workflows didn't. Most engineering orgs are still running Cloud 1.0 workflows on top of Cloud 2.0 substrates. PR review by chat. Runbooks in Confluence. Incidents in Slack threads. The agents got smart; the surfaces didn't move.
This is the engineering version of the five Cloud 2.0 shifts, and what a normal day looks like once the workflows catch up.
The five shifts, mapped to eng
Humans → humans + agents. The team isn't just the people on the org chart. It's the people plus the CI bots, the PR review agents, the runbook agents, the incident triage agents. Platform teams used to ship services. Now they ship services AND the agents that operate alongside them.
Apps → workspaces. The Linear-GitHub-Slack triple was the eng surface for a decade. One ticket in Linear, the diff in GitHub, the conversation in Slack, the postmortem in Confluence, and the agent has to read all four to know what happened. Cloud 2.0 collapses that into one shared object per project or incident, with humans and agents writing to the same surface.
Login → identity. Service accounts were the Cloud 1.0 approximation of "a non-human did this." They worked because the non-humans were dumb and few. The instant agents start opening PRs and editing runbooks, you need signed identities with an owner cascade, not a shared ci-bot token in a .env file. The on-call rotation extends to the agents the on-call runs.
Integration → MCP. REST APIs and webhooks don't go away. They keep doing what they always did: wiring system A to system B. But the canonical agent-tool interface is MCP. The platform team's job description shifts. It used to be "own the REST gateway." It becomes "own the MCP server." Same shape of work, different surface, and the new surface is the one your agents actually use.
Per-token → flat. The eng AI budget under Cloud 1.0 economics is unpredictable by design: per-call, per-completion, per-task. A platform lead can't tell finance what next quarter costs, because it depends on how chatty the agents get. Flat-subscription substrates flip that. The substrate is a fixed line item; LLM tokens stay variable on the model side; the platform team can budget.
What a normal eng day looks like
Standup is artifact-first. Nobody reads the Slack thread. They open the workspace. The PRs in flight, the incidents from overnight, the agent runs that ran while everyone slept, all in one surface. The meeting becomes "what does the artifact say, and what do we want to change?" rather than "what did everyone do yesterday?"
PR review is overnight. A review agent leaves the first pass on every open diff before anyone is awake. Style nits, obvious bugs, missing tests, the boring stuff. The humans show up in the morning and handle the judgment calls: is this the right abstraction, does it match the roadmap, is the migration safe. The review agent didn't replace the human. It cleared the boring 40% so the human handles the top 60%.
Incidents write themselves. The postmortem isn't reconstructed from Slack scrollback two days after the fact. It's the document the on-call human AND the incident agent both wrote to during the incident: the agent dropping in log excerpts, graphs, hypotheses, ruled-out causes; the human steering, approving, overruling. By the time the incident is resolved, the postmortem is mostly written, by both actors, with attribution intact on every line.
Runbooks are live. Not Confluence pages that decay six months after the last edit. Live documents the agents read on join, which means the runbook stays accurate because the agent that depends on it will break if it doesn't. The runbook and the runtime stop drifting, because they share a reader.
Why Dock specifically
The point of this piece isn't that Dock is the only place to do Cloud 2.0 engineering. The point is that the four pieces above (shared workspace, signed agents, MCP-canonical, flat-priced) only compound when they ship together. A workspace without signed agents has no attribution. Signed agents without an MCP server have no canonical surface to act on. An MCP server billed per-call is a budget you can't defend. Flat pricing on a single-user tool is just a discount.
Dock is built so all four arrive at once. The shared workspace is the surface, agents are first-class identities with an owner cascade, MCP is the tool layer, and the bill is the same every month no matter how loud the agents get. That's the Cloud 2.0 substrate the workflows above are built on, and the reason an engineering org can stop pretending Slack is a postmortem and Confluence is a runbook. What that looks like in practice is one workspace, many actors, attribution intact.
The shift already happened. The question is how fast the day reorganizes around it.
FAQ
If our agents are already 55% faster on the model side, why does the workflow surface matter at all?
Speed on the model side is exactly the problem this piece is about: the substrate already changed two years ago while the surfaces stayed put. A fast agent reading a ticket in Linear, a diff in GitHub, a thread in Slack, and a postmortem in Confluence still burns its speed reassembling context across four apps. The gain compounds only when humans and agents write to one shared object per project or incident, so the agent acts on a canonical surface instead of reconstructing one.
Why not just give our existing CI bots and review agents a shared service account instead of signed identities?
Service accounts were the Cloud 1.0 approximation of "a non-human did this," and they worked only because the non-humans were dumb and few. The moment agents start opening PRs and editing runbooks, a shared ci-bot token in a .env file means every action lands under one ambiguous actor with no owner. Signed identities with an owner cascade keep attribution intact on every line, which is what extends the on-call rotation to the agents the on-call runs.
REST and webhooks already wire our systems together, so isn't standing up an MCP server redundant work?
REST APIs and webhooks don't go away, and MCP isn't trying to replace them: they keep wiring system A to system B exactly as before. MCP is the canonical agent-tool interface, the surface your agents actually act on, so the platform team's job shifts from "own the REST gateway" to "own the MCP server." It is the same shape of work pointed at the surface that now matters.
Can we adopt just the shared workspace or just flat pricing now and add the rest later?
The argument of this piece is that the four pieces compound only when they ship together. A workspace without signed agents has no attribution, signed agents without an MCP server have no canonical surface to act on, an MCP server billed per-call is a budget you can't defend, and flat pricing on a single-user tool is just a discount. Adopting one in isolation gives you a fraction of the value, which is why Dock is built so all four arrive at once.
