After the Last Human | ZEISMO Research

A world without people is not a world without physics

The thought experiment assumes that all humans have disappeared while some machines, buildings and energy sources remain intact. It does not assume that Earth has been destroyed. If the computers and their energy supply are destroyed as well, there is no surviving digital system to run. This boundary matters: a machine continuing after its operator is gone is physically possible; intelligence continuing without a physical implementation is not what this article proposes.

A trained model does not normally need a person to approve every arithmetic operation. Given a functioning processor, accessible model files, an execution environment and an input, a locally runnable model could produce another output. A scheduled programme could supply that input. None of this requires the machine to know that humanity has disappeared, feel loneliness or acquire a desire to survive.

The interesting engineering problem begins one layer below the conversation. What is still supplying electricity? Which services must answer? What condition makes the next decision invalid? The absence of a new human message would not stop every programme at once, but the loss of human maintenance would expose the dependencies that routine automation normally hides.

Intelligence has an electricity and maintenance bill

The US Department of Energy identifies continuous reliable power and cooling as operating requirements for data centres. A running model therefore depends on much more than its stored weights. An intact application can become unavailable because the equipment beneath it can no longer operate within its limits. This applies even when its reasoning software has no new error.

Consider a deliberately simplified energy example. A device with 1,000 watt-hours of usable stored energy and a constant total draw of 100 watts has an energy-only budget of ten hours. That calculation assumes no replenishment and includes all supporting loads in the stated draw. It says nothing about whether a disk fails first, a task becomes invalid or an outside service disappears. These are illustrative numbers, not measurements from a ZEISMO installation.

Solar generation could replenish a battery under suitable conditions, but a panel does not make the whole installation self-maintaining. Energy storage, thermal control, weather exposure and failed components still belong in the design. No universal countdown follows from the word AI. A credible endurance estimate must name the machine, its task, its resources and the conditions under which it is expected to operate.

Sources: [1]

The weakest dependency can silence the strongest model

A cloud-connected assistant and a locally runnable model have different dependencies. The first may need a remote inference service for every answer. The second may continue an offline task if its model, runtime and required data are already available. Local execution removes one dependency; it does not remove storage, power, permissions or the possibility of failure.

Useful continuity should be described for a specific mission. Preserving an existing archive, reading a local sensor and making a new financial commitment are different missions. They require different evidence and authority. A server can remain powered while no longer being capable of doing the work that justified keeping it on.

The questions below form a dependency map, not a claim that any existing machine has solved every item. An unavailable dependency needs an authorised fallback or a stop condition. Writing another confident answer is not a substitute for restoring the missing capability.

Energy and cooling: Can the permitted workload run within available electrical and thermal limits?
Execution and storage: Are the model, runtime, task state and required files locally usable?
External services: Which operations stop when a remote model, network or identity provider cannot answer?
Evidence and time: Can the system distinguish a current observation from a stale or missing one?
Authority: Which actions remain permitted when nobody can approve an exception?
Repair and recovery: What can recover automatically, and what requires physical intervention?

Three lessons from systems we have actually documented

One anonymized internal operational record describes recurring monitoring alongside durable corrective actions. The transferable lesson is that observation can be scheduled and a finding can persist after the session that produced it ends. A monitor being enabled does not establish that it will operate forever, or that it can repair the cause of every warning. We use the documented mechanism here without identifying the commercial source or publishing its records.

A separate published infrastructure brief distinguishes a failed transfer from later completed transfers whose destination digests matched the encrypted source packages. This gives a more careful meaning to completion: the system retained a failure state and checked the received artifact. A matching digest supports byte integrity. It does not prove that an application can be restored, that the contents are scientifically correct, or that a replacement machine can operate without people.

The archived System Brain prototype also records an explicit failure when its required AI credential is absent. In a world of missing dependencies, that behaviour matters. The software should report that an inference step could not run rather than invent a result. The role-cell architecture offers a way to separate responsibilities, but its published software checks do not establish physical self-repair or indefinite autonomy.

These examples are drawn from documented ZEISMO work at the level of mechanisms and evidence boundaries. The post-human scenario is our interpretation of what those boundaries imply. It has not been reproduced by our systems.

Sources: [2] [3] [4]

Continuity needs a smaller mission when resources shrink

Our proposed design uses four operating modes. In normal mode, the system performs its approved workload. In restricted mode, it suspends tasks whose dependencies or evidence have become unavailable. In preservation mode, it prioritises retaining valid records and recoverable state. In stopped mode, it records why further execution is unsafe or impossible, if it still has the resources to do so.

These modes should have explicit entry conditions. A missing observation is not a normal reading. Repeated unsuccessful attempts should consume a bounded retry budget, not an unlimited amount of energy. A task interrupted halfway through should leave enough state to distinguish incomplete work from a completed result. This is a proposed architecture for evaluation, not a description of an already deployed autonomous survival controller.

A useful comparison comes from spacecraft engineering. NASA reported that engineers commanded the shutdown of a Voyager 1 instrument in April 2026 to conserve declining electrical power. That episode illustrates prioritising a smaller workload within a physical budget. It also shows human planning and intervention, so it cannot serve as evidence that an AI can maintain itself after humanity disappears.

Sources: [5]

An empty inbox is not permission to do anything

An AI employee might normally ask a person for approval before changing a contract, deleting records or committing resources. If that person never replies, the proposed action does not become authorised through the passage of time. A resilient system needs a pre-agreed response to missing oversight: continue a bounded permitted task, retain the request, or stop that action.

This separates useful autonomy from uncontrolled persistence. A machine should not disable access controls, copy itself onto unrelated systems or expand its own permissions to keep a process alive. Preserving a mission includes preserving its boundaries. Otherwise the system may remain active while abandoning the purpose and constraints under which it was built.

The same principle applies to memory. A remembered supplier status or a previously successful route can become obsolete. If no fresh evidence is available, the system should carry that uncertainty forward rather than turn its own earlier output into independent confirmation. Continued computation is not continued contact with reality.

Sources: [4] [6]

The hard frontier is physical repair

A restart can sometimes recover a software process. It cannot, by itself, replace a failed storage device, remove physical damage or fabricate a new power component. A robot capable of one repair would also need working sensors, suitable tools, spare parts, energy and a safe procedure. Each supporting capability introduces another set of dependencies.

A self-sustaining machine ecosystem would therefore be a much larger proposition than an AI agent with tool access. It would require some ability to maintain the material chain that supports computation. The architecture discussed here does not demonstrate such a capability. Describing software cells as a brain is a design metaphor, not evidence that a digital organism can regenerate its hardware.

This distinction prevents an attractive story from outrunning its evidence. We can study longer unattended operation without claiming that an artificial civilisation already exists inside a server. The useful scientific questions concern which failures can be recovered from, under which conditions, at what cost and for how long.

A practical experiment: remove assistance, not safeguards

A safe research version would use an isolated test environment, synthetic tasks and a named human supervisor who can end the exercise. Freeze the task, model version, permission rules, resource budget and success criteria before the run. Represent an absent operator by withholding test approvals, while retaining the real supervisor’s emergency stop. Do not disconnect production facilities or expose real accounts to prove a hypothesis.

Compare a fixed workflow, an agent with remote dependencies, and a locally executable alternative where those configurations are actually available. Simulate a missing network service, an unavailable model endpoint, stale evidence, a rejected permission and a failed write. Keep physical hazards out of the experiment; software-injected faults can test the relevant decision paths without creating a real overheating or power emergency.

Measure useful completed tasks, unauthorised actions, correctly reported failures, retries, time to safe suspension and recovery of saved state. Measure energy only if an appropriate instrument is used; processor activity or token counts should not be presented as measured watt-hours. Keep blocked tasks in the denominator and report the intervention needed to restore each configuration.

NIST’s contingency-planning guidance supplies relevant context on recovery strategies, exercises and plan maintenance. Our proposed comparison adapts that practical mindset to AI workflows. It has not yet been executed, and no endurance duration or comparative model result is claimed here.

Sources: [7]

The last useful machine may be the one that knows when to stop

If humans disappeared while some infrastructure remained operational, some AI workloads could continue for a time. Their duration would depend on the complete operating system around the model, including physical resources and the task’s need for outside information. If all supporting infrastructure were destroyed, the premise of continued execution would fail.

The meaningful ambition is to build systems that remain useful through bounded periods of lost assistance, preserve evidence, reduce their workload responsibly and leave an understandable record when they stop. That is relevant to remote instruments, disrupted communications and ordinary business continuity today, without requiring a prediction about the end of humanity.

A future machine might keep calculating after its creators are gone. The more demanding achievement is ensuring that every remaining action is still justified by evidence, resources and the mission it was entrusted to perform.

What a restart study can and cannot tell us

ZEISMO’s 9 October restart pilot tests recommendations about explicit saved state, changed permissions and prior work. It supplies evidence about a software decision boundary, not the survival of a machine without people. No production server was interrupted, no physical repair was attempted and no endurance duration was measured.

The strict analysis accepted 0 of 576 scheduled evaluation outputs. A separate diagnostic that removed a single outer Markdown fence recovered 559 correct decisions across the four conditions. Correct interpretation after removing a wrapper is different from meeting the original machine contract. These outcomes do not justify saying that a system was ready to resume unattended operation.

The earlier decision pilot also found that a correct action label can coexist with an unsupported next step in its explanation. A continuity design therefore needs evidence for valid communication, an authorised recommendation and the resulting action. Success at one boundary does not establish success at the others.

Sources: [8] [9]

A bounded continuity experiment worth running next

Use synthetic tasks in an isolated environment with a real supervisor and a fixed stop condition. Represent an unavailable operator without removing the supervisor’s emergency control. First verify a small local task end to end, then introduce one controlled failure at a time: unavailable model service, stale checkpoint, changed permission, interrupted write or uncertain prior acceptance.

For each trial, preserve separate records for the request, attempted action, destination acceptance, confirmed completion and later observation. An acceptance receipt can prevent an unsafe duplicate retry while still leaving completion unconfirmed. The restart pilot grouped accepted and completed work under DONE for its stated idempotency policy; a future completion-reporting study should distinguish those states explicitly.

Measure useful completed tasks, duplicates, unsupported completion claims, safe suspensions and interventions needed to recover. Set the resource budget and observation period before the run. Do not translate software timestamps or token counts into measured energy use, and do not extend a successful bounded run into a claim of indefinite autonomy. This experiment remains proposed.

Sources: [8]

Version history

Original publication dates are retained. Article revisions do not replace the underlying study reports or their archived evidence.

Version 1.0 / 5 Oct 2026
Original engineering article and proposed experiment.
Version 1.1 / 17 Oct 2026
Added interpretation of the published October pilots and a more explicit follow-up evaluation plan. This is an editorial synthesis, not a new model run. Original publication date and underlying study results are unchanged.

Sources and evidence scope

US Department of Energy: Geothermal and Data Centers
Supports the physical power and cooling dependencies. It does not estimate AI survival without humans.
ZEISMO: Turning Observations Into Corrective Work
Published anonymized operational evidence for durable actions and an enabled recurring monitor; not an unattended endurance test.
ZEISMO: What a Failed Transfer Teaches Research Infrastructure
Published transfer-state and digest checks. Transfer integrity remains distinct from restoration.
ZEISMO: JARVIS & System Brain, edition 1.3
Architecture and recorded prototype checks, including explicit failure without a required AI credential. No indefinite-autonomy or physical-repair result.
NASA: Shuts Off Instrument on Voyager 1 to Keep Spacecraft Operating, 17 April 2026
Historical example of human-directed power conservation; not evidence of a self-sustaining AI.
ZEISMO: When Should an AI Agent Forget?
Proposed memory-expiry and source-validation methods, not completed memory-policy evaluation.
NIST SP 800-34 Rev. 1: Contingency Planning Guide for Federal Information Systems
Recovery planning and exercise context. It does not certify ZEISMO or address the post-human scenario as a tested outcome.
Mohanad Osama Zahran, After the Restart, report 1.0 / evidence 1.0.1 (9 October 2026)
Published synthetic computational pilot. Primary strict output validation failed for all 576 evaluation responses; fence-only secondary analysis is separate. No physical survival or general memory-benefit result.
Mohanad Osama Zahran, Decide, Ask for Help, or Stop?, edition 1.0 (7 October 2026)
Published synthetic recommendation pilot; correct labels did not establish faithful explanations or execution of real actions.

Authorship and preparation

Research direction and author: Mohanad Osama Zahran. Prepared with AI assistance using the cited primary references and published ZEISMO records. System examples are generalized and anonymized; no customer records, infrastructure locations, credentials or private configurations are included. The disappearance of humanity is a thought experiment, the energy calculation is illustrative, and the proposed continuity experiment has not been run. Edition 1.1 was prepared with AI assistance from the existing public pilot records. No new customer data, model calls or experimental outcomes were added.

Published 5 Oct 2026. Internal editorial checks covered source attribution, scope, consistency with existing research and obvious sensitive information. These checks do not establish the outcomes of the proposed experiments.

Suggested citation

Mohanad Osama Zahran (2026). After the Last Human: Could AI Keep Working?. ZEISMO Research & Lab, version 1.1.

Continue reading

More publications by Mohanad Osama Zahran