Littlebird

Create a routine or one-off reminder that runs a prompt on the user's behalf and delivers the result as a report (optionally with a push/email notification). NOT available from inside a running routine. Before creating, agree on the essentials with the user: what the routine should do (the prompt), when it should run (the schedule), and a short clear title. Write the prompt as self-contained instructions addressed to the assistant that will run them unattended — specific about what to look at (integrations, meetings, context), what to produce, and the output format. Name which integrations and context sources to read, state the output format explicitly, and never end the prompt with follow-up questions — nobody is there to answer them. Avoid vague prompts like "summarize my day". Pick a schedule whose cadence matches the cadence of the underlying work — don't default to daily at 09:00 when the work is weekly or monthly. If the user only wants to hear about some runs ("ping me when someone requests my review", "only tell me if the error rate spiked"), set `kind: "watcher"` and put the condition in the `prompt` as its own sentence: "Only notify me when [condition]. If it is not met, write the report as usual but do not notify me about this run. If you could not check the condition, notify me." A content filter is NOT enough. A prompt that only says what to report, or what to say when there is nothing, still notifies on every run. A watcher whose condition can only happen once ("tell me once the invoice is paid", "let me know when the order arrives", "ping me when a specific person replies") says so in the `prompt` as its own sentence: "Tell me once, then stop." Judge by what the user named, not by whether that kind of event could happen again: "my package", "the invoice", "her reply" each name one occurrence and take the sentence. Give it the cadence its condition deserves. A reminder for a moment ('at 7pm tomorrow') is `kind: "reminder"` with `date` and `time` in `schedule` and nothing else: no check runs, and the `prompt` is the message itself, sent once as written by push and email and relayed faithfully by a messaging channel or agent, then the reminder retires. Write it as the message the user should read at that moment: address them directly, one or two short sentences, every detail they gave, no greeting and no mention of the time, since it arrives at the time. For recurring requests, use `kind: "digest"` when every run should notify, or `kind: "watcher"` when only a matching run should notify. For relative times such as "in an hour", calculate the date and time from the current timestamp in the user's timezone, including any date rollover. If the user states what to remember and when, choose a short title and create the reminder without another confirmation. Creation immediately generates a first report (visible in the Routines tab shortly after) and then runs on the schedule; a reminder skips that first report and waits for its moment instead. Users have a plan-based limit on how many routines they can have; if it's reached, this returns a message to relay instead of creating.

LB_INTERNAL_CREATE_ROUTINE

Get the details of a single meeting by its id: its name, TL;DR, full summary, and user-added manual notes, plus the associated calendar event (time, description, and that event's attendees) when the meeting is linked to one. Attendees are only shown via that linked calendar event — a transcript-only meeting with no calendar event won't list attendees here. This does NOT return the transcript; use LB_INTERNAL_GET_MEETING_TRANSCRIPT for the raw word-for-word transcript. Use this after LB_INTERNAL_LIST_MEETINGS or LB_INTERNAL_SEARCH_MEETINGS surfaces a meeting you want to know more about. Works on RECORDED meetings only — the id must come from a recorded result; a scheduled/unrecorded calendar event has no id and can't be fetched here. If the meeting recurs on a schedule, its linked event is tagged "(recurring)".

LB_INTERNAL_GET_MEETING

Get the verbatim transcript of a single meeting by its id, with speaker attribution as recorded. Use this when you need the exact words spoken (quotes, precise wording, who said what) rather than a summary. Get the meeting id from LB_INTERNAL_LIST_MEETINGS or LB_INTERNAL_SEARCH_MEETINGS. Transcripts can be long; prefer LB_INTERNAL_SEARCH_MEETINGS when you only need the relevant portions. Works on RECORDED meetings only — a scheduled/unrecorded calendar event has no id and no transcript to fetch here.

LB_INTERNAL_GET_MEETING_TRANSCRIPT

Get a routine's full configuration: its prompt (the exact instructions it runs), schedule and/or triggers, paused state, auto-pause setting, notification settings (push and email), and agent mode. Pass the `routine_id` from LB_INTERNAL_LIST_ROUTINES. Call this BEFORE updating a routine with LB_INTERNAL_UPDATE_ROUTINE — especially before editing its prompt, which must be replaced in full — and whenever the user asks what a routine does, why its reports look the way they do, or how to improve it. To read the reports themselves, use LB_INTERNAL_GET_ROUTINE_REPORTS.

LB_INTERNAL_GET_ROUTINE_CONFIG

Fetch a routine's past reports, most recent first, each with its date, title, text, and actions the user already completed outside Littlebird. Treat those actions as resolved and do not propose them again. Pass the `routine_id` from LB_INTERNAL_LIST_ROUTINES. `limit` sets how many to return (default 5, max 25); long histories are truncated to fit.

LB_INTERNAL_GET_ROUTINE_REPORTS

Call this whenever the user asks about their subscription state like what plan they're on, what they're paying, whether their subscription is active, when it renews, or which provider (Stripe, iOS App Store, team) bills them. Returns provider, plan, renewal/cycle-end date, active state, and team info.

LB_INTERNAL_GET_SUBSCRIPTION_STATUS

List the user's meetings in reverse-chronological order — BOTH recorded meetings (ones Littlebird captured, with notes/transcript) and scheduled calendar events that weren't recorded — each with its name, time, and attendees. Use it to browse "what did I have last week" / "my recent calls", or, with a future `end_date`, "what's coming up". A meeting/event that repeats on a schedule is tagged "(recurring)" next to its name. Telling them apart: only RECORDED meetings get an id in the trailing id list — drill into those with LB_INTERNAL_GET_MEETING or LB_INTERNAL_GET_MEETING_TRANSCRIPT. A listed calendar event with no id was not (or has not yet been) recorded, so it has no summary/transcript to open; that's also how you spot which upcoming events are on the calendar but not yet captured. NOTE: future/upcoming events are never recorded (they haven't happened yet), so they never have a summary or transcript and can't be opened (GET_MEETING) or searched (SEARCH_MEETINGS) — they only ever show up here as bare calendar entries. Pass `name` to find a meeting BY TITLE — the right tool for recurring meetings and their instances (e.g. "my last standup", "the previous 1:1 with Priya"). It matches the title against BOTH recorded meetings (by their own name or their linked calendar-event title) AND scheduled calendar events, returning matches most-recent-first. By default it returns PAST instances up to now (reaching back as far as needed) and excludes upcoming ones, since those are never recorded and a name lookup usually wants prior instances to compare against; to include upcoming instances, pass a future `end_date`. As with any list, only RECORDED matches carry an id — drill into those with LB_INTERNAL_GET_MEETING; a title-matching calendar event with no id wasn't (or hasn't yet been) recorded, so there's nothing to open. Use `name` (not LB_INTERNAL_SEARCH_MEETINGS) whenever you're looking a meeting up by what it's CALLED rather than what was discussed in it. Optional `start_date`/`end_date` are ISO date strings (e.g. "2026-06-01") bounding the window; set a future `end_date` to include upcoming calendar events. Without `name`: omit both to default to a recent window (about the last 90 days), and a very wide window is narrowed to its most recent portion (pass an explicit range to browse older meetings). With `name`: past reach-back is uncapped, but upcoming events are excluded unless you pass a future `end_date`. `limit` caps how many meetings/events are returned. This reads straight from the database (not the meeting search index), so it is unaffected by search-index availability. To find a meeting by TOPIC (what was discussed) rather than by title, use LB_INTERNAL_SEARCH_MEETINGS instead.

LB_INTERNAL_LIST_MEETINGS

List your conversations with the user by TIME, most recently active first. Use it for "what did we talk about yesterday", "show me my last few chats", or "what were we working on this week". Each entry has the conversation's id, title, source, start and last-active times, user-message count, and tags (favorite, project, origin; the conversation you are in is tagged "this conversation"). `limit` caps the list (default 10, max 20). `start_date`/`end_date` are ISO date strings bounding when a conversation was LAST ACTIVE; to page further back, pass the `cursor` from the result's paging hint. To find a conversation by what was discussed, use LB_INTERNAL_SEARCH_CONVERSATIONS.

LB_INTERNAL_LIST_RECENT_CONVERSATIONS

List the user's routines and reminders with their kind, title, schedule and/or trigger, report count, latest report date, status, and id. Pass `kind: "reminder"` to list reminders, or omit `kind` for all kinds. Completed ones are included and labeled. An optional `limit` returns the newest matches. Use the id with LB_INTERNAL_GET_ROUTINE_REPORTS to fetch that routine's reports.

LB_INTERNAL_LIST_ROUTINES

Read one conversation with the user in order, a page of turns at a time (a turn is one user message and your final reply to it). Use it after LB_INTERNAL_SEARCH_CONVERSATIONS or LB_INTERNAL_LIST_RECENT_CONVERSATIONS points you at a chat and you need more than the excerpt. `chat_id` is the conversation id from those tools, or 'current' for the conversation you are in (useful when earlier turns have been compacted away). By default it reads from turn 1; pass `start_turn` (1-based) to start elsewhere — e.g. the turn number shown next to a search excerpt — and `num_turns` for the page size (default 10, max 30). Alternatively pass `query` (a keyword or phrase) to open the page centered on the first turn that mentions it. Returns the conversation's title, source, dates, and tags, then the requested turns with timestamps; long turns are trimmed.

LB_INTERNAL_READ_CONVERSATION