I build organizations you can read.

Eric Connelly, July 2026

I stood in Europe's largest science museum and read the origin plaque twice, because I did not believe it the first time. The building went up as a slaughterhouse, the biggest ever attempted. While the walls were still rising, refrigerated trucking arrived, and meat no longer needed to travel to the city to be cut. The purpose died before construction finished. Decades later, somebody built a science museum inside the iron shell.

I think about the crews who kept laying stone after the first refrigerated trucks rolled past the site. The plans said slaughterhouse, so they built slaughterhouse. If you are building anything right now, a practice, an agency, a product, some part of your plan was drawn before the trucks showed up. The museum's founders eventually asked the useful question. What is the shell still good for?

I have an answer I trust for my own work. It took me about a year of client engagements to earn it, and I want to lay it out plainly enough that you can argue with it.

What is actually getting compressed

Anything that fits inside a prompt is moving into a prompt. I build software for a living, and most of the code I ship now starts as a paragraph of English. Strategy decks, contract redlines, customer service replies, the first draft of nearly everything. Work that took a person a week now takes an afternoon and an API call.

The companies that mattered after the first industrial revolution were not the ones who built better looms. They were the ones who built on what the looms made possible. I have been watching Codex hit sixty billion dollars by wrapping the LLM in VS Code. They did not build the model. They wrapped it. Amazon built on the internet, then built AWS, then Uber built on AWS. The same climb is starting again on top of the models.

That is the part of the story everyone is watching, and I agree with most of it. What I want to talk about is the line. Somewhere between a contract redline and a twenty-year client relationship there is a line. On one side of it, the work compresses into a prompt. On the other side, it does not. Every bet you can make for the next decade, what to build, what to sell, what to become, is a bet about where that line sits. Most people are making that bet without naming it.

I can tell you where the line sits in my own week. The code compressed, the reports compressed, the first drafts compressed. What refused to compress surprised me. It was a founder deciding to open her books to me, a team trusting a new system enough to retire the shadow spreadsheet they keep anyway, knowing which question to ask in a tense room. The plumbing got easy. Opening real data to anyone, an AI or a consultant, with real risk on the table, is the same work it always was.

The two deaths of an AI product

Most AI products die one of two deaths.

The first death is absorption. You build a clever layer on top of the model, memory for chatbots, document answering, meeting notes, research agents, and then a frontier lab ships the same thing as a feature in its next release, free, to a few hundred million people. Since 2024 the labs have shipped document reading, code agents, deep research, long-term memory, and scheduled tasks. Each of those was somebody's startup. Some of them had raised serious money a year before the feature announcement that ended them.

The second death is quieter. The right idea gets built by the wrong person. Someone with no history in the industry, no earned trust, and no path to the first ten buyers builds a perfectly good tool, then stands outside the building knocking. The product works. The demos go well. Nobody who matters ever tries it, because nobody who matters had a reason to take the call.

Neither death has much to do with quality. I have watched good products die both ways, and I have watched mediocre ones survive because they stood where neither death could reach them. Defensibility in this market comes from where you stand. What you build matters less than everyone building wants it to.

Software IN a Service

The software industry spent twenty years perfecting one shape, software as a service. The vendor owns the product, your data lives inside their product, and you rent access monthly, forever. That was a reasonable trade when software was expensive to build and expensive to run.

Software is no longer expensive to build. So the shape I work in now is the inversion. Stop selling the intelligence as a product. Embed it into a service the client owns, so deeply that the business would break if you pulled it out. Software in a service, instead of software as a service.

In practice this is almost embarrassingly plain. A business gets written down as rules in a folder of files the client owns, in English anyone on the team can read. How a lead gets handled, and what happens when an invoice goes three weeks unpaid. Which numbers the Monday report pulls, and who sees them. The AI is the worker that reads the folder and does what it says. When a better model ships, you swap the worker and keep the folder. Your vendors stop being landlords and start being staff.

There is a name for this. Lee Bryant has been arguing for the programmable organization at enterprise scale for years, and I think he is right. I run the practitioner version, for founder-led businesses and independent consultants, and the practitioner version needs a layer the enterprise version can hire for. Somebody has to coach the actual humans through the change, because new software in an old company is a people problem before it is a technical one.

Notice what this shape does to the two deaths. A lab can absorb any feature. It cannot absorb the accumulated judgment of your specific business, written down in files only you own, wired into relationships only you hold. The intelligence inside the service stays rented, swappable, cheaper every quarter. The service is the moat.

The test

None of this tells you what to build. For that I use a test, and the test has a name: the right to win.

Two questions. First, will the flagship platform absorb this? If the thing you want to build would make a tidy feature announcement at a lab's next keynote, it is already dying, whatever the demo looks like today. Second, do you have an unfair edge and a path to the first ten buyers? Twenty years inside one industry, relationships that return your calls, a reputation that puts a prototype in a real buyer's hands in a week where a funded stranger would wait a year. If the answer to the first question is no and the second is yes, you are holding something no lab can take.

Scoring ideas this way is now a good part of my work, because generating ideas is exactly the kind of work that compressed. Every consultant I know is sitting on a pile of AI-era concepts. The pile is not the problem; judgment about the pile did not compress, and excitement is a measurement of benefit taken with the least reliable instrument available. When I score, I score the barrier and mostly ignore the benefit. Every AI idea sounds useful in a pitch, so usefulness separates nothing. The barrier decides who is still standing in three years.

Why now, and why a person

Three things changed and made all of this practical instead of theoretical. The tooling matured, so a build that took a funded team a quarter in 2024 takes me a few weeks, alone. The models crossed a line where they can read a whole business's files and act on them dependably. And the one I underestimated is that it became possible for a founder to open her books to an AI running on infrastructure she owns, without handing a vendor the keys to the business. That last one is quiet, and it decides who gets to do this work at all.

But the hardest work in every engagement I have run sits outside the tooling entirely. It turns out to be the changing, the work of becoming the person and the company that can use this. The systems get easier every quarter. The work of being a person inside them does not. A founder who has held every decision for fifteen years has to watch a folder of files make some of those decisions, correctly, without her. That is not a software experience. Somebody has to stay in the room for it.

Which is why I sell the result and the method in the same breath, and I refuse to split them. The result is concrete. One audit I ran surfaced five figures of leaked revenue in its first week and mapped the client's full customer journey for the first time. The method is the part the client keeps. Everything built in files you own and can read, a person in the room while your team learns to run it, coaching the change instead of shipping a zip file. A result without the method is an agency invoice, and you will need another one next year. A method without a result is a workshop. Ask for both, from me or from anyone you hire in this era.

Where this leaves you

Here is the whole argument in working order. Anything that fits in a prompt is moving into a prompt, and nobody gets a vote on that. Products built on the compression die by absorption or by the wrong founder. What survives is a service the client owns with the intelligence embedded inside it. You choose what to build by scoring the barrier instead of the benefit. And the part that never compresses, becoming the company that can use all of this, deserves an actual person in the room.

Everything in this paper runs my own business first. The operation behind these words is a folder of plain files I own, read by an AI I rent, and it will keep working when I swap the worker for a better model.

If you run an established business on an automated stack nobody fully understands anymore, that is the audit conversation. I map what is actually there, read-only, and show it to you.

And if you are a consultant or operator sitting on a pile of AI-era ideas you cannot judge, here is the lowest-friction version of everything above. Send me one or two of them and I will score them for the right to win, free. If one survives the scoring, we build it together, and four weeks later you are holding a working prototype you built with me, in a real buyer's hands, in accounts you own.