Eight things Foundations built on Root — with the prompts to build them yourself.

You are adding identity + access tiers to my community backend so it can act
as the integration behind a Root agent platform tenant (protocol root-int/1).
Root owns all conversations and calls my backend to decide who a person is.
My database stays the only authority on membership — never store membership
state on the platform side.

Context you can assume:
- I have tables for members (id uuid, name, email, slack_id, status), company
  employees (id, name, email, slack_id, status, company_id), and external
  mentors/office-hours hosts (id, name, email). Adapt to the actual schema.
- Root sends signed HTTP requests: x-root-signature is an HMAC-SHA256 of
  "<timestamp>.<rawBody>" using our shared signing secret, x-root-timestamp
  carries the timestamp. Verify both and reject stale timestamps (>5 min).

Build the following:

1. POST /integration/identity/resolve
   Body: { "channel": "slack"|"email", "slack_user_id"?, "email"? }.
   Resolution order for Slack: members.slack_id → company_employees.slack_id
   → company_employees by the Slack profile email. For email: members.email
   → company_employees.email → mentors.email (only when that mentor has a
   current or upcoming hosted session), else tier "public".
   Respond: { "principal": { principal_ref, display_name, email, tier,
   is_admin, profile_context, traits } }.
   - principal_ref MUST be my immutable row id ("<uuid>" for members,
     "employee:<uuid>" for employees, the mentor uuid for mentors) — never an
     email or name. Root anchors long-term memory to this ref; returning a
     different ref for the same human silently creates a second memory.
   - Tier vocabulary: member, company_employee, mentor, public. Deactivated
     members resolve as public, not as their old tier.
   - profile_context: 1–2 sentences (< 300 chars) the agent can use, e.g.
     "Founder at Example Co; Seattle member since 2024."

2. Email delegation (executive assistants, calendar delegates, past CCs):
   when the sender is not the mentor but thread/CC history shows they act
   for one, return the sender as the principal (tier public) PLUS an
   "acts_for" block: { reason: "current_cc"|"historical_cc"|…, principal:
   <the mentor's principal> }. Root's authorization gate uses this to allow
   actions on the mentor's own things while refusing anything else. Never
   resolve the assistant AS the mentor.

3. GET /integration/roster — all active principals (ref, tier, email,
   slack_user_id, display_name, is_admin), INCLUDING employees and mentors.
   Root sweeps this to heal stale cached tiers; anyone missing from the
   roster gets demoted, so forgetting employees here locks them out.

4. Manifest declarations: "access_tiers": ["member","company_employee",
   "mentor","public"]; every tool gated with "tiers": [...]; and tier-scoped
   "prompt_sections" that tell the agent WHO each tier is and what to do
   instead of escalating (public: membership is application-based, office
   hours and directories are member benefits — explain, don't apologize;
   mentor: visiting host with no Slack and no member portal, building access
   arrives automatically as a day-of door code).

5. Tests: the same message from a member, an employee, a mentor, and a
   stranger produces four different tool surfaces; a deactivated member
   resolves public; an employee whose Slack profile email differs from the
   roster email still resolves by slack_id.

Add a community member search tool to my Root integration backend (protocol
root-int/1 — my backend already exposes signed /integration/tools/* endpoints
and a manifest; follow the existing patterns).

1. Storage: members table gains an embedding column (pgvector) and a tsvector
   column over name + bio + company + skills/topics. Embed on every write as
   a fire-and-forget hook, AND add a recurring audit job (every ~5 min) that
   re-embeds rows where embedding IS NULL or embedding_updated_at <
   updated_at. Inline hooks alone WILL drift — restarts and transient
   embedding-API failures are normal.

2. Tool "search_members":
   - parameters: { "query": string, "limit"?: number (default 8, max 20) }
   - description tells the model WHEN to use it: any "who…", "find someone",
     expertise, industry, or intro question about the community.
   - retrieval: run vector similarity and keyword tsvector search in
     parallel, merge/dedupe candidates (~30), then one fast-model LLM call
     that picks and orders the best matches and writes a one-line
     "why this person" for each. Return structured matches:
     [{ member_id, name, email, slack_id, company, reason }].
   - ids are the point: the agent chains member_id / slack_id into profile,
     booking, and alert tools without re-matching names.

3. A shared person resolver used by EVERY tool that accepts a person
   reference: email → slack id → exact name → tokenized name match where
   middle names are optional. Deterministic SQL, no LLM. Never write a new
   exact/substring name match inside an individual tool.

4. Field discipline: select only the columns the LLM should see (name, bio
   summary, company, links). Never return the raw row — no billing fields,
   no admin notes.

5. Manifest: tiers ["member"] (the directory is a member benefit; explain
   that to public users via prompt_sections instead of erroring), channels
   ["slack","email","api"].

6. Tests: a query by expertise returns relevant members with populated ids;
   a member with a stale embedding is picked up by the audit job; a name
   with an extra middle name still resolves through the shared resolver.

Build a complete office-hours program on my backend, exposed to my Root
tenant as integration tools (root-int/1 — follow my existing signed
/integration/tools/* + manifest patterns).

1. Schema:
   - office_hours: id, mentor_id, date, start_time, end_time, status
     (active/cancelled), calendar_id (the block event's iCalUID).
   - time_slots: id, office_hour_id, start_time, end_time, status
     (available/booked), booked_by_<channel-id>, booked_by_name, topic,
     duration_minutes.
   Slots are generated when a block is scheduled (default 30 min).

2. Member tools (tiers ["member"]):
   - list_office_hours { mentor_id?, from_date?, to_date? } → blocks with
     their OPEN slots, each carrying its real slot id. The booking tool must
     only accept those ids — never let the model invent a time.
   - book_office_hours { time_slot_id, topic?, additional_guests?: string[] }
     → transactional claim (UPDATE … WHERE status='available'), with a
     one-slot-per-session guard per member. Resolve guests through the
     shared person resolver (names / handles / emails); surface unresolved
     guests in the reply, never drop them silently.
   - view_my_bookings, cancel_booking { time_slot_id },
     reschedule_booking { time_slot_id, new_slot_id },
     update_booking_topic { time_slot_id, topic } — topic updates must NOT
     rebuild the attendee list; re-read the calendar event's current
     attendees so later-added guests survive.
   - search_past_office_hours { mentor_name?, attendee_scope? } for "who did
     I meet with" questions; a "hosted" scope lets a mentor see their own
     past sessions' attendees.

3. Host tools on the email surface (tier ["mentor"]):
   schedule_hosted_office_hours, list_hosted_office_hours,
   get_office_hours_registrants, reschedule_hosted_office_hours,
   cancel_hosted_office_hours. A reschedule must carry every existing
   attendee to the new event automatically.

4. Calendar integration (Google or equivalent), idempotent by construction:
   - One event per booking keyed by iCalUID "<slot_id>-booking"; the block
     itself keyed by the office_hours row's calendar_id. Upsert by iCalUID:
     search first, patch if found, insert otherwise.
   - CRITICAL: if the existing event's status is "cancelled" (a tombstone
     from an earlier cancellation), explicitly set status "confirmed" when
     rebooking — patching a cancelled event leaves it cancelled and no
     invites go out.
   - Store absolute instants; pass the business timezone as display only.

5. Door access hooks (adapt to my access system):
   - A non-member HOST gets a door code valid the entire day of their
     session, created when the block is scheduled, revoked on cancel,
     re-issued on reschedule; embed it in their invite and confirmation.
   - Non-member GUESTS on a booking share one day-long code, embedded in
     the calendar invite. Members never need one.
   All hooks best-effort: an access-system outage must never block booking.

6. Timezone rule (this bug shipped twice): the DB and Node run in UTC but
   business dates are local. Never use CURRENT_DATE / NOW()::date or
   new Date().toISOString().split('T')[0] for "today" — from 5pm local to
   midnight they're already tomorrow. Bind "today" computed in the business
   timezone as a query parameter everywhere.

7. Ship the workflow coaching as manifest prompt_sections — the tools alone
   don't teach the agent the conversational rules:
   - tiers ["member"], channels ["slack","api"]: "book a meeting" means an
     office-hours booking; list first, then book; distinguish BOOKING from
     HOSTING (someone offering times wants to host, not grab a slot); if a
     mentor is fully booked, share their contact info instead of promising
     to watch for openings.
   - tiers ["member","mentor"], channels ["email"]: members emailing about
     office hours are usually HOSTING; email manages the resolved mentor's
     own blocks only — never attendee bookings, and never scheduling a
     block for a third party (refuse plainly; a delegate's authority does
     not transfer hosting).

8. Tests: book → cancel → rebook sends a fresh invite (tombstone revived);
   evening availability shows the right day; a guest name that matches two
   members asks for clarification instead of guessing.

Add building-access capabilities to my Root integration backend (root-int/1).
My access systems: [DESCRIBE YOURS — e.g. UniFi Access reachable through an
internal HTTP service, and/or a vendor with no API where a browser automation
against their admin dashboard is acceptable]. Follow my existing signed
/integration/tools/* + manifest patterns.

1. Tools and gating (the security model lives in the SURFACE):
   - request_building_access {} — grant/reset the CURRENT user's access for
     an office. Tiers ["member","company_employee"]; channels
     ["slack","api"] plus email ONLY for non-sensitive resets.
   - check_building_access {} — read-only status across offices; all tiers
     that can hold access.
   - unlock_front_door {} — momentary remote release. Channels
     ["slack","api"] ONLY — NEVER email: a spoofable From header must not
     produce instant physical entry. Attribute every unlock to the
     requesting principal in the result payload.
   - create_guest_door_pass { office, valid_until? } — temporary door PIN,
     max 24h, defaulting to end of the local day. Same channel restriction.
     When invoked from a public channel, DM the code to the requester and
     return a scrubbed result so the public reply just points at the DM.
   - request_access_for_teammate { person } — a member grants a teammate
     (same company) access; resolve the person through the shared resolver
     and track the grant so it's revoked when the teammate is removed.

2. Vendor adapters:
   - API-based system: a thin client for the internal service (activate /
     deactivate / visitor pass / remote unlock), authenticated with an API
     key. Visitor-pass PINs are only returned at creation — persist them
     immediately; they expire on their own, so no cleanup job.
   - Dashboard-only system: a headless-browser automation (persist the
     session across runs). After creating/resending a tenant, scrape their
     personal registration link from the tenant detail page and RETURN it —
     vendor registration emails are unreliable, so the agent delivers the
     link in its reply. Never post that link in a public channel.

3. Lifecycle integration (the part everyone forgets):
   - Grant access automatically when a member/employee is created or a
     teammate grant lands; revoke automatically on deactivation.
   - Email changes re-key door-access accounts in BOTH systems (they're
     keyed by email); a missing account under the old email is a graceful
     no-op, a refusal falls back to a human task.
   - Track every grant/revoke as a retryable task: attempt, retry once on
     failure, then escalate to a human intervention. A deactivated person
     silently keeping door access is the failure mode to design against.

4. All hooks best-effort and fire-and-forget from the caller's perspective:
   an access-system outage never blocks the request that triggered it.

5. Tests: unlock is absent from the email tool surface; a guest pass from a
   public channel never echoes the PIN publicly; deactivating a person
   queues revocations in every system they had access to.

Build a community service-provider directory on my Root integration backend
(root-int/1, following my existing tool + manifest patterns).

1. Schema:
   - service_providers: id, name, category, website, contact info,
     ai_description, embedding, tsvector.
   - provider_recommendations: id, provider_id, member_id, rating (1-5),
     review text, created_at/updated_at. One recommendation per member per
     provider (upsert on conflict).

2. Tools (tiers ["member"], channels ["slack","email","api"]):
   - search_service_providers { query, category? } — hybrid retrieval
     (vector + keyword) then a fast-model rerank. Return structured results:
     [{ provider_id, name, category, avg_rating, recommendation_count,
     top_review_snippets, recommended_by }].
   - recommend_service_provider { provider_name, category?, rating, review,
     website?, contact? } — match to an existing provider first (fuzzy, via
     LLM over candidates) so "Acme Legal" and "Acme Legal LLP" don't fork;
     create the provider if genuinely new. Save the recommendation
     attributed to the RESOLVED principal — never trust a name in the
     message for attribution.
   - list_my_service_providers {} — the member's own recommendations.
   - update_my_provider_review { provider_id, rating?, review? } and
     remove_service_provider_recommendation { provider_id } — own rows only,
     matched on principal ref.
   - update_service_provider { provider_id, ...fields } — factual fixes
     (website, contact) open to any member; keep an audit trail.

3. Derived description: when recommendations change, regenerate the
   provider's ai_description fire-and-forget with a writing-quality model —
   a neutral 2-3 sentence summary of what the community actually said.
   Never block the recommendation write on it.

4. Knowledge sync: publish each provider as a knowledge page through the
   platform's kb sync API (stable external_id = provider id) so general
   questions ("how do I find a bookkeeper?") can ground on the directory
   even without the search tool.

5. Tests: a recommendation for a near-duplicate name attaches to the
   existing provider; a member can edit only their own review; the rerank
   surfaces a well-reviewed provider above a keyword-only match.

Build conference-room booking on my Root integration backend (root-int/1,
following my existing tool + manifest patterns). Rooms: [LIST YOURS — e.g.
"Huddle 1"]. Some rooms may be shared with other scheduling systems (in
Foundations, the office-hours program) — availability must consider all of
them.

1. Schema: conference_room_bookings — id, room, member_id, date, start_time,
   end_time, purpose, calendar_guests (structured JSONB: resolved guests
   with name/email/member_id), status (confirmed/cancelled), calendar
   event UID, guest door-pass columns.

2. Availability = a union query across EVERY system that can occupy the
   room (bookings + any other program's booked slots for the same room).
   Reject overlaps at write time inside a transaction — the conversational
   check-then-book gap is real.

3. Tools (tiers ["member"], all channels; see #5 for delegates):
   - submit_conference_room_booking { date, start_time, end_time, purpose?,
     calendar_guests?: string[] } — auto-confirmed; resolve guests through
     the shared person resolver; store them structured, not as raw strings.
   - list_my_conference_room_bookings {}
   - update_conference_room_booking { booking_id, ...changes } — guests are
     replaceable/removable after confirmation; refresh the invite for
     everyone on any change.
   - cancel_conference_room_booking { booking_id }

4. Calendar delivery through a queue worker (chat AND web edits share it):
   ICS attachment + provider event, idempotent by a deterministic UID per
   booking; update on change, cancel on cancel. If any resolved guest is
   NOT an active member, mint one shared day-long door code for the
   booking, embed it in the invite, revoke on cancel, re-issue on
   reschedule (date changed). Best-effort: invite/door failures never
   block the booking.

5. Delegate support (assistants booking for a member over email): when the
   email surface resolves an acts_for member, include these tools, attach
   the booking to the MEMBER's record, and run every call through the
   authorization gate so the delegate can only manage that member's
   bookings. Non-members with no acts_for member get nothing.

6. If a physical display shows the room's schedule, feed it from the same
   tables — never a copy.

7. Tests: an overlap with the other program's slot is rejected; a non-member
   guest's invite contains a door code; an EA can reschedule their
   member's booking but cannot book for anyone else.

Build event hosting on my Root integration backend (root-int/1, following my
existing tool + manifest patterns): member-proposed events with team
approval, conversational RSVPs, emailed calendar invites, and door access
scoped to the event.

1. Schema:
   - event_requests: id, member_id, title, description, proposed date/time,
     expected_attendance, status (pending/approved/denied/cancelled).
   - calendar_events: the approved event (public or members-only), with a
     public_token for shareable pages.
   - RSVPs: members-only events get rsvp rows (accepted/declined/tentative);
     public events capture { email, name } sign-ups. Both are also the
     door-access eligibility list.

2. Member tools (tiers ["member"]):
   - submit_event_request { title, description, date, start_time, end_time,
     expected_attendance? } — lands in the team's approval queue with an
     admin notification.
   - list_my_event_requests / update_event_request (pending only) /
     cancel_event_request (pending only).
   - cancel_approved_event_request { event_id } — the important one. A host
     cancelling an APPROVED event must trigger full cleanup: remove the
     calendar event, queue attendee invite cancellations (members-only),
     revoke the event's visitor door pass, notify the team. No admin in
     the loop.
   - rsvp_to_event { event_ref, response } — parse "count me in" / "can't
     make it" conversationally; write the RSVP or public sign-up capture.
   - check_event_rsvps { event_id } — counts for the host; attendee emails
     visible only to the host and admins.
   - send_calendar_invite { event_ref, email? } — email a
     standards-compliant .ics for the event. Accept the event id, its name,
     OR a pasted event-page URL (resolve the public_token). Send only to
     the member's own email unless an admin directs otherwise.

3. Approval hook (admin side, not a member tool): approving creates the
   calendar event AND fires a visitor door pass for the event's office,
   valid ~30 min before start to ~1 hr after end. Recognized attendees
   (RSVP/sign-up/member) can retrieve entry instructions; the pass is
   revoked on deny/cancel and reconciled when the event moves. Pass
   creation is fire-and-forget — it never blocks approval.

4. Strip door codes from every general-purpose calendar tool result; codes
   are only delivered through the gated access flows.

5. Tests: RSVP by event name disambiguates when two events match; a pasted
   /event/<token> URL resolves for send_calendar_invite; cancelling an
   approved event revokes its pass and queues attendee cancellations.

Build an office shopping-list pipeline on my Root integration backend
(root-int/1, following my existing tool + manifest patterns). Retailer:
[YOURS — Foundations uses Costco Same-Day, which has no API and blocks
cloud browsers, hence the design below].

1. Catalog: a products table of everything the account has ordered
   (scraped from order history on a schedule) plus items discovered via
   storefront search. Dedupe on the retailer's product id when derivable,
   else case-insensitive name; track times_ordered for match ranking.

2. Member tools (tiers ["member"], channels ["slack","email","api"]):
   - recommend_costco_item { request, office } — resolve free text ("more
     sparkling water") to a real product: (a) fast-model LLM match over
     ILIKE-prefiltered catalog candidates FIRST — cheap and favors what we
     actually buy; (b) live storefront search on the automation host as
     fallback (30-60s — set a generous per-tool timeout_ms in the
     manifest); (c) if still unmatched, SAVE the raw request for admin
     resolution — never silently drop it. Item lands in the office's
     basket as "recommended", attributed to the member.
   - list_costco_basket { office } and
     remove_costco_recommendation { item_id } — own items only.

3. Admin-only tools (never on member or autonomous-API surfaces):
   - submit_costco_order_admin { office, dry_run? } — order the APPROVED
     basket items; record an orders row with an item snapshot, total, and
     confirmation/error; stamp ordered items.
   - sync_costco_catalog_admin {} — refresh the catalog from order history.

4. The automation host: if the retailer blocks datacenter IPs / cloud
   browsers, run a small Playwright HTTP server on a machine on a
   residential/office network. Endpoints (API-key authed): session status,
   order-history sync, product search, submit order. One browser operation
   at a time (in-process queue); session cookies snapshotted to disk after
   every operation. My backend gets a thin typed HTTP client with long
   client-side timeouts — search minutes, order tens of minutes.

5. Checkout hard gates, enforced HOST-side (defense against everything
   upstream): (a) the office's saved delivery address must be selected at
   checkout (street-substring match); (b) a saved card ending in the
   designated last-4 (limited-credit office card) must be found and
   selected — no card, no order; (c) an ALLOW_CHECKOUT env kill-switch:
   anything but "true" makes every submit stop before the final click and
   report as a dry run. Rebuild the cart from the basket on every submit
   so the order exactly matches what was approved. Dump screenshot + HTML
   on failure.

6. Tests: "more of the usual coffee" matches the catalog without touching
   the browser host; an unmatched request appears in the admin queue; a
   submit with the kill-switch off completes as a dry run and never
   places an order.