Business Is Software Now

Business is software now. Not in the tired sense that every company runs on apps. In a narrower, stranger sense: the way you get real work out of AI agents is the way software engineers have organized work for decades. Folders. Projects. Plain-text instruction files. Small procedures, written down, that combine.

The usual advice follows fast: "learn to code." Wrong lesson. You don't need syntax. You need the thing underneath syntax: the shape of the system. Where does state live? What does each part know? What is written down versus held in someone's head? That is software engineering with the code removed, and it is exactly the discipline agents reward.

A chat is a conversation. It evaporates when the tab closes. An agent is a worker with a working directory: it reads what's in the folder, follows the standing instructions, uses the tools it has been given, and leaves its output as files. So everything about managing one comes down to decisions software people make by reflex and business people were never taught to make at all.

Model selection. Different models have different strengths and different prices. Choosing one is a hiring decision. A leaderboard is a stack of resumes. Read it like a hiring manager: work samples over exams, exams over popularity polls. Nobody hires from a popularity poll. Plenty of companies pick their AI that way.

Project structure. A folder is a scope. Put a project's documents, data, and outputs in one place, and the agent's context assembles itself: everything relevant, nothing else. Scatter them, and every run starts with archaeology.

Context files. A CLAUDE.md file is standing instructions: who we are, what matters here, what never to do. Written once, read on every run. It is institutional memory that new workers actually read (which, if you have ever onboarded a human, you know is a first).

None of that is coding. All of it is engineering.

Here is why the eval finding matters more than it looks.

A chat session costs the same every time. Ask the same question in March and in June, and you pay the full price twice: full prompt, full context, full back-and-forth. The work does not accumulate.

Agentic work accumulates. The mechanism is the artifact. A skill is a procedure written down. A connector is a door to a tool. A skill plus a connector is a plugin, and one person builds it, then the whole team gets it. That is the line I teach at the CU Business School and at the Gates Institute, and it is the whole economic argument in one sentence: training ten people no longer means ten people climbing the same hill. One person builds the lift.

But a skill has to live somewhere. It lives in a file, in a folder, under version control, next to a context file that tells the agent when to use it. The compounding only happens inside the format. That is why the format is the fundamental, not because engineers are special, but because files are the only place leverage can accumulate.

At the Gates Institute I build this way daily. GatesHub, our connected-data portal, was not commissioned as a grand system. It grew kaizen-style, a bite at a time, and now runs about twelve live modules: LIMS, a finance dashboard, onboarding and training, org-health screenings, market intelligence, a quality-management link, more. Each bite was the same move: describe the system in plain language, structure the project, let agents do their best work in the format they do it best in.

One module makes the point by itself. We needed user interviews for a technology analysis: normally weeks of calendar Tetris and one-on-ones. I built a module where people talk their answers instead of typing them, transcription turns speech into text, and the AI digs into responses live to pull more detail on pain points. The interviews ran in a day. I did not write that module so much as specify it: what it should ask, where the data should land, what the follow-up behavior should be. The shape of the system. Not the syntax.

If you run a business function and want agents doing real work, the curriculum is short and none of it is a programming language:

1. Read a leaderboard critically. Know which model to hire for which task, and what it costs.
2. Structure a project. One folder per effort. Inputs, instructions, outputs. An agent should find everything it needs by reading the directory.
3. Write a context file. Your standards, your constraints, your voice: once, in plain text.
4. Write one skill. A procedure you do weekly, written down well enough that an agent can run it. Then attach a connector and share it.

That is systems thinking with a file system. A software engineer would recognize every step. A business person can do every step. The gap between those two sentences is smaller than the industry wants you to believe, and closing it is most of what I teach.

Back to the eval. The models mostly did the task. The harnesses determined what was left when the task was done. That is the test I would put to any AI effort in any business, and it fits in one question:

When the run ends, what remains?

If the answer is a transcript, you have a tool. If the answer is an artifact that makes the next run shorter and cheaper (a folder, a context file, a skill), you have a system. Business is software now. Build like it.