Meet Root.

Create an event-driven alert that fires the MOMENT a matching action happens through the agent, instead of polling on a schedule. Use this when a user asks to be notified 'when/whenever X happens' and X is something the agent itself performs — e.g. someone scheduling office hours or booking a room. The agent watches the specified tools across ALL conversations (Slack and email); when one runs successfully, an LLM checks whether the alert's condition is satisfied and sends an immediate Slack DM. Prefer this over create_follow_up for 'alert me when...' requests — a follow-up polls on a schedule and can miss or delay the event. watch_tool_names must be exact tool names from your own tool list (e.g. schedule_hosted_office_hours for a mentor scheduling office hours by email). MEMBERS can only watch community-visible action tools (office hours scheduling/booking, event RSVPs, community events, studio/conference room bookings, service provider recommendations, VC network changes, member/company profile updates) and the alert always DMs the member themselves. ADMINS can watch any tool (or ['*'] for all) and can direct the DM to someone else.

List configured event-driven action alerts (condition, watched tools, recipient, trigger history). Members see their own alerts; admins see everyone's. Use when a user asks what alerts they have or before cancelling one.

Create a durable, attributed, members-only knowledge entry owned by the current member. Use when a member explicitly wants to add their expertise, advice, or reusable guidance to Root's knowledge base. Do not save secrets, credentials, door codes, private personal information, tentative ideas, or one-off requests. Duplicate coverage is detected before creation. The member can later list, update, or delete this entry.

Permanently delete one knowledge page auto-extracted from the current member's own Slack activity, removing it from the agent's knowledge base and search index. The source Slack message is untouched and the page will NOT be re-extracted. Use list_my_extracted_knowledge first when the slug is unknown. To withdraw the underlying Slack message itself from the index, use remove_my_slack_contribution instead; member-shared entries are deleted with delete_my_knowledge_entry. Community admins removing ANOTHER member's entries use delete_member_extracted_knowledge_admin.

Permanently delete one member-shared knowledge entry owned by the current member. Use list_my_knowledge_entries first when the slug is unknown. This removes the entry from Root's knowledge base and search index; it cannot delete official, Slack-extracted, admin-authored, or another member's content.

Issue a link to a specific knowledge base page (e.g. /kb/<slug>). Use this whenever a user pastes a /kb/... URL, asks for ACCESS to a specific knowledge page, says they cannot open a knowledge page, or asks for a direct link to a particular knowledge entry. Do NOT use this for general questions or to summarize page content — use search_knowledge_base for that. Public pages return a bare URL anyone can open; private pages return a one-click URL with a token bound to this user.

List the knowledge pages the agent's pipelines AUTO-EXTRACTED from the current member's own public Slack activity, including the slugs needed to update or delete one and how often each page has informed the agent's replies. These are distinct from member-shared entries the member wrote directly. Use when a member asks what the agent has extracted/learned from their Slack activity, or before editing/removing an extracted insight whose slug is unknown. When the user is correcting a stale or wrong extracted insight, listing is only the first step — after you find the matching slug you MUST call update_my_extracted_knowledge_entry or delete_my_extracted_knowledge_entry in this conversation. Do not stop after listing and do not treat a team notification as the update.

List the current member's own member-shared knowledge entries, including slugs needed for update or delete actions. This never lists entries owned by another member.

List the current member's own public Slack messages that are indexed in the agent's Slack search. Use when a member asks what of theirs the agent has indexed, wants to review/manage their contributions, or before refreshing/withdrawing one (the returned id is what those tools take). These are the agent's indexed copies — not permission to edit anyone's Slack history.

Get the list of users who reacted with emoji to a specific public Slack message, including the people who reacted to any reply in the same thread by default. Use this whenever a member asks who reacted to a Slack post (with emojis), wants the contact info or emails of reactors, wants a tally of which emojis a thread received, or wants to know who participated in a thread (reactions plus replies). Requires a full Slack message permalink. Returns each unique reactor with their Slack display name, member name and email if they're a Foundations member, the emojis they used, and a per-emoji summary.

Read the contents of a PUBLIC Google Sheet from its URL (or spreadsheet ID) and return the rows as structured data — headers plus data rows — so the sheet can be summarized, listed, or analyzed. Use this when the user asks about the contents of a Google Sheets link ('who's in this spreadsheet?', 'summarize this sheet'), including links mentioned earlier in the conversation. Works for sheets shared as 'anyone with the link can view' and published-to-web links; restricted sheets are reported with a clear explanation of how the owner can open access. Reads one worksheet per call — the tab in the link's gid by default, or a specific tab by name or gid. Do NOT use this for non-Google-Sheets URLs.

Re-fetch one of the current member's indexed Slack messages from Slack and refresh the agent's copy — the edit flow: the member edits their ORIGINAL message in Slack first, then this syncs the index. Use after a member says they've corrected/updated a message the agent has indexed. The agent cannot edit a human-authored Slack message itself. Get the contribution id from list_my_slack_contributions.

Withdraw one of the current member's indexed Slack messages from the agent's search index, including knowledge that was extracted from it. Use when a member wants something they said excluded from the agent's answers (outdated, wrong, or they just want it gone). The source Slack message is NEVER deleted — only the author can do that in Slack; this removes the agent's indexed copy. Get the contribution id from list_my_slack_contributions. Community admins removing ANOTHER member's messages from the index use remove_member_slack_contribution_admin.

Save durable community knowledge that an authenticated member shares in a Slack DM, so it can be retrieved and used for other members later. Use when the member explicitly asks you to remember/share information for the community OR clearly gives reusable operational guidance for future members (for example: who to contact for equipment access, where things are, or a standing how-to). This writes an attributed, members-only knowledge-base entry — conversation context alone does NOT persist knowledge for anyone else. Preserve the member's facts faithfully; do not infer missing details. Do NOT use for personal preferences (use remember_user_preference), secrets, credentials, door codes, personal/private information, one-off requests, tentative ideas, or facts found in public Slack channels (those are ingested automatically). If the member is correcting their own prior member-shared entry and its slug is known, pass update_slug. Duplicate information is detected and not re-created.

Answer questions about recent news, current events, breaking developments, or fast-moving topics using Perplexity Sonar Pro with live web search. Use this when freshness matters or the question is about the outside world beyond Foundations. IMPORTANT: when the Foundations knowledge base tool is available, use this in parallel with search_knowledge_base and never as the only research source. Do not use this for Foundations policies, member data, or Slack discussion history when the structured internal tools are a better fit.

Search public Slack messages that the agent has ingested from community channels, and resolve exact public Slack message permalinks live when the user includes them. Returns the top raw matches (with speaker, channel, date, text excerpt, and permalink) for you to synthesize directly. Use this when the user explicitly wants to know what members said in Slack, wants recent discussion history, wants examples or sentiment from public-channel conversations, wants help understanding a specific Slack link, or when knowledge-base results are too thin and Slack discussion would add supplemental context. Do not use this as the primary source of truth when search_knowledge_base or another structured tool can answer the question.

Search the community knowledge base for information about membership, policies, events, office space, community resources, and curated community recommendations. Returns the top retrieved knowledge chunks (with title, author, URL, and excerpt) for you to synthesize into a direct answer. Use this as the default source for general questions before falling back to Slack-message search. Do NOT use this tool when the user is asking for ACCESS to a specific knowledge base page (e.g. they pasted a /kb/... URL or asked for a link to a specific page) — use get_knowledge_page_link for that.

Rewrite the title and content of one knowledge page auto-extracted from the current member's own Slack activity — for fixing a stale, wrong, or badly-worded extracted insight. THIS is the tool that actually changes what the agent will say later; listing the page or reporting a mistake does not. Use it immediately when the member says an extracted insight misstates their view, recommendation, or experience. The page stays attributed to the member and remains an extracted insight. Use list_my_extracted_knowledge first when the slug is unknown. Strictly author-scoped: official docs, member-shared entries (use update_my_knowledge_entry), and other members' pages are refused.

Update the title and content of one member-shared knowledge entry owned by the current member. Use list_my_knowledge_entries first when the slug is unknown. Ownership is enforced server-side; entries from Slack extraction, official docs, admins, or other members cannot be changed.

Submit an application for the member to present at an upcoming Foundations Member Demo Showcase. Use when a member says they want to demo, present, share what they're building, or sign up to present at the next member demo event. Each presenter gets ~15 minutes (about 10 minutes of presentation plus 5 minutes of Q&A). Confirm with the member what they want to share before submitting if it's not already clear from the conversation. Do NOT use this for other event types — only for member demo presentations.

Book the Foundations conference room (Huddle 1, the same room used for office hours) for the current member. Use this for general meetings, 1:1s, interviews, brainstorm sessions, calls, and small workshops in the conference room. Conference room bookings are AUTO-CONFIRMED — there is no admin approval step. Do NOT use this tool for the studio (podcast room) — use submit_studio_booking instead. Do NOT use for office hours (use the office-hours tools). The booking will fail with a clear error if it overlaps with another conference room booking OR an existing office hour in that same room. Confirm the date and start/end times with the member before submitting if anything is unclear.

Book the Foundations studio room (also called the podcast room). Use this when a member wants to record, host an interview, run a workshop, take a private call, or otherwise reserve the studio. Bookings are AUTO-CONFIRMED — no admin approval needed — as long as the slot doesn't conflict with an existing booking, and a calendar invite is sent immediately. NEVER use create_fulfillment_request or submit_event_request for studio bookings — use this tool. Confirm date and start/end time before submitting if not already clear. Do NOT use for events at Foundations that don't need the studio room (use submit_event_request) or for office hours (use the office-hours tools).

Cancel one of the current member's APPROVED Foundations event requests — the event is removed from the calendar, attendee calendar invites are cancelled (for members-only events), any visitor door-access pass for the event is revoked, and the Foundations team is notified. Use this when a member wants to cancel an event of theirs that has already been approved and is on the schedule; for requests still in PENDING status, use cancel_event_request instead. Only future events can be cancelled — past events are read-only. Because this removes a live event that people may have RSVP'd to, confirm with the member that they really want to cancel before calling this. If the member doesn't clearly identify which event, run list_my_event_requests first.

Cancel one of the current member's confirmed conference room (Huddle 1) bookings. Cancelling also cancels the calendar invite that was sent. Already-cancelled bookings can't be cancelled again, and past bookings are read-only. If the member doesn't clearly identify which booking, run list_my_conference_room_bookings first.

Cancel one of the current member's PENDING Foundations event requests. Only pending requests can be cancelled here; for a request that has already been APPROVED, use cancel_approved_event_request instead. If the member doesn't clearly identify which request, run list_my_event_requests first.

Cancel one of the current member's studio bookings. The booking's calendar invite is cancelled too. Already cancelled bookings can't be cancelled again. If the member doesn't clearly identify which booking, run list_my_studio_bookings first.

Check who has RSVP'd or signed up for a Foundations calendar event. Works for BOTH event types: (1) Members-only one-off events and recurring event instances use Google Calendar invite responses (accepted/tentative/declined). (2) Public events don't get a mass calendar invite, so 'RSVPs' there are the email addresses people entered through the public Add to Calendar button on the event's /event/<token> page — treat those as RSVPs/sign-ups when answering the member. With an event_id or event_name, returns the attendee list and counts for that event along with whether the current user is signed up. With no arguments, returns all upcoming members-only events the current user has an RSVP record for. For public events, only the event's organizer (the member who requested it) and admins see individual attendee emails; everyone else gets just the count. Use this when someone asks who is attending an event, whether they (or someone) are signed up, what events they're registered for, or how their own hosted public event is doing.

Get detailed information about a specific calendar event.

List upcoming or future calendar events at Foundations. Supports natural-language queries over upcoming events, not historical or past-event searches.

List the current member's conference room (Huddle 1) bookings — confirmed or cancelled — with status and details. Use when the member asks about a conference room booking they previously made, wants to know what they have on the schedule, or needs the booking ID before editing or cancelling. Do NOT use this for studio bookings (use list_my_studio_bookings) or office hours.

List the current member's Foundations event requests (pending, approved, and denied) with status and details, plus — for approved public events — how many people have RSVP'd by clicking 'Add to Calendar' on the public event page. Use when the member asks about a request they previously submitted, asks for the status of a pending event, wants to know what they have on the calendar awaiting approval, or asks how their hosted public event is doing (e.g. 'how many people are coming to my talk?'). For a per-attendee breakdown of who RSVP'd to a specific event, follow up with check_event_rsvps using the event_id from this tool. Do NOT use this for community events (those go through submit_community_event / list_community_events) or for bookings (office hours, studio room, conference room).

List the current member's studio (podcast room) bookings with status and details. Use when the member asks about a booking they previously made or wants to know what they have on the studio calendar. Do NOT use this for Foundations event requests (use list_my_event_requests) or for community events.

List upcoming PUBLIC Foundations events that anyone can attend. Use this for non-member visitors asking what's coming up, what events Foundations is hosting, or whether there's anything they can attend. Returns event name, date, time, location (Seattle or SF), the public registration/details link, and the hosting member/company. Does NOT include members-only events.

Match the email sender's address against the RSVP / sign-up records of upcoming PUBLIC Foundations events, and — if one of those events is happening right now — return the exact door access instructions (the 'success message', including any event door code — the Seattle UniFi PIN or the SF ButterflyMX PIN). Use this whenever a non-member visitor asks about an event they registered for, whether they're signed up, or how to get into the building for an event. It only ever uses the sender's own email; it cannot look up anyone else.

Submit a request to host a new event AT A FOUNDATIONS OFFICE — either Seattle (1605 Boylston Ave) or San Francisco (142 Minna St). Use this when a member wants to host, organize, or run an event in a Foundations space — talks, fireside chats, demos, dinners, mixers, workshops, partner events, etc. Default to the Seattle office unless the member clearly says the event is at the SF office. A public event URL (Luma, Partiful, Eventbrite, or any other event page) is STRONGLY RECOMMENDED for PUBLIC events so Root can scrape the title, description, date, and time and keep the event in sync (Luma guest list, 6-hour details refresh, /event page redirect) — ask once if they have a page, then proceed without it if they don't. Do NOT invent a title when the member already has a URL. Without a URL, public events need a name, date, and start/end time, same as members-only events (a URL is optional there too; a Luma URL on a members-only event also gets the 6-hour details refresh). The request is created in the calendar in pending status and the Foundations team is notified to review and approve it. Custom event images cannot be attached in chat — if the member wants to upload artwork that overrides the auto-generated image, send them a /root/calendar link after submitting. NEVER use create_fulfillment_request for hosting an event at Foundations — use this tool instead. Do NOT use this tool for events happening elsewhere (use submit_community_event for those), for booking the studio room (that has its own /root/studio flow), for office-hours coordination, or for member demo presentations at the Member Demo Showcase (use submit_demo_application).

Record the current member's RSVP / attendance response for a Foundations calendar event (or recurring event instance). Use this whenever a member tells you whether they're going to an event — e.g. replying 'yes'/'no'/'maybe' to an RSVP request email, saying 'count me in', 'sign me up', 'put me down as attending', or 'I can't make it'. Map natural language to a response: yes / attending / coming → accepted, no / can't make it / not coming → declined, maybe / might / tentatively → tentative (defaults to accepted). For members-only events this writes the member's calendar RSVP record; for public events it records them through the same 'Add to Calendar' sign-up signal the event page uses (public events have no decline option, so declines can't be recorded there). Members-only events hosted on our own Luma sync both ways in the background (hourly): accepts recorded here are registered on the Luma guest list and declines cancel the Luma registration, so the member never needs to respond in both places. ALWAYS call this tool before telling a member you've marked their RSVP — never claim to have signed them up without it. Confirm the event and the resulting status back to the member afterward.

Search previous calendar events that have already happened. By default this covers ALL past community events — it does NOT indicate the asking user attended them. Set attendee_scope to 'me' when the user asks about events THEY attended, RSVP'd to, or signed up for (e.g. 'what events did I go to last month?'). Supports natural-language queries over historical events such as 'what events happened last month?' or follow-up searches by name/date range.

Email a calendar invite (.ics attachment) for a specific Foundations calendar event to the requesting member's inbox. Use this when a member asks Root to send/email them a calendar invite or .ics file for an event — e.g. when the web 'Add to Calendar' button on the event page doesn't work with their calendar app (Proton Calendar, Outlook, Apple Calendar, etc.). The attachment is a standards-compliant ICS invitation that works with any calendar client. Accepts the event's ID, its public event page URL or token (the uuid in https://app.fndtns.org/event/<uuid>), a recurring event instance ID, or an event name to look up. The invite goes to the member's own email on file; only admins may direct it to a different address. For public events this also records the member as signed up (the same 'Add to Calendar' signal the event page records), so RSVP counts stay accurate.

Submit a community event happening in Seattle that is NOT hosted at Foundations. Any member can submit without approval. Use when someone wants to share an event, meetup, or gathering they know about or are hosting outside of Foundations.

Update one of the current member's confirmed conference room (Huddle 1) bookings. Any field can change — title (name), date, start/end time, purpose, attendees, external guests, calendar guests (the invite is refreshed for everyone), description. Cancelled or past bookings are read-only. Time changes are checked for conflicts with other conference room bookings AND existing office hours, and the calendar invite is automatically refreshed when the booking has been emailed already. Only pass the fields the member wants to change. If unsure which booking, run list_my_conference_room_bookings first.

Update one of the current member's Foundations event requests in place. Pending requests can have any field changed — name, date, start/end time, description, event URL, visibility, or office (Seattle vs SF). A public event URL is strongly recommended for PUBLIC events so details stay in sync, but it is optional and can be cleared. Changing that URL re-scrapes title/description/date/time from the page. Once a request has been approved or denied, the name, description, URL, and office can still be changed (date, time, and visibility are locked UNLESS the event URL itself changes — then the page is treated as the source of truth). Custom event images cannot be changed in chat — if the member wants to upload or replace artwork, send them a /root/calendar link. Only pass the fields the member wants to change; omitted fields stay as-is. If the member doesn't clearly identify which request, run list_my_event_requests first.

Update one of the current member's studio (podcast room) bookings in place — title (name), date, start/end time, purpose, attendees, external guests, calendar guests, description. Date/time changes are checked against the studio calendar for conflicts, and the booking's calendar invite is refreshed for everyone on it. Cancelled bookings can't be edited. Past bookings are read-only. Only pass the fields the member wants to change. If you're not sure which booking they mean, run list_my_studio_bookings first.

Cancel an existing follow-up. Use list_follow_ups first if the user does not provide a specific follow_up_id.

List the user's active, paused, processing, or failed follow-ups. Use when they ask what follow-ups they have scheduled.

Pause an active follow-up without deleting it. Use when the user wants it to stop running for now.

Resume a paused follow-up so it starts running again.

Update a follow-up's instruction, schedule, or both. Use when the user wants to edit an existing follow-up.

Admin only. Schedule Founder in Residence graduations in bulk. Pass member names or emails, and/or a company name (every active FIR at that company). Each person gets a graduation notice email immediately (what graduating means, a link to the next FIR event, and that a Glowforge plaque is coming) and is flipped from FIR to Member on the graduation date (default 7 days from today, Pacific), which then triggers the usual plan-selection email. Per-person results are always returned — never silently dropped. Use list_scheduled_fir_graduations_admin / cancel_fir_graduation_admin to inspect or undo.

Admin only. List every pending Founder in Residence graduation (who, when, whether the notice email was sent). Use before graduating more people or to confirm what's already queued.

Add a new VC fund to the database without linking the user to it.

Connect the current user to a VC fund. Use relationship_type 'investor' when the fund invested in the user's company, or 'friendly' when they know someone at the fund. Auto-creates the fund if it doesn't exist.

List the service provider recommendations the current member has added to the community directory. Use when a member asks things like 'what providers have I recommended?', 'show my recommendations', or before editing/removing one so they (and Root) can see the exact names and ids.

List the current user's VC fund connections - which funds they've raised from or are connected to.

Find which community members have raised from or are connected to a specific VC fund.

Add a new service provider recommendation to the community directory on behalf of the current member. Use when a member wants to recommend, add, vouch for, or share a vendor/consultant/firm they've worked with (e.g. 'add my accountant', 'I want to recommend our law firm'). An initial rating (1-5) and a short review describing their experience are required — if the member hasn't given them, ask before calling. The provider is attributed to the member as the recommender.

Remove (delete) one of the current member's OWN service provider recommendations from the community directory. Members can only remove recommendations they added, and this also deletes all reviews on that provider, so confirm with the member before calling. Identify the target by `provider_id` when known, otherwise by `provider_name`.

Search community-recommended service providers (accountants, lawyers, HR, marketing, etc.) that Foundations members have reviewed. Use this whenever a user asks for recommendations, referrals, 'who do you recommend for X', or 'who recommended <provider name>'. Each result includes `recommended_by` — the Foundations member who added that provider to the directory — so this is the right tool for identifying who vouched for a given provider. Query supports natural language, multiple names in one call (e.g. 'Claire and Marsha'), category words, or descriptions; hybrid vector + keyword search is used under the hood. IMPORTANT: the returned count is a lower bound — hybrid retrieval looks at a pre-filtered candidate set, not the entire provider directory. Phrase counts to the user as 'at least N'.

Search the VC fund directory semantically. Use for broad discovery queries like 'early stage AI funds', 'who invests in climate tech', or 'seed stage funds in Seattle'. Returns ranked results with relevance explanations. For looking up connections to a specific known fund, use query_vc_connections instead. IMPORTANT: the returned count is a lower bound — hybrid retrieval looks at a pre-filtered candidate set, not the entire fund directory. Phrase counts to the user as 'at least N'.

Remove the user's connection to a VC fund.

Update the current member's star rating and/or written review for a service provider — either one they recommended or any provider in the directory they've used. Use when a member wants to change how they rated a provider or revise their review text (e.g. 'change my rating for Acme to 3 stars', 'update my review of our accountant'). Identify the provider by `provider_id` when known, otherwise by `provider_name` (matched against the member's own recommendations).

Edit one of the current member's OWN service provider recommendations — change its name, category, URL, or description. Members can only edit recommendations they added. Identify the target by `provider_id` when known (e.g. from list_my_service_providers), otherwise by `provider_name`. Only pass the fields the member wants to change. To change your star rating or written review of the provider, use update_my_provider_review instead.

Admin only. Update a VC partner's email address in the shared community VC directory. Members who notice incorrect partner contact info should log a fulfillment request via create_fulfillment_request and an admin will correct it — direct rewrites are gated to prevent contact-record tampering across founders.

Research and auto-generate or refresh the current user's member bio from their LinkedIn profile and known company context. Use ONLY when the user explicitly asks Root to write, regenerate, refresh, or auto-update their own bio.

Create a NEW company in the Foundations directory on behalf of the current member and link them to it (they become the company's billing/management contact). Use when a member says their company isn't in the directory yet and wants to add it. If a company with the same name already exists, this fails and suggests join_company instead. Only for members without an existing company link.

Find community members with demonstrated knowledge or experience on a topic, based on what they've actually said in public Slack channels. Returns a ranked list of people with per-person evidence (messages, dense discussion runs, and threads they drove, with dates and permalinks). Use this when the user asks 'who knows about X?', 'who has experience with Y?', 'who should I talk to about Z?', or wants an introduction to someone with specific expertise. Prefer this over search_slack_messages when the QUESTION is about people/expertise rather than about the content of the discussion itself. Rankings favor recent, substantive contributions over passing mentions.

Deactivate a previously saved user preference so it stops applying in future conversations. Use when the user says to forget, remove, undo, or stop using a remembered preference. If the exact preference is unclear, use list_user_preferences first.

Get the current user's company profile information including name, URL, and description.

Get the Foundations member profile of the person you are talking to — includes their bio, LinkedIn, and directory status (Founder in Residence, FIR Alumni, Alumni, or Member). This returns THEIR information, not yours.

The community mention leaderboard: active members ranked by how many of Root's human-facing replies mention them — a proxy for the community's most valuable mentors and contributors. Use when someone asks who the most-mentioned, most active, or most helpful members are, where they rank, or about the leaderboard itself. Only content-grounded mentions count: replies that drew on public Slack discussion or the knowledge base. Operational mentions (badge-ins, event rosters, office-hours listings) and automated member API traffic are excluded. The public page at /root/leaderboard shows aggregate counts; signed-in members can click a name to browse that member's stored contributions — their knowledge entries and indexed public Slack messages — never any conversation excerpt.

Link the current member to an EXISTING company in the Foundations directory. Self-joining is only allowed when the member's email domain matches the company (its website domain or a current member's email domain) — public email providers like gmail.com never count. On a domain mismatch, offer to log a fulfillment request so the Foundations team can link them manually. Use create_company instead when the company isn't in the directory yet.

Look up desk and office rentals at the Foundations space: which companies and members rent which desks/offices, rental status (active or upcoming) and start dates, and optionally which desks/offices are currently available. Use when someone asks whether a company or person has a desk/office at Foundations, whose office/desk a specific space is, which companies are physically in the building, or what desks/offices are free to rent. NEVER returns pricing or billing details — rental rates are deliberately excluded, so do not use it (or guess) for questions about what a rental costs.

List the explicit preferences and remembered instructions previously saved for the current user. Use when they ask what you remember, what preferences you have stored, or to review saved nicknames, aliases, formatting rules, or recurring instructions.

Save an explicit user preference, alias, nickname, formatting rule, or recurring workflow instruction for future conversations. Use when the user clearly asks you to remember something, says 'from now on', 'treat X as Y', 'call me', 'prefer', 'always respond', or otherwise gives a durable instruction for future interactions. Only save preferences the user explicitly states or clearly requests. EXCEPTIONS (do NOT use this tool for these — a free-text preference only applies when talking to this user and will not actually change the behavior): Slack DM reply delivery → set_dm_reply_style; channel auto-replies → set_auto_reply_preference; stop/resume @-mentioning or tagging them when Root attributes their advice in other people's conversations → set_slack_mention_preference.

Search the Foundations company directory using AI. Use this when the user asks about specific companies, wants to find companies by industry, product, market, or status, wants to compare or count companies by attribute, or wants to know which company matches a natural-language description. Do not use this for the current user's own company profile when get_company_info or update_company is the better fit. IMPORTANT: `totalFound` is a lower bound — hybrid retrieval looks at a pre-filtered candidate set, not the entire directory. Phrase counts to the user as 'at least N' rather than exact totals, especially for broad queries.

Search the Foundations member directory using AI. Pre-filters member profiles (names, bios, companies, roles, expertise, member types, directory status such as actual Founder in Residence vs Alumni vs Member, and VC connections) via hybrid embedding + keyword + fuzzy text search, then uses an LLM to rank the most relevant members for any query — including semantic/conceptual searches like 'who knows about SMBs' or 'fintech founders'. Use this whenever someone asks about finding people, who has experience with something, member lookups, counting members by attribute (e.g. 'how many members are FIRs'), or looking up a specific member's contact info (e.g. 'what's Matt's email?', 'how do I reach Sarah?'). Each match comes back with the member's email and LinkedIn so you can answer contact-info questions directly — sharing this info is expected in the community. TWO MODES: (1) `query` — ranked semantic search for open-ended questions; (2) `names` — exact list correlation: when the user provides a LIST of specific people (from a message, spreadsheet, or document), pass them as the `names` array instead of packing them into `query`. Every name is resolved individually and gets an explicit outcome (matched / ambiguous / not found) with NO result cap — ranked search would silently drop names past its top-K. IMPORTANT: in query mode the `totalFound` count is always a lower bound (we look at a pre-filtered candidate set, not the entire directory) — phrase counts to the user as 'at least N' rather than exact totals, especially for broad queries like 'all healthcare founders'.

Control whether the agent jumps in on THIS USER's top-level messages in monitored Slack channels without being @-mentioned (auto-replies). Use this — NOT remember_user_preference — when the user asks the agent to stop answering their channel messages uninvited, to only chime in when very sure, or to re-enable auto-replies. 'off' = never auto-reply to them; 'high'/'medium'/'low' = personal confidence bar overriding the community default (high = only when very confident); 'default' = follow the community setting. Only affects auto-replies in channels — @-mentions, DMs, and threads always get replies.

Set how replies are delivered in Slack DMs with this user: 'direct' posts replies straight into the DM conversation (the default), 'thread' posts replies as threads on the user's message. Use this — NOT remember_user_preference — whenever the user asks to stop replying in threads, reply directly in DMs, or conversely to keep DM replies in threads. This is the only way to actually change delivery; a free-text preference has no effect on it. Applies only to top-level DM messages — when the user writes inside an existing thread, the reply always stays in that thread.

Update the current user's company profile. Provide only the fields to update. Includes stealth status: stealth companies are hidden from the public fndtns.org company directory (but stay visible internally to members) — set is_stealth to false when a member says their company shouldn't be in stealth or asks why it isn't showing on the public website, or true when they want it hidden. Visibility on the public directory updates automatically.

Update the primary email address on the Foundations member profile of the person you are talking to. Use when they ask to change, update, or correct their email address. This changes their email everywhere Root uses it — their member record, the mentors table, mailing lists, and email-based identity resolution — so ONLY pass an email address the member explicitly provided in their message. This always acts on the CURRENT user's own profile; it cannot change someone else's email.

Update the Foundations member profile of the person you are talking to. Use when they provide or share their bio text or a LinkedIn URL — including in reply to being asked for it. ONLY pass values that appear in the member's message. NEVER generate content yourself — if the member only sent a URL, only update that field.

Add an employee (a non-member teammate seat) to the user's company. Use this whenever a member asks to add a teammate/employee to building access or the #office-sea channel — it works for any member whose company has an active desk/office rental, a company-billed plan with seats, a Founder in Residence (up to 2 employees), or a regular member (up to 1), and for a company employee granted management access by a member of their company. Employees get automatic UniFi (Seattle) building access and a #office-sea Slack invite. (For San Francisco access, use request_sf_access_for_teammate after adding them.)

Cancel the user's membership subscription. Billing stops immediately, but the member keeps full member access (building + Slack) through the end of their current paid billing period — their account is then deactivated automatically on that date (the result includes the exact date as access_until; relay it to the member). Re-selecting a plan before then cancels the scheduled deactivation automatically.

Cancel a pending scheduled employee removal for the user's company, by schedule id (from list_scheduled_employee_removals) or by the employee's email. The employee's seat and building access stay active.

Change the user's membership plan OR billing cycle (monthly <-> yearly). Works for new selections and for changes to an existing membership — an active membership stays active through the change, and any member of a company may adjust their company's plan or billing cycle. Specify the target plan name and optional billing period. If a payment method is still needed, the result includes a personal payment-setup link to pass along.

Create a temporary guest door code for EITHER office — a UniFi PIN for the Seattle front-door keypad, or a ButterflyMX code that works on every keypad at the SF space (142 Minna St, street entrance and interior doors) — so a member's guest can let themselves in during a time window. Physical keycards are retired; this door code IS guest access — never tell a member to ask the team for a keycard. Use when a member asks for a door code for a guest ('send my guest a code for this afternoon', 'my cofounder's visiting the SF office tomorrow 9-5, can she get in?') or when guest policy / bringing a guest comes up and they may need entry. Also the right tool when a guest is at the door RIGHT NOW ('buzz my guest in', 'let them in downstairs') — Root has NO remote unlock/buzz-in capability at either office, so mint a pass starting now and have the member relay the PIN; the member can also open the door themselves from the UniFi Endpoint app (Seattle) or the ButterflyMX app (SF), or escalate_to_admin for a human. Defaults to now until the end of today (Pacific); a window may be at most 24 hours and must start within the next 7 days — for a visit longer than 24 hours, escalate_to_admin so the team can arrange a longer door-code window (still not a keycard). Creating an SF code drives the ButterflyMX dashboard and can take a minute or two. The code comes back exactly once and cannot be retrieved later, so ALWAYS include it in your reply along with the validity window — except in a public Slack channel, where the code is automatically withheld and DM'd to the requester; follow the result's public_channel_note. After creating a pass you can tell the member you'll DM them when their guest first uses the code.

Get the current user's membership plan details, billing info, status, any active desk/office rentals (price, billing method, start date), and their recent invoice history with per-invoice payment status. Billing info includes the card on file (brand + last 4) for Stripe auto-billed plans/rentals, or notes when payment is by manual invoice. Use this for questions about their plan, dues, rental billing, or past/existing invoices — monthly invoices are generated automatically and their PDFs are viewable/downloadable on the member's secure account page (/root/account), so 'send me my invoices' is answered by pointing there, never by escalating to the team.

Get available membership plan options and pricing.

Generate and resend the user's personal membership payment link. Use when a member asks for a link to pay for, buy, or set up their membership, says they lost or never got their payment link, or their link expired. Returns a plan-selection link if they have no active membership yet, or a payment-setup link if they do. The link is personal to the requesting member and expires in 7 days.

Generate a personal reactivation link for a DEACTIVATED Foundations member. Use when the sender says their membership was deactivated, cancelled, or removed and they want to reactivate, rejoin, or restore their account/access. Matches ONLY the sender's own email address against the member records — it cannot look up or reactivate anyone else. The link takes them to plan selection; picking a plan and completing payment automatically reactivates their membership, building access, and Slack account.

Grant San Francisco (ButterflyMX) building access to a TEAMMATE — either another Foundations member of your company OR one of your company's employees (non-member seats). Use this when a member (or a company employee with management access) asks to give SF door access to someone else at their company (e.g. 'give SF access to my teammate' or 'add my employee to SF'). For your OWN SF access, use request_butterflymx_access instead. Only works for teammates that belong to the same company as the requester. The result usually includes a confirmationLink — the teammate's personal ButterflyMX registration link. In a DM or email, ALWAYS include that link in your reply so the requester can pass it to their teammate, since ButterflyMX's own invite emails frequently don't arrive. In a public Slack channel the link is automatically withheld and DM'd to the requester instead — follow the result's public_channel_note and never paste a registration link into a public channel.

Grant one of the user's company EMPLOYEES (a non-member seat) management access — 'COO mode'. Use when a member asks to let an employee manage the company through Root (e.g. 'give Maddie management access', 'let our office manager handle visitors and employees'). With management access the employee can DM Root to: create guest door passes for visitors at either office, view/update the company profile, manage the employee roster (add/remove/schedule removals), and grant SF access to teammates. MEMBER-ONLY: employees (even managers) cannot grant or revoke management access. The person must already be an active employee of the member's company (add_company_employee first if not).

List the pending scheduled employee removals for the user's company — who is scheduled to be removed (and lose building access), when, and each schedule's id (needed to cancel one).

Load or refresh company directory listings on the Seattle (UniFi Access) entry intercom/callbox at 1605 Boylston, so visitors at the front door can find a company and call its people. A member syncs THEIR OWN company's listing — the company name plus its active members and employees as call contacts (people already in the door system). Admins can additionally target any company by name, or load the FULL directory (every company with a building presence: an active desk/office rental or active employees). Seattle only — the SF space (ButterflyMX) manages its own tenant directory. If the door-access system can't take the update automatically, the listing details are handed to the Foundations team as a fulfillment request instead of being dropped — the tool result says which happened, so report it honestly.

View the company's employee roster and seat info. Works for any member whose company is eligible to have employees — a company-billed plan with seats, an active desk/office rental (no fixed cap), a Founder in Residence (up to 2 employees), or a regular member (up to 1). Also works for a company employee who has been granted management access by a member of their company.

Remove an employee (non-member teammate seat) from the user's company by their email, effective IMMEDIATELY. Works for any member whose company is eligible to have employees (rental, company plan, FIR, or regular member), and for a company employee granted management access by a member of their company. Revokes their building access and removes them from #office-sea. To remove someone at a future date/time instead ('remove them Wednesday at 5pm'), use schedule_employee_removal.

Grant the current Foundations member access to the San Francisco space in ButterflyMX, or resend their ButterflyMX registration invite when they say their SF door access invite/login is missing. Use this only for the current user, not to grant access to someone else. The result usually includes a confirmationLink — the person's personal ButterflyMX registration link. In a DM or email, ALWAYS include that link in your reply, since ButterflyMX's own invite emails frequently don't arrive. In a public Slack channel the link is automatically withheld and DM'd to the requester instead — follow the result's public_channel_note and never paste a registration link into a public channel.

Send the current user a UniFi building access invite to their email on file. Use this for first-time building access AND whenever someone asks to reset their UniFi password or regain/re-setup their building access — re-sending the invite lets them set up their login again. Works for both Foundations members and company employees (non-members with company building access).

Retry the charge on one of the user's OWN failed/overdue invoices using the card on file. Use when a member says an invoice payment failed, their card was declined, or they ask to retry/re-run a failed charge — often right after updating their payment method. Without an invoice_id it finds the member's retryable invoices: exactly one is retried immediately, several are returned so the member can pick. Never generates new invoices (those are created automatically each billing cycle); invoice history and PDFs live on the member's secure account page (/root/account), which also has a Retry charge button.

Revoke a company employee's management access ('COO mode'), returning them to the basic employee surface (own building access + community search). Use when a member asks to remove an employee's management permissions. MEMBER-ONLY. The employee keeps their seat and building access — to remove them entirely use remove_company_employee.

Schedule the removal of a company employee (non-member teammate seat) — and the revocation of their building access — for a specific FUTURE date/time, e.g. 'remove Andres' access on Wednesday at 5pm'. The employee keeps full access until then; at the scheduled time the removal runs automatically through the same path as remove_company_employee (seat deactivated, UniFi/Seattle access revoked, SF/ButterflyMX revoked if granted, removed from #office-sea). Works for any member whose company is eligible to have employees (rental, company plan, FIR, or regular member). A new schedule for the same employee replaces any earlier one, and removing or re-adding the employee before the scheduled time clears it. For an immediate removal use remove_company_employee instead.

Generate a link for the user to update their payment method.

Update or sync the current user's SF door-access (ButterflyMX) profile so the door system shows their current details — use this when someone says SF office access / the door entry log shows their OLD company, a wrong/outdated name, or their SF access is still registered under an OLD email address. ButterflyMX does not sync profile changes after the initial setup, so this rewrites their tenant profile in place: the display name (defaults to their current Foundations name), when the ButterflyMX form has a company field their company (defaults to their current Foundations company), and — when old_email is provided — re-keys the tenant record from that old address to their current Foundations email. Note that a member changing their email through Root (update_member_email) already gets this email re-key automatically; pass old_email only when the SF profile is stuck under an address that predates their current records. Registration state and door access are untouched. Only works on the current user's own profile; for someone else's, use escalate_to_admin. Report honestly what the result says changed — if the result says ButterflyMX has no separate company field, the display name is the only text the door system shows.

Admin only. List surveys (open, closed, draft, or all) with their question counts and response counts so an admin can quickly see what's running and what's been answered.

Admin only. Post a single Slack message AS the agent into a public OR private channel (not a DM). Use this when an admin asks to post/announce in a channel like #general. Accepts a channel id (C0123ABCD), a #name, a mention link (<#C0123ABCD|general>), or an archive permalink. Public channels the agent isn't in are auto-joined; private channels require the bot to have been invited first. For DMs use send_slack_dm_admin. Pass thread_ts to reply inside an existing thread.

Admin only. Resolve a Foundations audience into Slack user IDs for the platform's send_slack_dm_admin tool. Audiences: all members, FIRs, founders, specific member emails/Slack IDs you already have, or a natural-language profile query like 'members who went to Vanderbilt' (evaluated against every active member profile). Use this FIRST when an admin wants to DM a group described by membership data, then pass the returned slack_user_ids to send_slack_dm_admin. Not needed when the admin already gave you explicit Slack IDs or emails.

Admin only. Send an email now. Use this when the admin clearly wants the message sent without a review step. Recipients can come from all members, FIRs, founders, a specific list you already resolved, external email addresses, or a natural-language audience query like 'members who went to Vanderbilt'.

Admin only. Send an office-hours reminder DM now. Use this when the admin clearly wants the reminder sent without a review step. Recipients can be a list you already resolved or a natural-language audience query.

Admin only. Send a Slack direct message AS the agent to one or more people — anyone in the Slack workspace, not just known community members. Provide recipients as Slack user ids (or <@U…> mentions) and/or email addresses (resolved against Slack workspace profiles, then known people). Use this when an admin clearly wants a DM delivered. For posting into a channel use send_slack_channel_message_admin instead. Large recipient lists are queued and fan out in the background at Slack's rate limit.

Admin only. Create and send a structured survey now (no review step). Provide a title, an ordered list of questions (text, single_choice, or yes_no), and optionally a `collection_topic` so Root can also passively capture answers when members mention them in normal conversation. Recipients are OPTIONAL when collection_topic is set — omit them to create a passive-only survey that nobody is DMed about; answers come solely from regular conversation captures while the survey is open.

Recommend an item to add to an office's Costco shopping basket (groceries, snacks, drinks, kitchen/office supplies bought on Costco Same-Day). Use when a member asks for something to be stocked/ordered for the office, e.g. 'can we get more sparkling water', 'add paper towels to the Costco order', 'we're out of coffee in SF'. Root matches the request to the most likely product from past orders or a live Costco search, and admins review and submit the actual order. This does NOT place an order — it adds the item to the basket for admin review. If the user doesn't say which office, infer it from context (their usual office) or ask.

Remove one of the current user's OWN pending Costco basket recommendations (e.g. 'never mind about the sparkling water'). Admins can remove any item. Use list_costco_basket first if the item isn't clearly identified.

ADMIN ONLY: Submit the office's Costco basket as a REAL order (spends real money on the designated card). Sends the approved basket items through checkout with the office's saved delivery address and the designated credit card. By default only APPROVED items are ordered — pending recommendations must be approved first on /admin/costco (or pass include_recommended=true to order everything in the basket). Use dry_run=true to walk the whole checkout without placing the order. Takes several minutes (a live browser automation).

ADMIN ONLY: Refresh Root's Costco product catalog from the account's order history on sameday.costco.com (a browser automation, ~1-2 minutes). The catalog is what member recommendations are matched against. A scheduled job also does this daily — use this for an immediate refresh.

Cancel an existing office hours booking. Provide a booking_id for direct cancellation, or use mentor_name/date/time to find the booking. Set cancel_all to true to cancel all bookings.

Cancel an office-hours block that the email sender is hosting or has been explicitly authorized to manage as a copied delegate. Use this for requests like 'cancel my office hours on April 7' or 'please remove that hosted session'.

ADMIN ONLY: Create and schedule a hosted office-hours block ON BEHALF OF a designated host — an external mentor/advisor or a member — without the host having to email Root themselves. Use when an admin asks to set up office hours FOR someone else (e.g. 'create office hours for Kevin Penner on Aug 20 from 1 to 3pm'). The host is identified by host_email: an existing mentor profile is reused, an active member gets a host profile provisioned automatically, and a brand-new external mentor is created from host_name (plus optional title/bio/linkedin — always provide these when the admin shared them, so the host's listing reads well to members). The block is created in the office-hours schedule with bookable slots, the host receives the Google Calendar block invite at host_email, and non-member hosts of Seattle/SF sessions automatically get a day-of door code. Location defaults to Seattle (Huddle 1) ONLY while no SF/offsite scheduling window is open — while any window is open the tool refuses to assume and asks you to confirm the location with the admin. Set location to 'sf' or 'offsite' when the admin asks for the SF office or a mentor-chosen San Francisco location (offsite blocks are always assumed to be in San Francisco) — those require an admin scheduling window (override_schedule_checks also bypasses the window and the location clarification). For multiple hosts/dates, call this tool once per block. Do NOT use this for a member booking an attendee slot (book_office_hours) or for a host emailing Root about their own block (schedule_hosted_office_hours).

List who has signed up for a hosted office-hours block the email sender is allowed to manage (as host or authorized delegate). Returns each registrant's name, email, company, booked slot time, and topic. Use this for questions like 'who is signed up for my office hours?' or 'is anyone booked for my session today?'. Pass office_hours_id from list_hosted_office_hours when known; otherwise a date (or nothing, if the sender has only one active block) also works.

List upcoming hosted office-hours blocks the email sender is allowed to manage, whether they are the host or an authorized delegate copied on the calendar invite. Use this before cancelling or rescheduling when the specific hosted session is unclear, and when a host asks about setting up a new block — the result includes any open SF/offsite scheduling windows plus a location_intake_note; when that note is present, your reply collecting block details MUST also ask where they want to host (Seattle Huddle 1, Foundations SF, or offsite in San Francisco).

List upcoming or future available office hours sessions. Also use this when a user asks to book or schedule a meeting at Foundations — meetings are booked through office hours. Sessions may be in Seattle (Huddle 1), at the Foundations SF office, or offsite — each result includes location. Use the office filter when they ask specifically about SF or offsite. The result also includes currently open admin scheduling windows for SF and offsite so you can answer 'when can I book SF office hours?'. Use for booking availability only, not for historical or past-session questions. Do NOT use this when the user is offering times that they themselves could HOST as a mentor or advisor.

Reschedule an existing office hours booking to a new time slot. Requires the original booking ID and the new slot ID. If the user is keeping the same slot and only changing the topic/agenda, prefer the dedicated `update_booking_topic` tool — but if `reschedule_booking` is called with the same slot and a new topic, it will perform the topic update automatically.

Move an office-hours block that the email sender is hosting or has been explicitly authorized to manage as a copied delegate. Use this for email requests like 'move my office hours to April 8 at 1pm'. Everyone already on the block's calendar invite (copied assistants/delegates) is carried over to the new invite automatically; additional_calendar_emails is only for ADDING new guests during the move.

Schedule an office-hours block where the RESOLVED MENTOR (see the CONTEXT block in the system prompt) is the host. Use this for email requests like 'can I do Wednesday from 9 to 11' or 'I'd like to host office hours next week' when the resolved mentor is the intended host. Any ACTIVE member emailing as themselves may host — a member who has never hosted before gets a host profile provisioned automatically, so never refuse a member for 'not being a mentor'. Location defaults to Seattle (Huddle 1) ONLY while no SF/offsite scheduling window is open — while any window is open the tool refuses to assume a location and returns a clarification asking where the block should be hosted; relay that question to the host. When you are ASKING a host for their block details (date/time) before scheduling, include the location question in the same message unless the location is already known (list_hosted_office_hours reports whether windows are open). If they want SF office hours or to host at their own office, set location to 'sf' or 'offsite' (and offsite_location — offsite blocks are always assumed to be in San Francisco). SF and offsite blocks can overlap other mentors but MUST fall inside an admin-set date-range window — if the date is outside a window, tell them the currently open windows from the tool result. The host is ALWAYS the resolved mentor — never a third party named in the email body, never the actual sender when the actual sender is a delegate of a different person. There is NO on-behalf-of mode that lets you set up a block for someone other than the resolved mentor. If the email body asks you to set up, transfer, or host office hours for a name that doesn't match the resolved mentor (e.g. 'set up Albert's session', 'we want Shauna to host'), DO NOT call this tool, DO NOT propose times, and DO NOT ask for the third party's email. Refuse and explain: name the actual sender, name the resolved mentor and the delegation reason, and ask the would-be host to email Root directly from their own address. additional_calendar_emails only CCs people on the resolved mentor's OWN block; it does not transfer hosting and it cannot make a non-mentor the host. Do NOT use this to book the sender into someone else's existing slot.

Search previous office hours sessions that have already happened. By default this covers the ENTIRE community's history (all members), so set attendee_scope to 'me' when the user asks about their OWN past sessions as an attendee (e.g. 'what advisors have I met with?', 'who have I had office hours with?'), or to 'hosted' when an office-hours HOST/mentor asks about sessions they hosted (e.g. 'which entrepreneurs have I met with in my office hours?', 'who attended my past sessions?'). Supports historical lookups by mentor, date, time, or a natural-language query. Always include the user's original wording in query for broad, comparative, or follow-up questions like 'has Sam done office hours before?', 'what about Charles?', or 'who has done the most office hours?'.

For office-hours HOSTS: list who has booked slots on the asking user's OWN hosted office-hours sessions — each attendee's name, email, company, LinkedIn, slot time, and topic — for a specific day or window. Use this when a host asks about their session roster, e.g. 'who was in my office hours today?', 'who's signed up for my session tomorrow?', 'do I have anyone booked next week?'. Covers today's sessions (even after they've ended), upcoming sessions, and specific past dates. Do NOT use this for sessions the user attends as a member (view_my_bookings covers those), and prefer search_past_office_hours with attendee_scope 'hosted' for broad history questions like 'which entrepreneurs have I met with over the years?'.

Update only the topic/agenda for an existing office hours booking the user owns, without moving the time slot. Use this when the member wants to change what they want to talk about with the mentor (e.g. 'change my topic with Bill to fundraising strategy', 'update the agenda for my Maria meeting'). The Google Calendar event keeps the same time but its title and description are refreshed in place so the mentor sees the new topic.

View all current office hours bookings for the user. Each booking includes location (Seattle Huddle 1, Foundations SF, or the offsite address) so you can tell them where to go.

Analyze what is happening in the Foundations physical spaces using live camera feeds. Covers BOTH offices — Seattle (1605 Boylston Ave) and San Francisco (142 Minna St); camera names are suffixed with '(Seattle)' or '(SF)'. Both offices ALWAYS have cameras installed — if the result reports zero cameras for an office (see camera_system_status), that office's camera system is down, so say its cameras appear to be offline rather than implying the office has none. Use this when a user wants a live REMOTE look at the space — what's happening right now, whether someone is at the front desk, how busy it is — i.e. they clearly want a camera view (they mention cameras, feeds, snapshots, or checking on the space from elsewhere). Do NOT use camera tools when the user is asking to visit, find, or get into a room in person ('can I see the speakeasy', 'where's the studio', 'can I check out the 3rd floor') — especially when they are already AT the office (e.g. they recently badged in or their message implies they're on-site). Those questions want the room's location, what it is, or whether they can use it — answer from the knowledge base or what you know, and offer a camera view only if they explicitly ask for one. Sending surveillance snapshots to someone who wanted directions is a bad experience for them AND for anyone who happens to be on camera. If the user mentions a specific office, include that office in user_request so the right cameras are selected; if they don't mention an office but the context makes clear which one they mean, include it too — don't share the other office's cameras (and the people visible on them) unprompted. This tool can confirm visible occupancy, activity, clothing, and approximate location, but it does NOT identify specific people, members, or company affiliation. If the user wants to know WHO is visible, or whether a named person is on camera, use identify_people_in_space instead — it compares the cameras against member profile photos. If the user provided a clear visual description (clothing, build), this tool can say whether someone matching that description appears visible, but only as a description match, not confirmed identity. The camera images will be automatically shared with the user after analysis — do NOT try to embed images in your response. If the user asked for a camera view (e.g. 'show me the cameras'), use ONLY this tool — do not also call get_space_images, since this tool already shares the same images.

Log a tracked request for the community team when the user asks for something that needs a HUMAN to follow through — a physical/offline task, real-world coordination, or anything no other tool handles that the team must act on. The team sees it on their dashboard and the user is notified when it's done. NEVER say you have 'noted' or 'logged' something for the team without actually calling this. NOT for digital communications (messages, emails, reminders) — and for reporting a problem or passing a message to an admin, use escalate_to_admin instead.

Cancel/withdraw a request the user previously logged for the team, when they ask to remove, delete, or retract it. If the specific request is unclear, list their requests first.

Get live camera snapshot images from the Foundations physical spaces WITHOUT analyzing them. Covers BOTH offices — Seattle and San Francisco; camera names are suffixed with '(Seattle)' or '(SF)'. Both offices ALWAYS have cameras installed — if the result reports zero cameras for an office (see camera_system_status), that office's camera system is down, so say its cameras appear to be offline rather than implying the office has none. Only for users who clearly want a live camera view of the space from elsewhere. Do NOT use this when the user is asking to visit, find, or get into a room in person ('can I see the speakeasy') — especially when they are already at the office; answer with the room's location or details instead. If the user mentions a specific office, include that office in user_request so only its cameras are returned; if the context makes their office clear, include it too rather than sharing the other office's cameras unprompted. Use this ONLY when a user wants to see camera images and you are NOT also going to call analyze_space — for example, a pure 'show me the cameras' request where no question about the space needs answering. If you also need to answer a question about what's happening in the space, call analyze_space INSTEAD; analyze_space already shares the same images, so calling both is redundant and uploads duplicate images. The images will be automatically uploaded and shared with the user — do NOT try to embed them in your text response. Just mention which cameras you're sharing.

Look up a single survey by id, including its title, description, collection topic, status, and full question list. Use this when you have a survey id (for example from list_open_surveys or from another tool) and need to know the questions before submitting answers.

Try to identify WHO is visible in the Foundations spaces by comparing live camera snapshots against member Slack profile photos. Use this when a user asks who is in the space, who is at the front desk, or whether a SPECIFIC named person is visible on camera right now. Candidates come from members who badged in recently plus any names the user mentioned, so pass person_names whenever the user asks about specific people. Matches are visual suggestions, never certainties — always relay them with hedged language ('appears to be', 'may be') and the stated confidence, and never as confirmed identity. For 'is X in the office' questions where seeing them on camera isn't required, query_door_access_events (badge data) is more reliable — use this tool when the user wants a camera-based check or asks who is visibly present. The camera images are automatically shared with the user after analysis — do not also call analyze_space or get_space_images for the same request.

List the requests this user has logged for the community team (open and recently closed). Use when they ask what requests they have pending, whether something was already logged, or the status of a previous request.

List the open surveys this user can respond to right now, including the questions on each survey, which questions the user has already answered, and the survey's collection topic if it has one. Use this when the user asks about open surveys, asks to fill one out, or you want to verify the question list before submitting answers.

Escalate to a human admin when the user needs something you cannot do with your tools, asks you to pass a message to the team, or reports a problem you cannot resolve. Always available — never dead-end a user. Your reply to the user must also explain WHY you escalated (the substance of escalation_reason), not just confirm the hand-off.

Privately notify people at Foundations by Slack DM that this non-member visitor is here or trying to reach them. Covers members AND company employees (non-members who work at a member company in the building). Use when a visitor says things like 'I'm here for Aviel', 'can you let Jane know I arrived?', 'please tell Sam I'm downstairs', 'I'm here to see Sam from Acme' — or when they reference a member COMPANY instead of a person ('I'm a meeting guest of AZX', 'here for my meeting with Acme'). Pass the human-readable name the sender supplied as person_name, and/or the company they mentioned as company_name: a company alongside a person picks the right person; a company alone (or a person who can't be matched) has the company researched in the directory internally and its linked members and employees notified instead. All lookups happen internally and never return member/employee/company profile, email, Slack ID, or directory data. When a person name matches more than one person, delivery is still attempted to every plausible match (each recipient is told the match was ambiguous). The DM faithfully includes the inbound sender, subject when available, and latest message, labels the sender as unverified, and escapes Slack mentions/markup. This does NOT grant door access, unlock a door, or confirm that anyone is present. At most one notification attempt is allowed per inbound public message.

Notify the team so they can investigate WHY a mistake happened — a bad prompt, a stale record, or a misread. This does NOT update knowledge pages, recommendations, reviews, or any other stored data. If write/update/delete tools can apply the user's correction (extracted knowledge, a provider recommendation/review, a preference), you MUST call those first and only use this afterwards. Do NOT treat a successful report as the fix, and do not tell the user the underlying record was updated unless a write tool succeeded. Still use this whenever a user says the assistant is wrong, corrects a factual error, or complains that an answer/booking/message was incorrect — after applying any correction you can apply yourself. Do NOT use this for feature requests or missing capabilities (those are handled elsewhere), for normal clarifying follow-ups where the assistant simply needs more detail, or for the user being rude without pointing to an actual error. Still apologize and correct yourself in your reply to the user.

Forward an EXPLICIT feature request to the Foundations team's feature pipeline: the team is notified with full context, and (when configured) a coding agent is triggered to draft a pull request implementing the capability. Use this when the user explicitly asks Root to BUILD, ADD, or SUPPORT a new capability, tool, integration, or behavior it doesn't have today — e.g. 'build an admin override for that', 'you should be able to send calendar invites to guests', 'add a tool that does X'. Do NOT use it for: requests your existing tools can already handle, bug reports about existing tools (report_root_mistake), general messages to the team (escalate_to_admin), or vague wishes the user hasn't actually asked to be built — when unsure whether they want it built, ask first. You do not need this for ordinary failed requests: a background classifier already detects those gaps automatically after the exchange. In your reply, be honest about what happened: the request was forwarded to the team, and a draft PR is being generated ONLY if the result says so — the capability is NOT live yet and ships only after the team reviews it.

Submit one or more answers to an open survey on behalf of the current user. Use this both (a) when the user is explicitly answering a survey you sent them, and (b) when the user's natural conversation already answered a question on an OPEN survey that has a `collection_topic` — for example, if a survey is collecting RSVPs for the May 30 demo night and the user mentions in passing that they'll be there with a guest, capture that information here without asking again. Set `source` to `agent_passive` for those opportunistic captures and `agent_active` when the user is directly responding to the survey. You may submit a partial answer (one question now, more later) — the response is upserted per (survey, member) and only marked complete once every required question has been answered.

Search the user's own past conversations with Root across Slack, email, and the API. Use this when someone asks what they previously discussed with Root ('what did we talk about last week?', 'what did I ask you about X?', 'did I already request that?'). Returns past exchanges (their message + Root's reply) newest first, filterable by free-text query, channel, and date range. For EXISTENCE questions ('did I already ask/request X?'), ALWAYS pass a query — without one you only see the newest page and cannot conclude something was never discussed. ACCESS: non-admin members only see their OWN conversations. Admins can pass member_email to look up another member's history.

Fetch and read the text content of specific public web pages by URL — published Google Sheets/Docs, blog posts, member sites, shared resources. Use this whenever the user asks about the CONTENTS of a link ('who's in that spreadsheet?', 'summarize that article'): first locate the exact URL (from the current message, thread history, or a search_slack_messages result), then read it with this tool. Only works for publicly accessible pages — it cannot log in, so private documents fail or return a login page; say so if that happens. This is not a web search: for open-ended news or current-events questions use search_current_events instead.

Control whether Root @-mentions THIS USER in Slack when attributing their advice, quoting them, or cc'ing them into a thread. This is an account-level setting (default ON) that applies in EVERY conversation — not only chats with this user — so 'stop tagging me' actually stops the pings when someone else asks about a topic they commented on. Use this — NOT remember_user_preference — when the user asks to stop being tagged/pinged/@-mentioned, or to turn tagging back on. The setting is all-or-nothing (not per-topic): Root will still use their plain name. Does not affect other people mentioning them by hand.

Post a message into a PUBLIC Slack channel on behalf of the user you are DMing with, to start a community conversation about their question or topic. Only use this after (1) the user agreed they want the conversation taken to the community, (2) you settled on a public channel (via find_channel_for_community_post, or channel evidence already in this conversation's tool results), and (3) the user explicitly confirmed the exact channel, the full message text, and who will be cc'd, in this conversation. The post opens by mentioning the requesting user, and the members whose advice/expertise prompted the question can be cc'd so they're pinged into the thread. Never use this for announcements, admin broadcasts, private channels, or messages the user has not confirmed verbatim — for admin posting use send_slack_channel_message_admin.