The Shortstack Model

The Shortstack Model; Software Architecture as Strategic Optionality

Walk into almost any legal department or enterprise IT steering committee today, and you will find a group of smart people quietly maintaining a museum of recent enthusiasm.

Three years ago, as generative models began showing real promise, the immediate institutional instinct was to convene a committee. Procurement teams drafted hundred-page RFPs, enterprise architects designed elaborate custom orchestration layers, and steering committees debated multi-tier software roadmaps. Millions were spent building wrappers and API integrations around whichever frontier model held the performance benchmark crown that quarter.

Today, the hangover has settled in. The underlying models moved on a six-month clock. The enterprise committee architecture was built on a five-year deprecation clock. Organizations now find themselves paying staggering annual carrying costs to maintain custom code written for obsolete model paradigms and, worse, designed to solve problems that baseline foundation models absorbed two updates ago.

We did this to ourselves because we confused elaborate process with prudent governance. In our haste to manage risk through bureaucracy, we built a bloated software architecture that converted today’s temporary feature into tomorrow’s impossible switching cost.

This is where the technical trap springs open. It asks a heavy, committee-driven question: How do we design a custom enterprise architecture to deeply embed today’s AI into our systems?

Prudent AI asks a far simpler, sharper question: How short can we keep the stack, and how fast can we make a solid, reversible decision?

What Is the Shortstack?

To preserve strategic optionality, an enterprise doesn’t need a massive, custom-engineered software architecture. It needs a Shortstack.

The Shortstack is both an architectural posture and an operating discipline. It means making simple, fast decisions around mainstream, interoperable tools and keeping your active technology stack brutally short rather than running every initiative through months of committee reviews, custom software builds, and complex middleware projects.

Consider what a pragmatic, short-stack legal environment might look like in practice:

That’s it. Four proven components. No custom orchestration code. No proprietary middleware wrappers. Minimal administrative glue.

Why focus on mainstream platforms? Because mega-vendors spend billions ensuring their platforms interoperate cleanly out of the box. Relying on mainstream tools eliminates the need to hire consultants to write custom glue code. And you don’t need to sift through hundreds of specialty AI tools.

More importantly, a Shortstack turns intake into a fast, low-stakes decision. You can decide quickly because the decision is easily reversible. If a tool fails to deliver value, you haven’t built a custom API bridge that takes six months to dismantle. You simply turn off the license and move on.

Architecture Is Where Optionality Becomes Operational

Now we arrive at the physical machinery that makes that strategy work on a Monday morning.

An executive committee can pass all the resolutions it wants about remaining “model-agnostic.” But if replacing your primary model provider requires rewriting eighteen months of custom middleware, re-architecting your document management system, and retraining fifty lawyers on a vendor’s proprietary interface, you do not possess optionality. You possess a hostage situation.

For decades, enterprise leadership was warned about the risks of vendor lock-in. In the rush to avoid committing to a single AI ecosystem, many organizations made a far worse mistake: they traded commercial vendor dependence for bespoke architectural lock-in. Paying a license fee to a mega-vendor isn’t what traps you. What traps you is the millions spent on custom glue code designed to avoid making a clear platform choice.

The impulse to over-engineer comes from a mistaken belief that a complex problem requires a complex stack. But in a rapidly shifting technological landscape, complexity simply means lock-in. The Shortstack posture recognizes that software architecture is where strategic optionality stops being a leadership slogan and becomes operational reality.

The Shortstack Operating Rule: Dev, Test, Prod

To maintain the Shortstack discipline over time, Prudent AI separates technical decision-making into three simple layers organizations already know well:

1. Dev: Experiment Broadly

This is your low-cost laboratory. Here, in secure sandbox environments using synthetic or non-sensitive data, individuals and small teams explore open-weight models, lightweight local runtimes, specialized niche APIs, and new software features. The goal in Dev is emphatically not to launch an RFP or build an enterprise integration. The goal is to discover what is technically possible and build internal literacy without exposing client assets or creating a single permanent vendor dependency.

2. Test: Benchmark Ruthlessly

Before any tool touches a live client matter or a core enterprise workflow, it must be evaluated against real-world Jobs to Be Done like complex indemnification exceptions, multi-jurisdictional filings, or messy, non-standard client paper. You don’t ask an RFP committee to score vendor promises. You test competing tools against actual work for drift, error rates, and edge-case failures.

3. Prod: Deploy Narrowly

When a tool passes testing, you add it to active production only if it fits cleanly into your Shortstack. If a proposed tool requires building custom middleware or adding an expensive, redundant administrative layer to active production, you reject the integration. Keep the job inside your primary platforms.

Governing Principle: Concentrate production; simplify intake.

The Architecture Matrix

When you look closely at how legal departments and enterprises assemble their technology, they generally settle into one of four quadrants based on intake speed and integration debt:

• Overbuilt / Conflicted (High Debt / Slow Intake): The enterprise trap. Committees spend months approving custom orchestration layers around a single commercial model, creating fragile, expensive software that breaks with every major model update.
• Big Legal AI (Low Debt / Slow Intake): The department buys an all-in-one specialist platform. It goes through an exhaustive evaluation process and trades architectural control for total vendor dependence. This can be a defensible choice for small teams lacking technical resources, provided they acknowledge their switching costs will be high.
• Fragmented Bureaucracy (High Debt / Fast Intake): Individual teams rapidly adopt isolated point solutions that require custom connectors and IT support. Administrative overhead, security debt, and data fragmentation escalate while real adoption stalls.
• Prudent AI / Shortstack (Low Debt / Fast Intake): The target state. Fast, confident intake decisions focused on four or five mainstream, interoperable tools. Active production remains thin, costs remain predictable, and the organization retains the practical capability to swap components whenever better technology or better terms emerge.

Procurement Filters: Testing for Reconstitution

Before approving any new AI software acquisition or getting dragged into a custom integration project, leadership should apply two diagnostic filters:

1. The PE-Stress Test:

Buy every AI product as if the vendor will have a new private equity owner in three years. Assume the vendor will be acquired, customer support will be slashed, and subscription rates will triple. If that happens, what is your exit time-to-good-enough? If removing the tool breaks your core workflow for six months, you haven’t bought software. You have surrendered operational control.

2. The Specialist Vendor Test:

What irreplaceable job does this specialist tool do well enough to justify adding another permanent dependency to active production? If a tool like Clearbrief does a specific, high-value job exceptionally well, buy it and use it. But if a specialist tool merely wraps a standard foundation model with a pretty interface and a light prompt template, skip the contract. Keep the job inside your primary core platform.

Diagnostic Tool: The Reconstitution Test

When evaluating your current technology stack or considering a new software proposal, ask this single diagnostic question:

If this software component or vendor disappeared tomorrow, what would have to be rebuilt, how long would it take, and what core capability would we discover we no longer possess?

If you are trapped in an overbuilt enterprise architecture, answering that question requires a six-month audit, a consulting engagement, and a million-dollar custom rebuild.

If you are running a Shortstack anchored in mainstream platforms like Gemini or Copilot, NetDocuments, Practical Law, and a handful of sharp point tools, the answer probably is measured in days or weeks.

Simplify intake. Make fast, solid decisions. Deploy narrowly. Keep the stack short, and your exit is always close.

Prudent AI is not a prescription for moving slowly. It governs consequential AI commitments under uncertainty while preserving the capacity to learn, adapt, and recover. Real-options reasoning and portfolio thinking provide tools for doing that: move fastest where experiments are cheap, failures are reversible, and learning is valuable. Demand progressively stronger evidence as commitments become harder to unwind and the consequences of error increase.

Accelerate reversible learning. Pace irreversible commitment.

Dennis Kennedy – CC BY 4.0 license

[Originally posted on DennisKennedy.Blog (https://www.denniskennedy.com/blog/)]

DennisKennedy.com is the home of the Kennedy Idea Propulsion Laboratory

Like this post? Buy me a coffee

DennisKennedy.Blog is part of the LexBlog network.