Virtual Teammates Are Users Now. Scope Them That Way.

Matt Damon

26 Oct 2026 • 12 min read

At Opticon in New York at the start of September, Optimizely put a virtual teammate named Paige on stage. She spotted a gap on Optimizely's own site, dug into the analytics, proposed new messaging, generated a revised landing page, and routed it for approval. It was a good demo. For anyone who has to implement this, it was also the least interesting part of the launch.

The interesting part is one sentence in the documentation. Each Virtual Teammate gets its own Opti ID account, with its own login and email address, and is flagged as a virtual user.

That sentence changes who you're talking to on the client side. A chat assistant is a feature, and marketing can turn it on. Something with a login is an identity, and identities belong to the security team. On our engagements, I expect the first hard question won't be what a teammate can do. It will be what a teammate can touch, and who answers for it when it touches the wrong thing.

This post is the scoping conversation I think partners should have before a client hires its first teammate. It's based on the documentation as it stands in late October rather than a production rollout, so treat the recommendations as a starting position, not a playbook.

A quick note on names, since I wrote about Opal a few times last year. Since Opticon, Opal has been the Optimizely Agent Platform, and the AI you chat with is Mark. You'll still see "Opal" in parts of the docs. I'll use the new names throughout.

A teammate has two identities, and only one of them is its own

Inside Optimizely, a Virtual Teammate acts as itself. When it edits a content item or stages an experiment, the action is taken under its own Opti ID account. This is the part of the model Optimizely got right, and it's better than most agent tooling I've worked with. The teammate is a distinct principal that doesn't automatically get access to everything its owner has. You grant it access the same way you'd grant it to a person, and it doesn't take a product seat while doing so.

Outside Optimizely, the model flips. In third-party products, a teammate acts through an account that a person connects on its behalf, usually whoever hired it. It can't authorize a third-party connection on its own. So when a Chief of Staff teammate reads a calendar or sends a follow-up email through the Google Workspace connector, it's doing that through your marketing director's account.

Attribution is the first casualty. This part is my read of how delegated access usually works, not something the Optimizely docs spell out. In a tool like Google Workspace, the teammate's actions land in the audit log under the human's account. Google can likely see that Optimizely's app did it, but not which teammate, or that a teammate was involved at all. Optimizely keeps teammate usage separate from human usage on its side, so the full answer lives in the Agent Platform, not in Google's logs. If a client's security team investigates an unexpected email sent from a director's mailbox, somebody needs to know to look there, and today that's a runbook entry nobody has written.

Scope is the second. "It uses only the access you grant it" holds up well inside Optimizely, where you assign Opti ID roles per instance and CMS access rights per content item. Connectors are coarser. The docs don't describe connector scopes at all. The documented controls are which connectors an administrator makes available to the organization and whether a person connects or disconnects one. Once the Google Workspace connector is connected, its tools include sending email from that person's Gmail account, whether or not the teammate's jobs need it. Your practical control is closer to the connector's full tool set than to the teammate's job description.

The practical move, where the third-party product allows it, is to stop connecting personal accounts. Have the hiring manager connect a purpose-specific account instead, something like a marketing-ops mailbox or a GA4 user with read-only property access. That restores a clean line in the third-party audit log and decouples the teammate from one employee's identity. It isn't free: a dedicated Workspace account usually costs a license, and some SaaS terms don't allow shared or non-human accounts. Price that into the scope rather than discovering it in week three.

Scoping access inside Optimizely

Access inside Optimizely takes two steps, and the first one doesn't do what it looks like it does. Choosing a product and instance for a teammate tells it where to work. It doesn't grant anything. An administrator still has to assign the teammate a role on each instance in the Opti ID Admin Center. I'd put that sentence in bold in any client-facing setup guide, because the UI makes the connection step feel like the permission step.

CMS 13 and CMS SaaS add a second layer. After the Opti ID role, you add the teammate under Set Access Rights and give it rights per content item, anywhere from Read up through Publish and Administer. That's the same model your content editors already live under, which is exactly why it works. It's also where I'd spend most of the scoping time.

Our starting position is to give teammates a dedicated Opti ID role and grant CMS rights to that role rather than to each teammate. The docs only show adding a teammate individually, so test the role approach on a non-production instance before you rely on it. Either way, withhold Publish. On a headless build, publishing isn't a staging step. The frontend asks Graph for published content, so the moment an item publishes, it's what visitors get on the next request. A teammate with Create and Change can still do nearly all of the useful work, drafting and revising and filling in metadata, while the publish decision stays with a person in the normal approval flow. The Opticon demo stopped at approval, and that's the right instinct. On a regulated client's site, publish is the action compliance cares about most.

One caveat about CMS 12. The documentation only describes content access rights for CMS 13 and SaaS. The Agent Platform's Graph tools are listed for CMS 12 PaaS, so reading CMS 12 content through Graph may work, but nothing documents a teammate creating or changing CMS 12 content. Don't promise it to a client still on 12. It's on the list of open questions at the end of this post, and I expect it to become one more line in the upgrade conversation.

Autonomy is a dial. Write down who turns it.

By default, a teammate drafts and proposes, and you, or another of its managers, approve or redirect the work over Team Messages before it acts. Once results are consistent, you can let specific actions run on their own within boundaries you set, and change those boundaries whenever you like.

That default is the right one, and I'd leave it on longer than most clients will want to. The setting I'd actually worry about isn't automatic, though. It's approval that has stopped meaning anything. A manager clearing forty proposals a day across a few teammates isn't reviewing anymore. They're clicking. That's worse than an honest automatic setting, because the record says a human looked.

So the deliverable we're adding to scope is small: a graduation policy per teammate. For each action that might go automatic, write down what evidence justifies the move, such as a few weeks of approved proposals that needed no material edits. Then name who signs off on the change and when it gets looked at again. It fits on a page. The value is that moving the dial becomes a decision somebody made, rather than something that drifted.

The audit trail has a seam

The first section was about a teammate's actions landing under a human's name in third-party tools. Inside the Agent Platform, the reverse can happen.

From a teammate's page, you can switch identity and work as the teammate. From that point, every action is taken as the teammate until you switch back. It's a useful feature. It's how you manage a teammate's connectors, and I'd expect it to be how you fix a job that has gone sideways. It also means a person's actions can be recorded under the teammate's name. The overview says a teammate fits your existing access and audit processes, but the documentation doesn't say whether the activity record captures who was really at the keyboard during one of these sessions. If it doesn't, an investigation that starts with "the teammate did it" can end with nobody able to say which person did.

The logs themselves are the second gap. The Agent activity logs page covers specialized and workflow agents. It records who triggered each execution, along with its status and approximate credit cost, and it doesn't mention teammates or an on-behalf-of user. The per-agent log pages do support manual export to CSV or Excel, capped at the 500 most recent runs for specialized agents. What I couldn't find anywhere is a retention period, an API, or a streaming feed. Teammates have their own activity view, a history of runs and a record of what they've produced, but that's a screen, not a feed. Every regulated client I've worked with will want that activity in their SIEM next to everything else, and today the honest answer is manual exports.

Private executions add a wrinkle. When they're turned on, only the user who triggered an execution can open its contents, and I found no documented override for administrators. That's reasonable for a personal draft. It's a harder conversation when a security reviewer needs to see what an agent did with production access.

Finally, map where a teammate talks. Teammates message each other, join Agent Platform meetings, and share transcript summaries in Teams and Slack. CMSWire's Opticon coverage reported that they can carry on outside Optimizely too, even over SMS. Each of those channels is an egress path for whatever the teammate knows, and each one belongs in the client's data loss prevention review before go-live, not after. The channels are configurable per teammate, which helps.

Lifecycle: hiring, offboarding, and memory

Hiring is decentralized by design. An administrator enables a teammate for the organization, and from then on each user hires and configures their own. Admins can freeze hiring and control which jobs a teammate makes available. Without a policy on top of that, you get agent sprawl: a growing set of persistent actors, each configured by whoever hired it, some of them with production content access. The fix is unglamorous. Decide who can hire which teammates, and keep an inventory the same way you'd track service accounts.

Offboarding is where the "on behalf of" model bites again. A teammate's third-party connectors run through the account of the person who connected them. When that person leaves and the identity team disables their account, I'd expect those connectors to stop working, probably quietly, with jobs failing where nobody is watching. If the account isn't disabled promptly, the outcome is worse: the teammate keeps acting as a former employee. The Roles setting refers to a teammate's managers in the plural, which suggests you can name more than one, but I haven't found how ownership moves when the person who hired a teammate leaves. That one is on the open questions list too.

Then there's teardown. Deactivating a teammate is permanent and deletes the memory and context it has gathered. Pausing is the reversible option. For most clients that's a convenience detail. For a regulated client, a teammate's memory may hold material that counts as a business record, and deleting it could conflict with a retention schedule or a legal hold. Settle that with the client's records team before anyone gets near the Deactivate button, and default to Pause until then.

Which points at the broader issue: memory is a data store. Ask what lands in it. A Chief of Staff with mail and calendar connected will accumulate meeting context and email content. A Marketing Analyst will hold analytics data. Classify it like any other repository the client owns, because from a data governance standpoint that's what it is.

Credits: spending scales with every hire

Everyone watches credits, and unattended spending isn't new. Workflow agents could already run on a schedule, a webhook, or an inbound email well before teammates arrived. What changes is who sets that spending in motion. A workflow agent's trigger is something a builder created on purpose. A teammate arrives from the directory with its jobs already defined, and every user who hires one gets their own copy. The Chief of Staff, for example, comes with a daily brief, a weekly brief, and prep and a recap for each meeting. If those jobs are left on, ten people hiring a Chief of Staff means spend that follows ten calendars, and nobody designed any of it.

The math is simple, with one caveat. For workflow agents, cost is the sum of the agents invoked, with no overhead for the workflow itself. The docs don't say whether teammate jobs are billed the same way, so treat this as an estimate. The Page Builder agent averages about 130 credits a run, so a job that calls it once a day would use around 3,900 credits a month. For comparison, each instance's complimentary allowance is 200 credits a month, and Optimizely says that allowance runs through December 31 and can be changed or ended at any time.

The controls are coarse. Optimizely doesn't support credit limits per user; you control spend by controlling who has Agent Platform access. Administrators can see usage in the Opti ID Admin Center, sign up for monthly usage notifications, and get notified when the organization hits its limit. Optimizely's own docs note that those notifications don't stop you from going over, so none of them will catch a misconfigured event trigger in the middle of the month. The docs do say teammate usage is tracked separately from human usage, which should help with chargeback. Put a monthly credit estimate for each teammate in the scope, and make someone responsible for reading the dashboard.

The timing matters if you're in Q4 budget conversations now. The complimentary allowance ends right around the time most clients will be moving their first teammates into production.

Subprocessors and the kill switch

Two items belong in front of procurement and in the incident runbook.

Since March 15, 2026, Anthropic's Claude models, accessed through Google Vertex AI, have been among the Agent Platform's approved LLMs alongside Google Gemini, and Anthropic is an Optimizely sub-processor under its Data Processor Agreement. Optimizely may allocate workloads to any approved model and reserves the right to add, remove, or substitute them. That's normal for an AI platform. Regulated clients will still want to hear it during procurement, not after a teammate has been reading an inbox for a month.

The kill switch exists, with fine print. Administrators can turn off generative AI across Optimizely applications from the Opti ID Admin Center. As the docs describe it, admins can't turn it back on themselves, so reversing it is a call to Optimizely Support, not a toggle. For a single misbehaving teammate, Pause is the right tool, and it's also the one that doesn't destroy memory. Name who holds each switch in the client's incident runbook, and make sure they know which one to reach for.

What the docs don't answer yet

These are questions our clients have already asked us, and as of this writing the documentation doesn't answer them. Seven weeks after the announcement, that isn't surprising. I'll come back to them in a follow-up post as answers come in.

When someone acts as a teammate, does the activity record show who was really at the keyboard?
Do teammate runs appear in the Agent activity logs, and is there an API, streaming feed, or retention period beyond manual CSV exports?
Can an administrator or security reviewer open a private execution?
How does ownership of a teammate move when the person who hired it leaves?
Who can change a teammate's autonomy boundaries?
How are teammate jobs billed, and whose credits do they draw on?
Can an administrator turn off individual tools within a connector, such as allowing Gmail read but not send?
Can teammates create or change CMS 12 PaaS content, or only read it through Graph?
Do custom tools receive the teammate's identity and the person it's acting for, so a tool can make its own authorization decisions?
Can teammates be provisioned and configured as code, so a teammate's setup can be versioned and promoted from a test instance to production?

The last two belong to a bigger question that deserves its own post: what is a developer's job here? The documentation is written almost entirely for users and administrators. My read is that developers don't build teammates. They build the tools and integrations teammates call. That's where the follow-up will pick up.

What this doesn't solve

Everything above is about controlling a teammate. None of it makes a teammate's work good. Teammates operate on whatever content model and data they're given. KPMG's story at Opticon, as CMSWire reported it, was consolidation first: they retired legacy intake systems and replaced ad hoc approvals before layering agents on top. CMSWire's Opticon analysis framed the event around a readiness gap, and that framing is right. A well-scoped teammate working in a disorganized content repository will produce well-governed messes, faster.

Where we are with it at WOW

Regulated industries are moving slower on this, and they should. We're working through exactly these questions with our newest Optimizely clients right now, and nearly every conversation comes back to the principle we apply to any AI system we build: the work stays accountable to a person.

A Virtual Teammate doesn't change that. It changes where the accountability sits. When a teammate proposes and someone approves, that person owns the result, the same as if they'd written it themselves. When an action has been graduated to run on its own, accountability belongs to whoever set that boundary, and the boundary is only as good as the review behind it. In both cases, someone with a name is still validating and confirming the work. Most of the scoping in this post comes down to making sure that person exists and can see what the teammate actually did.