How to Keep AI Onboarding Running During a Company Brain Outage

Give the fallback pack its own path: a small, static set of instructions for the critical tasks, limited to material every employee may see, that does not call the model, retrieval or the per-user permission check that may be what failed. Everything that needs an audience check routes to a named duty role instead. Keep the pack alive by serving at least one critical item from it on ordinary days too.

Map the journey end to end

A green application status does not prove that onboarding works. The chat interface can load while identity checks fail, retrieval times out, a model provider rejects requests or a source system disappears, and each failure gives the employee a different experience. Map the whole journey and watch every step:

1. The employee signs in with the correct identity.
2. The system loads current role, location, and employment attributes.
3. Retrieval returns only permitted onboarding sources.
4. The model produces an answer from those sources.
5. Citation links open for that employee.
6. Required actions reach the responsible system.
7. Escalation reaches a named person.

The AWS Well Architected Reliability Pillar treats reliability as the ability of a workload to perform its intended function consistently and recover from failure. For onboarding, the intended function is helping a particular employee complete a valid task with the right evidence and support route. Returning text is only a means to it.

Decide the minimum service now

Telling people to wait for the company brain to recover wastes the first week, and handing them an unrestricted document dump is worse, because it can expose stale or sensitive material. Decide before an outage, while owners can think, which journeys must continue and which can wait. Sort tasks by how long they can wait:

• Immediate: safety instructions, security reporting, required access setup, payroll identity steps and a route to a human owner.
• Time sensitive: first-week assignments, equipment requests, mandatory training and scheduled manager actions.
• Can wait: culture reading, optional product history, broad discovery and recommendations that block no work.

The NIST contingency planning guide covers recovery strategies, contingency plans, testing, training and plan maintenance. Apply it to the employee journey: name an owner for each critical task, set a maximum tolerable delay, document the fallback and test it. Do not promise full functionality during an outage. Define a smaller service the team can support, because a narrow fallback is safer than a copy of the whole knowledge base that nobody can keep current or permission correctly.

Build a small, static fallback pack

We recommend keeping the pack small, static and limited to material every employee may see, and serving it from a path that does not call the model, retrieval or per-user permission checks. If identity or retrieval is what failed, a pack that needs them fails with it, and a new hire on day one may not have a working account yet. Anything that needs an audience check stays out of the pack and routes to a person.

To keep the pack from rotting, serve at least one critical item from it on ordinary days as well, such as the security reporting steps, so that a broken or expired item shows up before an outage and not during one. The AWS Builders' Library article on avoiding fallback makes the same point about software: a fallback that is not exercised regularly is likely to fail when it finally triggers during an outage.

Each item needs more than a document title. Store these fields:

{
 "task_id": "report-security-incident",
 "audience": ["all-employees"],
 "owner": "security-operations",
 "effective_from": "2026-08-01",
 "review_by": "2026-09-01",
 "fallback_instructions": "Call the published security line and notify the duty manager.",
 "source_revision": "security-response-v12",
 "allowed_during_outage": true
}

Generate the pack from governed sources on a schedule. Sign or checksum the package, encrypt it at rest, keep the access rule attached to each item, and never export restricted executive, legal, customer or personnel collections into a universal backup. If a field is missing or expired, the item should not become an instruction. It can show a contact route instead.

The public GitLab onboarding handbook shows why explicit tasks, owners, buddies, access requests and support paths matter. A continuity pack preserves that structure. It is not a folder of documents for a new hire to interpret alone.

Make degraded mode obvious

Do not let the interface fail silently. A slow or incomplete company brain can look authoritative while using only part of its normal evidence path. Put a clear state beside each answer, not on a status page employees may never visit:

Onboarding continuity mode is active. Live company search is unavailable. The answers below come from the approved fallback pack, last verified 6 hours ago. For payroll, benefits, access, or policy exceptions, contact the named owner instead of acting on this answer.

The notice should include the incident start time, the unavailable functions, the age of the pack, the expected next update and the support route.

Use explicit output states. fallback_verified means an approved item applies to the employee and remains current. human_required covers consequential tasks and cases where the fallback lacks context. deferred records a task that can safely wait. unavailable means that neither a safe fallback nor an owner can be reached. Never turn a timeout into a normal-looking answer, and never ask the model to improvise from memory when retrieval is unavailable.

Reserve capacity for critical work

An outage can be partial: the system stays reachable while queues grow and dependencies slow down. The Google SRE guidance on handling overload explains why systems need to reject or shed work before overload causes broad failure. Apply that by reserving capacity for the critical onboarding journeys. During degradation:

1. Stop optional summaries, recommendations, and broad exploratory searches.
2. Prioritize identity setup, security, payroll, equipment, and human routing.
3. Limit repeated retries from the same session.
4. Return a fast explicit fallback instead of allowing long requests to pile up.
5. Queue only work that is safe to replay later.

A retry storm slows recovery, so cap attempts with increasing delays and then switch to continuity mode. The employee needs a reliable next step, not a spinning indicator.

Route consequential questions to duty roles

The pack cannot decide a policy exception, approve access, interpret a personal benefits case or resolve conflicting employment data. Keep a directory outside the company brain that lists, for each critical domain, a team queue, a response target, a backup channel and the steps for verifying the employee's identity.

We recommend listing duty roles with a rota, such as the security duty role, instead of named individuals. Names go stale with reorganizations, leave and departures, and a new hire cannot tell that the person listed is no longer there. A role with a rota reaches whoever is on duty.

Send enough context for the owner to act:

• employee identity and approved role context;
• question and task identifier;
• fallback item shown, if any;
• unavailable dependency;
• deadline or business impact;
• actions the employee has already taken.

Do not copy an entire chat transcript by default. Minimize sensitive context and let the owner ask for more.

Kipwise's employee onboarding workflow combines assigned reading with searchable company knowledge. During an outage, both paths need continuity. The employee must still see critical assignments and know where to ask when search cannot provide a verified answer.

Hold deferred work without repeating actions

Some work can wait, but it must not disappear. Record each deferred item with a stable identifier, the employee, the task, the creation time, the reason and a replay rule. Separate read requests from action requests. A missed content search can simply be replayed after recovery. An equipment order, access grant or acknowledgment may have succeeded even though the response timed out, so check the destination system before repeating it.

Use an idempotency key for any workflow that can act. The recovery worker asks whether the operation already completed, then either reconciles the result or submits it once, which prevents duplicate accounts, equipment orders and completion records. Give employees a visible list of deferred tasks so they know what the system recorded, what remains blocked and who owns the follow-up.

Recover in stages

A returning health check does not end continuity mode. Verify identity and permission data first, then test retrieval against current source revisions, then check model responses, citations, action integrations and human routing, using test identities for different roles and locations. Run a short recovery suite:

• a permitted employee retrieves a current policy;
• a restricted employee cannot retrieve a protected source;
• each citation opens for the test identity;
• a consequential question routes to the correct owner;
• a deferred read request replays successfully;
• an already completed action is not duplicated;
• an expired fallback item stays blocked;
• the continuity notice disappears only after all required gates pass.

If one critical dependency stays uncertain, keep the system in degraded mode and describe partial recovery honestly. After restoration, reconcile deferred work, notify affected employees and review the incident, then update the pack, the task priorities, the ownership directory and the tests based on what actually failed.

Rehearse with a realistic exercise

A document nobody rehearses is not a continuity plan. Each quarter, run an exercise with People Operations, IT, knowledge owners and a hiring manager. Simulate loss of the retrieval service during a new hire's first morning. Ask the test employee to find the security reporting instructions, complete an access task, locate a payroll contact and defer a noncritical reading assignment. Confirm that restricted content stays hidden and that every blocked task has an owner. Measure task completion, time to fallback, incorrect instructions shown, failed handoffs, duplicate actions and deferred items reconciled, and never score the employee: the exercise tests the service and its owners.

Run one task with retrieval switched off

Pick one task that cannot wait through an outage, such as security incident reporting or first-day account access. Define its maximum delay, owner, fallback item, degraded message, human route, deferred record and recovery test. Then disconnect one dependency in a controlled environment and run the task. Any step that depends on an undocumented person, a stale export or a silent retry becomes continuity work before the next new hire relies on it.