About

Aids belong in your identity system.

aidizen is an independent company building the Aid identity layer for IT. We started with the highest-volume, best-defined helpdesk surface — Microsoft 365 — and a single conviction: the Aid should be a real principal in your IDM, not a bot wedged into a chat surface. Everything else flows from that.

Why we exist

The "first-class citizen in your enterprise" pattern shouldn't be a vendor's secret.

For two years the AI conversation has been about what models can do. The harder problem turned out to be: who is the AI citizen, where does it live, who can it act for, and where does its activity land in the audit log? Those are identity questions, not model questions.

We call our answer an Aid. An Aid is a first-class citizen in your enterprise — peers of your team, not employees, not bots. They have identity, presence, and an audit trail like any colleague. They show up where work happens.

aidizen exists to ship Aids — and to keep the underlying pattern open. We ship the product, and we publish the identity primitives Aids depend on so the broader ecosystem can adopt the same model.

What we're optimising for

  • Aids are first-class citizens in your enterprise — peers in the directory, not employees, not bots.
  • The Aid is a real principal in the IDM, by construction.
  • Every action is in the customer's own audit log, under the Aid's name.
  • Tenant boundary is a container boundary — no exceptions.
  • The brain is interchangeable. The Aid is not.
  • The protocols Aids depend on are open. Anyone can implement them.
Identity protocols

The work we're publishing.

We're authoring the Aid-identity primitives we depend on as open protocols. The point isn't to own the ecosystem — it's to make sure the audit-clean, IDM-agnostic Aid pattern is durable enough to outlast any single IDM, any single agent harness, any single model.

Aid provisioning

A standard shape for "create an Aid identity in an IDM" — display name, presence, scoped capabilities, audit metadata — so the same Aid can be provisioned in Entra, Okta, Workspace, JumpCloud, or anything that comes next.

Capability descriptors

How an Aid declares what it can do in a way IDMs and audit systems can reason about. Pairs with MCP for the wire protocol; this is the identity-side complement.

Audit shape

A canonical event shape for "Aid acted on behalf of human" that includes the confirmation gate. Maps cleanly to existing M365 / Okta / Workspace audit logs.

Presence & routing

How an Aid advertises availability and how DMs route to the right per-customer container without leaking topology to the end user.

Offboarding / lifecycle

How an Aid identity is torn down across the IDM, the container host, and the audit log — without orphaning state on either side.

IDM ⇄ HRIS bridge

The v3 horizon: Aid identities sourced from (and recorded in) the systems that already define who works at a company. Aids belong in those records too — as first-class citizens, not contractors, not bots. Specs to follow as we get there.

The drafts publish as we ship. Want to be notified when a spec lands? Tell us.

Why now

Three things had to be true. They are.

1. MCP became the lingua franca

Anthropic's protocol got adopted across Claude, Cursor, the OpenAI ecosystem, Nous, and several open-source harnesses in under 18 months. aidizen's tool surface is an MCP server — which means any LLM that speaks MCP can drive it. Including ones that don't exist yet.

2. Real agent harnesses shipped

OpenClaw, Hermes and others are now production-ready with their own gateways, memory, skills, and scheduled tasks. We don't have to build the brain. We plug into whichever brain the customer wants.

3. Graph subscriptions matured

Webhook delivery for Teams DMs is now reliable enough to be a production interaction surface. As recently as 2023, it wasn't. The plumbing the product depends on finally works.

Where we run

Hosted on peasyCloud.

aidizen's per-customer containers run on peasyCloud — a regional, audit-friendly container host designed for tenant-isolated workloads. peasyCloud is operated independently; we're a customer of it, not an owner. That separation is a feature: our hosting boundary is itself an operator boundary.

Regions are available in US and EU today, with additional residency options on the v2 roadmap to support customers with strict data-residency obligations.

The hosting picture

  • One Linux container per customer tenant.
  • Per-customer encryption-at-rest keys.
  • EU / US regions; more on the roadmap.
  • SBOM & signed images on request.
  • Independent of any single LLM provider.
Roadmap

v1 → v2 → v3, in one line each.

v1 — Now

Per-customer container, Teams DM only, ~13 admin tools, three orchestrator options. Manual onboarding by our operator.

Shipping

v2 — Next 6 months

Customer-self-service onboarding portal. Proactive scheduled work (Monday-morning license reviews, expiring access). Expanded tool catalog. SOC 2 Type II. Okta + Google Workspace adapters in beta.

In progress

v3 — 2027

Multi-channel (email + SMS for after-hours). Skills marketplace (customer-specific runbooks). Analytics dashboard. HRIS / employee-system bridge. Full identity-protocol publication.

Horizon

The names you'll see

Who is who in our world.

Aid

The thing we ship. A first-class citizen in your enterprise — peer, not employee, not bot. They have identity, presence and an audit trail.

aidizen

The product. The company. The customer-facing brand. This site.

peasyCloud

The container infrastructure that hosts each per-customer Aid. Operated independently; we're a customer of it.

Sam HelpDesk

The example Aid we use throughout the docs. In your tenant, your Aid is named whatever you want.

Want to follow the work?

Subscribe to protocol drafts and product updates. We send one email a month — no marketing fluff.