Software in the Middle

Software was a crutch for humans. We need to do the same thing 10,000 times, so pour some concrete.

That sentence is not a complaint about technology. It is an economic history of the firm. Cognition used to be expensive. People who could understand a client, invent a workable approach, coordinate the pieces and carry the consequence were scarce. So companies did the rational thing: they decided the procedure once, encoded it into applications and workflows, and recovered the investment by running the same path again and again. Consistency was a feature. Labour substitution was the point. Computers and software moved into the middle because they were cheaper than too much labour, and more consistent than real staff.

When variation is the value

The bargain has a failure condition that most software-centred companies treat as a defect in the customer. If you are always doing a unique service — different objectives, different relationships, different constraints, different stage of the client’s journey — the software does not have the payoff. It is a negative return.

Trying to anticipate every variation means paying twice. First you build the generalised machinery for “the standard engagement.” Then the actual client does not fit, and you pay again: exception tickets, specialist overrides, shadow spreadsheets, manual bridges between systems, and the quiet sentence that ends more conversations than any roadmap slide — our system doesn’t support that.

Take a corporate client who does not primarily need another scorecard, registration flow or sponsor package configuration. What they need is help deepening relationships with a small number of important people, without their staff spending weeks organising it. The generalised events machinery can still be paid for in full. Then the team works around it — research, invitations, introductions, format, follow-up — while the application continues to insist that the valuable work looks like fields and features. The full inventory of that kind of build walks later. The economic shape is already visible here: machinery purchased for repetition, then paid for again as friction against fitted service.

If the procedure is the thing that should vary, pouring concrete is not thrift. It is pre-paying for the wrong rigidity.

Repetition moves up a level

The alternative is not to abandon reuse. It is to move repetition up a level. Reuse the ability to understand and solve — accumulated knowledge, research capabilities, calculation tools, verification methods, playbooks with evidence strength attached — rather than insist on reusing the same solution. The service can be unique without every ingredient being new. Ten thousand different engagements can still compound, provided what compounds is judgement and capability, not identical branches in an application.

The services paradox, resolved

This also dissolves an apparent contradiction that has been confusing the industry. Services businesses failed — and keep failing under scarce human effort — for understandable reasons. The industry pushed products, packages and SaaS because repetition looked like the only scalable economics. With agents at the core, delivery can look and feel like services again: fitted, situational, personal. The customer experiences a service. The company owns a reusable system for designing and delivering it. You get the adaptability of an excellent services firm without restoring its old dependence on scarce cognition, and the repeatability of a product firm without forcing every customer into the same answer.

Sequoia’s recent framing sits adjacent to this economics, even though it is largely a go-to-market argument. A copilot sells the tool; an autopilot sells the work. For every dollar spent on software, companies still spend on the order of six dollars on services.¹ Useful colour. The claim in this chapter is more internal: if cognition is no longer the scarce input that justified freezing 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.

What the bargain still protects

None of this argues for chaos. Money must still add up. Permissions must still be enforced. Commitments must still be honoured. Exactness belongs in ledgers. The bargain still holds for operations that should be identical. What no longer holds is using that same bargain to define the company’s offer, its method, and the limits of what a client is allowed to need.

Once applications sit in the middle, a second job appears — one the original bargain rarely priced honestly. The company must make the business and the customer legible to the software. That legibility work becomes the human role. And it becomes a filter on what the company can imagine.

A customer asks for something reasonable. Not exotic — just fitted to their situation. A staff member opens the application and starts translating. The request becomes fields. The fields become a workflow stage. The stage rejects a combination the form never contemplated. Someone opens a spreadsheet beside the system. Someone else emails a specialist. A week later the customer hears a softer version of the truth: our system doesn’t support that. Inside the company the sentence has already hardened into something worse: we don’t do that.

That is legibility work. The bargain that put software in the middle rarely priced it. Software removes some labour and introduces its own: making the business and the customer legible to the software. Staff become the translation layer — customer into system, system back into customer. The application is no longer merely a tool used during the work. It is the structure into which the work must fit.

The filter starts before the customer speaks

Then the narrowing happens upstream of any honest market test. Based on what founders actually do when they vibe-code a platform into existence, the sequence looks like this:

1. What competitors already ship — the inherited picture of a “real” product.
2. What the founder recognises as a requirement — the requirement frame.
3. What can be explained to a coding agent — the promptable subset.
4. What can be made to work — the demoable subset.
5. What fits the assembled stack — the integrable subset.
6. What customers are finally allowed to see — the offering.

Each filter can remove a valuable possibility without anyone deciding that the possibility lacks customer value. Something quiet moves from “I don’t know how to implement that” to “that isn’t part of our offering” to “that isn’t what our customers need.”

A limitation of the production method becomes a presumed limitation of the market.

Every idea collapses through software — filtered by what competitors have done, by the founder’s requirement frame, by what can be made to work — until the whole thing is stifled into a software package: not a company, not an offering, not an experience. How good does our software fit the narrowest thing we could write?

Ceiling versus floor

An operating system built around understanding, responsibility and inspectable capabilities is meant to be a floor from which the company can do more. A software-first path risks becoming a ceiling beyond which the company cannot think. The beta then tests usability inside the chosen answer. Customers respond to the vocabulary they are shown — registrations, stages, notifications, packages. They ask for a different field. Excellent feedback on the scorecards does not establish that the company found its strongest offering. It establishes that the scorecards were easy enough to complain about.

Build the software and they will come. Then beta-test customers to see if they fit the software. That is testing the software, not the business.

Vibe coding pours the concrete faster

The danger is not typing speed. It is who questions the premise before implementation. A coding agent can faithfully implement a brief that is already too narrow. Faster implementation then makes that narrow interpretation more substantial: more screens, more dependencies, more records, more effort invested in making the parts cooperate.

There is direct evidence for the self-reinforcing pattern. OpenAI’s account of building with coding agents is blunt: Codex replicates patterns that already exist in the repository — even uneven or suboptimal ones. Over time that drift compounds; their team spent a fifth of every week cleaning up what they called AI slop until they put mechanical constraints in the harness.²

As soon as you go software-first and test that software on early clients, you have already hardened the concrete to some degree. Web search can refresh the available technologies without changing the question being asked. Finding a newer integration is not the same intellectual move as realising the integration may be unnecessary. Flexible edges run AI to code, AI to workflow, AI to wiki. Rigid edges run code to SaaS, code to new dependency, code to code that is already hard to manage. Vibe coding, pointed at an inherited platform brief, bakes in older methods at higher speed.

Features are the wrong unit of ambition

Twenty-plus years of software thinking — systems thinking narrowed to applications, requirements thinking, backlogs, sprints — trained a generation to treat the feature as progress. For building software, that can be sane. For building a company whose value is fitted service, the whole notion of a requirement or feature is often the wrong thinking. A feature describes something the software must do. An outcome-focused responsibility describes something the company must achieve or resolve. “Build configurable sponsor packages” has already decided that sponsorship should be packaged, configured, and managed through a software interface. “Work out whether a sponsor would improve this particular engagement, and how both sides would benefit” still permits the answer to be no sponsor, an introduction, a tailored agreement, a small tool, or simply a decision.

When an events business ends up as three application components, one database, ten external integrations and not one model call in the operating path, that is what the filter looks like when it “succeeds.” The full walk of that inventory comes later. The tell is already here: AI helped construct a conventional middle. It did not help eliminate parts of it.

One diagnostic belongs on the wall even before the field chapter formalises it. Suppose the current application disappeared, but you retained client relationships, knowledge and the ability to use AI. What valuable service would you choose to deliver? Compare that answer with what the existing software encourages. The gap is the filter’s shadow.

The filter is how a software middle defends itself. It shrinks imagination until the remaining work looks like translation. Then AI arrives — and translation is exactly what it is good at.

What AI deletes depends on what sits in the middle.

That is the whole causal claim. The previous chapter ended where the filter finishes its work: the remaining human labour looks like translation. AI is excellent at translation. So the default insertion of AI into a software-centred company is not mysterious. It replaces the translators, because translation is what the humans were there for. Anti-jobs. Anti-purpose. Not because anyone hated the staff — because the architecture wrote their job description that way.

Build the company around the client file instead, and AI removes the translation step. The people who remain are not there to make the customer legible to software. They are there to understand, decide, commit and stay accountable. More human internally and more human externally are one design decision seen from two sides. Remove the system from the middle and both the staff member and the customer stop being inputs to it.

One pattern at three levels

The stronger version is larger than “internal versus external.” The same middle decision repeats at three levels that cannot be cleanly separated:

1. Parent to founder — whether a person is met through a folder of accumulating work or processed through a funnel.
2. Company to founder — whether their valued work stays at the centre while agents do the rest, or whether they become operators of the company’s software.
3. Company to customers — whether delivery is fitted service or a package customers must squeeze into.

A funnel-run parent produces funnel-shaped offspring. The way you treat the founder becomes the template for how their company treats customers. That is why “more human inside” is not a wellness programme bolted onto an unchanged middle. It is the only coherent way to get “more human outside” without theatre.

This book treats the folder as an internal operating interface. The customer-facing, co-owned version of that idea is a different conversation. The architectural claim still stands: the three levels mirror each other whether or not you productise the folder for the outside world.

Period support, not nostalgia

There is business-school scaffolding from the same era many operators now half-remember. In 1994, Heskett, Sasser, Schlesinger and colleagues published the service-profit chain in Harvard Business Review: profit and growth stimulated by customer loyalty; loyalty from satisfaction; satisfaction from value; value from satisfied, loyal, productive employees; employee satisfaction from high-quality support services and policies that enable people to deliver results to customers.³ Frontline workers and customers, they argued, need to be the centre of management concern — including technology that supports those workers rather than treating them as system peripherals.³

A later empirical study of 210 high-contact service shops in Hong Kong found most of the postulated relationships in that chain highly significant: employee satisfaction and loyalty linked through service quality to customer satisfaction and loyalty and on to firm performance.⁴ 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.

What this refuses

We do not want to dangle AI off the end of ordinary software, or use AI to make ordinary software more efficient. In the frame of the casualty rule, that programme is ridiculous: it automates the translation layer while leaving the offer trapped inside the application’s imagination.

Nor do we want the opening design question to be what CRM are we going to run? Twenty-plus years of workers have never seen a company without software in the middle. That question taints every decision after it. The CRM fork — relationship bookkeeping versus relationship work — belongs in the next chapter. The point here is simpler. If you start by placing an application in the middle, you have already chosen which casualty you will get when cognition gets cheap.

Same technology. Different architecture. Different casualty.

The remedy is not a costume party for the 1990s. It is a middle that can hold understanding and obligation without making juniors serve the information medium. That middle has a name older than CRM and a modern form that agents can actually work in.

The senior pulls last year’s manila folder from the compactus and sits you down. Here is this client. Here is what we know. This is what happened last year. This is what has changed. Here is what matters this time. You are now responsible for carrying this part of the work forward. The folder is placed on your desk. It does not disappear when the conversation ends. The obligation remains present.

That ceremony joined things we now split across systems: client understanding, historical evidence, current intent, professional judgement and responsibility. The folder supplied the evidence. The conversation supplied the interpretation. The allocation supplied the obligation. The folder on the desk kept the obligation from evaporating into a closed ticket.

Brought forward

The modern form is not cardboard. It is a continuing engagement space:

• A wiki carries the understanding — client context, lessons with evidence strength, methods, distinctions.
• A responsibility register carries the obligation — what must get done, by whom, and how completion is evidenced.
• Knowledge-worker agents get a workplace in which to build — not a separately programmed pathway for every request.

Every assignment 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 real capability for decades without changing their underlying applications. Sponsor-renewal analysis, for example, is often a document and a set of judgements over existing records — not a reason to commission sponsor-renewal software.

Treat agents as knowledge workers with documents and a workplace. Give them responsibilities, access to relevant information and somewhere to leave the work. Personal assistants that vanish when a chat ends are not the same design as company workers whose context, work and obligations persist in an operating environment.

Schema follows questions

A CRM is schema-first: the fields decide in advance what may be known about a client. The folder is content-first: structure gets extracted when a question needs it. Agents inserting rows into a CRM-shaped database reproduce the form without the constraint that justified it. Keep a ledger for what must be exact — money, commitments, permissions — and let understanding live in the folder.

Anthropic draws a related distinction in agent design: workflows orchestrate models and tools through predefined code paths; agents dynamically direct their own processes and tool use.⁵ Put exactness where commitments must not be creative. Put adaptive judgement where the client’s situation is the point. Consistency in standards does not require identical experiences.

The 1993 fork

The idea and the software were born in the same year and then forked.

In 1993, Don Peppers and Martha Rogers published The One to One Future, arguing that interactive technology would force businesses to treat different customers differently and to compete on share of customer rather than only share of market.⁶ Their later revisit is explicit: when media became interactive, companies would have to engage in different behaviours based on the individual characteristics of particular customers.⁷

Also in 1993, Thomas Siebel and Patricia House founded Siebel Systems. At first known mainly for sales force automation products, the company expanded into the broader CRM market.⁸ Early products helped large sales forces analyse and act on centralised information about competitors and clients — organisation-facing machinery priced per seat.⁹

CRM was the relationship’s bookkeeping. The folder is the relationship’s work.

The software that inherited the name “CRM” delivered forecasts, stages and visibility. The customer-facing half of the 1993 promise — treating different customers differently at the level of the work itself — had no technology able to hold an individual relationship at scale. Graduate CRM pedagogy arrived as its own textbook wave around 2004; Peppers and Rogers’ own teaching text is part of that wave, alongside other 2004 CRM textbooks.¹⁰ Bookkeeping got an enterprise category. Relationship work kept living in people’s heads and, if you were lucky, in folders.

The nostalgia guard

The late-90s firm is a reference class, not a costume. It was client-dedicated and often not staff-centred. If you describe a junior accounting job by hours spent, photocopying can be more than half the work. 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. The medium-serving was overhead. AI-native means keeping the first and eliminating the second, for the first time.

Hours were the billing unit. They were never the value unit. Recreate the function of the handover, not its chain of command.

That is the middle the casualty rule requires: understanding, obligation and a workplace. Both middles compound. They compound differently.

An unfamiliar request arrives. Watch where it goes.

In a software middle, the path is grimly familiar. The request does not fit a screen. It becomes a ticket. The ticket waits for the founder — or for whoever still understands how the parts connect. The founder interprets. A coding session produces a branch, a field, an integration, a fix for the interactions the change disturbed. The estate grows. The next unfamiliar request is slightly more expensive. He is compounding through a slow loop of tech debt, increasingly slower, with the founder in the middle — attempting to vibe code.

Feedback primarily becomes a development backlog. He is testing his software, not his business. The application can improve while company judgement remains concentrated in one person. Untested assumptions, tightly connected components and founder-only understanding become progressively harder to change.

In a folder middle, the path is different. Deliver the engagement. Observe customer and commercial outcomes. Retain the evidence. Improve the wiki, the working methods and the agent capabilities. Apply them to the next engagement. Feedback can become company-owned capability rather than another permanent feature. The next unfamiliar request tests whether retained knowledge actually helps — strengthens, qualifies, or overturns what you thought you knew.

Transfer the lesson, not the event

Suppose feedback from one golf day suggests inexperienced players found a competitive format intimidating, while informal team activities helped them make connections. The useful learning is not “repeat Client A’s day for Client B.” It is: for groups with many beginners, where relationship-building matters more than competition, a less competitive format may produce a better experience. Another client can have a different industry, budget and venue and still share that pattern. The agent can reason about relevance. You do not have to programme every customer category in advance.

Bespoke delivery, shared learning. Every client does not have to fund the business learning the same lesson again.

“This happened once” and “this is a reliable principle” are different things. Keep observations separate from interpretations. Client-confidential detail stays restricted; the reusable operational lesson need not expose it. Further engagements strengthen, qualify or overturn the inference. That is how the business builds IP in the wiki without turning the wiki into a junk drawer of unverified guesses.

Two assets improve together

You are compounding the business’s capability, not just its information.

Accumulated knowledge: experience with clients and contexts; what worked and why; commercial outcomes; useful relationships; approaches worth repeating or avoiding. More dimensions and depth mean better distinctions — not merely more pages.

The harness that applies it: instructions, tools, reasoning, coordination, verification and recovery. Knowledge left in a library is not yet an operating asset.

These reinforce each other. Experience reveals a missing capability; a new capability lets the business attempt work it could not previously attempt, producing further experience. A model upgrade can then be evaluated against that existing work. You need not rebuild the company’s experience whenever the weights change. The enduring asset belongs to the business, outside any particular LLM. OpenAI’s agent-first engineering account makes the same environmental point from the other direction: from the agent’s point of view, knowledge that lives only in docs outside the repository or in people’s heads effectively does not exist — repository-local, versioned artefacts are what the system can see.²

Four directions, not one

You’re compounding your IP in your wiki. You can scale the business not only in size, but in complexity, richness and flexibility. That is the architectural payoff of putting the folder in the middle. It only holds if software stops being the place every improvement must live — if software becomes an instrument with a lifetime, and new work climbs a ladder before it becomes permanent machinery.

Code is to agents as a spreadsheet is to a human knowledge worker.

An analyst builds a sheet to compare three options. The sheet earns its existence by helping resolve that decision. It does not need a product roadmap, a subscription model or thousands of future users. Similarly, an agent can create a query, a comparison script, a grouping calculation or an engagement-specific interface because it is the appropriate instrument for the work in front of it. The software is working material — not necessarily a permanent product.

That distinction changes the maintenance equation. You can generate more code during delivery while maintaining less permanent application machinery. Anthropic’s agent capabilities make the mechanism concrete: with code execution, a model can load data, iterate on calculations and return useful results without narrating every row in natural language.¹¹ The negative-return risk is not code itself. It is turning every variation into permanent software before there is a reason to preserve it.

Lifetime tiers

1. Scratch inside an engagement. Let agents write what they need. Scoped to the folder. Disposable.
2. Scripts kept in the client’s folder because this client will need them again.
3. Promotion to a shared library, with a skill file that maps the territory. Gate only this tier.

Review promotions, not writing. A repeated pattern in the exhaust is evidence that structure has been earned — mine what gets repeated and standardise it as components, not as a whole CRM.

The research rhyme is no longer speculative. Voyager’s ever-growing library of executable skills compounded an agent’s abilities, transferred to new worlds, and outperformed prior methods on exploration milestones.¹² Agent Workflow Memory induces commonly reused routines from past trajectories and feeds them back to guide later work, with large relative gains on web-agent benchmarks.¹³

Anthropic’s Agent Skills package the same instinct for production agents: organised folders of instructions, scripts and resources that an agent can discover and load dynamically — “like putting together an onboarding guide for a new hire” — so you specialise an existing agent instead of building a fragmented custom agent for each use case.¹⁴ Skills can include code the agent executes for deterministic reliability without loading every script into context.¹⁴

Gating matters. When reusable artifacts are persisted without lifecycle governance, they succeed once and fail under drift. SKILL.nb shows selective formalisation and gate-conditioned execution retaining far more of initially successful tasks across re-executions than persistent baselines, and limiting regressions after repair.¹⁵ For sustained automation, the question is not merely how to recall prior experience, but when to promote, formalise, repair, demote or retire a workflow whose assumptions no longer hold.¹⁵

The change ladder

Deliver each new business idea with the smallest additional amount of permanent machinery.

The default is to reuse and recombine before adding. Flexible edges: AI→code, AI→workflow, AI→wiki. Rigid edges: code→SaaS, code→new dependency, code→code already hard to manage. Moving an enormous decision tree from TypeScript into English is not the architectural improvement. Anthropic warns that encoding extensive brittle logic in prompts creates its own maintenance complexity; start simple and add complexity when evaluation shows it helps.⁵

A self-describing environment

The durable design is not an exhaustive feature catalogue. It is a small, understandable working environment that can investigate and close the gap between the current situation and the desired outcome. Wiki pages, a few schema queries, search over code — enough for an agent to start from almost any point: describe the outcome, audit the assets, plan the missing pieces, add them on the fly. If a revenue field’s meaning can be traced through docs, records and code, the environment is describable. If it cannot, you are asking intelligence to guess inside opaque machinery.

Y Combinator’s request for startups for “a cloud for small software” names the complementary pressure from the other direction: agents make purpose-built tools easy to generate, while incumbent clouds were designed for big software that scales to many users, at a complexity tax tiny tools never needed.¹⁶ That is the instrument view of code — small, demand-earned, disposable until promotion is justified.

Every’s agent-native architecture 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 book 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.

Judge the design by the next ten requests, not the first demo. The proof chapters that follow show what a software-middle “success” looks like in the wild — and what two reference classes look like when the computer was never allowed to define the work.

Three application components. One database. Ten external integrations. Not one LLM call in the operating path.

That inventory belongs to a founder vibe-coding an events platform — golf days and corporate gatherings, registrations and payments, sponsors and follow-ups. Strip the long tool list of libraries and SDKs and the logical estate is still substantial: a React web app, a Node API, a React Native mobile client, PostgreSQL underneath; then Stripe for money, dual storage paths, a cluster of communications and support services, analytics, address-book OAuth, internal notifications, plus hosting and mobile release administration.

Libraries are not the main objection. The operating scope is. Managed infrastructure does not mean managed application responsibility. Someone still owns login boundaries, payment state, uploaded files, third-party data flows, OAuth tokens and who can deploy. For a starting events business, the inventory reads like a build towards a broader software platform — not minimal tooling for delivering excellent days.

AI helping construct a conventional platform versus AI helping eliminate parts of it.

That is the central contrast. Using AI to simplify a stack — more build, less buy; chunks of work done with bounded intelligence instead of coded branches — is a different move from using AI as a faster construction crew for the inherited competitor feature list. OpenAI’s harness team reported that in some cases it was cheaper to have the agent reimplement a small subset of functionality than to work around opaque library behaviour — putting more of the system into a form agents could inspect.² The zero model calls are the tell. The middle is still applications. Cognition never entered the operating path. It only accelerated the pouring of concrete.

The email that should not become a feature matrix

Consider a message that arrives mid-cycle: two people have dropped out, Sarah is replacing one of them, send the revised invoice to accounts.

In the software middle, the temptation is combinatorial. Cancellation paths. Substitution paths. Partial refunds. Re-issue invoice. Notify the club. Update the attendee list. Sync the CRM. Each combination becomes a branch, a state, a test case, another reason the founder stays in the loop.

In the instrument middle, the same message is bounded work with controlled tools. Confirm who is out and who is in. Recalculate the amount that must be exact. Prepare the invoice revision for accounts. Notify the people who need to know. Leave a short note in the client folder about what changed and why. Authority is scoped: the worker may draft and calculate; consequential money movement still passes a gate. You have not programmed every combination. You have equipped a worker to handle this combination.

The analysis that needed a document

Sponsors are not renewing. Someone asks why.

The software-middle reflex reaches for sponsor-management features: packages, portals, automated sequences, scorecards. The folder-middle reflex asks what we already know. Attendance records. Notes from last year. Which introductions were promised. Which follow-ups happened. Whether “logo placement” was ever the thing sponsors valued. Often the gap is missing evidence, not missing analytical software. The useful artefact is a sponsor-renewal analysis — a document — plus a way to capture better evidence next time. Capability grows the way Word-and-Excel departments always grew: new knowledge as a new document, not a new subsystem. The underlying tools can stay largely unchanged while the tenth engagement becomes better informed than the first.

The Sydney group that tests recombination

A new corporate client. Small group. Sydney-based. How do we help them best — who else to invite, which club, which sponsors?

That brief is not a feature request. It is a knowledge-worker assignment. Establish the objective first: entertain existing customers, meet potential customers, strengthen a team, or simply have a good day. Adding players and sponsors is only useful when it serves that objective. Then recombine what the business already knows about people, clubs, conflicts, budgets and previous outcomes. The software middle would have waited for the founder to invent “group matching” screens. The folder middle asks whether existing relationships and knowledge can satisfy the request without a new permanent branch.

The cost of the next change

Once AI is helping maintain the system, change the system and execute the work, a smaller, better-described architecture becomes valuable across all three. The objective is not fewer logos on an architecture slide. It is more of the business inside a system that intelligence can understand, inspect, test and change under controlled permissions.

For each new idea, ask how many things must be understood, edited, coordinated, verified and released before the business can do this. That is closer to fleet-footed than counting repositories. The change ladder from the previous chapter is the practical preference order: knowledge first, then instructions, then small code, then dependency. The events platform inventory fails that test in advance. Almost every new commercial idea arrives as a candidate for permanent machinery, because permanent machinery is the middle.

The stack explains how the software runs. It does not explain how the business learns. Where do we capture what we learnt about each client, venue, sponsor and event — and bring that knowledge into the next proposal? A shared wiki, used by people and AI workers, makes experience cumulative rather than something the founder has to remember personally. Without that, the filter from earlier chapters completes itself: competitor features and founder capability shaped what got built; customers will now be asked to fit it; the beta will refine the fit without ever testing whether the answer was right.

This is what “success” looks like when software stays in the middle. Recognise it. Then look at two reference classes where the computer was never allowed to define the work.

I. The cadet

You already had a client, a brief and a responsibility before you booked time on the computer.

In the accounting firm where I started, that booking was literal: a piece of paper on the wall in the specialist computer room. Dot-matrix printers sat under big hoods with foam padding because they were so loud. The general journal arrived in pencil. A manager handed me a handwritten book of ledger entries, added it up, made sure it balanced. Can you imagine? In pencil.

Everything lived in manila files in the compactus — last year’s work papers, tax returns, invoices, letters typed by secretaries on electric typewriters. Photocopying was more than half my job as a cadet straight out of school. Different documents needed different numbers of copies: tax office, bound client copy, compactus copy. You keyed a client code into the photocopier because copies were expensive enough to bill. If you had to describe the job by hours spent, I was a photocopying expert.

There was purpose-built Unix software for profit and loss, general ledger, balance sheet, the simplest tax schedules. Anything slightly non-standard deferred to printed tax-office schedules. The computer was a calculator with ambitions. It did not manage the workflow. It did not own the relationship. It did not decide what the client was allowed to need.

Partners got desktop machines first and often did not turn them on. Secretaries printed emails; partners annotated by hand; replies went back out through the same paper loop. Inside-office email arrived before outside-office email, which now sounds like a joke. Debriefs happened in person because there was nowhere else for them to go. Partner to senior to junior: don’t forget, they said to do this.

I remember being handed the manila folders from the compactors, and the senior would sit you down and say what we’re doing with this client and what made them special.

It was a ceremony. What happened last year. What the partner had just learned was different this year. Receipts. Outputs from their accounting system. Sometimes a site visit. Sometimes a stock portfolio to sift. Tribal knowledge about this client. You were being trusted. You had a responsibility. The folder sat on your desk. You might have several. Next year, if you had been the junior, you were often the senior, with a new junior beside you. What accumulated was judgement about the account — not merely proficiency with the machinery.

Staff were allocated to accounts. Teams of two and three. No CRM. The customer relationship lived in people’s heads, which is both the strength and the fragility. You worked hard because you had met them and understood their business. Later CRM gave the organisation forecasts, stages and visibility. It helped sales management. It did not, on that evidence, deliver better service to the client. Peppers and Rogers had already argued that interactive technology should force companies to treat different customers differently;⁷ organisation-facing sales automation was a different inheritance of the same year.

Flexible thinking is partly a reference class. People who started before computers and software turned everyone into automatons had already seen businesses where every workflow for every client was different — standard bones, dramatic variation in the flesh. That is teachable. It is not a personality cult. We do not want to use AI to speed up writing software that makes us ordinary. We do not want to dangle AI off ordinary software. We want tools that deliver authentic, personalised service — with the computer back in the role the booking sheet implied: an instrument you use to complete part of the work.

II. The toy company

Years later I built a project called Venture World — a visualisation of running a business as a kind of computer game. Birds move around an office. Packages arrive. Letters get written. Money gets spent. A kid tester shows up after school. Images land on the side like magazine clippings and opened envelopes. It starts in 1983, writing early computer games. And look at the basis of it: there is no computer software running the company. It is a services-shaped, human-run business. There is no CRM. They just say: are we going to do this project? There is a letter someone wrote in.

I built the thesis as a toy before I said it out loud. The development record contains something better than coincidence.

The first version let the market model generate the season. Those episodes lacked visible business: no orders, dispatches or decisions an audience could watch being made. Correct, in a thin sense. Lifeless. The fix was not a better model. We went story-first, with the simulation kept underneath as the economic spine and deterministic code owning accounting and continuity. Machinery-first gave a correct but lifeless company. Experience-first, with machinery demoted to keeping the promises, gave one worth watching.

The recorded finding from a reverted inventory experiment is sharper still: a good player and a good episode are not the same objective. Replace “player” with “pipeline” and “episode” with “client journey” and you have the funnel critique, discovered empirically in a build. Optimising the company’s numbers can quietly remove what made it worth being near. That is a one-paragraph warning, not a product brief for replacing funnels. The architectural point is enough: the metric you optimise becomes the middle you get.

Why 1983 works as a setting is also extractable. In a software house of that era the work is legible: a letter arrives, someone argues, a decision gets made. In a SaaS-era company the work is invisible, inside apps. Agent-run companies have the same legibility problem. Venture World is an accidental glass office — a way to give people who have never seen a pre-software-middle business a reference class they can watch. Flexible thinking becomes teachable because the specimen is visible.

Inside that toy, the instrument stack showed up without a doctrine memo: composable scripts, skill files that map territory, shared components earned by demand rather than roadmap, agents writing code during delivery, repeats promoted as components rather than as a CRM. CRM, as a stupid interface to a database, is exactly what the agents did not want. They wanted a folder, context and responsibility — with tools along the way for accuracy and speed. That is Chapter 6 running in a sandbox before Chapter 6 had a name.

Two reference classes. One lived. One built. Both say the same thing: when the computer is an instrument, the middle can hold understanding and obligation. When the computer is the middle, you get a platform that looks complete and a company that cannot think past it. The reader still needs instruments of their own.

Pass shape is concrete. Client understanding, held responsibility and a workplace for knowledge workers sit in the middle. Software is instrument. New work climbs the change ladder — knowledge, then instruction, then small code, then dependency — before anyone opens a feature ticket. Fail shape is equally concrete. Staff hours are mostly system navigation. Customers squeeze into packages. Unfamiliar requests return to one person and harden into branches. The application disappearance test produces an awkward silence, or an answer identical to the current feature list.

You do not have to delete your CRM tomorrow. Ledgers for money, commitments and permissions can remain. What has to move first is authority over the offer: stop letting the application define what the company is allowed to imagine. Put new work through the folder and the ladder. Let permanent machinery earn promotion.

The handover test, operationalised

For any engagement pick-up, ask the design question from the folder chapter until it becomes habit:

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

If you cannot answer the first half, understanding is not in the middle. If you cannot answer the second, obligation and learning are not in the middle. Chat transcripts and CRM stages will not rescue you.

Judge by the next ten requests

The first demo flatters every architecture. The next ten unfamiliar requests expose it.

Those are different objectives. A suitably equipped worker can address them with the same records, tools and wiki — without a separately built application feature for each. Some requests will still need new tools. Adding machinery stops being the automatic response.

The static defender

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. Competence inside the wrong middle still leaves the firm structurally slow where variation is the value.

The AI-native firm is the dynamic attacker in that environment — not because it has better slogans, but because worthwhile difference does not automatically become a four-step change programme. Sequoia’s distinction is adjacent: a copilot sells the tool, an autopilot sells the work.¹ Selling the work still fails if the company’s middle forces every difference back into tool-shaped exceptions. This is a competitive consequence of architecture. It is not a catalogue of opportunity types. Those selections are a different conversation. The point here is narrower and harder: if you keep software in the middle, you have chosen the defender’s cost structure.

Outcome first, in one paragraph

Design from the outcome. Start with the valuable experience this client should receive, then assemble knowledge, people, agents and software underneath it. The methods for discovering that experience — testimonials worked backwards, abundant-expertise thought experiments, stakeholder reviews — have their own depth elsewhere. The architectural requirement is enough for this book: do not let the production method decide the ambition before the ambition has been stated.

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.