aidizen ships Aids — per-customer Linux containers bound to a real identity in your IDM. An Aid shows up in Teams, takes DMs, and takes action against your admin surface. Everything they do is logged in your own audit trail under their name — because they are a first-class citizen in your enterprise, not an employee, not a bot identity.
A live example. Doug needs to grant a new hire an E3 license. He doesn't need to know what an "Entra group" is, or where the M365 admin centre lives. He just DMs Sam, the way he DMs anybody.
SamHelpDesk@clinicalcarepartners.com in the directory, starts a DM.m365.license.assign at 10:14.
Five hops. The customer's audit log is the source of truth — everything the Aid does ends there.
m365_license_assign).# A typical confirmed run, conceptually on teams_dm(from=doug): intent = orchestrator.reason(message) if intent.is_state_changing: reply("I'll {{summary}}. Confirm with 'yes'.") await user_confirm() result = mcp.call(intent.tool, intent.args) reply("Done. {{result.summary}} — logged {{result.audit_id}}") # Audit log entry, customer-side: # actor: SamHelpDesk@clinicalcarepartners.com # action: m365.license.assign # target: sarah.lin@clinicalcarepartners.com (E3) # on_behalf_of: doug@clinicalcarepartners.com # confirmed_at: 2026-05-21T10:14:08Z
Narrow surface on purpose. The Aid declines anything outside the catalog. Anything genuinely unusual escalates to a human — by design, not as a bug.
Every tool emits a structured audit record. v2 expands the catalog (conditional access, device, Exchange transport, SharePoint sharing). Customer-specific runbooks land in v3 as the skills marketplace.
The orchestrator slot is pluggable. We integrate over MCP, so any compliant harness can drive aidizen's tool surface. The deployment, the audit, the integration to Teams — all identical regardless of which brain is selected.
Swap orchestrators per-customer without changing anything about the audit trail, the tool surface, or the end-user experience.
The pattern — "a first-class citizen in your enterprise that acts like an admin" — is what makes the audit story work. We're building on open identity protocols (some we're authoring) so that pattern is portable.
Microsoft 365 + Entra is v1. The Aid uses two app registrations: a narrow one for chat, a broader one for admin actions. Graph subscriptions deliver DMs.
Shipping
The same Aid pattern, the same audit posture, against each IDM's native primitives. Identity adapter swap; the rest is unchanged.
Roadmap · 2026
The system that already knows who an employee is should also be where the Aid identity is provisioned. That's the v3 horizon and the protocol work is for.
Horizon · v3
Creates the AIAid user (e.g. SamHelpDesk@yourco.com), registers two app registrations
(chat scope + admin scope), and grants admin consent. Our shell script drives this via Graph; it's roughly
three commands.
Runs onboard-customer.sh on aidizen's hosting infrastructure (peasyCloud). The script allocates
a port, generates secrets, brings up the per-customer container, walks the AIAid user through a device-code
login, and starts the Graph webhook subscription.
They just start DM'ing the Aid in Teams. No client install, no browser extension, no portal. The Aid is a first-class citizen in your enterprise.
Day-2 operations — credential rotation, persona swaps, capability changes, customer offboarding — all have runbooks. All operator-side. None customer-facing.
We chose to ship one thing well rather than ten things half-built. The boundary is part of the product.
Scope is admin actions, period. The Aid declines anything outside its tool catalog.
Strong on the high-frequency, well-defined surface. Anything genuinely unusual escalates to a human.
Microsoft Teams DM is the v1 surface. Email and SMS land in v3 — explicitly later, not sooner.
The Aid is a first-class citizen in your enterprise, not a bot, not a service account. That distinction is the entire audit-and-compliance story.
We'll bring a Sam HelpDesk into a sandbox, DM it together, then show you the audit log.