Try it live: https://gilbertdemo.sequi.company — sign in with demo@example.com / demo. It is a mock Stalwart held in memory: no real mail and no real data, and it restarts every night, so nothing you leave there survives.

Gilbert

General-purpose Intelligent Lifecycle Butler for Enterprise Resource Traceability.

Gilbert is company mail and operations with AI agents inside — self-hosted mail, calendar, contacts and files, a knowledge base and the procedures a job follows. Agents read incoming mail and files, file documents into the right folder, read the document inside them, draft replies and report what they did in the group's chat. What they may do is a capability list an administrator writes and code enforces; every effect is recorded before it happens; and anything that leaves the group waits for a person to approve it, in words.

The agent part (gilbertagents) is designed but not yet functional, and is being reworked — see KNOWN-ISSUES.md.

Everything Gilbert keeps — mail, files, the knowledge base, rules, audit trail — is a document in your own Stalwart mail server, under the account it belongs to. There is no Gilbert database: no index, no cache tier, no writable disk, nothing to back up twice, and a redeploy that loses nothing. The only thing that leaves the installation is the model call the installation itself configures.

Who it is for

Gilbert is operations software. It is built for the people who keep a business running — administration, back office, service desk, accounting, whoever answers the phone — not for the people who sell.

It is deliberately not a CRM and ships no sales functions (no pipeline, deals, leads or quote engine), and it is not an ERP either. A company that sells can use it, because mail is mail and a purchase order that arrives as a PDF can be read, filed and answered, but the product takes no position on revenue. What it supports is the operation underneath: the work between something arriving and the matter being closed.

The four blocks

Gilbert is four blocks. They are areas of the product, not directories — one code tree holds several of them — and every document names them this way and no other:

• gilbertmailer — the mail suite: mail, calendars, contacts, files, sharing and the Sieve editor. This is the block that came from upstream.
• gilbertserver — the Node process beside the browser: sign-in, sealed sessions, JMAP forwarding, the settings policy, the image and calendar proxies. The agent fleet runs inside it.
• gilbertagents — the agents: the Master principal, the agent fleet, the automations, the approvals and the audit.
• gilbertstalwart — what is set inside Stalwart itself: the server's own configuration and system scripts, written through its management API, and the objects it holds (an account's identities, for example), written through JMAP.

Server is the word worth pinning down: Stalwart is the mail server that holds every durable byte, and gilbertserver is this product's own Node process.

One block and part of another came from ihasmail, Coffey Labs' immutable webmail for Stalwart; the attribution is in NOTICE. Everything else is Gilbert's own, written here and not contributed back. Why, and what happens at the boundary, is ADR 0002.

What it does

The short version; FEATURES.md is the inventory.

• Agents for mail and files. An agent is a Stalwart account of its own (gilbert@…) granted on a group like any colleague. An automation is a trigger (mail, chat, a file, the clock), an instruction in prose and a capability allowlist. The allowlist is checked in code on every answer, so neither the model nor a cleverly worded instruction can widen it. A group's review policy can pause a run for a person; a send outside the group always asks first.
• A receipt for everything. Every run is recorded, one line written before the effect, in a monthly document per group kept twelve months and readable by every member.
• Groups, chat and a shared directory. A group mailbox is an account owned by the group; chat is one conversation per group in that account; Global contacts is one directory the installation owns and every account reads.
• A knowledge base and workorders (Gilbert's own modules): a company-wide KB and one per group, holding the company's policies and procedures, with a shared draft, an administrator's approval and every issued revision kept; checklist templates authored with a checklist builder — a choice that holds throughout, sections that differ by it, a section that loops per item and a section assigned to a group, not markup; and workorders that gather the folders, files and pages of one job with a checklist bound to a KB template.
• A mail client you would keep anyway. Three-pane and keyboard-driven, with conversations, labels, search grammar, undo send, scheduled send, read receipts, S/MIME signature checking, calendars with invitations and free/busy, contacts with vCard import, and a visual Sieve rule builder. This is the part that began as upstream's.
• Nothing sensitive in the browser. The sign-in password is sealed on the server; the browser gets an HttpOnly cookie. Strict CSP, sanitised HTML, remote images through an SSRF-safe proxy, every JMAP call on the same origin.
• Nothing of its own to keep. No database, no search index, no cache tier. Sessions included, so a redeploy does not sign anybody out.

How it works

browser  ──(same-origin /api/*)──►  Gilbert server (Node + Hono)  ──(JMAP over HTTPS)──►  Stalwart
  React SPA                           • session cookie ⇄ Basic auth
  JMAP client + stores                • /api/jmap, /api/blob, /api/upload, /api/events, /api/image

• web/ — React 19 + TypeScript SPA (Vite): JMAP client, zustand stores, views.
• server/ — Node + Hono: authenticates against Stalwart's JMAP session endpoint, seals the credentials, proxies JMAP/blob/SSE and serves the SPA under a strict CSP. src/mock/ is an in-memory fake Stalwart for development; src/agent/ is the fleet.

JMAP only, to Stalwart; no own database; every durable byte lives in Stalwart. Features degrade gracefully by JMAP capability. The architecture decisions are one file each in docs/adr.

Requirements

A Stalwart 0.16 or newer server. Sign-in refuses older versions by name. Node 24 (the LTS line) for a host install; the container carries its own. Upgrading from 0.15 is a one-way migration — see KNOWN-ISSUES.md for the version notes.

Quick start

With Docker — the published image, against a Stalwart 0.16+ you already run. Gilbert expects a TLS reverse proxy in front of it (see INSTALL.md):

cat > .env <<'EOF'
STALWART_URL=https://mail.example.com
GILBERT_AGENT_ADDRESS=gilbert@example.com
GILBERT_AGENT_PASSWORD=change-me
EOF
docker run -d --name gilbert --restart unless-stopped \
  --env-file .env -p 127.0.0.1:8080:8080 ghcr.io/sequico/gilbert:latest

From source (development) — the whole app against an in-memory mock:

npm install
npm run dev:mock        # complete Gilbert against an in-memory mock Stalwart

Then open http://localhost:5173 and sign in with demo@example.com / demo. npm run dev:mock:agent is the same stack with an agent process running. The full install and operation guide is INSTALL.md.

Where to read more

🚀 INSTALL.md	Installing, running, configuring and operating Gilbert
📋 FEATURES.md	Everything Gilbert does today, feature by feature
🧪 KNOWN-ISSUES.md	What was verified live, and where Stalwart departs from a spec
🛣 ROADMAP.md	What Gilbert does not do yet, and why
🧭 CONTRIBUTING.md	Building, the gates, the mock, and how to contribute
🏛 docs/adr	The architecture decisions behind all of it

Contributing

CONTRIBUTING.md · CODE_OF_CONDUCT.md · SECURITY.md — report vulnerabilities privately, not in a public issue.

Gilbert is free software under the AGPL; if it is useful to you, you can sponsor its development.

License

Copyright (C) 2026 sequicompany — AGPL-3.0-or-later. See LICENSE. The mail client Gilbert derives from is covered by the attribution in NOTICE.

The AGPL's section 13 is the point of it: webmail is nearly always run as a network service rather than handed to anyone as a binary, and that section closes the gap. That offer points at your source, not this one: if you run a modified Gilbert, set SOURCE_URL to your own repository — the sign-in page and Settings › About both show it.