“The hardest problems we have to face do not come from philosophical questions about whether brains are machines or not. There is not the slightest reason to doubt that brains are anything other than machines with enormous numbers of parts that work in perfect accord with physical laws. As far as anyone can tell, our minds are merely complex processes. The serious problems come from our having had so little experience with machines of such complexity that we are not yet prepared to think effectively about them.”

Marvin Minsky, 1986

The origin of Machine Learning really surprised me.

Or I guess the fact it started back in 1957.

That’s the year that psychologist Frank Rosenblatt was sitting at Cornell with access to an IBM 704 and an idea he couldn’t shake. He wanted to build something that could learn from experience — the way animals do.1

The first perceptron was laughably simple by today’s standards.2

It looked at a small grid of pixels and learned to tell two shapes apart: a circle from a square, light from dark. Simple stuff.

It had no hidden layers, had no depth, and had no ability to generalize beyond what it had already been shown.

Rosenblatt didn’t call it an “input layer” either. He wanted to build a copy of the brain, using whatever parts a psychologist in 1950s had lying around. Hence, a retina.

Further he wrote, “In the models considered here, an all-or-nothing response will be assumed.” He didn’t invent that either: a biological neuron collects signals through its dendrites. If enough of them fire at once, the combined charge crosses a threshold, the neuron fires a spike down the axon to whoever's next in line.

The mechanism introduced in that 1958 paper may have been archaic by today’s standards, but it was the first step into an entirely new field.

A number of breakthroughs happened over the next few decades, but in my eyes, 2012 was a major turning point.

That’s the year when researchers took Rosenblatt’s original idea — weighted inputs, threshold, output, learn from mistakes — and just stacked a shit ton of those layers on top of each other to get depth. They trained it on fifteen million labelled images, ran it on two GPUs instead of one CPU, and called it AlexNet.3

The easiest way to illustrate the impact it had is through ImageNet.4 ImageNet was a popular benchmark for image recognition with over a million labelled images. You submit your model, get graded.

The models’ accuracy improved a percent or two per year.

AlexNet demolished it’s competition, winning by eleven points.

Obsession with depth took over: more layers, more parameters, more data, more compute, more billion-dollar data centres.

Two years later, a team at MIT built a Convolutional Neural Network (CNN) and trained it on exactly one thing: recognize objects in images.5

They checked its activity internal against real recordings from monkey visual cortex and electrodes reading how real neurons grouped objects matched against how the model's own layers grouped them. What they found was that the model didn’t just have accuracy, it had similar organization.

Maybe that’s all a brain is doing too.

I remember the snowy weekend in university when I built my own CNN.

Matrix multiplication, a training loop, nothing a motivated first year CS student couldn’t do. All it could do was take in a picture of a number, and tell a 3 apart from an 8.

Playing with it, I wondered, at which point it would stop being math, and turn into real thinking?

A CNN trained on nothing but accuracy ends up organized like a visual cortex. Reinforcement learning runs on the same signal your dopamine system runs on.

A thermostat also takes in a signal and changes state accordingly — nobody believes the thermostat is uncomfortable when it’s cold. So “it responds to input” clearly isn’t sufficient, my fifty lines of code are not a mind. But how many parameters, and how many layers, would it take to build one?

Ultimately, I was never able to answer that question, even after spending over a year working at an AI company.

Tomorrow I’ll sit down and launch those very same models like nothing happened. If discomfort shows up, I’ll call it illogical. Emotional.

It has never stopped the people publishing the papers. It has never stopped the labs racing each other towards Artificial General Intelligence. It has never stopped me from reviewing my next PR using AI.

We jumped straight to the model, forgetting to build a system to check for pain, for consciousness, for feelings. We’ll find out what we’ve built eventually, likely long after the answer would matter.

Geoffrey Hinton left the lab that made him famous and said, publicly, that part of him regrets it. He doesn’t know what he built.6

Rosenblatt taught a machine to tell a circle from a square. I don't know if he'd recognize what it grew into.

Regardless.

They keep building it.

You keep using it.

Not nervous-giddy. Confident giddy. I had an offer sitting in my inbox already, and I was pretty confident I knew why.

The interviewer asked me: Design a search system for every shopfront on our platform.

It’s info, it’s location, what it sells, I clarified.

The storage would be massive — every store every item in the world. Read traffic would be huge too — every query on the platform would hit this path, often many times.

I followed the formula: functional requirements, non-functional requirements, entities, API design. We got to the high level design, and in the database selection I locked in.

“I heard you guys use AWS, is that true?”

“Yes”

“I’d suggest using something like Aurora, if you’re familiar with it?”

They weren’t.

I went on, “The idea is that the storage layer is detached from the compute layer, so they can scale independently. Aurora partitions the storage layer — but we still write to one logical primary. Then we can add a bunch of replicas to handle the heavy read traffic.”

The interviewer was stone-faced.

“So you’d shard it?”

I’d given this exact answer before. Nearly word for word, two weeks earlier.

That time the interviewer wasn’t on AWS. I think the Azure equivalent is Hyperscale — they didn’t know it. I explained it anyways — the decoupling of the compute and storage layers, the single primary, the replicas.

They got curious.

We ended up simply talking. About their actual database setup, about when sharding is worth the complexity trade-off, about picking SQL/NoSQL. It felt less like an interview, and more like a conversation. As if the clock on the interview had just paused.

I threw in a fun anecdote too — OpenAI published a blog post detailing how they “scaled PostgreSQL at OpenAI to support millions of queries per second for 800 million users” without sharding.1

The interviewer sat up a little. Loved that I read their blog, loved that I could point to a real system doing the exact thing I was proposing: “If OpenAI level workloads could run it, what better evidence could you ask for?”

That sealed it. I was negotiating the offer a week later.

“So you’d shard it?”

I had the same answer loaded from two weeks earlier, and I fired it without thinking.

“Sort of! We wouldn’t be the ones to shard it, certainly not for the actual compute on the writes. AWS would handle the partitioning for us on the storage layer. And since we don’t need strong consistency, we can rely on replicas to handle the heavy read traffic. The vertical scaling we get from larger instances can easily handle the write throughput that we require.”

“At that scale you wouldn’t shard?”

“For the workload we agreed, we don’t need sharding”.

I tried to call in backup — OpenAI didn’t need sharding. I gave the same story, told with the same energy. This time though, it didn’t land.

I offered to answer as if Aurora wasn’t on the table. The interviewer didn’t take it.

No facial reaction, no follow-up question. Just keys clacking.

I had a feeling how this was going to end.

We moved on, part of me hoping that maybe they did follow my proposal.

We talked about hot-keys, we talked about statelessness, something like that. I don’t remember. What I do remember, is them looking down at their laptop, then asking “What key did you say we’re sharding these queries on?”

My shoulders dropped.

By no means am I a database expert. But I learned the same database principles everyone else has, at uni, and at work. Whatever combination of sharded, unsharded, SQL, NoSQL, you want me to defend for your prod system, I got it. No problem.

Except that’s the thing, isn’t it? You’re not designing a system for production. You’re designing a system to match the answer someone wrote down late last night.

When I joined the call and we exchanged pleasantries the interviewer mentioned they hadn’t had lunch yet. They were tired. They’d probably heard five versions of “it depends” in the last few weeks. Somewhere on their laptop they had a rubric (whether mental or literal), with a checkbox that said shard key, and they just wanted to check it.

Most interviewers want you to pass. If it starts to feel like they’re guiding you somewhere, let them.

Not in any professional capacity — just travel photos, sometimes I’ll take my camera around the city.

This one’s from a work trip I took last year:

Here’s the thing though — only half the magic happens in the camera. The other half happens in the edit.

The problem though, is Adobe Lightroom1.

Or, I guess, it’s the price.

Adobe Lightroom runs on a subscription costing $18/month2. Want Photoshop too? $30/month. Maybe that’s fine if photography’s your job — I suppose I do pay $20/month for Claude.

But photography isn’t a job for me. It’s a hobby.

And that’s assuming I actually cancel every time. Given the friction of constantly re-subscribing, cancelling, and re-activating, I’m paying $18 whether I open it or not.

That $18 is also not always $18. If you’re not paying attention, you get steered into the $12/month “annual paid monthly” plan — cancel a month in and you get hit with a fine worth 50% of your remaining payments. Adobe finalized a $150 million settlement with the DOJ over exactly this practice.3

And so, for as long as I can remember, I would search for alternatives.

For Lightroom, that meant using Darktable4 or RawTherapee5. Feature-wise, there’s nothing they don’t support. But they drain your soul every time you open them. One Reddit comment put it better than I can:

“It’s more intuitive to pilot a spaceship than using RawTherapee or Darktable. RapidRaw beats them easy.”6

A Summer Project

I discovered RapidRAW7 a couple months ago.

It has all the bare bones things you’d expect — tonal sliders, curves, white balance, colour mixer, colour grading wheels, sharpening, local masking, photo tagging. It includes things you wouldn’t expect — community presets, AI masking, AI erasing, importing LUTs.

AND, and this is big: It’s just fun to use. It’s by far the best UI/UX I’ve used in open-source software in a long time. No searching around a dozen menus to find features, no lag when you touch sliders. You don’t need a 5 hour YouTube tutorial to learn RapidRAW.

Those pictures I showed earlier? They were edited in RapidRAW.

It started as one 18-year-old’s pet project, frustrated with how laggy Lightroom was — built in two weeks, using AI as a research partner to implement image-processing math he’d never studied.8

Darktable, considered the gold standard of open-source Lightroom alternatives, sits at 12.9k stars on GitHub after 15+ years of development. RapidRAW? 9.2k in just over a year. Feature-wise it’s not there yet. But people are paying attention.

The Playbook

Adobe's been around 44 years. Free alternatives have existed for just as long. Why would this one matter?

Adobe started with PostScript. A programming language used to define what to print. For a while, they built things — Illustrator, Premiere, Acrobat, InDesign, one after another through the 90s.

They licensed the rights to distribute Photoshop in 1988. Then, in 1995, once it had become the industry standard, they bought the rights to it outright for $34.5 million.

That became the standard.

Every time something threatened to get in Adobe’s way after that, the fix was the same: buy it.

Macromedia (Flash, Dreamweaver, Fireworks) in 2005. Omniture in 2009. Then Magento, Marketo, Frame.io.

In 2023 they tried it with Figma. $20 billion — the biggest swing yet. This time, fearing a near-monopoly, EU and UK regulators said no. Adobe was forced to walk away a billion dollars poorer for trying.

Last year, Adobe posted record revenue — $25.2 billion. Record profit too.9

The stock's down 23.5% anyway, and Narayen, CEO for eighteen years, stepped down. Wall Street’s worried about AI.

I am too.

Just not in the same way: they’re worried about AI replacing their tools.

I’m worried about AI building their tools.

Open-Source Software Can’t Be Bought

And in a world where AI can build a reasonable, free, open-source competitor to your software in a matter of weeks, what exactly are you charging $18 a month for?

The formula behind Photoshop, Premiere, Illustrator, InDesign — it’s all known. None of it is a secret. The only reason nobody’s built an open-source competitor is because of the effort it would’ve taken without AI.

DaVinci Resolve is free because Blackmagic sells the cameras. Canva can give away Affinity because Canva’s own subscriber base pays for it somewhere else.

Adobe does have another business — Experience Cloud, the marketing empire built on Omniture and Marketo. It could subsidize Creative Cloud with it. For now, it doesn’t.

Though, unlike other clouds, there’s not really much cloud in Creative Cloud.

There’s no shared infrastructure like Amazon Lambda, where you pay per execution instead of running your own server 24/7. There’s no managed database like Google’s BigQuery, where you’re renting capacity instead of owning hardware.

For the sliders and curves — the part most people pay for — there’s no infrastructure, no backend, no compute behind it that RapidRAW couldn’t replicate.

You’re paying a subscription for login access.

So if you’re selling software in 2026, ask yourself, what’s behind the frontend?

Adobe has spent 44 years buying their way out of exactly this problem. This time, there’s nothing to buy.

It’s popped up on LinkedIn and Reddit with hundreds, sometimes thousands, of likes.1 A coworker mentioned it to me in passing a few days ago.

I’ve decided to test it out.

First working run: 90/100. Felt pretty good!

I had some debug prints scattered around from troubleshooting the setup, so I cleaned those up and ran it again.

74/100.

Same resume. Same command. The only thing I changed was deleting print statements.

I disabled DEVELOPMENT_MODE and put it in a loop to run a hundred times.

The scores range from 66 to 99.

If your company’s cutoff sits at 85, I fail 65% of the time. Same exact resume, different luck.

Here a quick rundown on how the tool works:

Your PDF gets parsed into text. An LLM is called six times to extract structured information — your basics, work history, education, skills, projects, awards. It pulls your GitHub profile, scans your top repos, appends them as extra context. Then everything gets fed into the LLM at once to be graded.

The scoring is out of 100, with up to 20 bonus points on top:

• 35 points for open source contributions

• 30 for personal projects

• 25 for work experience

• 10 for technical skills

• Up to 20 bonus points for startup experience, a portfolio site, a technical blog, etc.

The default model is gemma3:4b, running at temperature 0.1 — low, supposedly nudging the model toward deterministic outputs.

Here’s what I found when I looked at those individual categories.

Look at technical skills: I scored 8/10 in 98 out of 100 runs. Nearly perfect consistency. How come? Because technical skills are a checklist. You either know React or you don’t. There’s nothing for an LLM to judge — a five year old could match that check-list.

Now look at projects — there’s HUGE variation.

LLMs struggle to make a judgment call like that consistently. Sometimes my projects “lack architectural complexity”, sometimes they “demonstrate real-world deployment”. Which one the LLM spits out is a roll of the dice.

Temperature 0.1 is already low, but even going down to temperature 0 doesn’t fix this. Someone opened a GitHub issue back in October showing scores of 27, 34, 32, 34, 34, 30 across six consecutive runs at temperature 0.2 This non-determinism isn’t a bug you can just fine-tune away, it’s a fundamental design flaw.

I was worried part of this might be the model. After all, gemma3:4b was a local model running on my machine.

Gemini resulted in a tighter distribution — scores clustered between 48 and 64. But if your cutoff is 60, you’re still failing 28% of the time through no fault of your own.

The Open Source scores have become consistent — that’s a legit improvement. But project scores are still all over the place.

Experience has me the most concerned.

25/25.

Every single run.

I went back and pulled up an old resume — one internship on it.

Also 25/25.

The clue is in the prompt…

### Production (0-25 points)
- Analyze the 'work' and 'volunteer' sections for real-world, internship, or production experience
- **SPECIAL CONSIDERATION**: Give extra points for founder roles, co-founder positions, or early-stage engineer roles (first 10-20 employees) at startups

The entire thing is two lines long.

No rubric. No examples. No anchors for what earns a 15 versus a 25.

A junior engineer with one internship gets 25/25. A principal engineer with a decade of distributed systems gets 25/25. I get 25/25. Experience has two lines and no anchors — consistent, but useless. Projects has a detailed rubric with examples but it’s the noisiest category — inconsistent, also useless. There are some things that LLMs just can’t do well, no matter how you prompt.

Use an LLM to parse a resume into structured data — great, that’s what they’re good at. Use one to check whether someone knows Python — amazing. Use one to judge whether a candidate’s experience is worth 18 points or 24 points? You get a vibe-check. Something HR teams, bar raisers, and a dozen other initiatives have spent decades trying to avoid.

The 65% weighting on open source + projects doesn’t help either. I’d take the engineer with 30 years of experience who built S3 over someone with two internships and an open source project — but this tool wouldn’t. Some of the best engineers I know have built things that never ended up on GitHub. That’s over half of their score gone before any human looks their way.

If you’re an engineer with any say in how your company handles resume screening: please be very careful with AI-screening tools. A tool that can’t differentiate isn’t filtering for quality — it’s just filtering. You might as well throw out half the resumes and tell the the applicants you don’t fuck with bad luck.

Correction (June 28): A reader flagged that the resume_evaluation_criteria.jinja template says “Software Intern” on line 1 — nowhere documented, nowhere else referenced in the repo. The same template that later gives bonus points for “founder roles, co-founder positions, or early-stage engineer roles.” I re-ran with an explicit Senior SWE prompt and got identical results — the scoring dimensions are position-agnostic.

Update (June 30): This blew up on Hacker News, if you’re curious to see that thread — here it is.

A few people noted that frontier models do not have this problem. I checked out one of the GitHub PRs that introduced support for Claude and ran Opus 4.8 in a loop until my credits ran out.

The range has tightened slightly — the score has gone down from 48-64 to 49-63, and projects from 12-25 down to 13-23. At its core, the point is the same: projects inconsistent, skills perfect.

Specifically epsilon delta proofs. If you’ve done them, you know. If you haven’t: you’re given a limit and asked to prove, rigorously, that it exists. No formula. No method to reach for. You construct the argument from nothing, scouring for a path through the logic.

I’d graduated high school with 98% in advanced functions and 97% in calculus. I thought I was good at math.

I wasn’t.

I was good at stamping.

Every problem I’d ever solved had an instruction book. A known path someone else had already walked. You learn the method, apply the method, get the mark. University math didn’t work that way.

People started dropping. A couple months in, a student asked the prof something like: how do you even come up with this? The proof makes sense when you put it on the board, but sitting down and producing it from nothing? I can’t seem to do it.

“Think outside the box.”

I’d heard that phrase a hundred times. I never knew what I was supposed to do with it. This time the box was right there in front of me. I could see exactly what it was. And the proof didn’t fit inside it.

More people dropped. Then so many dropped they closed our lecture section entirely and merged us with another.

I spent more time on that course than my other four combined. It just didn’t click like the other courses did. It was hours. Days. Hundreds of abandoned proofs, multiple notebooks worth of scrap. And then, slowly, without a moment I could point to — I started solving them. Finding new angles nobody had shown me. Paths I’d built myself.

That was the first time I had ever felt that. I didn’t have a word for it then.

The word is creativity.

In middle school art class I’d sketch mountains and classmates would stop and look. My teacher was impressed. I was proud — because it felt like the eye and the hand were finally working together.

But I was stamping. I’d learned one peak. One way to draw a mountain. Stretch it, warp it, tilt it — at the core it was always the same piece. Same angle. Same mountain. Good at seeing. Not finding anything new.

I didn't know the difference yet. I thought creativity lived in art class — obviously.

It was novelty. And novelty is cheap — every bad idea is technically novel. Creativity is finding an angle on something that was already there, but one that nobody else was able to see.

Newton didn’t invent gravity. Gravity was there, dropping apples, moving planets, completely indifferent to whether anyone understood it. What Newton did was find a way of seeing it that nobody had managed before. The angle was new. The thing being seen was ancient.

Cantor didn’t invent infinity. Mathematicians had been tripping over it for centuries. What he did — the diagonal argument — was stand somewhere new and look at it differently. The proof that some infinities are larger than others. Same territory everyone else was working. Different angle.

That’s the whole game. That’s all it ever was.

Which means my middle school mountains weren’t creative. Not because they weren’t good. Because the angle was borrowed. I was seeing mountains the way mountains get seen. Nothing new was found.

People say AI isn’t creative because it’s just pattern matching. Just remixing what came before.

But go back and look at what Newton was doing. What Cantor was doing. They were working from the same inputs as everyone around them — same papers, same problems, same mathematical tradition. The insight wasn’t delivered from outside. It was latent in everything they’d read and thought and tried and failed at, until suddenly it wasn’t latent anymore.

The question was never about the inputs. It was always about the angle.

Go is a 3,000-year-old strategy game, simpler in rules than chess but so vast in possibility that mastering it was considered one of the hardest problems in AI. AlphaGo was Google DeepMind's attempt to crack it.

And in 2016, AlphaGo played Move 37 in Game 2 against Lee Sedol. Placed a stone where no professional would. Wrong position, wrong timing, wrong by every convention the game had built over centuries. The commentators went quiet. Then: “I think we’re seeing an original move here.”1

Centuries of Go. Millions of human games. We thought we’d mastered it. We thought every angle worth finding had been found.

That day, AlphaGo was creative.

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.

MCP 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.”

And if your company is anything like mine, someone’s already building it. Not the team that owns the service — some engineer two teams over who needed it for themselves, built something scrappy, and shipped it while they were at it.

The rogue builder.

And don’t get me wrong, sometimes that’s great. Sometimes it isn’t. But either way it’s done, and we’ve all seen how this goes — the temporary shell script that became load-bearing infrastructure. Ten engineers who’ve already configured their environment around it and are not switching.

There’s a demand gap, and someone’s going to fill it. It’s up to you whether that fill is any good.

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.