Skip to content

Leadership · March 21, 2026 · 8 min read

Amazon Just Ran the Experiment — Your Board Will Ask Why You Haven’t

Thirty thousand jobs. One shareholder letter. No hedging.

Image generated using Gemini 3 Pro

Thirty thousand jobs. One shareholder letter. No hedging.

Jack Dorsey’s letter to Block shareholders this month didn’t describe AI as a productivity multiplier layered on top of an existing team. It described a smaller company doing more work because intelligence tools replaced the need for a larger one. Amazon made the same statement at greater scale: 30,000 positions eliminated since October, with AI tooling named as a direct cause, not a contributing factor.

These aren’t announcements about the future. They’re disclosures about decisions already made, results already observed, and operating models already changed. If your board hasn’t asked you yet why your organization looks different from the ones in those filings, it will.

The question isn’t whether AI can replace knowledge work at scale — that’s now just a data point. The question is whether your corporate AI strategy is built for an environment where the answer is yes -or whether it’s still built around the assumption that the answer is uncertain.

The strategy that no longer fits

Most corporate AI strategies were written for a specific model of the technology: AI as a capable assistant, available on demand, useful for accelerating individual tasks, requiring human review before any output becomes consequential. That model produced a particular set of strategic responses — deploying copilots, running pilots, measuring productivity lift per seat and reporting to the board on adoption rates. That model is no longer current.

GPT-5.4 operates computers without developer pre-configuration. It retrieves tools on demand, executes multi-step tasks across software environments, and does it without human checkpoints at each stage. Anthropic’s Claude Opus 4.6 ships with agent teams -multiple instances dividing a task, working in parallel, coordinating outputs — built at the model level, not bolted on at the application layer. And the acquisition of Vercept now gives Claude screen-level computer control, meaning the agent can observe its own actions in a live desktop environment and adjust accordingly.

These systems don’t assist workflows — they operate them.

The strategic difference isn’t semantic. An assistant requires a human to define each step and review each output. On the other hand, an operator takes a goal, determines the steps required, executes across the necessary systems, and returns a result. The difference is that the value of an assistant scales with the number of seats purchased while the value of an operator scales with the number of workflows it runs. And unlike a seat, an operator doesn’t have a headcount.

A copilot strategy is a seat-purchasing strategy. An agent strategy is an operating model strategy. Companies that confuse the two are measuring the wrong things, funding the wrong projects, and building governance for the wrong risk profile.

What the labor data is actually telling you

The 51% year-over-year increase in technology sector layoffs isn’t a signal about conditions in the technology industry. It’s a signal about what the technology industry, which has the earliest access to these tools, has concluded about optimal team size at current AI capability levels.

Amazon’s reduction is the most significant in absolute terms. Block’s is the most significant in proportional terms and in the explicitness of the stated rationale. Neither company described headcount reduction as a response to market conditions. Both described it as a response to changed productivity expectations per employee.

The implication for corporate strategy is specific: the companies emerging as operational benchmarks aren’t those that added AI to existing org charts. They’re the ones that used AI to redesign what the org chart needs to accomplish and then resized accordingly.

Morgan Stanley’s estimate of $3 trillion in AI infrastructure investment by 2028 tells you which direction the capital is moving. Infrastructure investment at that scale doesn’t slow deployment — it accelerates it. The productivity expectations embedded in the Amazon and Block decisions won’t remain outliers. They’ll become the reference point against which your board measures your own operating efficiency.

If your AI strategy is about producing adoption metrics but not operating model changes, you’re accumulating a gap between your current cost structure and the one that’s becoming the competitive baseline.

The infrastructure change that changes your business case

NVIDIA’s GTC 2026 announcement — the Vera Rubin platform, a rack-scale reference architecture designed specifically for the demands of agentic systems — confirms that the hardware layer is being rebuilt around a specific assumption: always-on agents running complex, multi-step work continuously, at scale.

The Cerebras-AWS arrangement running on Amazon Bedrock produces a 5x improvement in token throughput. The consequence for corporate strategy isn’t just technical — it’s economic. Use cases that were previously too expensive to run as continuous agents rather than on-demand queries have crossed the cost threshold. Autonomous monitoring, continuous document processing, real-time cross-system coordination were all pilot-worthy in 2025 because the unit economics were marginal. But they’re production-worthy now.

This means your business case math from 18 months ago is wrong. Not directionally wrong — just wrong in the hurdle rate. Use cases that previously didn’t clear the cost threshold now do. If you’re still running the same cost-benefit analysis you ran in 2024 and 2025, you’re leaving deployable ROI on the table.

The correct response is to rebase the business case every quarter. Inference costs are falling fast enough that a quarterly review cycle isn’t excessive — it’s the minimum necessary to keep investment decisions calibrated to actual economics rather than assumptions made when compute was more expensive.

The governance problem you don’t have time to defer

The Amnesia research paper, published this week, demonstrated that adversarial inputs can change what a model does in mid-task. And in ways that are not visible at the output level. In a conversational AI product, this is a meaningful but manageable vulnerability. However, in an agentic system operating financial workflows, it’s a different category of problem.

A model that gives a wrong answer is a nuisance. But an agent that’s adversarially redirected while processing a payment, updating a customer record, or executing a multi-step approval workflow is an operational and liability exposure.

Both GPT-5.4 and Opus 4.6 now ship with computer-use capabilities out of the box. That means the threshold for deploying an agent that can interact with production systems has dropped to near zero. Organizations that weren’t planning on having autonomous agents operating core systems this year may now have them within months — not because of a deliberate decision, but because individual teams will deploy them to solve specific problems without central oversight.

This isn’t a reason to restrict deployment. It is a reason to build the governance layer before deployment proliferates, and not after the first incident forces the question.

A credible governance architecture needs four components:

· Approval thresholds that define what actions an agent can take autonomously and what requires human review.

· Logging at the action level, not just the output level, so that agent behavior is auditable.

· Retrieval controls that determine which data environments agents can access and under what conditions.

· Human override mechanisms that are tested and functional before they are needed in a production incident.

While none of these are technically complex, they’re all significantly harder to retrofit than to design in advance. The companies that will handle the first serious agentic incident well will be the ones that built the governance layer before they needed it.

The four workflows you should be moving on now

The shift from pilot to production requires a different selection criterion. Pilots are typically chosen to demonstrate capability, but production deployments should be chosen to deliver operating model change.

The right selection criterion is process friction, not task complexity. This means identifying workflows where the bottleneck isn’t intelligence but throughput — where delay, repetition, document volume, or cross-system handoffs create measurable cost or cycle-time problems. These are the workflows where an agent that acts continuously, and without handoff delays, delivers operating model change and not just a productivity lift at the margin.

Four categories consistently meet this criterion in enterprise environments.

Finance operations — invoice processing, reconciliation, variance analysis, and reporting cycles. These involve high document volume, defined decision rules, and significant manual coordination between systems. The output expectations per finance employee are already changing at companies running agents in this function.

Customer-facing support and service operations. These involve high repetition, defined resolution paths, and cross-system lookups that agents handle without the latency of human-in-the-loop coordination. The reduction in average handle time at companies running production agents in this function isn’t marginal.

Sales operations — pipeline data hygiene, follow-up sequencing, proposal generation, and CRM maintenance. These all involve the kind of high-frequency, low-complexity work that consumes disproportionate time relative to its strategic value.

Engineering — specifically code reviews, test generation, documentation, and deployment validation. These are already the functions where agent productivity data is most mature. The output expectations per engineer at companies running agents in this capacity aren’t the same as those at companies still running copilot-only deployments.

These aren’t the only four, but they are the four where the operating model change is most measurable, most defensible to a board, and most likely to produce the benchmark data that makes the next investment decision easier to approve.

The question your operating model needs to answer

The strategic framing that holds across everything that happened this week is simple, and it’s not the framing most corporate AI strategies were built around.

The question isn’t: how do we use AI to help our current team do more? That’s the copilot question and it produced useful results in 2024 and 2025. It’s not the wrong question, but it is the question from the previous era.

The question now is: which parts of our operating model get better when AI acts rather than answers?

That question produces a different investment portfolio, a different governance architecture, a different org design conversation, and a different set of metrics for the board. It also produces a different risk posture — one that takes the Amnesia finding seriously, that builds override mechanisms before they’re needed, and that updates business cases on a quarterly cycle rather than an annual one.

Both Amazon and Block have answered that question for their own organizations. The infrastructure being deployed under the NVIDIA and AWS announcements will make the tools that enabled those decisions available at lower cost and higher performance to every enterprise by the end of the year.

The remaining question is how long will it take your organization to act on them.

Sources: OpenAI GPT-5.4 release documentation; Anthropic Claude Opus 4.6 product announcement and Vercept acquisition; NVIDIA GTC 2026 keynote and Vera Rubin platform specification; Cerebras-AWS Bedrock throughput announcement; Amazon Q1 2026 workforce announcements; Block shareholder letter; Morgan Stanley AI infrastructure investment estimates; Amnesia adversarial LLM research paper.

By Ivan Ruzic, Ph.D. · Originally published on Medium