Software in the Middle: What AI Deletes Depends on What Your Company Is Built Around

A founder vibe-coding an events platform can assemble something that looks complete: three application components, one database, ten external integrations — and not a single model call in the operating path. AI helped construct a conventional platform. It did not help eliminate parts of it.

That inventory is not a stack complaint. It is a company-architecture tell. The business is still organised so that value has to become a feature, a workflow branch, or another integration before it can reach a customer. Adding AI to that shape makes the translation cheaper. It does not, by itself, make the company better.

What AI deletes depends on what sits in the middle.

The bargain that put software in the middle

We put computers and software in the middle because it was cheaper than too much labour, and more consistent than real staff. The economic deal was simple: we need to do the same thing 10,000 times, so pour some concrete. Encode the procedure once. Recover the investment across identical runs.

That bargain worked when variation was the exception. It fails when variation is the value. If every client needs a fitted answer — different objectives, different relationships, different constraints — generalised machinery is paid for twice: once to build it, again to work around it when the actual situation does not fit. The repetition has to move up a level. Reuse the ability to understand and solve, not the same solution.

Sequoia’s recent framing of services as the new software lands adjacent to this: a copilot sells the tool; an autopilot sells the work.¹ The spend ratio they cite — roughly six dollars of services for every dollar of software — is a reminder of where the labour budget still sits.¹ The point for company design is sharper than a go-to-market thesis. If cognition is no longer the scarce input that justified freezing the procedure into applications, keeping applications in the middle is no longer the cheap path. It is the path that forces the business to keep translating itself into yesterday’s concrete.

Legibility work and the software filter

Software removes some work. It also introduces its own: making the business and the customer legible to the software. Staff become the translation layer — customer to system, system back to customer. “Our system doesn’t support that” quietly becomes “we don’t do that.”

Then the filter starts before any customer is asked what they need:

1. What competitors already ship
2. What the founder recognises as a “requirement”
3. What can be explained to a coding agent
4. What can be made to work
5. What fits the assembled stack
6. What customers are finally allowed to see

A limitation of the production method becomes a presumed limitation of the market. The beta then tests usability inside the chosen answer. It rarely tests whether the answer was right.

Vibe coding accelerates the wrong loop. Coding agents replicate patterns that already exist in the repository — including uneven or suboptimal ones.² OpenAI’s own harness-engineering account is blunt about the drift that follows when agents pattern-match against whatever is already there.² Web search can refresh the available technologies without changing the question being asked. Faster implementation makes a narrow interpretation more substantial: more screens, more dependencies, more effort invested in making the parts cooperate. The software becomes a ceiling on what the company can imagine, instead of a floor it builds from.

The casualty rule

In a software-centred company, people were there — to a first approximation — to translate. Drop AI into that architecture and it replaces the translators, because translation is what the humans were hired to do. That is the anti-jobs, anti-purpose default.

Build the company around the client file and held responsibility instead, and AI removes the translation step. The people who remain do the debrief, the judgement and the relationship. More human internally and more human externally are one design decision seen from two sides.

That is not a values slogan. It is a causal claim with an old business-school backbone. The service-profit chain, published in Harvard Business Review in 1994, links internal service quality to employee satisfaction, then to external service value, customer loyalty and profit.³ A later study of 210 high-contact service shops found most of those postulated relationships highly significant.⁴ Human inside produces human outside when the architecture supports it. The SaaS decades built over that result by putting the system in the middle and asking people to serve it.

The pattern runs at three levels that cannot be cleanly separated:

• Parent to founder — folder versus funnel as the way a person is treated
• Company to founder — valued work at the centre; agents do the rest
• Company to customers — fitted service versus package

A funnel-run parent produces funnel-shaped offspring. The way you treat the founder becomes the template for how their company treats customers.

The nostalgia guard

The late-90s firm is a useful reference class, not a costume party. In the accounting firm where I started, the computer was something you booked time on. A sign-up sheet on the wall. Dot-matrix printers under foam hoods. A general journal in pencil. Manila folders from the compactus. Partners’ emails printed and answered by hand.

If you had to describe my junior job by hours spent, I was a photocopying expert. That matters. The firm was client-dedicated and not staff-centred. Every era makes its juniors serve the information medium — photocopying then, typing into the CRM now. The valuable part was the account-team dedication and the handover ceremony: the senior sitting you down to explain what made this client special, handing you the folder, and leaving the obligation sitting on your desk. Keep the dedication. Delete the medium-serving. Recreate the function of the handover, not its chain of command. Hours were the billing unit. They were never the value unit.

Flexible thinking is a reference class. You have seen businesses where per-client variation was normal. That makes it teachable.

What belongs in the middle

The manila-folder handover was the real operating interface. The folder supplied evidence. The sit-down supplied interpretation. The allocation supplied obligation. The folder on the desk kept the obligation present.

Brought forward:

• A wiki carries the understanding
• A responsibility register carries the obligation
• Knowledge-worker agents get a workplace in which to build

Every piece of work should leave two outputs — one for the customer, one for the business’s future work. A new kind of knowledge needs a new document, not a new subsystem. That is how Word-and-Excel departments grew capability for decades without their software changing.

Schema follows questions. A CRM decides in advance what may be known about a client. A folder extracts structure when a question needs it. Keep a ledger only for what must be exact: money, commitments, permissions.

This is also where the 1993 fork becomes visible. Peppers and Rogers’ The One to One Future argued that interactive technology would force businesses to treat different customers differently and compete on share of customer.⁵ The same year, Siebel Systems was founded and became known first for sales force automation — organisation-facing software for forecasts, stages and visibility.⁶ The software that inherited the name “CRM” delivered the bookkeeping half of the relationship. The customer-facing half had no technology able to hold an individual relationship at scale. Graduate CRM pedagogy arrived roughly a decade later as its own textbook wave.⁷

CRM was the relationship’s bookkeeping; the folder is the relationship’s work. Test: would you show it to the client?

Anthropic’s distinction between workflows and agents is the technical rhyme for the same idea: workflows orchestrate LLMs through predefined code paths; agents dynamically direct their own processes and tool use.⁸ Predetermined paths belong where commitments must be exact. Adaptive judgement belongs where the client’s situation is the point.

Both middles compound — differently

A software middle compounds through a slow loop of tech debt, increasingly slower, with the founder in the middle. Every unfamiliar request returns to one person and becomes permanent code.

A folder-and-wiki middle compounds capability. Transfer the lesson, not the whole event. “This happened once” and “this is a reliable principle” are different things. Every client does not have to fund the business learning the same lesson again. Two assets improve together: the accumulated knowledge, and the harness that applies it. The asset lives outside any particular model, so a model upgrade is evaluated against it rather than forcing a rebuild.

The business can scale in four directions, not one: volume, depth, breadth, adaptability. The unit of compounding is not pages, tools or events. It is the range of valuable outcomes the business can reliably deliver for a given amount of effort and cost. The tenth engagement can be better informed than the first with the tools largely unchanged.

Software’s new place: instrument

Code is to agents as a spreadsheet is to a human knowledge worker — built for the decision in front of you, no product roadmap required. You can generate more code during delivery while maintaining less permanent machinery.

Lifetime tiers:

1. Scratch inside an engagement — let agents write what they need; disposable
2. Scripts kept in the client’s folder because this client needs them again
3. Promotion to a shared library, with a skill file that maps the territory — gate only the promotion

The research rhyme is strong. Voyager’s ever-growing library of executable skills compounded an agent’s abilities and transferred to new worlds.⁹ Agent Workflow Memory induces commonly reused routines from past trajectories and feeds them back to guide later work.¹⁰ Anthropic’s Agent Skills package instructions, resources and optional scripts so an existing agent can be equipped for additional tasks without a separately constructed agent for each use case.¹¹ And gated promotion matters: when reusable artifacts are persisted without lifecycle gates, drift and silent failure follow; selective formalisation and gate-conditioned execution retain far more of what once worked.¹² Mine the exhaust for repeats. Gate the promotion. Do not build the CRM again by accident.

Y Combinator’s request for “a cloud for small software” names the complementary pressure: agents make purpose-built tools easy to generate; incumbent clouds were designed for big software that scales to many users, at the cost of complexity the tiny tool never needed.¹³ That is the instrument view of code — small, demand-earned, disposable until proven otherwise.

The change ladder

Default to reuse and recombine before adding. Flexible edges: AI→code, AI→workflow, AI→wiki. Rigid edges: code→SaaS, code→new dependency, code→code. Judge by the next ten requests, not the first demo.

Every’s agent-native application guide argues that features become outcomes you describe, pursued with atomic tools rather than choreographed in advance.¹⁴ Useful — and still an application-architecture argument. This piece is the company-architecture argument underneath it: what sits in the middle of the firm decides whether those agent patterns expand the offer or merely accelerate the old filter.

Run the Middle Test

Before you add another feature, another CRM field, or another coding-agent sprint, ask:

1. What are staff translating themselves into?
2. What are customers translating themselves into?
3. Suppose the current application disappeared, but we kept our relationships, knowledge and ability to use AI — what would we choose to deliver?
4. Where does an unfamiliar request go today: into a founder backlog that becomes permanent code, or into a knowledge-worker assignment that can inspect, recombine and leave learning behind?

Design test for the handover you are trying to recreate:

What would an excellent senior tell a capable new colleague before entrusting this client to them — and what must that colleague leave behind?

A software-in-the-middle incumbent is a static defender. Its cost of responding to a worthwhile customer difference is an exception, a specialist, a supplier change and a system change. The attacker competes exactly where the standard package fits badly. The incumbent does not have to be stupid for this to hold. It only has to keep software in the middle.

Design from the outcome: start with the valuable experience this client should receive, then assemble knowledge, people, agents and software underneath it. That method has its own depth elsewhere. Here the architectural point is enough — outcome first, machinery second.

We put software in the middle when cognition was expensive. Cognition got cheap. What you put in the middle now decides what AI deletes. Choose the translators, or choose the translation step.