There used to be a social cost to laying off people. Not a legal one — a reputational one. The kind that made engineers think twice about joining you, and recruiters nervous about representing you. For a long time, Big Tech understood this — Google went decades without a mass layoff. It was part of the brand. Not just the free lunch and the 20% time1, but the implicit promise underneath all of it: if you’re good enough to get in, you’re good enough to stay.

A whole generation of engineers made real decisions based on that promise. They took the equity over the salary. They turned down less exciting jobs at less exciting companies. They optimized their entire careers for a shot at the logo — because the logo meant something beyond compensation. It meant you’d won a kind of stability that the rest of the market couldn’t offer.

Then, in 2022, Meta cut 11,000 people and called it the “year of efficiency”2.

What happened next matters more than the cuts themselves. Meta’s net income went from $23 billion to $60 billion in two years3. The stock went up. And every board in Silicon Valley took notice. The lesson learned was simple: you can do this, the market will reward you for it, and the reputational costs you were afraid of don’t actually exist.

Amazon watched.

Then Amazon cut 27,000 people4 — a company that had largely avoided mass layoffs since the dot-com crash, a company that posted $59 billion in profit the year after5. The justification was familiar: efficiency, streamlining, investing in the future. The stock went up.

The taboo didn’t erode gradually. It died over one winter.

None of this required malice. That’s the thing that’s hard to sit with. No one had to lie, or scheme, or decide to betray anyone. It’s just what happens when a company runs a play, gets rewarded, and other companies notice. The promise wasn’t broken so much as it quietly expired — somewhere between the press release and the earnings call, with no announcement and no acknowledgement that it had ever existed.

I watched a principal engineer get laid off recently. Sixteen years at the same company. Started his career there. Smart, productive, the kind of person who just makes things work. But he’d been on the wrong side of an internal argument — backed a project that lost, in an org where losing that particular argument turned out to matter. He got an email. I found out through LinkedIn. That’s just how it goes now.

He didn’t fail. The company didn’t fail. Someone ran the numbers, and the numbers included things that were never in the job description.

FAANG companies were never a different type of company. They were regular companies that had an unusually long run of growth, and the promise was implicit — which made it easy to keep, and easy to let expire. When it became expensive, they did what companies do.

Stop holding them to a standard they invented for recruiting purposes and have now quietly retired. They’re often still good places to work, they pay well, and the problems are interesting. But they’re not a covenant. They’re an employer.

The free lunch is probably still there. The promise isn’t.

In 2002, Jeff Bezos issued a now infamous mandate:

1. All teams will henceforth expose their data and functionality through service interfaces.

2. Teams must communicate with each other through these interfaces.

3. There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team’s data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.

4. It doesn’t matter what technology they use. HTTP, Corba, Pubsub, custom protocols — doesn’t matter.

5. All service interfaces, without exception, must be designed from the ground up to be externalizable.

6. Anyone who doesn’t do this will be fired.

7. Thank you; have a nice day.1

Bezos’s insight wasn’t really about AWS, or even about external consumers. It was simpler than that: you can never predict what your engineers will build when they have access to each other’s capabilities. And you don’t need to. Build the interface for any consumer. Let them run loose.

Now think about what’s happening inside your company right now.

Engineers are using AI to write code, debug issues, draft documents. And every time one of those agents needs to touch an internal tool — your deployment pipeline, your ticketing system, your internal docs — it hits a wall. That’s assuming it even knows those resources exist.

Most times the tool will have no interface accessible to an agent at all. Sometimes someone will have hacked together a wrapper that returns a wall of HTML. But HTML is not made for agents. It has padding declarations and cookie banners and a thousand other things that exist only to look nicer for human eyes. Your agent doesn’t have eyes. It doesn’t care. What it does have is a context window. And your garbage HTML is filling it up.

If you have internal tooling that an agent can’t reach — or can’t use effectively — you’re not just slowing down your engineers. Your AI is stuck asking you to copy and paste internal docs while your competitor’s is shipping.

So why not just have the agent call the API directly?

Because APIs weren’t designed for agents. They were designed for developers. The mental model is that a human reads the docs, understands the intent, writes the integration once, and it runs forever. The human is load-bearing.

Agents don’t work that way. An agent needs to discover what a tool does at runtime, decide whether to use it based on a description, and handle weird results without a human in the loop. There’s no one to read the docs. The description is the docs.

MCP2 isn’t a better API — it’s a different primitive, built for a different consumer. An API says “here’s how to talk to me.” An MCP says “here’s what I can do for you.”

So here’s my mandate:

1. Every internal service must expose an MCP interface. If a human can use it, an agent must be able to use it.

2. It doesn’t matter how old the service is, what language it’s written in, or how much you hate touching it. Wrap it. That’s the job.

3. Every MCP must be registered in a central registry — discoverable by humans, queryable by agents. If it can’t be found, it doesn’t exist.

4. Every MCP must be designed for agent consumption. Not a wrapper around your HTML. Not a raw dump of your REST response. The agent doesn’t have eyes. Give it the juice, not the packaging.

5. Anyone who doesn’t do this will be fired.

6. Thank you; have a nice day.

Most companies haven’t done this yet. And unlike Bezos’s mandate, nobody is going to force them to.

But the insight still holds: give your agents the full toolbox, let them run loose, and see what happens. The teams that do are going to pull ahead fast. The teams that don’t are going to wonder what happened.