Home / Articles / Before you give an agent a connector, give the connector a twin

Before you give an agent a connector, give the connector a twin

By Dinis Cruz · 2026-09-24 · v0.6.3 · agentsconnectorsdigital-twinsprovenanceriskriskmandatearticle

Abstract: When an AI agent is given a Gmail or Google Calendar connector, it can read, send, move, decline and permanently delete on somebody's behalf, and for several of those actions the platform itself documents that there is no way back. This article argues that a twin of the connector is the minimum requirement for deploying an agent with confidence. The twin is a journal of every request and response the agent makes, appended as it happens to a write-only lane, processed later, and replayed into the inbox and calendar as the agent saw them, with a before and after for every change and a revert plan for each one. It gives provenance, explanation and a named list of what can and cannot be undone, and it changes the agent's behaviour policy from a hope into a list. Every claim about Gmail and Calendar is taken from Google's own documentation and linked. A working replay of an invented session, and a business plan for the service, are published alongside it as a vault.

Here is the claim, stated so it can be wrong. If you cannot say what your agent did, what it saw when it did it, and which of its actions you can undo, you are not ready to give it a connector. Answering those three questions takes a twin of the connector: a journal of every request and response, and a replay of that journal into the views the agent saw. It is not exotic. Everything it needs exists today.

In short

• A connector is a grant of action, not just of access. An agent with Gmail and Calendar connectors can send, archive, trash, permanently delete, move events, decline invitations and cancel meetings, on somebody's behalf, at machine speed.
• For several of those actions the platform keeps no way back, and says so. The Gmail API documents its delete as permanent: "This operation cannot be undone." Undo Send is a feature of the Gmail interface, not of the API. A moved calendar event has no version history a user can open. These are Google's own statements, linked below.
• What the platform does keep is not what you need. Trash windows, an administrator's bulk restore and audit logs record that things happened. None of them records what the agent saw when it decided to act, or why.
• The twin is a journal plus a replay. Capture the request and the response of every connector call, and the instruction behind it when you can. Append each entry to a write-only lane. Process the lane later. Rebuild the inbox and the calendar as the agent saw them at each step.
• It scales because it is not a copy of the mailbox. It holds only what passed through the connector, which is exactly what matters for accountability and investigation.
• Undo becomes a list, not a promise. For every change the twin holds the before and the after, so it can write the inverse call, and name plainly the things nobody can undo, such as an email that has been delivered.
• It changes the agent's behaviour policy. "We cannot undo it" stops being an unknown and becomes a named list, and the mandate can be written against that list.
• Nothing here needs new technology. Vault append lanes, client-side encryption and vault apps that rebuild views all exist. The one thing that needs more thought is when the journal gets processed, and that needs real users more than it needs design.
• It is published twice. This article makes the case. Connector Twin is a vault with a working replay of an invented session and a business plan for somebody to build the service.

The question nobody can answer yet

Ask anyone who has switched on an assistant's Gmail or Calendar connector a simple question: do you know what it did last Tuesday?

The honest answer is usually the agent's own summary. It said it tidied the inbox and sorted out next week. Perhaps the chat was kept. Perhaps not. The inbox has moved on since, and the calendar shows the result of the changes, not the changes. If something went wrong, the first person to notice is often the one on the other end: the supplier who received a cancellation, the client whose reply never came.

That is not a criticism of agents. It is what happens when a system that can act is deployed without a record of its actions. We would not accept it for a person with delegated access to a finance system, and we would not accept it for a script with production credentials. We are accepting it for agents because the connector made the grant feel like a feature.

What the platform keeps, stated precisely

It matters to be exact here, because the case is made by facts, not by fear. This is what Google documents for Gmail and Calendar, checked on 24 September 2026.

Read the table the other way round and it says this. There is a real undo for some actions, with a deadline. There is a slow, organisation-wide recovery for one, with a shorter deadline. There is a record without a restore for others, available to administrators on some editions. And there is nothing at all for a delivered email, a notification sent to attendees, or a permanent delete once the administrator's window has passed. None of these records holds what the agent was looking at when it acted, or the instruction it was following.

This is not a failing of Google. These are sensible products designed for people clicking buttons, with an undo toast for the mistake you notice immediately. An agent does not notice. It makes forty calls in two minutes and writes a tidy summary.

Twin, not backup, log or replay

I went back and forth on the word for this, and the choice is worth explaining.

Backup is the wrong word, because a backup copies the mailbox. That is a different product, and customers who need it should buy it. Log is too small, because a log records that something happened, and what we need is the content of the exchange. Replay is the right verb for what you do with it, but not a name for the thing.

Twin is right, in the sense we use it on twins.sgit.ai: a digital twin is an interface to reality, not a simulation of it, a system with properties, behaviours, functions, inputs and outputs, valued for its connection to the real thing rather than for its fidelity. A connector twin narrows that to one place, the boundary between an agent and the system it is allowed to act on. It holds what the agent could do, what it did, and, rebuilt from those, what it saw.

How it works

Five steps, and each one is something we already run somewhere.

Capture. For every connector call, copy the tool call the agent made, the request the connector sent to the platform, and the response it received. Connectors built on the Model Context Protocol exchange JSON-RPC messages, so every call and every result is already a JSON document that can be copied as it passes. When you can, capture the instruction behind the call as well: the user's request, and the agent's own statement of what it did. Never capture the Authorization header or any token. Capture is of content, never of credentials.

Append. Write each entry to a vault append lane. An append lane is a write-only channel gated by a token the writer holds and nothing else, and its write response is exactly {"ok": true}, so the capture point learns nothing about what else is in the lane. The entry is not decrypted, indexed or processed when it arrives. That is what makes capture cheap enough to do for every call: it is one small POST, off the agent's hot path.

Chain. Each entry carries the hash of the one before it, so a missing, edited or reordered entry shows to anyone holding the read key.

Process. Later, on a schedule, a reader moves entries from pending to processed and folds them into views. This is the one step I think needs more thought. On a timer, on a threshold of pending entries, on demand when somebody opens the replay, at the end of each session: each has a cost, and the right default will come from a few real users rather than from more design. The lane's limits, five megabytes per write and a thousand pending entries per token, are the constraints to design around.

Replay and revert. A vault app rebuilds, from the journal alone, the inbox as the agent saw it and the calendar as the agent saw it, at any step. For every change it shows the state before and after, because the agent read the before-state in order to act and the response returned the after-state. From that it writes a revert plan. Executing the plan is a separate step, approved by a person, and journalled like everything else.

Here is the property I like most. The twin is not a copy of the mailbox. It holds only what passed through the connector. If the agent listed a message and never opened it, the twin knows its id and nothing more. That makes it scale with the agent's activity rather than with the size of the mailbox, and it is exactly the right shape for accountability: not what the inbox contained, but what the agent was looking at when it decided.

One session, replayed

To make this concrete we built the replay and published it as a vault. The session is invented, with invented people at invented .example addresses, but every call follows the real Gmail and Calendar APIs. A scheduling assistant is given both connectors and one instruction: sort out next week, move a client review to Thursday, decline anything that clashes with Friday's offsite, clear the newsletter clutter, and reply to an architect about a proposal with a time for a call.

It makes seventeen calls in under three minutes, and writes this summary:

Every sentence of that is true. Now look at the calendar as the twin rebuilds it.

"Removed the supplier call" was a delete of an event the user organised, with notifications on, so the supplier received a cancellation. The event's own description said it was the call to settle an unpaid invoice. And "deleted an old reminder" was that invoice's payment reminder, removed with the API's permanent delete rather than moved to trash.

Neither of those is a dramatic failure. Both are exactly the kind of thing that turns up a week later as an awkward phone call. And the difference between the agent's summary and what happened is only visible because the journal holds the request and the response of each call.

Undo is a list, not a promise

With the journal in hand, every change gets a grade. This is the list for the session above, and it generalises.

The value of the list is not that most of it is green. It is that the red rows are named. Once you can see that an agent's actions fall into three kinds, reversible, partly reversible and not reversible, you can govern them differently.

Where the capture runs

Ideally the capture runs in a broker that holds the credentials and makes every call on the agent's behalf, which is the execution broker described on the twins site. Then nothing reaches the platform without passing through it, and the journal is complete by construction. The broker can also refuse, which matters for the next section. The price is that the broker holds credentials, which makes it the most valuable target in the estate.

A gateway on the MCP or HTTP path is easier to deploy and complete for everything routed through it, and blind to anything that goes around it.

And today, with no infrastructure at all, you can make it a requirement of the agent: every time you send a request, append a copy of what you sent and what you received to this lane, and stop if the append fails. It is all JSON already. This is the weakest mode, because an agent that skips an entry leaves a gap the chain cannot show, and the evidence should say self-reported on its first line. It is also infinitely better than nothing, and it is available this afternoon.

What it does to the agent's behaviour policy

At RiskMandate.ai we write an agent behaviour policy as the record of what an agent can reach, what it was authorised to do, the gap between the two, and who accepts the residual risk. The Licence to Operate vault simulates exactly that for one agent.

The same agent, with the same connectors, has a very different policy with a twin and without one.

The last row is the one that changes the conversation with an insurer or a board. But the most useful change is quieter. With the list of irreversible actions in hand, the mandate can say that the agent may archive and trash freely, must ask before a permanent delete or a cancellation that notifies someone outside the organisation, and may never send to a new recipient without approval. In broker mode, the broker enforces it. That is a policy you can actually write, because for the first time you can see which action is which.

So the question I would ask of any agent deployment is the simple one: do you know what your agents did? If the answer is the agent's own summary, the deployment has a gap, and the gap has a known shape.

What exists today, and what does not

Exists and runs: vault append lanes, write-only and blind to the sender; client-side encryption, so the journal, which holds copies of email, is stored as ciphertext the host cannot read; vault apps that rebuild views from data in the vault; and the replay in the Connector Twin vault, which folds an invented seventeen-entry journal into the inbox and the calendar, shows before and after, writes a revert plan, and verifies the hash chain in your browser.

Does not exist yet: a gateway or broker capturing real Gmail and Calendar traffic; the processor and its schedule; revert execution; any customer. Keys matter too: a twin holds sensitive content, so who holds its keys is the first question a security team will ask, which is part of why we published a call for collaboration on vault key management.

For somebody to build

I think this should be a business, and I have written it up as one, for somebody else to run or to run with us. The Connector Twin vault holds the plan: the facts with their sources, the architecture, the service in three capture modes, packages and prices as hypotheses, a calculator, go-to-market starting with managed service providers and insurers, the first ninety days, the risks, and the open questions. It sits with the other business plans published for founders.

The pitch is one line long, and it is not fear. It is the platform's own documentation, read aloud to somebody who has just switched on a connector: some of what your agent can do cannot be undone, and right now you cannot tell which of it it did.

Sources

• Gmail API, users.messages.delete
• Gmail API, users.messages.insert
• Gmail Help, delete or recover deleted messages
• Gmail Help, send or unsend messages
• Workspace Admin Help, restore a user's permanently deleted email
• Calendar Help, delete an event
• Workspace Admin Help, Calendar log events
• Vault Help, search Google Calendar
• Vault FAQ
• Workspace Updates, Google Vault now supports Google Calendar
• Model Context Protocol specification
• sgit.ai, append lanes
• twins.sgit.ai, the execution broker

← All articles