What Doesn’t Kill You Makes You Stronger

How two unexpected AI disruptions led to a more resilient approach to building business capability

AI is increasingly moving beyond experimentation and becoming part of the way businesses analyse information, support decisions and manage day-to-day operations.

That creates significant opportunities. AI can process volumes of information that would be impractical for people to review manually, identify patterns across disconnected data, retain context from earlier analysis and help management recognise emerging issues sooner.

But as AI becomes more capable—and more deeply integrated into business processes—a different management question emerges:

Which capabilities should a business own and control, and which is it prepared to depend upon an external AI provider to deliver?

For us, that question did not begin as a theoretical discussion about technology risk. It emerged through two practical experiences while developing AI-enabled management tools.

In the first, the AI service remained available but changed the way it interpreted information.

In the second, the AI capability continued to exist but access to it disappeared without warning.

Neither experience resulted in data loss or operational failure. Both, however, changed the way we thought about designing AI-enabled business capability.

The result was not to use less AI.

It was to use AI differently.

Experience one: when the service remained but its behaviour changed

Our first experience arose during the development of an AI-enabled email-reading capability for a growing export manufacturer.

The company generated large volumes of operational email across customers, merchandising, procurement, planning, production, quality and logistics. Important information existed within those communications, but management could not practically read and connect thousands of individual messages.

AI created an opportunity to turn that fragmented information into management insight.The objective was not simply to search emails or summarise individual conversations. We wanted the AI to interpret communication across the business, connect related issues and identify patterns that might otherwise remain hidden.

e.g.Were internal teams repeatedly chasing the same information? Were operational issues being resolved—or merely discussed and deferred? Did apparently isolated problems reveal a wider weakness in process, accountability or management control?

The capability was initially developed as an analytical tool, with people remaining actively involved in reviewing and challenging the findings.

Over approximately three weeks, we developed and tested detailed rules to guide how the AI interpreted the source material. These rules addressed issues such as ambiguity, inference, incomplete information and the distinction between an observed fact and a conclusion drawn from several pieces of evidence.

The results were valuable.

AI was able to analyse a volume of communication far beyond normal human capacity and identify patterns that helped management understand the business from several perspectives.

Then OpenAI upgraded the model.

The service remained available. The source data had not changed. The rules we had developed were still available.

But the model’s reasoning capability had changed.

In some areas, the new model was more capable. It could make stronger connections and draw more sophisticated inferences from the information it reviewed. However, it also approached ambiguity differently. Rules that had produced reliable results under the previous model did not always produce the same interpretation after the upgrade.

The improvement in capability therefore created an unexpected consequence: the system needed to be retested.

A further week was spent reviewing the existing rules, examining how the upgraded model interpreted the source material and introducing additional controls to maintain the distinction between evidence, inference and unsupported assumption.

The experience did not make the capability less useful. In many respects, the upgraded model increased its potential value.

But it highlighted an important difference between conventional software and AI.

With traditional software, an organisation will often decide whether and when to install an upgrade. The existing version can continue operating until the organisation has tested the new version and is comfortable adopting it.

With a cloud-based AI service, the provider may change the underlying model. The service remains available, but its behaviour can evolve.

For an analytical tool operating with people actively reviewing the output, that risk was manageable.

For a management tool expected to produce reliable daily information without extensive human review, it required greater caution.

We therefore decided to retain the email-reading capability as an analytical tool and defer routine operational deployment until its behaviour was sufficiently stable and the controls had been tested further.

The project had still produced valuable insights and continues to do so – as an analytical tool..

The experience changed our understanding of AI dependency. Normal business continuity is to consider mitigation in the case the service is not available. This was a new twist.The service might remain available—and improve—while changing in ways that affected a business process built around its previous behaviour.

Experience two: access to AI  disappeared

The second experience arose during work on a production-planning tool for the same manufacturing environment.

The company used a large Excel workbook to manage customer orders, production lines, capacity and delivery schedules. A newly appointed general manager wanted the existing production plan to provide more of the planning functionality and management information she had used in a previous company.

The underlying business data already existed in the workbook. The opportunity was to build additional planning, reporting and analytical capability around it.

During the early development work, we tested routines using Fable 5, an AI model from Anthropic, to interpret production information and generate daily activity reports and management insights.

The potential was significant.

Fable 5 could help management examine changes in production schedules, identify emerging capacity constraints, highlight unusual movements and connect operational signals that might otherwise remain hidden within a large spreadsheet.

Then, without warning, Anthropic, under instruction of the US Government,  withdrew access to Fable 5. The reason mattered less than the management implication.

A business could build a valuable operating capability around an AI service and still lose access because of circumstances outside its control—and potentially outside the provider’s direct control.

Future interruptions might arise from provider decisions, domestic regulation, regulation within the provider’s home jurisdiction, restrictions on cross-border technology services, infrastructure failures or disruption to international connectivity.

These were not reasons to abandon the project.

They were reasons to reconsider where AI should sit within the business architecture.

Rethinking the design

The original concept had placed AI relatively close to the daily operation of the production-planning process.

The two experiences suggested a more resilient approach.

The essential planning capability should remain within a system the client owned and controlled. AI could then sit above that operational foundation as an additional intelligence layer.

This led to a two-stage design.

The first stage was to strengthen the existing Excel production-planning workbook.

AI was used extensively during development to write, test and help refine approximately 1,500 lines of VBA code. The code provided the planning engine, controlled data inputs and outputs, and generated the routine reports required for day-to-day management.

Once developed and tested, however, the operational capability sat inside the client’s own spreadsheet.

The company owned the workbook.

It controlled the source data.

The planning routines could continue operating without a live connection to an AI provider.

If an external AI model changed, became temporarily unavailable or could no longer be accessed, the factory could still maintain its production plan and generate the routine management information needed to operate the business.

AI had helped build the capability without becoming a necessary dependency for its daily operation.

The second stage retained AI where its distinctive strengths added the greatest value.

The reports generated by the planning system could be analysed by AI to identify patterns, relationships and faint signals that might indicate future problems.

A small movement in one part of the plan might not be significant by itself. But when connected with repeated schedule changes, material delays, capacity pressure, quality issues or earlier operating patterns, it could become an early warning.

In this architecture, the spreadsheet provided the resilient operational foundation.AI provided an additional layer of interpretation, challenge and continuous learning.The business did not need to choose between control and intelligence.

It could retain control of the critical operating capability while continuing to benefit from AI where its analytical strengths were most valuable.

A new management asset: context memory

The work also revealed a less obvious issue.

As AI is used repeatedly within a business, it can accumulate context.

It begins to understand the language used by the organisation, the relationships between functions, the meaning of recurring issues, the assumptions behind earlier decisions and the history of how problems have developed.

That accumulated context can improve the quality of future analysis.

An isolated event may appear unimportant. The same event viewed against months of operating history may reveal a pattern. A small change in production planning may become more meaningful when connected with earlier material delays, customer concerns or capacity constraints.

The value can compound over time.

In traditional organisations, much of this knowledge existed in people’s experience. It was often described as institutional or tribal knowledge.

Experienced managers understood why a process worked in a particular way. They remembered earlier problems. They recognised recurring behaviours. They could interpret a new event in the context of what had happened before.

That knowledge was valuable but vulnerable. It could be lost when people left the organisation.

AI introduces the possibility of creating a new form of organisational memory—one developed through repeated analysis, interaction and accumulated business context.

That creates value.

It also creates a management question:

Who owns and controls the intelligence being created over time?

The source data may belong to the business. But the value created through accumulated context may extend beyond the original documents and transactions. It may include relationships, interpretations, organisational history and knowledge developed through repeated interaction with the AI.

If that context exists only within one provider’s environment, changing providers may involve losing more than access to a technology platform.

The business may lose part of the intelligence it has helped create.

This does not mean every AI interaction must be retained internally or that organisations should avoid external models. It means context memory should increasingly be considered alongside data, systems and intellectual property when businesses assess AI risk and continuity.

Where practical, important instructions, decision rules, analytical frameworks and business knowledge should be retained in forms the organisation can access and reuse.

The objective is not complete independence from external technology.

It is to avoid unnecessary dependence on knowledge that the organisation cannot recover or transfer.

What the two experiences changed

Neither experience was a failure.

The OpenAI model upgrade improved capability but required previously tested rules to be reviewed and adapted.

The withdrawal of access to Anthropic’s Fable 5 demonstrated that a valuable AI capability could continue to exist while access to it disappeared because of an external regulatory decision.

Together, the experiences led to a stronger design approach

The essential operational capability was placed in a client-owned and client-controlled environment.

AI was used extensively to accelerate development and remained available as an intelligence layer capable of analysing patterns, identifying weak signals and supporting management decisions.

The result was more resilient than the original concept.

The client retained control of the data, the planning engine and the routine management information required to operate the business.

AI continued to add value without becoming a single point of operational failure.

Management lesson

The lesson is not that businesses should reduce their use of AI.

The opportunity is too significant.

AI can expand analytical capacity, accelerate development, connect fragmented information, challenge assumptions and help management identify emerging risks earlier.

But as AI moves from experimentation into business operations, management needs to distinguish between using AI to build capability and making the business dependent upon AI to operate that capability.

The stronger architecture is often to build resilient operational capability first, retaining control of the essential data, processes and routines the business needs to function.

AI can then sit above that foundation as an intelligence layer—learning from information over time, identifying patterns and faint signals, and helping management make better-informed decisions.

Both experiences improved the final design.

What did not kill the project made the architecture stronger.