How An Email System Drafts And Completes Work Overnight Without The Cloud

An email system can draft and complete work overnight without touching the cloud when the agent doing the work runs entirely on hardware the organisation owns, reads mail through a zero-egress inbound perimeter, and writes every action into a signed local ledger. The mail never leaves the building because no outbound connection to a public model is ever opened. Mickai is a Sovereign Intelligence Operating System, a SIOS, that runs offline on operator-owned hardware and seals each action cryptographically, so overnight drafting is a local computation rather than a call to someone else's server.

This matters in 2026 because the default inbox assistant is a cloud copilot. A public cloud model can be capable, but it sends the content of the mail to a third party to be processed. For a bank, a hospital, a law firm or a defence supplier, that transfer is the whole problem. Regulation now treats where data is processed as a first-order question, and an agent that acts on mail overnight has to answer it before it reads a single message.

How does an offline email agent actually work?

The agent lives beside the mail server, not in a data centre you rent. It reads new messages through a local connector on the internal network. The sovereign models that draft replies, summarise threads and prepare actions run on the organisation's own GPUs and CPUs. Nothing is posted to an external endpoint.

• The mail server and the agent sit inside the same owned perimeter.
• A zero-egress inbound perimeter lets the machine receive mail but gives message content no route out to a public model.
• Every model runs locally, so drafting is bounded by owned hardware, not by an external quota.

How does it draft overnight without an outbound connection?

Overnight, the agent works a queue. It triages the inbox, groups threads by sender and subject, drafts replies, extracts tasks and prepares documents. Each draft is saved locally as a draft, not sent. A person approves sending in the morning. Because the models are local, the building can be air-gapped and the work still completes.

What can an auditor check the morning after?

Every action the agent takes is written to an append-only ledger. Each entry records what was read, what was drafted, which model produced it and when. The ledger is signed with post-quantum digital signatures under FIPS 204 (ML-DSA), with FIPS 205 (SLH-DSA) available as a second scheme, so a signature made today stays verifiable against a future quantum adversary. The identity that signs is bound to the physical machine through hardware attestation, so an entry cannot be forged on another box and slipped into the chain. An auditor can verify the whole ledger offline, with no call to us and no call to any vendor. The test is simple: can you verify last night's work with the network cable pulled out.

“When the model runs on hardware you own, an inbox assistant becomes a local computation you can audit, not a data transfer you have to trust.”

Which rules make an on-premise agent necessary?

The rules are converging on the same requirement: know where processing happens and be able to prove it. DORA has been in force since January 2025 and holds financial entities responsible for the resilience of their information and communication technology, including third parties. NIS2 extends security and reporting duties to essential and important entities across many sectors. GDPR still governs where and how personal data is processed. The US CLOUD Act means data held by a US provider can be compelled regardless of where the server sits, which is precisely why a European regulated buyer may not be able to use a US cloud model at all. The EU AI Act adds obligations for high-risk systems: the Annex III obligations once due on 2 August 2026 were deferred by the Digital Omnibus to 2 December 2027, with embedded Annex I high-risk moving to 2 August 2028 and the Article 50 transparency duties largely unchanged. We read that as a build window, not a reprieve. ISO/IEC 42001 gives a management-system standard for the AI itself. An agent that never sends mail to the cloud satisfies the hardest part of all of these by construction.

How does this compare to a cloud inbox copilot?

A cloud copilot and a sovereign agent can produce a similar draft. The difference is architectural. The copilot sends the message content to a third-party model and trusts a contract to govern what happens next. The sovereign agent keeps the content on the owner's hardware and proves what happened with a signed ledger. One asks you to trust a policy. The other lets you verify a fact. For most inboxes the copilot is fine. For a regulated inbox, verification beats trust.

What stops the agent from acting beyond its remit?

Two controls keep the agent inside its remit. First, it drafts but does not send: outbound mail waits for a person to approve it, so nothing leaves on the agent's own authority. Second, high-stakes drafts can be checked by cross-model consensus, where more than one local model has to agree before a draft is proposed, which reduces the chance a single model's error reaches a recipient. The agent can read and prepare all night, and it acts outward only when a person signs off. The architecture described here, from the zero-egress perimeter to the post-quantum signed ledger, sits within 104 filed UK patent applications and approximately 2,340 claims owned by Mickai LTD, all patent pending and none granted.

Frequently asked questions

Can an email agent really run without any internet connection?

Yes. When the models run on the organisation's own GPUs and CPUs, the agent needs no outbound connection to draft, triage and prepare work. It can operate on an air-gapped network. The only step that involves the outside world is sending, which stays behind a human approval gate in the morning.

Where are the emails processed if not in the cloud?

On hardware the organisation owns, beside the mail server, inside its own network perimeter. The content of each message is never posted to a public cloud model. This is what lets a bank, a hospital or a defence supplier use an agent on data that regulation will not allow to leave the building.

Is an on-premise email agent compliant with the EU AI Act?

An on-premise agent addresses the hardest requirement of the AI Act by keeping processing local and verifiable. The high-risk Annex III obligations once due on 2 August 2026 were deferred by the Digital Omnibus to 2 December 2027, with embedded high-risk under Annex I moving to 2 August 2028 and the Article 50 transparency duties largely unchanged. We treat that timeline as a window to build the controls now rather than a reason to delay.

How do you prove to an auditor that no email left the building?

Pull the network cable and verify last night's ledger offline. Every action is written to an append-only log signed under FIPS 204, the primary post-quantum signature standard, and bound to the physical machine by hardware attestation. If the ledger verifies with no network present, the work never needed the network, and nothing was sent.

What is the difference between this and a cloud inbox copilot?

A cloud copilot sends message content to a third-party model and relies on a contract to govern it. A sovereign agent keeps the content on hardware you own and proves each action with a signed ledger you can check yourself. For an ordinary inbox the copilot is convenient. For a regulated inbox, the ability to verify what happened matters more than the convenience of the cloud.