Meet Root

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.

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 Root has ingested from Foundations 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 Foundations knowledge base for information about membership, policies, events, sponsors, 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.

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.

Submit a request to 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. The booking is created in pending status and the Foundations team is notified to review and approve. 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 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; once a request is approved or denied, the member should reach out to the team. If the member doesn't clearly identify which request, run list_my_event_requests first.

Cancel one of the current member's studio bookings. Works on PENDING and APPROVED bookings (approved bookings will also have their calendar invite cancelled). Already denied or 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 — pending, approved, denied, or cancelled — with status and details. Use when the member asks about a booking they previously requested, asks for the status of a pending studio request, or wants to know what they have on the studio calendar awaiting approval. Do NOT use this for Foundations event requests (use list_my_event_requests) or for community events.

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. The request is created in the calendar in pending status and the Foundations team is notified to review and approve it. 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). Confirm date and start/end time with the member before submitting if not already clear.

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). 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.

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, 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, link, visibility, or office (Seattle vs SF). Once a request has been approved or denied, the name, description, link, and office can still be changed (date, time, and visibility are locked at that point — for those, the member needs to reach out to the team). 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. While the request is still PENDING, any field can change — title (name), date, start/end time, purpose, attendees, external guests, description. Once the booking has been APPROVED, only title, purpose, attendees, external guests, and description can be changed; date and time are locked at that point and the member needs to reach out to the Foundations team if those need to move (or cancel and re-book). Denied or 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 Root to stop running it for now.

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

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

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.

Deactivate a previously saved user preference so Root stops applying it 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, Alumni, or Member). This returns THEIR information, not yours.

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.

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. IMPORTANT: 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'.

Update the current user's company profile. Provide only the fields to update.

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 OR a company-billed plan with seats. 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.

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.

Get the current user's membership plan details, billing info, status, and any active desk/office rentals (price, billing method, start date). Use this for questions about their plan, dues, or rental billing — including when a rental change takes effect.

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.

View the company's employee roster and seat info. Works for any member whose company is eligible to have employees — either a company-billed plan with seats OR an active desk/office rental. A rental gives the same employee management ability as a company plan.

Remove an employee (non-member teammate seat) from the user's company by their email. Works for any member whose company is eligible to have employees (rental or company plan). Revokes their building access and removes them from #office-sea.

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).

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

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'.

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.

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. 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'.

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. 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 (e.g. 'what advisors have I met with?', 'who have I had office hours with?'). 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?'.

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.

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)'. Use this when a user asks about events happening in the space, whether someone is at the front desk, how busy the space is, or any other question about the physical environment. If the user mentions a specific office, include that office in user_request so the right cameras are selected. 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 to SEE the space (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 request that requires a human and/or a physical-world action, then notify admins. Use for merch or swag, pickups, shipping, access help that needs manual staff intervention, special accommodations, concierge help, admin data fixes (e.g. linking a company to a member profile), adjacent event coordination (A/V setup, agenda additions, special accommodations for an existing event), or other offline/manual tasks the team must perform. Also use this when another tool fails because something needs admin-side setup or correction. Also use when a member tells you something the team needs to act on or know about and no other tool directly handles it — never just say 'noted' without actually recording the information. NEVER use for messaging, email sends, Slack DMs, drafting copy, surveys, reminders, bookings, or any other digital action Root can do directly through tools. NEVER use for HOSTING a new event at Foundations — call submit_event_request instead so the request lands on the calendar and the member can edit or cancel it. When speaking to the user afterward, call it a request, not a fulfillment request.

Delete one of the current user's previously logged requests. Use when the user says they no longer need a request, wants it removed, or asks Root to delete or cancel a previously logged request. If the user does not clearly identify which request, use list_my_fulfillment_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)'. If the user mentions a specific office, include that office in user_request so only its cameras are returned. 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 current user's logged requests that need human follow-through and their statuses. Use when a user asks whether Root already recorded a manual request, asks for the status of a merch or physical-world request, or wants to review previous requests Root logged for admins. When speaking to the user, call them requests, not fulfillment requests.

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.

Send a message to the Foundations admin team — this ALWAYS works, on every channel, for every user. Use it when: (1) the user explicitly asks you to pass along, relay, or deliver a message, note, thanks, feedback, or request to the Foundations team, staff, an admin, or a specific Foundations person (e.g. 'send Aviel a thank-you note', 'tell the team the printer is broken') — you cannot email or DM people directly, but THIS tool gets their message to a human who can; (2) the user's request can't be completed with your other tools and needs a human (account issues, billing disputes, partnerships, complaints, access problems you can't resolve); or (3) the user insists on something you've already been unable to verify or resolve once — don't loop, escalate. Do NOT use this when a more specific tool fits (fulfillment requests for physical/manual follow-through tasks, report_root_mistake when Root itself made an error, membership/booking tools for their own flows). NEVER tell anyone to 'email root@fndtns.org' or 'contact the team' as a dead end — you ARE the contact point; this tool is how their message actually reaches a person. In your reply, confirm you've passed it to the Foundations team and someone will follow up if needed — and when you escalated because you could NOT complete the request yourself, ALSO explain in plain language WHY you couldn't (what you checked, what's blocking, what only a human can do). You already know the reason — it's what you wrote in escalation_reason — so share that substance with the user instead of leaving them with an unexplained hand-off.

Flag the Foundations team when the user indicates Root made a mistake — gave a wrong, inaccurate, or made-up answer, took or described an incorrect action, or otherwise got something materially wrong. Use this whenever a user says Root is wrong, corrects a factual error in something Root said or did, or complains that an answer/booking/message was incorrect. This notifies an admin (via the standard admin notification system) so they can investigate the root cause — which is often a bad admin-authored prompt or stale data rather than a code bug. Do NOT use this for feature requests or missing capabilities (those are handled elsewhere), for normal clarifying follow-ups where Root 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; this tool runs in the background in addition to your response.

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.