Our first measured setup.

12 September 2026 · One agent-assisted application reinstall. A baseline for improvement, not a speed promise.

58m 16s from installer start to full verification. 1h 09m 34s including teardown and cleanup.

Native Codex MCP sent, read and replied to real email. Gmail receipt was independently confirmed. SPF, DKIM and DMARC passed, and all 11 required setup checks passed.

Where the time went

These are sequential wall-clock intervals between milestones. Each includes the work, troubleshooting and evidence collection happening during that interval. Rounded values can differ slightly when added; native receipt timing has minute-level precision.

Phase	Elapsed interval
Teardown and clean-state verification	8m 06s
Bootstrap, prerequisites and first preflight	4m 01s
Provider configuration, approvals and browser recovery	17m 59s
Service planning and provisioning	3m 09s
DKIM publication	55s
First email receipt after DKIM publication	4s
Network, webmail, DNS repair and direct MCP verification	13m 12s
Native Codex MCP verification	≈4m 44s
Additional checks, diagnostics and DNS retry	≈12m 20s
Final reply verification and supported completion	1m 51s
Completion capture and cleanup	3m 12s

Waits overlapped useful work

Owner approval window: 6m 36s. Two questions were resolved in one response. The shorter firewall approval window was inside the credential approval window. This is not measured hands-on user time.
Gmail DKIM failure to passing email: about 30m 16s. Consistent with negative DNS caching. MCP, webmail and security verification continued during that span. No signing-key or source change was needed.
Local DNS repair: about 7 minutes. Also overlapped verification. The subagent lost browser access, and a supervisor handled browser operations; that assistance was not separately timed as overhead.

Subtracting the DNS span from the total would not produce a valid “setup excluding DNS” result. Pure DNS idle time, individual screenshot effort and agent/tool overhead were not separately measured.

What the measurement includes

The timer ran from 20:40:49 to 21:50:23 UTC. The installer started at 20:48:55 and completed at 21:47:11. Native MCP was demonstrably usable approximately 44m 05s after installer start.

Preparation and provider logins were outside this timer. One recorded login request took 2m 09s to observed resolution; earlier preparation was not fully timed. An evidence-packaging checkpoint followed cleanup by another 3m 16s. Later reporting is excluded.

This was a clean application reinstall on an existing Linux VPS with OS packages, Docker cache, provider accounts and signed-in sessions retained. A pinned private prerelease archive was supplied. It was not an unassisted agent, blank-OS or public-clone test. Source code remained unchanged during the rehearsal.

We retained 39 actual screenshots and timestamped private logs. This page is a sanitized summary: it does not publish mailbox content, credentials, account identifiers or private infrastructure. Initial test messages reached Spam; successful delivery does not guarantee Inbox placement.

Help bring setup under 10 minutes

The target is configuration in under 10 minutes once required inputs, credentials, access and approvals are ready. DNS waiting must be shown separately, with a supported estimate and a way to resume. Fully verified status still requires real delivery, authentication and permission checks.

Copy this prompt for your agent. Begin with a prompt-only or documentation-only PR; implementation and another measured rehearsal follow separately. The repository currently requires access; the complete prompt is available here without GitHub access.

Read the improvement prompt

Prompt for your agent

Improve Hermesaki setup so configuration takes less than 10 minutes once the required details, credentials, access and action approvals are available. This is a target to verify, not an existing performance claim.

First read the repository instructions, setup guide and the published 12 September 2026 baseline. The assisted rehearsal took 58m 16s for installation and full verification, or 1h 9m 34s including teardown and cleanup. Provider configuration, approvals and browser recovery occupied 17m 59s. Service provisioning occupied 3m 09s. DNS-related delays overlapped useful work; do not subtract the approximately 30-minute fail-to-pass window to invent an active setup time.

Inspect the current implementation and propose the smallest practical fixes. Check prerequisites and provider permissions once, reuse supplied details, publish DNS as early as dependencies allow, run independent work concurrently, keep browser ownership stable, and use tested MCP client configuration. Preserve existing resources and authorization protections. Do not bypass approvals, disable TLS verification, loosen permissions, send unauthorized email, or tear down a live installation for a benchmark.

Represent configured, DNS pending, and fully verified as distinct states. When observed DNS/cache information supports it, show an approximate retry interval and its basis: “Setup configured. DNS is still propagating. Try verification again in approximately X minutes. Your agent can resume without reinstalling.” If the interval cannot be estimated, say so. Preserve progress and idempotency; after the suggested window, diagnose a persistent failure instead of repeatedly reinstalling or calling every error propagation. Keep native MCP send/read/reply, recipient receipt, SPF/DKIM/DMARC, TLS and access checks mandatory before fully verified status.

Instrument setup start, configuration ready, each explicit DNS-blocked interval, owner requests and responses, native MCP readiness, full verification, cleanup and evidence collection. Use UTC wall-clock timestamps and monotonic durations. Label overlaps, agent/tool failures, supervisor assistance, prerequisites, cache state, source revision and benchmark environment. Report human hands-on time only if actually measured. Keep teardown, preparation, DNS waits and extended audit time separate; retain the full elapsed total as well. Do not obtain a sub-10-minute result by omitting required work or blindly subtracting overlapping waits.

Start with a prompt-only or documentation-only PR describing the inspected causes, proposed changes, acceptance checks and measurement plan; do not implement application changes in that PR. Link the baseline and distinguish observed facts from hypotheses. A later implementation PR should include focused local tests for resumability, DNS-pending UX, permission failures and timing accounting, followed by an explicitly authorized measured rehearsal. Preserve private evidence locally and publish only sanitized results. Do not change repository visibility or add CI/automatic deployment.

Open plain text →Read the prompt-only PR ↗

← Back to Hermesaki