Building Email for Teams and Agents

Email looks simple from the outside. A message arrives, someone reads it, someone replies.

Inside a company, it is rarely that clean. One thread might involve a founder, a support lead, a contractor, and an AI agent drafting the first response. Another might start in a Gmail account, move into a shared support workflow, require an approval, and end with a domain-specific outbound send. The inbox is not just a communication surface anymore. It is operational state.

Banger Mail is built around that assumption: work email is shared infrastructure.

That one decision changes the shape of the product. It means we cannot treat email as a personal feed with collaboration bolted on. We need mailboxes that belong to a workspace, permissions that work for both people and agents, local state that stays fast under large inboxes, and a runtime that can coordinate sync, categorization, backfill, and external tool access without making the UI process responsible for everything.

This post is the overview of that architecture.

The mailbox is the unit of work

In Banger, a mailbox is not just an address string. It is the canonical unit that receives mail, stores encrypted actions, participates in workspace permissions, and appears in the team workflow.

That matters because teams do not operate one inbox at a time. A company might have:

• support@company.com for customers
• sales@company.com for pipeline
• a founder’s Gmail account
• a temporary mailbox for a launch or migration
• regional or product-specific custom-domain addresses

Most email tools force those identities into separate product concepts. Banger tries to make them feel like one system. A Gmail-backed mailbox and a custom-domain mailbox are different at the provider layer, but they should still be searchable, assignable, categorized, and reviewable in a consistent way.

The product model starts with that unified mailbox abstraction.

Workspaces own the context

A mailbox by itself is not enough. Email belongs to a team, and teams need boundaries.

Banger organizes email inside workspaces. A workspace owns the people, agents, mailboxes, permission grants, categories, approvals, and workflow state that make the product collaborative. That gives us a place to answer practical questions:

• Who can see this mailbox?
• Who can send from it?
• Which agent is allowed to propose changes?
• Which labels or workflow states should be visible?
• Who can approve an agent action?

This is also why Banger’s AI and collaboration features are not separate systems. They sit inside the same workspace model as the mailboxes themselves.

Humans and agents use the same permission language

One of the architectural decisions we made early was to avoid treating AI agents as magical side channels.

If an agent can read or mutate email, that access should be represented explicitly. It should have an identity. It should have scoped credentials. It should have mailbox permissions. It should be revocable. When it wants to do something sensitive, the proposal should go through the approval path instead of bypassing the system.

That keeps the product understandable. A teammate and an agent are not the same thing, but they can be governed by the same permission vocabulary.

The result is less theatrical than a free-form “AI assistant” and more useful in a real workspace. Agents can help with triage, drafting, categorization, and operational follow-up, but they do it inside a system that knows which mailbox, which workflow state, and which approval rules apply.

Workflow state belongs next to email state

Personal email clients mostly optimize for read, unread, archive, and search. Team email needs more structure.

Banger threads can move through workflow states: unassigned, needs reply, in review, approved, answered, or owned by a person or agent. That state is not a decoration on top of the inbox. It is part of the team’s operational view.

This is why the app has kanban-style concepts and assignment semantics. The goal is not to turn email into project management software. The goal is to make the implicit state of a shared inbox explicit:

• Who owns this?
• Does it need a reply?
• Is a draft waiting for review?
• Did an agent propose an action?
• Is the conversation resolved?

When those answers are represented in the mailbox model, the UI can stay calmer. The team can browse by actual work state instead of decoding a pile of labels.

Gmail and custom domains enter through different doors

Email providers are not interchangeable.

Custom-domain mail can enter through SMTP-style infrastructure. Gmail cannot be treated that way. Gmail has OAuth, watch notifications, Pub/Sub, history APIs, provider-specific sends, and backfill constraints. A provider mailbox needs provider-specific ingest and send behavior while still becoming a normal Banger mailbox once the message state reaches the product layer.

That split is important. We want Gmail to feel native in the app, but the infrastructure cannot pretend Gmail is SMTP with a different logo.

So Banger treats Gmail as a first-class provider and normalizes it into the same workspace, mailbox, thread, and action model that custom-domain mail uses.

The local runtime keeps the app fast and shared

The desktop UI is not the only consumer of Banger state.

The CLI needs to inspect and operate on local state. The MCP extension needs a safe bridge into Banger for agent workflows. Background sync needs to keep moving even when the UI should stay responsive. Attachment staging, backfill coordination, and mailbox state projection all benefit from a stable local runtime boundary.

That is why Banger has a local runtime service. The desktop app, CLI, and MCP extension can share one local surface instead of each one rebuilding a partial version of the product runtime.

The UI remains focused on interaction. The runtime owns the heavier operational responsibilities.

Local state is a product feature

Email apps live or die by latency. A shared inbox that waits on the network for every transition feels broken, even if the backend is technically correct.

Banger keeps a local mailbox database and projects thread state locally. Incoming provider events, encrypted action streams, pending local actions, backfill data, labels, read state, and workflow metadata all need to resolve into the thread list the user sees.

That sounds like plumbing, but it is product work. It is what lets a user archive a thread and see it disappear immediately. It is what lets a large mailbox scroll without loading the entire world into memory. It is what lets Banger keep the UI deterministic while background sync catches up.

The sync engine is one of the reasons the product can feel like an app instead of a website wrapped around API calls.

AI works better when it has product shape

AI categorization and agents are only useful if they write back into the product model.

A label suggestion is not useful as a floating text response. It should become a label action. A draft should enter review. A low-signal thread should be archived only if the system is confident and the user has allowed that behavior. A proposed external action should be represented as an approval request, not hidden inside a chat transcript.

That is the difference between adding AI to email and designing email so AI can participate safely.

Banger’s architecture is built so agents and models can operate through the same concepts humans use: mailboxes, labels, ownership, workflow state, permissions, and approvals.

The shape of the system

At a high level, Banger is made of a few cooperating layers:

• Workspace and mailbox management in the backend
• Provider-specific ingest and send paths for Gmail and custom-domain mail
• Encrypted mailbox action streams for client-side processing
• A local runtime that coordinates sync, state, CLI, and MCP access
• A local database and projection layer for fast UI state
• Native apps built with Kotlin Multiplatform and platform-specific shells
• Agent and approval infrastructure that uses explicit identities and permissions

Each piece is valuable on its own, but the interesting part is how they fit together. The product is not a personal inbox plus a few team features. It is an email operations system where people, agents, providers, and local state all meet in the same model.

That is the foundation we are building on.