The Module Library: What We Reuse Across Clients and How It Earns Its Place

Every client we install AIOS for gets 80% of what they need from our module library. The other 20% is custom, and the two sides earn their keep on different schedules.

The sibling post covers the decision framework for which side a given need lands on. This one is about the library itself: what's in it, how a module qualifies, how we version across installs, and how modules evolve without turning into a graveyard of half-maintained code.

The short version: the library is the accumulated backbone of everything we have built across engagements. It is not open-source and not a product we sell. Client-specific logic stays with the client. What we carry forward is shape. Patterns, scaffolds, config surfaces, input and output contracts, known failure modes. Over the last year, roughly twelve modules have landed in almost every install with only minor adaptation. That twelve is what borrow before you build looks like at a firm that has shipped the same classes of problem enough times to know their outline.

What's in the library

The library covers the workflow shapes that recur across mid-market firms, not specific features for specific verticals. Categorically, it breaks into seven buckets.

Intake modules handle inbound lead routing and qualification scoring. A lead arrives from a form, an inbox, a referral partner, or a phone system. The intake module normalizes it, applies a qualification rubric, and routes it to the right queue. The differences across firms sit in the scoring criteria and the routing rules, both of which are config.

Content pipeline modules cover drafting, editing, voice-matching, and the handoff into publishing. A firm that produces any volume of external writing, whether newsletters, reports, client deliverables, or social posts, needs a pipeline that drafts against a brief, checks against a voice profile, and moves through an approval surface. The pipeline is generic. The voice profile is Context work and lives in Layer 1.

Reporting modules produce the daily brief and the monthly leadership packet. These are the synthesis surfaces the firm actually reads. The module pulls from the data layer, summarizes against a template, flags anomalies, and delivers on schedule. Clients tune the template and the delivery rules. The aggregation logic is shared.

Follow-up modules handle scheduled touches and pipeline revival. A prospect goes cold. A deal stalls. A renewal is coming. The follow-up module runs the cadence, drafts the message, surfaces the approval.

Ops modules run the firm itself rather than its client-facing work. Task audits, workflow mapping utilities, the Blueprint output generator we use in our own Blueprint phase before Build begins. These sit closest to the firm's nervous system.

Integration modules are the common API connectors, CSV ingestion, and webhook handlers. Nothing exotic. The ones we have built enough times to know the retry patterns, the auth failure modes, and the shape of a reasonable error log.

Governance modules are the approval gate UIs, the audit log, and escalation routing. If automation ships without these, the firm loses trust the first time something goes sideways. Approval gates get their own post, because that surface is where most AIOS installs either build confidence or leak it.

None of these are named products. They are shapes, and the shape is what makes them reusable.

How a module earns its place

A thing is not a module until it passes three gates. We are strict about this, because the cost of a module that has not earned its place is higher than the cost of writing the same code twice.

First gate: shipped in three or more engagements with minimal rework. One engagement proves the idea works. Two suggests the pattern might generalize. Three is where we have evidence that the shape holds across different firms, different operators, and different edge cases. Before three, it is a candidate, not a module. Candidates stay in a staging area until they have earned a clean name. The Bain operations work on scaled AI operations makes the same point from a different angle: premature standardization is one of the top failure modes.

Second gate: defined input and output contracts. A module that works only when you happen to call it right is not a module, it is a landmine. Every library module has a written contract for what comes in and what goes out, along with the failure modes for inputs that do not fit. This is what makes the next engagement's adaptation cheap. You read the contract, you pipe the client's shape into it, you configure the knobs. You do not re-read the module's internals.

Third gate: maintenance cost per install under ten percent of the build cost of a custom equivalent. This is the economic test. If carrying a module forward costs nearly as much as rebuilding from scratch each time, the module is doing no work for the firm. Maintenance cost includes updates when a dependency changes, tuning when a new install surfaces an edge case, and keeping the contract stable. If that number creeps up, the module has drifted into something too specific or too entangled to carry.

A candidate that fails any of the three goes back to staging, gets refactored, or gets retired. The library does not grow for the sake of growing. HBR's technology and analytics coverage has covered this pattern in other contexts. The firms that succeed at internal tooling prune as aggressively as they build.

How modules evolve

Every engagement tunes the modules it uses. A new edge case in an intake module. A better prompt in the content pipeline. A faster query path in the reporting module. After the engagement, the tuning that is genuinely general flows back into the library. The tuning that is specific to the client stays with the client.

The library is versioned. Old clients can stay on an old version as long as that version is still under a supported maintenance window. New clients get the current version. When we retire an old version, we notify the clients on it and work through a migration window. Mundane software discipline, and the only thing that keeps a reuse library from rotting.

The feedback loop matters more than the versioning mechanism. A module that does not get observed in the wild stops being worth anything. Every install has telemetry on its modules, and every quarter we look at which modules are getting hit, which are idle, and which are throwing errors nobody has chased down. The Sloan Management Review work on ML system observability maps onto the same problem at the module level: if you cannot see what the thing is doing after it ships, you cannot improve it, and you cannot trust it.

What we never put in the library

The library is defined as much by what it excludes as by what it includes.

Client-specific logic stays with the client. A scoring rubric that matters only for a particular firm's sales motion. A workflow branch that maps to a particular firm's org chart. Pricing tiers, named accounts, internal jargon. None of that belongs in the library. It belongs in that client's Context layer and in config.

Vertical-specific assumptions get their own preset, not a module slot. Scheduling logic for a beauty salon, intake handling for a law firm, reporting cuts for a specialty distributor. These are vertical presets that ride on top of generic modules. The underlying scheduling module is vertical-neutral. The preset supplies the vertical shape. Mixing the two corrupts the module.

Tools the firm has strategic reasons to avoid standardizing on. Some categories we deliberately keep case-by-case even when we have built the same thing several times. Usually this is because the tool choice itself is a strategic variable the client should own, not something the module bakes in. An example: the messaging layer a firm uses for external communication. Standardizing on one vendor in the module itself would lock clients into a choice that should remain theirs.

The adaptation pattern per install

A new install starts with the library at roughly 80% fit. The remaining 20% is where the firm's actual difference lives. How we sequence the layers covers the order of operations; the acceptance bar for a layer covers what "done" looks like for each layer. Inside that sequencing, Layer 5 runs the library-then-custom pattern.

The adaptation work is almost entirely config. The intake module's scoring rubric gets tuned. The content pipeline loads the firm's voice profile. The reporting module points at the firm's data warehouse and loads its brief template. The follow-up module picks up the firm's cadence rules. None of this requires new code. It requires knowing the firm well enough to fill in the knobs correctly, which is what the first four layers were for.

Custom work is reserved for the 20% that is genuinely unique and worth the build. When the custom work is done, the question is always the same: is this piece a one-off for this firm, or a candidate for the library? Most are one-offs. The ones that are not get logged and revisited after the next two engagements. If the shape holds, we start the promotion process.

Integrating the library into an existing stack without blowing things up is its own discipline. Integrating without rip and replace covers that in detail.

Anti-patterns and maintenance

Three anti-patterns kill reuse libraries. We watch for all three.

Over-abstraction. A module that tries to do everything ends up doing nothing well. The signal is a config surface with twenty knobs that interact in non-obvious ways. A good module has a tight config surface with a small number of well-understood levers. When the surface starts expanding to cover every edge case we have ever seen, the module needs to split or the edge cases need to go back to being client-specific custom work.

Premature modularization. Building a module after one engagement. The three-engagement bar exists precisely because one engagement does not produce enough signal. Anything promoted too early gets retrofit in painful ways the first time a second client's shape does not match. We have done this. It is not fun. McKinsey's digital practice writes about the same dynamic at enterprise scale, and the cure is the same at our scale: resist the promotion until the evidence is there.

Fork and forget. A module gets forked for a specific client, drifts, and nobody maintains the fork. Six months later it breaks, and the client is stranded on code nobody owns. The defense: every module has a named maintainer and a scheduled quarterly audit. If it does not have an owner, it does not go in the library. If the owner changes, the handoff is documented. Dead modules get retired cleanly with a migration path, not left to decompose.

The quarterly audit is what makes all of this hold together. We read the last quarter's telemetry on every module. We decide whether each is carrying its weight, whether any candidates have cleared the three-engagement bar, and whether any current modules should be demoted. This is the hygiene that keeps the library from turning into the bespoke-code graveyard Ed wrote about earlier.

The library is the reason a Build phase gets shorter every year. The cost of shipping Layer 5 for a new client in our third year of running AIOS engagements is meaningfully lower than it was in the first year, and the quality floor is higher. That is what compounding looks like when you do the maintenance work. A client's Build phase benefits from every prior client's Build phase, which is the only way a mid-market firm can afford the kind of system that moves their revenue per employee the way month 12 of the Run phase expects it to.

If you are weighing an AIOS engagement, the Fit Check is where we figure out how much of your need the current library already covers. The Blueprint is where we draw the line between the 80% that borrows and the 20% that earns custom work.

-Jeremy