The exquisite-system trap

The objective is not the simplest system, nor the most advanced. It is the least complex architecture that can reliably do the whole job. That includes the cost of operating it, the people needed to sustain it, what happens when something fails and how readily it can change.

A proposal can become more impressive at every presentation while becoming less attractive to operate.

Imagine an AI project gaining a more capable model, another specialist agent, a bespoke integration and a richer management dashboard. Each addition has a plausible justification. Yet the organisation may be acquiring more dependencies, more training, longer implementation and more difficult upgrades and another reason why only the original supplier can maintain it.

None of those additions is necessarily wrong. What is missing is the comparison: does the extra capability improve the organisation’s outcome enough to justify the extra burden?

That is the exquisite-system trap: mistaking excellence in individual components for excellence in the system that contains them.

The most advanced component may be indispensable. It may also be an expensive way to make the wrong architecture more impressive.

The complexity the job requires

By requisite complexity, I mean the complexity genuinely required to perform a function reliably. Requisite design is the discipline of finding an architecture that contains that complexity without accumulating more than the job warrants.

The objective is not simplicity for its own sake. It is the least complex system capable of satisfying the complete requirement, rather than the smallest demonstration that works under favourable conditions.

The distinction matters because reliability, governance, maintainability and resilience are functions too. A second supplier, an audit trail or a reserve of replacement equipment may look redundant on a diagram while being essential to the operating result.

W. Ross Ashby’s Law of Requisite Variety provides a useful conceptual reference. A regulator needs sufficient response variety to deal with the disturbances it must control. In organisational terms, a system needs adequate ways of handling the situations it will encounter. But response variety is not the same as component count, and Ashby’s law does not say that a more elaborate architecture is automatically better.¹

A practical extension is to ask whether the problem can be bounded, standardised or routed to an appropriate exception process before adding machinery to handle every possibility. Where human escalation is part of the answer, however, the humans and their workload belong in the system’s cost and capacity calculation.

Complexity removed from a diagram has not necessarily been removed from the organisation.

A rocket does not have to carry the whole answer

On 10 July 2026, China’s Long March-10B placed a satellite in orbit and recovered its first-stage booster using a net on the recovery vessel Linghangzhe, according to China’s space agency.²

In subsequent engineering interviews, the programme described a recovery arrangement that dispensed with landing legs, avoiding their onboard weight. The arrangement still required precise rocket control, communication with the vessel, ship positioning and an actively adjusted cable net. This was not a simple rocket falling into a passive fishing net.³

The interesting management question is where the complexity sits. Instead of giving every vehicle all the equipment needed to stand on a landing surface, part of the recovery function sits in infrastructure that could serve successive vehicles.

There is a plausible fleet-level argument here. A sufficiently deep fleet, supported by enough recovery capacity and manageable replacement lead times, could make the loss of a booster during recovery less disruptive to continuing launch operations. Shared equipment might also spread some recovery costs across many flights.

That is a hypothesis, not a demonstrated economic advantage. The evidence reviewed does not establish repeated reuse, lifecycle costs or fleet resilience at scale. A shared recovery vessel can itself become a bottleneck; a common design defect can ground a fleet. Moving complexity does not automatically remove it, and accepting an equipment-loss risk is not permission to compromise flight safety.²³

Nor is this a uniquely Chinese insight. SpaceX’s Super Heavy tower catch in October 2024 also placed recovery hardware outside the vehicle.⁴ The comparison concerns design choices, not national character.

For a manager, the equivalent question is whether a capability belongs inside every application, in a shared service, or with a specialist provider — and what happens when the shared element is unavailable.

DeepSeek: efficiency can require sophistication

DeepSeek offers a different version of the same lesson.

US export restrictions narrowed Chinese access to certain advanced chips. In a July 2024 interview, DeepSeek founder Liang Wenfeng identified high-end chip restrictions, rather than money, as the company’s immediate constraint.⁵⁶

That supports the argument that constraints made compute efficiency especially valuable. It does not prove that restrictions caused every subsequent innovation, or that restrictions were beneficial overall.

DeepSeek’s engineering papers describe approaches including activating selected model components rather than the entire network for each processing step, reducing memory requirements and coordinating computation with communication between chips. These are sophisticated techniques intended to get more useful work from the available hardware.⁷⁸

The much-repeated cost claim needs equal care. The DeepSeek-V3 report estimated $5.576 million for its official training computation, using 2.788 million H800 GPU-hours at an assumed $2 per hour. That covered pre-training, context extension and post-training. It explicitly excluded prior research and experiments comparing architectures, algorithms or data. It was not an all-in development budget covering the organisation, its hardware investment and its research programme, nor a total bill for the separate R1 reasoning model.⁷

The managerial lesson is not that advanced engineering is wasteful. Here, advanced engineering was part of the route to resource efficiency. Nor does a low reported training-compute figure tell a buyer what an organisational deployment will cost.

The right question is what the sophistication buys across the whole system. Some complexity pays its rent. The rest merely occupies the premises.

The weapon that wins today — and the capacity needed tomorrow

Military procurement makes the distinction particularly uncomfortable.

An exquisite weapon may be exactly what a difficult mission requires. But a force also needs enough usable equipment and ammunition, people trained to operate and maintain them, and production capable of replacing losses and expenditure.

The US Government Accountability Office reported in July 2026 that major defence acquisition programmes were taking, on average, more than 12 years to deliver initial capability. That is an acquisition-development measure, not the time needed to manufacture one replacement weapon.⁹

An August 2026 analysis by the Center for Strategic and International Studies examined multi-year delivery lead times for legacy munitions and argued for a high-low mix: sophisticated weapons alongside more affordable systems. It also distinguished industrial expansion plans from the funding and production needed to turn them into delivered capacity.¹⁰

Winning an engagement and sustaining a campaign are different optimisation problems. A highly capable interceptor does not replenish its own magazine. A manufacturing announcement does not create deployable stock.

This is not an argument for inferior weapons. A cheaper system that cannot perform its mission is not a bargain; in some roles, advanced capability is the minimum acceptable requirement. The design problem is the mix, the stock available, the production rate and the time needed to restore effective capacity after losses.

The organisational analogy is not that an ERP implementation is a battlefield. It is that a scarce expert, irreplaceable integration or long replacement cycle can be a strategic weakness even when the component itself performs brilliantly.

Replaceability is part of capability.

When our own design became more complex

We had already built a relatively lean automated sales-negotiation system for our own internal use when it came to the attention of a business looking for an automated procurement capability. That led to the design of a broader procurement decision system, and discussions are now under way about implementation.

The original negotiation system was close to the simplest architecture we considered capable of autonomous deal-making within defined constraints. It combined hard guardrails with a way to value several deal variables together, generate offers, manage concessions, model the counterpart and learn from outcomes.

That was not merely a chatbot allowed to bargain. The guardrails defined what it could not trade away; the multi-variable evaluation allowed it to consider the value of a package rather than price alone. Its simplicity came from a bounded job, not from pretending the job had no difficult parts.

The first-phase scope under discussion covers roughly $30 million of purchasing. Across all categories, a wider rollout could extend that to around $350 million.

The procurement requirement was broader. It needed governance and auditability, configurable rules, category-specific priorities, multiple roles and decision rights, and a way to balance organisational objectives. Learning, modular client configuration and eventual integration also had to be accommodated.

Consider the difference between negotiating a satisfactory sales package and advising on purchases across an organisation. A locally cheaper option may create a larger cost elsewhere. Different categories may legitimately need different priorities. The person using the system may not have authority to change the policy it applies.

Those are not decorative features. They define whether the system can perform the required job.

The procurement design therefore became substantially more complex. That was not necessarily a failure of restraint. Removing an audit requirement would simplify the architecture by abandoning part of the requirement. Hard-coding one organisation’s rules might simplify the first version while creating an architectural dead end for the next.

The useful question was not simply, “Can this be made simpler?” It was, “What is the least complex system that can satisfy the necessary functions without creating foreseeable architectural dead ends?”

This is a design lesson, not performance evidence from a procurement deployment. It nevertheless exposes a distinction that a feature-counting approach would miss: apparent complexity may be requisite.

In an AI stack, the avoidable layer might be an agent coordinator doing work a predictable sequence could handle. In an ERP project, it might be custom code preserving an old departmental preference rather than a necessary process. Either could be justified. The obligation is to show why — and to include time to useful deployment, upgrade effort and the cost of changing course in the comparison.

Three decisions, not one feature list

Managers need a way to distinguish building too much from preparing sensibly. The useful division is not between simple and complicated. It is between three kinds of commitment.

On a narrow screen, each capability category is shown as a separate card.

The middle category requires discipline. “We might need it one day” is not enough. There should be a credible scenario, a reason the decision affects today’s foundations, and a trigger for implementation.

For example, live integration may be deferred while the design still separates decision logic from organisation-specific data connections. That preserves a route forward without pretending every connector needs to exist immediately.

Conversely, modularity has costs of its own. Splitting a small application into many independently managed services can create more work than it removes. The aim is useful boundaries, not the maximum number of modules.

What to ask before approving the exquisite proposal

Use these questions with the supplier and the people who will operate the result. The purpose is not to make every answer smaller. It is to make every architectural commitment earn its place.

Capability and operating burden

1. Show us the leaner alternative that meets the same mandatory requirements. What measurable improvement does the proposed extra sophistication produce? A cheaper comparison that omits governance or reliability is not a valid baseline.
2. Where has the work gone? Include maintenance, staff training, exception handling, monitoring and specialist support. Has the design removed a burden, or moved it outside the quoted project price?

Failure and replacement

3. What continues working when an important dependency fails? Ask for a demonstration or test evidence, including the effect of a shared service failing. Redundant-looking components are not protection if they depend on the same fragile upstream element.
4. How do we replace the supplier, model or key expert? Ask what happens to data, rules, configuration and decision history; how long the transition takes; and which capabilities must be rebuilt rather than transferred.

Future requirements and scale

5. Which future requirements change today’s architecture? Require a specific scenario, the cost of preserving the option, and an implementation trigger. Distinguish a foundation that avoids rebuilding from a feature sold on hypothetical future demand.
6. What becomes the bottleneck as use expands? Test operational adoption as well as technical throughput: user effort, exception volumes, approval capacity and the supply of people able to maintain the service.

A strong answer names trade-offs and provides evidence. “Our platform is more advanced” is a description of the product, not an answer about your organisation.

Buy the operating outcome

Vendors often optimise the thing they sell. Managers need to optimise the system they actually operate.

That does not require assuming bad faith. A model provider, software vendor, integrator and specialist consultant naturally see different parts of the problem. None automatically owns the consequences across your whole organisation.

Before approving the next elaborate proposal, define the job, the mandatory performance and governance thresholds, and the credible failure conditions. Then compare architectures that meet those requirements over their working life, rather than awarding points for features in isolation.

Do not confuse the smallest build with the strongest design. Do not confuse an impressive build with one that will remain operable, affordable and replaceable.

Requisite design is not minimalist design. It is resolved design.