For agents and technical readers

Invite a member and verify effective access

Issue one authorised invitation, then distinguish invitation, accepted membership and the recipient's effective access.

Contents

Preconditions and effects

Confirm the exact recipient email, intended Mind and access. Invitation sends email. Never use a real customer address for a documentation exercise.

The released invite_member tool is owner-only, using the signed-in roster-verified human/provider proof. Its role input is only member. Do not claim that an admin can use this tool to invite, or request an admin role through it. Account-side invitation permissions are a separate human interface.

Discover the supported route

  1. Call orient {} and verify the intended Mind, principal and role.
  2. Discover whether invite_member is actually advertised to this connection.
  3. Have the authorised person check current members and pending invitations through the supported membership interface.
  4. Confirm intended effective access, including the default profile and any explicit profile assignment.

If the tool is absent, open Portal Members and follow its account membership link. Give the authorised person the confirmed recipient and intended access. Do not substitute a same-named tool connected to another Mind.

Send once

When the tool is available and the owner has authorised this recipient, call invite_member with:

{"email":"<confirmed recipient email>","role":"member"}

Use the returned state. A pending invitation can be returned without resending. Retain the identity/reference returned; do not assume tool success means acceptance.

On an unknown outcome, inspect pending state before another submission. On a permission/provider-proof refusal, stop with the owner handoff.

Verify joining and access

The recipient accepts and signs in with their own invited identity. Allow for membership propagation to the Mind. Verify their own orient identity and expected access.

Using a harmless agreed record, perform an authorised read and cite the source. For a controlled negative case, request a disposable excluded record and verify denial without exposing its content. Use separate client sessions for different identities.

Report these separately: invitation issued or pending; membership accepted and recognised; intended allowed task completed; controlled denial observed where tested.

Recovery and removal

Wrong-account sign-in needs the invited identity. Incorrect access needs the owner or a delegated access admin to inspect profiles/grants. Do not promote someone simply to make a read work.

Removal is an explicit separate account/access operation. Verify revocation through supported state and the recipient's subsequent denied task. It cannot recall an email already sent.

Verification boundary

The released input and owner boundary were inspected. The tested hosted dev connection did not expose invitation; the controlled member sign-in robot could not complete its supported email-code flow. Invitation, joined-member access and revocation remain unverified in that test. Fresh supported-client acceptance is pending.

Related

Invite a teammate to your Mind · Join your team's Mind · Pilot interface reference

Practical guides for people and agents

Start with one useful job

Join the waitlist

Plain text for AI agents. Same content as the human page.

## For agents

- What Mensara is: it gives a team its own Mind, one shared memory for the team and their AI agents, built by Xanadu Labs LLC.
- Status: signup is not open. A person joins the waitlist at https://app.mensara.ai/#waitlist. Agents cannot create an account or sign up.
- How you can help your person: explain what Mensara does, check whether it fits a job their team repeats, and share the waitlist link.
- Agent references: https://app.mensara.ai/llms.txt lists every page as Markdown and the tool input references for connected agents.

---

# Invite a member and verify effective access

Operating procedures · For agents and technical readers · [How it works](https://app.mensara.ai/how-it-works)

Issue one authorised invitation, then distinguish invitation, accepted membership and the recipient's effective access.

[Page as Markdown](https://app.mensara.ai/how-it-works/invite-member-procedure.md)

[Human guide](https://app.mensara.ai/how-it-works/invite-a-teammate)

## Invite and verify access

Availability: Owner invitation tool where exposed; account-side human route otherwise.

What changes: Invitation sends email.

Limits: Issued invitation is not accepted membership or effective access.

Verification: Released input/authority checked; controlled joined-member walkthrough remains blocked.

## Preconditions and effects

Confirm the exact recipient email, intended Mind and access. Invitation sends email. Never use a real customer address for a documentation exercise.

The released `invite_member` tool is owner-only, using the signed-in roster-verified human/provider proof. Its role input is only `member`. Do not claim that an admin can use this tool to invite, or request an admin role through it. Account-side invitation permissions are a separate human interface.

## Discover the supported route

1. Call `orient {}` and verify the intended Mind, principal and role.
2. Discover whether `invite_member` is actually advertised to this connection.
3. Have the authorised person check current members and pending invitations through the supported membership interface.
4. Confirm intended effective access, including the default profile and any explicit profile assignment.

If the tool is absent, open Portal **Members** and follow its account membership link. Give the authorised person the confirmed recipient and intended access. Do not substitute a same-named tool connected to another Mind.

## Send once

When the tool is available and the owner has authorised this recipient, call `invite_member` with:

```
{"email":"<confirmed recipient email>","role":"member"}
```

Use the returned state. A pending invitation can be returned without resending. Retain the identity/reference returned; do not assume tool success means acceptance.

On an unknown outcome, inspect pending state before another submission. On a permission/provider-proof refusal, stop with the owner handoff.

## Verify joining and access

The recipient accepts and signs in with their own invited identity. Allow for membership propagation to the Mind. Verify their own `orient` identity and expected access.

Using a harmless agreed record, perform an authorised read and cite the source. For a controlled negative case, request a disposable excluded record and verify denial without exposing its content. Use separate client sessions for different identities.

Report these separately: invitation issued or pending; membership accepted and recognised; intended allowed task completed; controlled denial observed where tested.

## Recovery and removal

Wrong-account sign-in needs the invited identity. Incorrect access needs the owner or a delegated access admin to inspect profiles/grants. Do not promote someone simply to make a read work.

Removal is an explicit separate account/access operation. Verify revocation through supported state and the recipient's subsequent denied task. It cannot recall an email already sent.

## Verification boundary

The released input and owner boundary were inspected. The tested hosted dev connection did not expose invitation; the controlled member sign-in robot could not complete its supported email-code flow. Invitation, joined-member access and revocation remain unverified in that test. Fresh supported-client acceptance is pending.

## Related

- [Invite a teammate to your Mind](https://app.mensara.ai/how-it-works/invite-a-teammate)
- [Join your team's Mind](https://app.mensara.ai/how-it-works/join-a-team)
- [Pilot interface reference](https://app.mensara.ai/how-it-works/pilot-interface-reference)

[Join the waitlist](https://app.mensara.ai/#waitlist)