Product

From request to audit log — attributed to a real principal.

A Role Twin is a per-customer isolated container bound to a real user identity in your IDM. It accepts work through the surfaces Corporate IT already uses — chat and DMs are common; email, agent-to-agent, and tool-to-tool paths fit the same spine — runs admin actions as itself, and lands every entry in your own audit log under its name, on behalf of a named human. Never a login as them. L1 is live on Microsoft 365, Google Workspace, Azure, and GCP.

Example surface · chat

One request path, illustrated.

Doug needs to grant a new hire an E3 license. He doesn’t open an admin portal. He reaches Avery the way he’d reach any colleague — here, a chat DM. The same confirmation and dual-audit loop applies when the request arrives another way.

  1. Doug finds avery@yourco.com in the directory and starts a request.
  2. Doug describes what he needs in plain English.
  3. Avery summarises the intended action and asks for explicit confirmation.
  4. Doug confirms with yes. Avery runs the change as itself.
  5. Audit entry lands under Avery’s name, on behalf of Doug, with Doug’s confirmation timestamp.
Av
Avery
IT Support · Available
Can you give Sarah Lin an E3 license? She started today.
I'll assign E3 to sarah.lin@yourco.com. Confirm with "yes".
Avery · just now
yes
Done. Logged under Avery, on behalf of Doug, with your confirmation.
Avery · 3s ago

The same identity spine covers L1 across your platforms today. L2 paths — deeper cloud ops and cost intelligence — are rolling out under the same gate and audit spine, whatever surface brought the request in.

Av
Avery
IT Support · Available
add jordan to the sales-shared group
I'll add jordan@yourco.com to sales-shared. Confirm with "yes".
just now · L1 live
Av
Avery
IT Support · Available
restart the prod web app, it's hung
I'll restart web-01 in prod with JIT elevation of my own identity. Confirm with "yes".
just now · L2 rolling out
L1 platforms · live

First-line work where Corporate IT already lives.

Accounts, access, licenses, groups, and routine admin — same Role Twin, same confirmation, same dual audit.

L1 live

Microsoft 365

Entra directory, licenses, groups, mailbox and calendar admin — same twin model.

L1 live

Google Workspace

Workspace directory and first-line identity admin under the same twin model.

L1 live

Azure

First-line Azure identity and access work for Corporate IT, dual-attributed.

L1 live

GCP

First-line Google Cloud identity and access work — same spine as the rest.

Request surfaces

Channel-agnostic by design.

The twin’s value is identity, confirmation, and dual audit — not a single front door. Chat is a natural surface for people; the product spine is built so work can also arrive from email, agent-to-agent calls, MCP and other tool protocols, or whatever channel you enable later.

People surfaces

Chat / DM and email-style request paths — where end users already ask IT for help.

System surfaces

Agent-to-agent and tool-to-tool (including MCP) so automation can invoke the same governed twin principal.

One spine

Same dual attribution, confirmation policy, and action catalog — the ingress adapter changes, the audit story does not.

Behind the scenes

Five hops. Your audit log is the system of record.

  • 1. Request arrives. Ingress from an enabled surface (chat, email, agent, tool, …) into the customer container.
  • 2. Reasoning. Orchestrator runs managed or private, isolated inference.
  • 3. Tool call. Picks a registered action from the twin’s catalog.
  • 4. Confirmation gate. State-changing tools require explicit "yes", bound to the requester when a human is in the loop.
  • 5. Action + response. Execute as the twin principal; reply on the originating surface; dual audit entry.
# Confirmed run, conceptually
on request(from=doug, surface=…):
  intent = orchestrator.reason(payload)
  if intent.is_state_changing:
    reply("I'll {{summary}}. Confirm with 'yes'.")
    await requester_confirm()
  result = tools.call(intent.action, intent.args)
  reply("Done — logged {{result.audit_id}}")

# Audit (extract):
# Actor:          avery@yourco.com
# RequestedBy:    doug@yourco.com
# ConfirmedAt:    2026-05-21T10:14:05Z
# Operation:      license.assign

L2 · JIT elevation for escalations Rolling out

Deeper cloud operations and high-stakes writes elevate the twin’s own identity just-in-time, time-bound, then drop. Zero standing infrastructure admin. Same confirmation gate as L1.

Role Twin vs Team Twin

Same spine. Different bonding.

Available now

Role Twin

One twin for a job function — usually first-line IT. Shared desk coverage for the org. L1 live across M365, Workspace, Azure, and GCP; L2 for that role is rolling out.

Roadmap

Team Twin

Same spine, shaped around how your team works — handoff, pause, take-back per person without shutting coverage off for everyone. Complements Role Twin. See roadmap →

Action surface

Narrow catalog. No shell. No surprise scope.

If it isn’t a registered action, it can’t happen.

license assign / revoke L1
user create / disable / enable L1
password & access recovery L1
group membership changes L1
joiner / mover / leaver L1
mailbox & calendar access L1
cloud cost intelligence L2
resource start / stop / restart L2

See Avery in a sandbox.

20-minute live demo — request work from a Role Twin, watch dual audit, stand up yours when ready.