Why there is an email view

This week Dustav's drafts moved into Gmail. When the agent reads an email overnight and writes the reply it thinks you owe, that draft now lands in your actual Drafts folder, threaded into the conversation, sitting on your phone in the Gmail app like you'd started typing it yourself. Edit it on the couch and Dustav sees your edit. Delete it there and it's gone here. It was the last piece of state Dustav still kept privately, and moving it completed a shape I'd been building for months before I had words for it.

Here are the words: Dustav is not an app with a Gmail integration. It's a mirror of Gmail with a judgment layer on top. And I've come to think that's not just Dustav's shape — it's the shape of every AI business tool that's going to matter.

The shape everyone builds

The standard way to wire AI into someone's tools is a chatbot with an integration. There's a whole protocol for it now: hand the model your Gmail as a set of tools — search, read, draft, send — and let it orchestrate. It costs nearly nothing to build, which is why it's what most products do. Ask the chat to find the invoice, and it finds the invoice. Genuinely useful.

I could have built Dustav that way in a weekend. The integration wasn't the hard part; the hard part is everything the integration doesn't touch. And the reason it can't touch it comes down to one observation I keep returning to.

You can't run an inbox from a chat window

An operator cannot automate her inbox from a chat view. That is why there is an email view.

Think about what running an inbox actually is. Forty conversations at a glance. Bold versus receded. What's new since this morning, what needs you, what's handled, what's waiting on someone else. You triage by eye, in about four seconds, using a spatial layout your hands have known for twenty years. Then you open one thread and write, with the conversation right there beside the composer.

A chat window is a serial keyhole onto all of that. Every question re-asks something a queue view shows for free. "What came in?" — a list, in prose, that you can't scan. "Reply to the second one" — which one was second? The state that a surface holds has to be dragged through the conversation turn by turn, and a model relaying state is the flimsiest part of any system I've built. The view isn't chrome around the AI. The view is half the product.

So Dustav has an inbox view, drafts and sent views, a composer, a calendar — real surfaces, purpose-built — and the chat sits beside them as a copilot, for the judgment calls a grid can't express. The model recedes into the machinery. Most of what Dustav does all day never touches a chat at all.

A mirror, not a replacement

But here's the part that took me longest to see, because I had to almost get it wrong twice.

If the chat-shape is too small, the obvious correction is too big: build a whole new email client, a whole new store, and ask her to move in. Nobody moves in. Her mail is in Gmail, her folders are in Gmail, her phone is Gmail, her muscle memory is Gmail. Any product that asks a busy shop owner to migrate has already lost.

The answer is the mirror. The store stays hers. The primitives stay Gmail's. Dustav files with Gmail's labels, deletes into Gmail's trash, drafts into Gmail's Drafts, sends through Gmail's send, and mirrors Gmail's unread — including the parts I found slightly dumb. Her data never leaves the system she already trusts. Adoption is one OAuth click, and — this is the underrated half — departure is free. She can walk away any day and lose nothing, which is precisely why she can say yes on day one. There's no lock-in to apologize for, because the lock-in was never the plan. Everything proprietary lives in one place: what the model understood. The decoded card on every email, the reply already drafted, the to-do it noticed, the question it knew to ask. Gmail never read your mail. Dustav did. That's the entire divergence, and it's enough.

And because it's a true mirror, every other client keeps working. She starts a reply in the Gmail app in a parking lot; it shows up in Dustav's composer. Dustav drafts one at 6am; it's on her phone at 7. There's no "my version and its version." There's one mailbox, and one layer of judgment on top of it.

Where a mirror pays — and where it doesn't

I know the boundary of this idea because I've hit it. This summer I spent a whole session trying to find Dustav's angle on the same owner's online store, and walked away with nothing — because Square's own dashboard is first-party, structured, and genuinely good. There was no judgment gap to live in.

So the test is two-sided: mirror a canonical system whose data is rich and whose intelligence is absent. Email qualifies perfectly — unstructured, relentless, load-bearing for every small business on earth, and not one mail client ships judgment. Calendars qualify. Accounting qualifies in a specific way: the right move there is to feed QuickBooks the classifications its dumb rules can't make, never to shadow its ledger. The one thing you never do is build a competing store beside the canonical one. I did that once — four beautiful auto-maintained tables of her books that nobody, including the agent, ever read — and deleting them made the product better.

The grind is the moat

The honest cost of this shape: strict mirroring is hard, and it stays hard. My bug ledger for the last month is almost entirely mirror bugs. Rows that lingered after she deleted the real email. An unread model that meant the wrong thing. Delete buttons that removed one message when the row was a conversation. And this week's flavor: Gmail mints a brand-new message id every time a draft is updated, which sounds like an API nuisance until you realize it's the only way to tell her edit apart from your own echo — the quirk became the mechanism.

None of this is glamorous. All of it is the product. Anyone can bolt the standard integration onto a chatbot in an afternoon, and they'll have my tool calls with none of my invariants — and an operator feels the difference in a week, because a half-mirror doesn't read as a smaller feature. It reads as a bug. Both views agree, provably, in both directions, or she stops trusting the one she can't see.

There's a tax, too, and I'll name it: you live at the platform's pleasure. Google's verification process, restricted scopes, security audits, review videos. It recurs for every canonical system you mirror. Price it in. It's rent on the best real estate in software — the place the user already lives.

The rule

I think this is how you build business tools in the AI era, and I half suspect it's the only way. Not a chatbot bolted onto the canonical system — the operator can't run her business through a keyhole. Not a replacement for it — she won't move, and she shouldn't have to. A mirror: her store, her primitives, her finger on send, and a layer on top that has actually read the mail.

The store stays theirs. The judgment is yours. That's the product.