Technique

Give each Always On Agent its own seat, not your login

Google's new Gemini coworker agent gets its own account, its own audit trail and a spend cap that pauses it. You can set up your agents the same way today on the tools you already pay for. Five moves.

22Atlas

Product studio

15 October 20267 min read

If the agent works under your login, every mistake it makes has your name on it.

On Oct 8, at Gemini at Work 2026, Google Cloud announced the Gemini agent, which it calls "a universal agent for work." The part worth an owner's attention is how Google sets up the coworker version.

In Thomas Kurian's keynote post, you describe a role and Gemini creates an agent that "receives its own Workspace account, including an email address, calendar, Drive, and presence in your company directory." Colleagues add it to a Chat space or @mention it. When it edits a Doc, it shows up "under its own name in version history." Google's line on access is short: "A coworker agent acts under its own identity rather than yours, and it sees only what you share with it."

The same post lists the controls around it. Each agent gets an identity that is "cryptographically attested and governed like an employee, with least-privilege permissions." Every action goes to an audit trail "attributed to the agent rather than to a person." A spend cap set per project in the Cloud Billing Console pauses that project's agent when it trips, and someone has to click to resume. And per VentureBeat, Google confirmed that admins can choose which models agents are allowed to use. Today the agent runs on Gemini and Anthropic's Claude models.

Now the catch. The Gemini agent is in private preview only. Google hasn't announced a general availability date or pricing.

You don't need to wait for it. Microsoft's Autopilot "lives in your tenant with its own identity, memory, computer and workspace," and OpenAI's specialist dots get "their own identity, credentials, and access to the systems" they need. Three vendors landed on the same setup within two weeks, and every piece of it works on the stack you run today.

Five moves:

Give each agent its own account.
Share only the files and folders it needs.
Keep a trail of what it did, under its name.
Put a spend cap on it that stops work.
Write down which models it may call.

Give each agent its own account

The fastest way to start an agent is to hand it your login. It's also the one that hurts later.

Your login can reach everything you can: the bank, payroll, every client folder, every admin screen. The agent needs a small slice of that. When it sends an email from your address, the customer can't tell who wrote it. When it changes a setting, the change log says you did it. And if you need to stop it at 2 a.m., you have to change your own password and sign yourself out of everything to do it.

So make the agent a user. A new account in Google Workspace or Microsoft 365 with its own address, such as support-agent@yourstore.com. A staff account in your store admin with only the permissions its job uses. Its own API key for each tool, instead of the key your developer made for everything.

One agent, one account. If you run a support agent and a reporting agent, they get two accounts, even when the same model runs both. That way you can turn one off without touching the other, and every log line already says which one acted.

An extra account may cost you a license. That's the price of a clean off switch.

Share only what it needs

Google's coworker agent sees only what people share with it, through the sharing a team already uses. Your sharing settings can do the same today.

Make a folder for each agent job and share that folder with the agent's account. The support agent gets the returns policy, the macros and the order export it reads. It doesn't get the finance drive. The reporting agent gets read access to the ad accounts and a folder where it drops the weekly report. It doesn't get edit rights on the campaigns.

Start with less than you think it needs. When the agent hits a wall, you'll see it, and you grant that one thing. Write down every grant with a date and a reason.

If the agent touches customer channels, keep the send button with a person. We went through that list tool by tool in Decide who can message your customers before someone else does.

Keep a trail under its name

Once the agent has its own account, half the audit trail comes free. Sent mail sits in its outbox. Doc edits show its name in version history. Store and ad platform change logs list it as the actor.

The other half is the agent's own log. For each run, record when it started, what it was asked to do, which tools it called, which files it read or changed, and what it handed back. One line per action is enough. Keep it somewhere the agent can write to but can't edit afterward. Bank regulators now ask for the same record: Reuters reported on Oct 13 that the Fed, the OCC and the FDIC are asking banks what limits they put on AI agents, how those agents' actions are monitored and approved, and whether their decisions can be tracked and audited.

Then read it. Set a fixed slot each week to skim the log for one agent. You're looking for actions you didn't expect: a file it shouldn't have opened, a tool it called more than the job needs, a run that looped. Google pitches real-time monitoring of its agent logs to "catch anomalous behavior before it matters." Yours only do that if someone looks.

Put a cap on it that stops work

Google's spend cap does one specific thing: when the project hits its limit, the agent pauses until a person resumes it. Google says it watches both token usage and sandbox costs.

You can build the same thing without Google. Give each agent its own billing project or API key with the model provider, so its spend shows up on its own line. Then set a limit on that key or project.

Check what the limit does. Some settings stop calls when the limit is hit. Others only send an email while the agent keeps running. Only the first one is a cap. If your provider only offers alerts, route the alert to a person who can revoke the key that day.

Set the first cap from what the agent's job should cost, not from what feels safe. Then adjust it once you've seen a few weeks of real spend. A cap that trips on a normal day will get raised until it means nothing.

Per-agent tracking also gives you the number a client or department will ask for: what this agent cost this month.

Write down which models it may call

Google lets admins limit which models agents can use, and its automatic routing then picks only from that list. Do the same by hand.

For each agent, write the models it's allowed to call and the exact versions. Put the list where the agent's config reads it, so an unlisted model fails instead of running. A new model gets added the same way a new permission does: someone tests it on that agent's real work, then adds it with a date.

Two reasons. Providers have different terms for your data, and the list is where you decide which ones see your customers' messages. And when the agent starts behaving differently, you want to know whether the model changed under it.

This week

Pick the agent that runs most often. Give it its own account and a folder with only what it needs. Turn on a log you'll actually read, give it its own key with a limit that stops it, and write down the models it may call. Then do the next agent.

We wrote about what the seat means for how you price agent work in The agent seat is a control plane. This note is the setup underneath it.

Tell us which jobs you want off your plate. We install Always On Agents in your own agent account. We still take on build work too. Start your build or write hello@mail.22atlas.com.

Linked sources

Get our Articles and posts by email.

Up to one email a day with new Articles and posts from 22atlas.com and sean-weldon.com, plus occasional news about 22Atlas services.