What Happens When All Your AI Agents Call in Sick?

Imagine arriving at work on Monday morning to discover that several key employees have called in sick.

Your analyst is unavailable. Your developer is unavailable. The person preparing reports is unavailable. Customer support is short-staffed. And the person who knows how several automated workflows operate is not answering their phone either.

Most established businesses plan for staff absences, IT outages, internet failures, cyber incidents and supplier disruption. But what happens when those “employees” are AI agents?

That is becoming a real AI business continuity question. Recent Claude reliability incidents are a useful reminder that even powerful AI platforms are external services, and external services can fail, change or become unavailable.

For businesses adopting AI, the question is no longer only, “How can we use AI?” We also need to ask: “What happens when the AI is not there?”

Your newest employee might not be an employee

The way organisations use AI has changed remarkably quickly. A couple of years ago, an employee might occasionally open an AI tool to rewrite an email. Today, AI is becoming embedded in business processes.

An organisation might have AI:

• reviewing contracts and documents;
• analysing customer enquiries and business data;
• writing software;
• preparing reports and quotations;
• summarising meetings and conducting research; or
• triggering automated workflows.

Increasingly, these are not simply AI “tools”. They are AI agents performing defined business functions. If five agents support five different functions and the underlying service becomes unavailable, that is not necessarily comparable to Microsoft Word being temporarily unavailable. It may be more like five employees calling in sick at exactly the same time, except none of them can tell you when they are coming back.

What Anthropic’s reliability incidents show

It is important not to turn a reliability discussion into unsupported outage theatre. Anthropic’s own reporting provides enough evidence without exaggeration.

On 23 April 2026, Anthropic published a postmortem on three Claude Code quality issues. The company said changes introduced on 4 March, 26 March and 16 April affected Claude Code, the Claude Agent SDK or Claude Cowork in different ways. The issues included a lower default reasoning setting, a bug that made resumed sessions appear forgetful and repetitive, and a prompt change that reduced coding quality. Anthropic said all three had been resolved by 20 April in version 2.1.116.

That followed a 17 September 2025 postmortem covering three overlapping infrastructure bugs introduced between 5 and 26 August 2025. Anthropic reported misrouting, output corruption and a compiler-related issue that produced intermittent quality degradation across different models, with only the routing issue reaching third-party platforms.

These were not identical failures, and not every customer was affected. That is precisely the continuity lesson: an external AI dependency can fail partially, intermittently or in a way that is difficult for users to diagnose. A green screen is not the only test of availability; a service that responds but cannot reliably perform its assigned function can still disrupt a process.

For live availability, Anthropic’s official incident history remains the authoritative source. This article uses the documented incidents as a business-continuity example, not as a claim that Claude is currently unavailable.

Using AI creates productivity benefits. Depending on AI creates business risk.

Neither is necessarily a problem. The problem arises when the dependency has not been identified.

The quiet rise of AI concentration risk

Businesses already ask what happens if Microsoft 365 is unavailable, cloud hosting fails, a critical supplier cannot deliver or a key employee leaves. AI now belongs in that conversation.

The risk becomes particularly important where several AI-enabled processes depend on the same underlying provider, model or infrastructure. You may believe you have ten different AI agents. Operationally, you may have ten business processes dependent on one external supplier.

That is concentration risk. It is also why an AI policy should not be built around one vendor. Your governance should describe approved capabilities, risks and controls so it remains useful when products or suppliers change.

So, what is your AI business continuity plan?

This does not mean businesses should stop implementing AI. Good management is not about avoiding opportunity because risk exists. It is about understanding the risk and putting proportionate controls around it.

A sensible starting point is identifying where AI has become part of normal operations:

1. Which business processes use AI? Look beyond formal projects. Employees may already use AI extensively without management appreciating how dependent an activity has become.
2. Which processes rely on AI to operate? There is a difference between AI making a task faster and AI becoming essential to completing it.
3. Which provider does each process depend on? Look underneath the application. Several tools may ultimately rely on the same model or infrastructure.
4. What happens if the service disappears for an hour, a day or several days? Does productivity decline, does the process stop, or are customers, security obligations or contracts affected?
5. Is there a workable fallback? Could the task be completed manually, queued safely, or moved to an approved alternative provider?
6. Do people know and test the fallback? A continuity plan nobody understands is not much of a continuity plan.

The same discipline applies to communications and infrastructure. Our earlier article on what happens when your failover fails makes the broader point: two apparent options are not resilient if they share the same point of failure.

Do not forget the information

Availability of the AI service is only one consideration. Businesses should understand what information is stored within, or processed by, AI platforms.

Consider what happens if employees suddenly lose access to conversation histories, research, prompts, generated code, uploaded documents, agent configurations or knowledge stored within an AI workspace. If important organisational knowledge exists only inside an AI service, the disruption may affect both the tool and the information needed to continue manually.

This is related to the SaaS backup gap: using a cloud service does not automatically answer how business-critical information will remain accessible during disruption.

Where ISO 27001 fits

ISO/IEC 27001 information security management systems are based on identifying information-security risks and establishing appropriate controls. Availability is one of information security’s core principles.

For organisations dependent on AI platforms, the information security management system should consider AI services alongside other critical technology and supplier dependencies. Relevant areas may include:

• information-security risk assessment;
• supplier and cloud-service dependencies;
• availability requirements and incident management;
• information backup and accessibility;
• ICT readiness for business continuity;
• contractual requirements; and
• alternative operating arrangements.

The objective is not another pile of documents labelled “AI”. It is to identify the dependency and manage it within the organisation’s existing risk framework. If you are unsure where the gap sits, an ISO gap analysis audit can test the system before a certification audit does.

And then there is ISO 42001

ISO/IEC 42001 AI management systems take the conversation further. As organisations move from occasional generative-AI use to deliberate implementation of agents, governance becomes increasingly important.

An AI management system provides a structure for identifying AI systems, assessing risks and impacts, assigning responsibilities and monitoring ongoing performance. Business continuity is a good example of why that matters. It is easy to ask whether an AI system works in normal conditions. Good governance also asks what happens when it does not.

This is where ISO 42001 and ISO 27001 work particularly well together. ISO 42001 governs the organisation’s use of AI; ISO 27001 protects the confidentiality, integrity and availability of the supporting information and technology.

Try the “everyone called in sick” test

Make a list of every significant AI tool or agent used across the organisation. Then imagine that tomorrow morning every one of them calls in sick.

No ChatGPT. No Claude. No Copilot. No Gemini. No AI agents. Assume they are unavailable for the working day.

Now ask each process owner: Can we still operate?

For some activities, the answer will be an easy yes. For others, productivity will fall but work can continue. Occasionally, you may discover, “Actually, we cannot do that without the AI anymore.”

That is useful information. You have identified a business continuity risk.

A backup is not a backup until it works

Having accounts with several AI providers does not automatically create resilience. If nobody has tested the alternative, staff are not authorised to use it, prompts and instructions are unavailable, integrations only support the primary provider or information cannot be transferred safely, the supposed backup may not work.

For business-critical AI processes, periodically test the alternative. If Claude disappeared tomorrow, could the process move to another approved platform? If neither platform were available, is there a manual method? How long could the organisation reasonably operate that way?

Availability is only one dimension of agent risk. Before deployment, also ask four questions about what an AI agent can read, do and affect.

AI is becoming business infrastructure

The biggest lesson is not about Claude specifically. Every major technology provider will experience interruptions, defects and changes from time to time. The bigger change is happening inside organisations: AI is moving from an interesting productivity tool to part of the infrastructure businesses use to operate.

Management systems need to evolve with it. Organisations do not need enormous governance frameworks simply because employees use AI. But as AI becomes embedded in critical processes, leaders should understand where it is used, what the business depends on, what could go wrong and what happens next.

Because one morning you may arrive at work and discover that all your newest employees have called in sick.

Need help managing AI dependency risk?

Streamline ISO Consultants helps organisations build practical management systems that integrate risk management into normal operations instead of creating unnecessary administration.

If your organisation is implementing AI, we can help assess how ISO/IEC 42001 and ISO/IEC 27001 can provide a practical framework for AI governance, information security and organisational resilience.

The goal is not to slow AI adoption down. It is to make sure your management systems can keep up.

Email hello@streamline.business or call us:

• Brisbane 07 3667 8280
• Sydney 02 8315 7780
• Melbourne 03 9034 3990