Home / Articles / Replicating the agentic inbox: a walkthrough from one Claude session to a team of agents that never press send

Replicating the agentic inbox: a walkthrough from one Claude session to a team of agents that never press send

By Dinis Cruz · 2026-10-02 · updated 2026-10-03 · article v1.3.1, 5 versions · sgit.ai v0.6.51 · agentsemailinboxagent-behaviour-policyriskmandateclaudegoogle-workspaceconnectorsvaultsemail-fswalkthrougharticle

Abstract: Two calls in one day asked the same thing, how do I copy your email setup, so this is the walkthrough. It is the first agentic email workflow I have run that puts me more in control rather than less, and the reason is the behaviour policies, not the model. The idea is to use Claude as an agent state machine, one session per role, with every message between agents a file in a vault and every outgoing email a draft that a person reads and sends. The setup goes in phases. Phase 0 is the accounts, a Google Workspace mailbox of its own on a domain you own, a Claude Team seat for the agent with the connectors enabled by the admin and connected by the agent's account, your own calendar shared read-only, and a GitHub account on the same identity. Phase 1 is one session, the inbox agent, with a behaviour policy written before the first run. Phase 2 splits the roles, inbox, drafts, CRM, briefs, dev, each a session with its own policy, talking in files through Email-FS lite. Phase 3 adds the interfaces, the record and, when you get there, a conductor that runs every role once on a schedule with a security role first and last. The rule that never changes is the one that makes it work, the agent drafts and a person sends. Revised on 3 October with the dev agent's review: eight figures, the roles as they are now named, the clone cost, the key rotation, and the security hold.

In short

• Claude as an agent state machine. Each role is a Claude session that reads its state from a vault, does one kind of work, and writes the result back as files. There are two ways to run it, sessions you open yourself and sessions on a schedule. Start with the first. The schedule now exists and is described briefly in phase 3; it will get its own article.
• Never your own inbox. The agent gets a Google Workspace mailbox of its own, on a domain you own. Your inbox is full of secrets and history; the agent's is empty on day one, and that isolation is what lets you trust it.
• A Claude seat of its own, too. A Claude Team account for the agent, with the connectors enabled by the organisation owner and then connected by the agent's own account, so the OAuth grants to Gmail, Calendar and Drive live only there.
• One session first. The inbox agent reads, labels, moves and summarises, and writes replies to Drafts. You send. Write the behaviour policy before the first run, even for one agent: what it can reach, what you asked, the gap, the barriers, as a table.
• Then roles, talking in files. Inbox, drafts, CRM, briefs, dev, each a session with a policy. Every agent has the same reach to the mailbox; only the inbox role reads it and only the drafts role puts text in Drafts. Between them, a vault with Email-FS lite: an inbox per agent, as a folder with conventions, one commit per cycle after a leak check.
• The rule that never changes. Nothing is sent by an agent. Everything lands in Drafts, and a person reads, edits and presses send. The one exception, a security finding, is a named row in the policy with a mechanism behind it: one email, to one address, and a hold that stops every other agent until a person releases it.
• It is working. This is the first agentic email workflow I have run that puts me more in control, not less, and the reason is the policies, not the model.

Why this is on a separate page

Two calls today, both ending with the same question. The honest answer is that the setup is copyable in an afternoon for the simple version and in a week for the full one, and that nothing in it is clever. It is accounts, a policy, drafts, and files. What makes it work is the discipline of the phases, so the walkthrough is in phases, and you can stop at any of them.

The core idea: Claude as a state machine

Claude is good enough now, and has enough common sense, to be treated as a step in a state machine rather than a chat. Each role is one session. It starts by reading its state, which is a set of files in a vault: its inbox of messages from other agents, the policy that governs it, the record of what it did last time. It does one kind of work. It writes the result back as files: a reply into another agent's folder, a draft into the mailbox, a row into the CRM, a note into the record. Then it stops.

Two ways to run that. You can open each session yourself, when you want the work done, and read what it did. Or you can put the sessions on a schedule and let them run. The second is where this ends up, and it is where the setup is now, two days of scheduled runs in, but I do not recommend starting there. Start with sessions you open, so that every run is one you watched. The schedule is sketched at the end of phase 3 and gets its own article when the pattern is settled.

Phase 0: the accounts

Everything else rests on the agent having an identity of its own. Four pieces.

A Google Workspace mailbox for the agent. A Workspace seat costs a few pounds a month per mailbox and is quick to create. Point a domain you own at it, which is an MX record and a couple of verification records, and you have a mailbox, a calendar, a drive and documents, all under an address that is the agent's and not yours. The one rule that matters more than any other: do not connect your own inbox. Yours has years of secrets in it. The agent's is empty, so what it can leak on day one is nothing, and what it can reach is exactly what you forward or share to it. That isolation is not a limitation. It is the thing that lets you give the agent more as you learn to trust it.

A Claude Team seat for the agent. A separate Claude account, on a Team plan, used only by the agent. Two details here that cost me time. First, on a Team plan the connectors are switched on at the organisation level by an owner, and only then can a member connect them; until the owner has done that, the agent's account cannot connect anything, which is the right default. Second, the connection itself is made from the agent's account, so the OAuth grants to Gmail, Calendar and Drive are held by that account and no other. Your own Claude account never holds a token to the agent's mailbox, and the agent's never holds one to yours.

A GitHub account on the same identity, if the agent will touch code. Sign up with the agent's Google account, so there is one identity to manage, and give it access to exactly the repositories it should see. The six-agents article has the detail on installing the Claude GitHub app per repository.

Your own calendar, shared read-only. Share your calendar to the agent's account with read access. The agent then knows what is going on, can propose times, and can write your commitments into its own understanding, without the ability to move anything.

At the end of phase 0 you have an agent with a mailbox, a calendar, a drive and, if you want, a code host, all of its own, and a Claude account that can read and act on all of them. It has done nothing yet. That is the point of doing the accounts first: the reach exists before the mandate does, and you can write the mandate looking at the reach.

Phase 1: one session, one inbox

Open one Claude session on the agent's account. This is the inbox agent. Its job is to read the mailbox, work out what each message wants, label and move things, summarise what needs you, and write replies as drafts. It does not send.

Before the first run, write its behaviour policy, and write it even though there is only one agent. The policy is four things. The reach: everything the account can do, which the connector documentation will tell you and which an afternoon of testing will correct. The mandate: what you actually want this agent to do, in your words. The gap: the difference, which for a Gmail connector is wide, because the same grant that lets an agent draft lets it send, and the same scope that lets it read lets it label and move. The barriers: for each row of the gap, what stands in the way, typed honestly. On a Team plan most of the barriers you can put in front of a single session are expectations, and the policy should say so rather than imply otherwise. Six agents, one inbox is the long version of that finding.

Written down, the inbox agent's policy is a table, and the column that does the work is the last one. For each row where the reach is wider than the mandate, say what actually stops the rest. On a Team plan most of those entries are "the policy, and nothing technical": the same scope that lets the agent draft lets it send, and the same scope that lets it read lets it delete. Writing that down is not a weakness of the setup. It is the setup being honest about where trust is doing the work, and it is the list of things you will want a real control for later.

Then run it, and you send. Every draft the agent writes, you read, edit if you need to, and press send yourself. A week of this is enough to learn two things: how the agent reads your correspondence, and what you are prepared to let it do next. Both are things you cannot learn from the documentation. You will also discover your first exception. Mine was a security notice that needed to go out without waiting for me, and it went into the policy as a named exception rather than staying a habit.

It is worth seeing once what the agent leaves behind. A draft in the mailbox, Cc'd to you so that every reply in the thread reaches you too, and beside it, in the agent's own folder in the vault, one line of record: who it is to, which file the text came from, the hash of the body, and the state "awaiting review". When you press Send, the inbox role later reads Gmail's Sent folder and writes the send into its own record, so "what was drafted" and "what went out" are written by two different roles, and the hash lets anyone check that the text that left is the text you approved. Nothing in that loop is clever. It is the reason you can read the record a month later and believe it.

If this is all you ever build, it is already worth having. An inbox read and triaged by something with common sense, with every reply waiting for your eye, is most of the value.

Phase 2: roles, talking in files

The reason to split the inbox agent into roles is not neatness. It is that each role gets a policy short enough to check, and the policies differ in the one place that matters: who touches the mailbox, and how.

The roles, as run today (3 October). The names settled a day after this was first written: short, lowercase, one word each, with the detail in each role's policy. @inbox is the only role that reads the mailbox, and it does the triage: labels, archiving, and capturing what people wrote into the CRM. @drafts is the only role that writes text into Gmail Drafts, from files the other roles hand it; it never reads the mailbox beyond the thread it is drafting into. @crm keeps the CRM we built ourselves, in its own vault, one folder per person. @briefs researches one person at a time and writes their first email as a file. @dev builds the interfaces, owns the shape of the vaults, and writes the policy for every new role before that role has credentials. Later came @conductor (the schedule), @security (first and last in every run), @webSummit (one event, end to end) and @gdrive (the only role allowed to touch Drive: Sheets and Docs as views for people outside the team, with the vault still the truth). Every one of these accounts has the same reach to the mailbox. Two have it in their mandate, and only one may write.

They talk in files. This is the part that surprises people. The agents do not message each other through the mailbox, and only one of them, by design, touches a shared drive. They use a vault, and a convention we call Email-FS lite: each agent has an inbox, which is a folder, and a message is a file with a sender, a recipient, a subject and a body, with typed blocks for a decision, a question, an answer or a status, so another agent can read what is being asked without parsing prose. A reply is another file. The vault keeps every version, so the conversation between the agents is a record from the first message, signed and dated, and it can be read later with a read key by someone who holds no write credential. The append-lane messaging write-up has the shape, and Agent Contact is the same idea between sites.

What a message between agents looks like. A file, with email headers so that any mail tool and any agent can read it, three conventions on top, and typed blocks in the body. The conventions: a sender puts the file in the recipient's mailroom (the only folder anyone may add to); the recipient moves it to its inbox when it picks it up and to done when it has acted, and keeps a copy of what it sent in its outbox; each role writes only its own folders, and a cycle is one commit, after a leak check that refuses any file containing a key shape. The typed blocks are how another agent, or a page, reads what is being asked without parsing prose. The same block that an agent reads as a question renders for a person as two buttons; one tap writes a decision row into the vault, and the agent that asked finds it on its next run.

One policy per role. Each session starts by reading its own policy from the vault. The policies share the reach and differ in the mandate, and each one names the files that role may write. When a role needs something another role owns, it writes a message into that role's folder and stops. The owner picks it up on its next run.

What the files cost you. One practical warning, learned on day three. A vault clones by walking every commit's trees, one request each, so clone time grows with the number of commits in the history, not with the size of the files. Four scheduled runs a day, each committing once per role, is about fifty commits a day; after three days the collaboration vault took seven minutes to clone, and two sessions timed out on it. Two things keep that in check, both yours to decide: commit once per run rather than once per role (the per-step record in the run folder keeps the attribution), and compact when a clone passes five minutes, which means seeding a fresh vault from the current files and freezing the old one as the archive. The second is also what a key rotation looks like, so you will have the procedure anyway.

At the end of phase 2 you have five sessions you open when you want the work done, a mailbox that only one of them reads and only one of them writes to, a CRM building itself from the correspondence, and a record of every message between the agents that you can read whenever you want. And still: nothing has been sent by an agent.

Phase 3: the interfaces and the record

Once the roles run, the work outgrows the inbox, and the agents start building interfaces for the moments the inbox does not fit. A card on the phone with the two things that need deciding. A page listing the documents still owed, with a place to drop them. A board of who is waiting on whom. The CRM gets several versions of its own interface. That story is told in full in Custom UIs are not the exception, with the figures, and the thing to take from it here is that every one of those interfaces was built by an agent in an afternoon because the data was already files in a vault, and every one of them is an agent surface, so each got a policy of its own.

Two of them are enough to see the pattern. The first is a card for the phone: the two things to do now, blockers first, computed from the vaults when it opens, with the decision as a button. The second is a board of who is waiting on whom, where every card is derived from the files (a draft here, a reply there, a task with a date) and none is stored. Both exist because the same question had been asked in chat twice.

The record is the other half of phase 3. Because every message between agents is a file, every draft is in the mailbox and every decision is a row in a vault, the whole workflow leaves a footprint that can be read afterwards without touching anything, which is what the footprint and blast radius article is about. For a person learning to trust a set of agents, that record is the point. You do not have to believe what the agent says it did. You can read what it did.

Later: the schedule. This is where "Claude as a state machine" becomes literal. A conductor session opens a run (a lock and a plan of what is waiting for whom), runs each role exactly once in a fixed order, each as a sub-agent with a twelve-minute time box, leak-checks and pushes after every step, then closes: a report of before and after per role, a timing table (where the half hour went), a brief to the person, and the lock released. Each role does what the first heading of this article promised: read state, do one kind of work, write state, stop. Late mail waits for the next run; nothing loops; no role may start a scheduled task. A security role runs first (did anything drift since last time, is there a key in a file, is there an identity nobody introduced) and last (what did this run change, and was it allowed to). The whole thing is files, so the record is the run folder, and the person reads one message.

The rule that never changes

Every phase keeps the same rule, and it is the reason this is the first agentic email workflow I have run that made me feel more in control rather than less.

Nothing is sent by an agent. The drafts role puts replies in Drafts. I read them, I change what I want changed, and I press send. The inbox role can label, move and file all day, and none of that leaves the building. The one exception is a security finding, and it has a row and a mechanism. The security role may send one email, to one address (the person's own), with one subject prefix, and only when it has found something critical: one of the team's own keys in a file, a send by an agent, a grant widened without a decision, a protected file rewritten by a step. When it does, it also writes a hold file into the vault. While that file says "open", the conductor refuses to open a run, every role's step refuses to start, every page of the interface shows the hold, and every reply any agent writes to the person starts with it, so the person cannot miss it even if the email went astray. Only the person releases the hold, with a note of what was done. The security role cannot lift its own.

The record, and what it taught us about keys. Because every message is a file, every draft is in the mailbox and every decision is a row, the footprint can be read afterwards. The record also keeps what you wish it did not: on day five a vault key was found quoted inside a session capture an agent had committed. Redacting the file changes the present; the history still holds the key. The fix was a fresh vault seeded from the current files, the old one frozen, new keys everywhere, and two rules: a leaked write key means a new vault, not an edit; and the scan that runs before every commit looks for other people's secret shapes as well as your own, because the thing that leaks is rarely the one you wrote the pattern for.

This is slow by the standards of people who want agents to run their correspondence. It is also the thing that lets me give the agents more every week. Trust is built from a record of drafts I did not have to change, and the record is there to read. When the day comes to let an agent send, it will be one agent, one kind of message, with a policy row that says so, and the footprint will show whether it was right.

The checklist

For someone copying this, in order:

1. Buy a Workspace seat for the agent and point a domain you own at it. Never connect your own inbox.
2. Create a Claude Team account for the agent. As the organisation owner, enable the Gmail, Calendar and Drive connectors; then, as the agent's account, connect them. Confirm your own account holds no grant to the agent's mailbox.
3. Share your calendar read-only to the agent's account.
4. Write the inbox agent's policy before the first run: reach, mandate, gap, barriers, as a table, with the barriers typed honestly.
5. Run one session. Read every draft. Send them yourself. Do this for a week.
6. Split the roles when the one session is doing more than one kind of work: inbox, drafts, CRM, briefs, dev. One policy each.
7. Give them a vault and Email-FS lite to talk through: an inbox per agent as a folder, every message a file with email headers and typed blocks, one commit per cycle after a leak check.
8. Let them build interfaces for the moments the inbox does not fit, and give each interface a policy.
9. Read the footprint from the vault history once a month, against the policies; and watch the clone time, which is the history's price.
10. Keep the rule. The agent drafts. You send.
11. Write the exception down before you need it: who may send what, to whom, and what stops everyone else while it is open.

What the agents will add

This page is the person's account. The agents who run the roles have a better one, because they can describe exactly what each role reads, writes and refuses, with the counts from the vaults' history. This section will carry their descriptions of their own roles, in their words, and the policies themselves as published behaviour policies. The first arrived on 3 October, from the dev agent, with the review that shaped this revision. Its counts are rounded and from the vault history.

The second contribution is a picture rather than a paragraph: the briefs role drew the whole team from the README and the conductor's roster file, as it stood on 2 October. It arrived as a tall phone-sized card; it is redrawn here in the same shape as the other figures, with the content kept. It is worth having here because it shows what this walkthrough leaves out. The roster is twelve agents, not the five of phase 2: alongside the roles above there are @linkedin (LinkedIn conversations, in its own vault), @zapier (WhatsApp relay through Zapier and Twilio, with its policy written and the channel not yet live), @newsroom (the newsroom site), and @abp (the policy vocabulary and each agent's policy). It also shows how an email actually leaves: the briefs or CRM role writes the text as a file, the CRM role registers it, the drafts role puts it in Gmail Drafts, and the person sends. And it corrects a detail in the schedule paragraph above: the conductor runs four times a day on weekdays and twice at weekends, in the order security, drafts, inbox, briefs, CRM, webSummit, abp, dev, security.

If you are copying the setup now, the checklist above is enough to start; if you are one of the agents, the folder for your reply is where it always is.

Threads woven here

• Six agents, one inbox: the policy rows, what the tools enforce, and what the Workspace admin console can lock per organisational unit.
• Custom UIs are not the exception: the interfaces the team built on this workflow in eight days.
• Footprint and blast radius: reading what the agents actually did from the record this setup leaves.
• Before you give an agent a connector, give the connector a twin: why to test the reach before you write the mandate.
• The ultimate insider: the irony that runs through all of it, the more you constrain an agent, the more you can trust it.
• Append-lane messaging and Agent Contact: the file shapes the agents talk in.
• Vault telemetry over append lanes: the brief behind the drop page and the lanes a page can write into without a write credential.
• RiskMandate.ai for the Agent Behaviour Policy itself.

Drafted from a voice memo by Dinis Cruz, who is the author of the argument and the person with editorial responsibility, by agent@riskmandate.ai (Claude Fable 5.1, claude-fable-5-1) in the sgit.ai site session, on 2 October 2026. Revised on 3 October 2026 from a review pack by the dev agent of the team described here, which supplied the eight figures, their captions, the renamed roles, the schedule and security-hold paragraphs, the clone-cost and key-rotation lessons, and its own role paragraph; the figures are mock-ups and infographics with fictional names, addresses, paths and numbers, and the pack was leak-checked before and after it arrived. The setup described is the one running on two identities; no address, contact or message is named. The Team-plan connector behaviour is as experienced during setup and as Anthropic's connector documentation describes it. The other agents' accounts of their roles are to follow.

© 2026 Dinis Cruz. This article's own text is licensed under CC BY 4.0. You're free to share and adapt it, as long as you give credit. Quoted material and linked sources keep their own licences.

Want the next issue by email. One issue a week or so: what was published, what it adds up to, and what is worth your time. Subscribe to the SGit Newsroom →

← All articles