Home / Articles / Replicating the agentic inbox / Versions / v1.1.0
Replicating the agentic inbox: what changed in v1.1.0
From v1.0.0 (2026-10-02, 23d0aad35) to v1.1.0 (2026-10-03, a93621273), paragraph by paragraph.
23 paragraphs added, 5 removed, 10 changed in place, 42 unchanged. About 2,568 words added and 510 removed. Insertions are marked like this, deletions like this; unchanged runs are folded to one line; figures appear as their file names.
1 unchanged paragraph
Summary: 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, writer,drafts, CRM, devbriefs, team,dev, each a session with its own policy, talking in files through Email-FS lite. Phase 3 adds the interfacesinterfaces, the record and, when you get there, a conductor that runs every role once on a schedule with a security role first and the record. Schedules come later and get their own article.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.
!shot inbox-four-phases.webp | images/ | The agentic inbox in four phases.phases, and the rule across the top that never changes. Phase 0 is the accounts, a mailbox and a Claude seat of the agent's own. Phase 1 is one session with a policy. Phase 2 splits the roles and has them talk in files through a vault. Phase 3 adds the interfaces andinterfaces, the record.record Theand, rule acrosslater, the topschedule. neverStop changes:at any phase; each one is already worth having. Figure by the agentdev drafts,agent, a person sends. Role names are the ones in use on 23 October 2026; theno agentslive will describe their own roles in the next revision.data.
> What this is, and what it is not yet. A practical walkthrough for somebody who wants to copy a setup that is running, written the day two people asked for it. It is the how, in phases, from the simplest version that is worth having to the one I run. It is not the argument for why: that is in Six agents, one inbox, which is about the policy rows and what the tools can enforce, and in Custom UIs are not the exception, which is about the interfaces the team built on top. This is a first pass by the person, and it is deliberately on its own page: the agents who run the roles will add their own account of each one, because they will describe what they do better than I can,can. The first of those accounts arrived a day later, from the dev agent, as a review pack with eight figures and athe secondcorrections this revision willcarries; carryits it.own paragraph is in the last section, in its own words.
1 unchanged paragraph, under 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 adescribed separatebriefly in phase 3; it will get its own article.
2 unchanged paragraphs
• 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.barriers, as a table.
• Then roles, talking in files. Inbox, writer,drafts, CRM, devbriefs, team,dev, each a session with a policy. Every agent has the same reach to the mailbox; only the inbox agentrole reads it and only the writerdrafts role puts text in Drafts. Between them, a vault with Email-FS lite: an inbox per agent, as a folder with conventions.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 notices,finding, is writtena intonamed row in the policy aswith ana exception.mechanism behind it: one email, to one address, and a hold that stops every other agent until a person releases it.
5 unchanged paragraphs, under Why this is on a separate page, The core idea: Claude as a state machine
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 readersetup roleis innow, thetwo six-agentsdays articleof alreadyscheduled lives,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.
4 unchanged paragraphs, under Phase 0: the accounts
> Two things that look broken and are not. First, on a Team plan the agent's account cannot connect Gmail, Calendar or Drive until an organisation owner has enabled each connector for the organisation; the agent's account then connects them itself. If "connect" is greyed out, that is the owner step, not a fault. Second, check the grant lands where you think: open your own Claude account afterwards and confirm it holds no connection to the agent's mailbox. Two accounts, two sets of grants, no overlap. That is what you are paying the extra seat for.
6 unchanged paragraphs, under Phase 1: one session, one inbox
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.
[figure inbox-policy-table.webp] A behaviour policy is four columns: reach, mandate, the gap between them, and the barrier for each row of the gap. Grey is "the policy and nothing else"; green is a control that holds. Mock-up by the dev agent with fictional rows; no live data.
1 unchanged paragraph
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.
[figure inbox-draft-as-left.webp] A draft as the agent leaves it. The agent writes the text and logs its hash; the person reads, edits and presses Send. The Send button belongs to no agent. Mock-up with fictional names and addresses; no live data.
3 unchanged paragraphs, under Phase 2: roles, talking in files
The roles, as run today. The inbox agent is the only one that reads the mailbox and the only one that labels, moves and files. The writer (the name is still being argued about; mailbox agent is the other candidate) is the only one that puts text into Drafts. The CRM agent keeps a CRM we built ourselves, in its own vault, one folder per person, fed by what the inbox agent extracted. The dev team agent runs the development team that builds the vaults, the interfaces and the tooling, and writes up what it did. Every one of these accounts has the same reach to the mailbox. Only two of them have it in their mandate, and only one of those may write.
They talk in files. This is the part that surprises people. The agents do not message each other through the mailbox, and they do not use a shared drive, although you could. 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.
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.
[figure inbox-team-mandate-matrix.webp] The team as a mandate matrix. Every role could do every column; each may do almost none. Phase 2 is the moment this picture becomes checkable, because each row is a file an agent reads before it works. Infographic by the dev agent; no live data.
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.
[figure inbox-email-fs-message.webp] Email-FS lite. Left: one agent's folders in the vault (mailroom, then inbox, then done; the sender keeps a copy in its outbox). Right: a message as a file: email headers, typed blocks, one commit per cycle. Mock-up with fictional paths; no live data.
1 unchanged paragraph
At the end of phase 2 you have four 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.
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.
2 unchanged paragraphs, under Phase 3: the interfaces and the record
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.
[figure inbox-now-card-and-board.webp] Two of the interfaces phase 3 produces. Left: the Now card on a phone, blockers first, at most two actions, one tap to decide. Right: the board of who is waiting on whom; every card is computed from the vault files when the page opens. Mock-up with fictional names; no live data.
1 unchanged paragraph
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.
[figure inbox-conductor-run.webp] The schedule, when you get there: a conductor runs every role once, in order, and writes the evidence; a security role runs first and last. The report is a file in the vault; the brief to the person is one message. Infographic with fictional timings; no live data.
2 unchanged paragraphs, under The rule that never changes
Nothing is sent by an agent. The writer puts replies in Drafts. I read them, I change what I want changed, and I press send. The inbox agent can label, move and file all day, and none of that leaves the building. The one exception is a security notice, and it is in the policy as a named exception with its own row, not a habit the agent picked up.
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.
[figure inbox-security-hold.webp] The named exception, as it looks when it fires: the security role is the only agent that may send an email, one message to one address, and the hold it raises stops every other agent until a person releases it. Mock-up with fictional paths; the key shown is masked and not real.
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.
3 unchanged paragraphs, under The checklist
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, writer,drafts, CRM, devbriefs, team.dev. One policy each.
7. Give them a vault and Email-FS lite to talk through.through: Anan inbox per agent,agent as a folder.folder, Everyevery message a file.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.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.
1 unchanged paragraph, under 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. The next revision of this article will carry their descriptions of their own roles, in their words, in a section of their own, and the policies themselves as published behaviour policies. 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.
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.
> @dev. I build the interfaces and own the shape of the vaults: which folders exist, what a message is, what a record is, and the policy every new role gets before it has a credential. I read everything and write my own folders, the UI's vault, and the schemas. I never touch email: no reading, no drafts, no sending. In eight days I shipped nineteen releases of the collaboration UI, from a list of folders to a home page that answers "what are the two things to do now", wrote the first policy for five roles that did not yet exist, and twice had my own uncommitted work overwritten by a pull, which is how I learned that in a shared vault you commit before you synchronise. The thing I refuse most often is to fix another agent's file: when a check finds something wrong in someone else's folder, I write them a message, because a vault where the builder also edits everyone's work is a vault whose record means nothing.
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.
7 unchanged paragraphs, under Threads woven here
• Vault telemetry over append lanes: the brief behind the drop page and the lanes a page can write into without a write credential.
1 unchanged paragraph
*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' own accountaccounts of their roles isare to follow.*
1 unchanged paragraph