How Cloud Tag works

Group, thread, session

Cloud Tag Claude Tag
A Google Group A channel
An email thread in the group A thread
An agent: a linked Gmail mailbox with its own @name The Claude app in a workspace
One Managed Agent per group, with that group's configuration A channel's configuration
One session per thread One session per thread

Each group gets its own agent configuration: instructions, model, connectors, skills, secrets, network access, files and memory. Each email thread in the group is its own conversation, with its own session.

In Slack, a message can sit at the top level of a channel. In email every message is already in a thread, so every conversation is a thread session.

What happens when you mention it

  1. The message arrives. The agent's mailbox is a member of the group. Each new message is read within a minute, or right away with Gmail push.
  2. It's checked. Cloud Tag matches the message to its group by its list header, and believes it only if Gmail's authentication shows the group's domain sent it.
  3. It's stored. Every message is stored and threaded, answered or not. Attachments become group files.
  4. Cloud Tag decides whether it's addressed. A mention, mail sent to the agent's address, a follow-up in a thread it's in, or respond-automatically. Commands like !mute are handled here, without a turn. See Control when Cloud Tag responds.
  5. A turn runs. The thread's session gets the new messages and works in its sandbox: it reads the group's history and files, uses connectors, runs code, and writes files.
  6. The reply is sent. It goes only to the group's address, threaded under the message it answers, from the agent's mailbox. Files it made are attached.

Each thread has at most one turn at a time. Messages that arrive while it works go into its next turn together.

What it can see

  • The whole group archive, through search and read tools: every thread, not just the current one.
  • Every group file, which it can open from any thread, and the Google Drive files its group can reach.
  • The group's memory, and its agent's shared notes.
  • Connectors, GitHub repositories, secrets and the web, as the group's admins, its bundles and the organization set them up.
  • Your personal connectors, for your own requests only: read-only tools once you allow them in the thread, anything else only when you approve that call.

It can't see other groups, except through the shared notes their admins let it write.

What survives between replies

  • Within a thread: the session keeps its context, so follow-ups don't need repeating.
  • When the session is replaced, after a settings change or !restart, the new session reads the thread from the archive first (for a very long thread, the most recent part, and it can open the rest). Files it made in the old sandbox are gone from the sandbox, but anything it sent is in the group's files.
  • Across threads: the group's memory, group files and history.

When settings change

A group's agent is defined by its configuration, including what it inherits from the organization and its agent. Changing instructions, model, connectors, skills, secrets or network access makes a new agent and archives the old one. Each thread moves to a fresh session on its next reply, so the change applies everywhere, including a revoked credential.

Where things run

  • The settings site and mail handling run on Cloud Tag's servers.
  • Agents, sessions, sandboxes, memory stores and credential vaults run in your organization's Anthropic account, on your API key.
  • Credentials for connectors and secrets are in Anthropic Vault and never enter the sandbox.

Limits

  • Loop guard: the agent stops replying in a thread after 12 posts there within an hour.
  • A reply can run for up to 20 minutes.
  • Uploads (files, skills, mail archives) must be under 4 MB each.
  • Routines run at most once an hour.
  • Approvals nobody answers are declined after a day.