Your twin is a real user in your Identity Directory — it takes Teams DMs and grants licenses, resets passwords and fixes groups. Every action lands in your own audit log under its name, under your authority. Not an employee. Not a bot. A peer your team can DM.
We don't charge for the twin. We earn revenue only when you ask us to help on other projects.
Your twin lives in your identity system — Microsoft 365 today, more on the way
An twin is a first-class citizen in your enterprise — provisioned in your IDM with an identity, a presence and an audit trail like any colleague. Think of them as the category between "human employee" and "bot integration": they show up where work happens, but they're not pretending to be human. (Sam HelpDesk, the example you'll see throughout the site, is one of them.)
twins don't draw salary, take PTO, or sit in standups. Your HR system doesn't track them as headcount — but your IDM treats them as real principals with their own scope.
"Bot identities" are shadow accounts whose actions get attributed to the bot framework, not a named actor. Twins are real users in the directory. Their actions land in your normal audit log under their name.
Same standing in the workplace as any colleague — same name conventions, same Teams presence, same compliance posture — but a different kind of contributor.
Every team running an Identity Directory (and every MSP supporting one) burns hours on the same repetitive requests: license grants, password resets, group adds, distribution list changes. The work is high-volume, well-defined, and almost completely automatable — if the interface weren't a portal nobody remembers.
Lives in a "bot" identity that doesn't appear in any audit trail as a real actor. Locked to Microsoft's own LLM choices. Awkward conversational UX.
Works for the IT pro at their desk. Does nothing for the end user who just wants to DM somebody in Teams.
Built for ticket workflows. Not conversational. Routes work — doesn't take action.
Every team has tried. Webhook lifecycle, MSAL, tenant isolation and audit is a six-month project before you ship a single feature.
A licensed user identity in your IDM. Talks like a colleague, acts like an admin. Audit-clean because every action is just a real principal calling Graph. Per-tenant isolated because every customer gets its own container. Bring-your-own LLM. Microsoft 365 + Entra today.
Each twin is bound to a real principal in your IDM (e.g. SamHelpDesk@yourco.com) with a friendly display name and a green "Available" dot in Teams 24/7. Not an employee. Not a bot. A peer who shows up in the directory like anyone else.
Actions go through Microsoft Graph as the twin itself. The audit entry lands in your normal M365 log under the twin's name. "Sam HelpDesk assigned E3 to Doug at 10:14" — exactly what compliance already knows how to read.
One Linux container per customer. Separate encrypted token caches, separate audit logs, separate everything. A breach of one customer's deployment exposes one customer's tokens — and nothing else.
No client install. No browser extension. No "open this URL." Doug finds Sam in the directory the same way he finds anyone else — and asks for what he needs in plain language.
nurses-on-call)
group.member.add at 10:14.
Subtwin is the company. Your twin is what you get. Pick the delivery path that fits how you already work.
You run your own M365 tenant. We onboard your twin in ~20 minutes; your team uses it from day one. Free, forever.
You operate the deployments yourself, white-labelled to your brand, across your client tenants. Free per client. You keep the relationship.
Want it managed? Get your twin delivered and supported by a Subtwin-verified MSP. Current Subtwin Partners:
Three short steps — the same shape across IDMs. We provide the scripts; you run them.
Create the twin's identity (e.g. SamHelpDesk@yourco.com), register two app registrations (one narrow for chat, one broader for admin actions), and admin-consent both. A shell script drives this via Graph in ~3 commands.
onboard-customer.shAllocates a port, generates secrets, brings up the per-customer container on peasyCloud, walks the twin through a device-code login, and starts the webhook subscription. ~5 minutes on our side.
No client install. No browser extension. Sam is a real user — finding it in Teams works exactly like finding any colleague.
The "twin is a real user in your IDM" pattern shouldn't be locked to a vendor. We're building on open identity primitives — some we're authoring — so the same twin identity, audit posture and tool surface work across IDMs as adapters land.
We're working on shared primitives for twin provisioning, capability descriptors and audit shape, so the next IDM and the next agent harness can adopt them. Spec drafts publish as we ship; see About for status.
Microsoft 365 is v1 because that's where the volume is. Okta, Google Workspace and JumpCloud are next. The twin stays the same — the IDM adapter changes.
HRIS, IDM, ITSM — the same twin identity should flow across the systems that already define who works at a company. Twins belong in those records as first-class records, not contractors, not bots. The v3 horizon.
Your twin is free, forever. 20-minute setup. We earn revenue only when you love working with us and want help on other projects.