aidizen ships Aids — first-class citizens in your enterprise, with their own name, Teams presence and audit trail. Not an employee. Not a bot. A peer in the directory who handles passwords, licenses and group changes. End users DM them like any colleague. Every action lands in your own audit log under the Aid's name.
And the Aid is free. We get paid only when you love working with us and want help on other cool projects.
Aids live as first-class citizens in your enterprise — Microsoft 365 today, more on the way
An Aid is a first-class citizen in your enterprise. They have an identity in your IDM, a presence in Teams, and an audit trail behind everything they do — the same posture as any colleague in the directory. They take DMs. They take action. They belong there.
Aids aren't humans. They don't draw salary, take PTO, or sit in standups. The HR system doesn't track them as workforce — but the IDM treats them as first-class principals.
"Bot identities" are second-class shadow accounts that don't appear in audit trails the way humans do. Aids are real principals in the directory. Their actions land in the audit log under their name.
A new category: same standing in your enterprise as a colleague, but a different kind of contributor. They show up where work happens — in Teams, in groups, in the audit log — as themselves.
Every IT team running Microsoft 365 (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 real user identity in your IDM. Talks like a colleague, acts like an admin. Audit-clean by construction. Per-customer-isolated by construction. Bring-your-own LLM by construction. Microsoft 365 + Entra today — any IDM tomorrow, on open identity protocols we're publishing.
Each Aid is bound to a real identity in your IDM (e.g. SamHelpDesk@yourco.com) with a friendly display name and the green "Available" dot in Teams 24/7. Not a service account. Not a bot identity. A peer who shows up in the directory like any other citizen.
When asked, it actually does it — via Microsoft Graph today. Every action lands in your normal audit log under the Aid'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.
Three short steps — the same shape across IDMs. We provide the scripts; you run them.
The customer's M365 admin creates the Aid's identity (e.g. SamHelpDesk@yourco.com), registers two app registrations (one narrow for chat, one broader for admin actions), and admin-consents both. A shell script drives this via Graph in ~3 commands. (Same shape for Okta / Workspace as those land.)
onboard-customer.shAllocates a port, generates secrets, brings up the per-customer container on peasyCloud, walks the Aid through a device-code login, and starts the webhook subscription. ~5 minutes.
No client install. No browser extension. The Aid is a first-class citizen in your enterprise — finding them in Teams works exactly like finding any colleague.
The "Aid is a first-class citizen in your enterprise" pattern shouldn't be locked to a vendor. We're building aidizen on top of open identity protocols — some of which we're authoring and publishing — so the same Aid identity, audit posture and tool surface work across IDMs and, eventually, across HRIS / employee systems.
We publish the Aid-identity primitives we use — provisioning, presence, capability descriptors, audit shape — so the next IDM, the next agent harness, can adopt them without re-inventing them.
Microsoft 365 is v1 because that's where the volume is. Okta, Google Workspace and JumpCloud are next. The Aid stays the same — the IDM adapter changes.
HRIS, IDM, ITSM — the same Aid identity should flow across the systems that already define who works at a company. Aids belong in those records too, as first-class citizens. That's the v3 horizon and what the protocol work is for.
Your Aid is free, forever. 20-minute setup. We earn revenue only when you love working with us and want help on other projects.