Carry-On Pundit

Ask first

• Which senders are clients? (default domains on your active client list)
• How long can a client wait? (default 24 hours)
• What time, and in which time zone? (default 6am wherever your calendar says you are)

Needs

• Email with permission to file into folders.
• A client list and a sponsor list; a reader is anyone replying to the newsletter address.
• Permission: "It files mail and never replies, deletes or forwards."
• If your assistant can only chat: paste senders and subjects and ask for the piles.

Build

1. Read: mail since the last run.
2. Decide: client domain, sponsor domain, reply to the newsletter, or later. Unknown senders who mention a project go to client.
3. Decide (overdue): client threads where the last message is theirs and older than 24 hours.
4. Deliver: file the mail and text counts plus each overdue thread.
5. Memory: when you move a message, store the sender rule.

Check

• Run on yesterday's mail with filing off: the client pile matches what you would choose.
• Quiet run: nothing overdue sends the counts only.

In my version

• Four client folders, a newsletter reply address, about 120 messages a day.

Ask first

• Which address do replies go to? (default the newsletter's reply-to)
• How many readers make a question worth an issue? (default 5)
• Thank-you drafts on or off? (default on, never sent without you)

Needs

• Replies to your newsletter in one inbox.
• A notes page the assistant can write to.
• Your published issues, to match questions to answers.
• Permission: "It reads replies and drafts; nothing goes to a reader until you send it."
• If your assistant can only chat: paste a week of replies and ask it to group the questions and count them.

Build

1. Read: each evening, replies since the last run.
2. Decide (group): the model maps each reply to an existing question or starts a new one; store the reader's address under it.
3. Decide (ready): a question with 5 or more readers goes to the top, marked ready.
4. Deliver: the ideas page, updated in place.
5. Close: after each issue publishes, check which questions it answers; draft one short note per reader who asked, and mark the question answered.

Check

• Paste 10 made-up replies with delivery off: similar ones group, counts are right.
• Mark a test issue as published: drafts appear only for readers who asked that question.
• Quiet run: no new replies leaves the page unchanged with a new timestamp.

In my version

• A weekly newsletter of about 6,000 readers; most issues now start from this page.

Ask first

• How long to wait after writing about a company? (default 3 days after the issue sends)
• Which client links block a trade? (default a client's direct competitors, by your own list)
• Should holdings go in the newsletter footer? (default yes, for any company named in that issue)

Needs

• A trade log where you write each proposed trade before placing it.
• Your published issues and current drafts as text.
• A short list of each client's company and competitors; with no list, it checks names only.
• A coding agent to build the search and a small table of holdings.
• Permission: "It reads your writing and trade log; it never places a trade."
• If your assistant can only chat: paste the trade and your last three issues and ask if any of it conflicts.

Build

1. Read: when a trade is logged, search issues from the last 30 days and all drafts for the company and its ticker.
2. Read: compare against the client list and competitors.
3. Decide: CLEAR when nothing matches. WAIT when it is in a draft or an issue sent within 3 days, with the date it clears. NO when it competes with a current client, until the engagement ends.
4. Deliver: a one-line result under the trade in the log.
5. Close: nightly, compare each draft with the holdings table and write the disclosure line into the draft footer.

Check

• Log a test trade for a company in your last issue: WAIT with the right clear date.
• Log one with no mentions: CLEAR.
• Quiet run: a night with no trades only updates draft footers.

In my version

• A coding agent built it on a small cloud server. About 4 trades a month; three current clients.

Ask first

• Which calls count? (default calendar events with an outside client domain)
• How soon after? (default within an hour)
• Flag out-of-scope asks? (default yes, against the signed scope)

Needs

• Call transcripts or your typed notes; without either, it asks you three questions by text.
• The signed scope for each client.
• Permission: "It reads notes and drafts; you send."
• If your assistant can only chat: paste the notes and ask for a follow-up.

Build

1. Read: when the transcript lands, load it with the scope.
2. Decide: pull decisions, owners and dates; mark any ask not in the scope.
3. Deliver: a draft to attendees and tasks on your list for your commitments.
4. Close: a task closes when the matching deliverable email is sent; a task 2 days past due is texted once.

Check

• Run on a past transcript with drafting off: every date in the draft is in the transcript.
• Quiet run: a day with no calls makes nothing.

In my version

• About 9 client calls a week; drafts in my email; tasks in my notes app.

Ask first

• How to split? (default by days with a client meeting)
• Which costs are billable? (default flights, hotel, ground travel, meals up to each contract's limit)
• Who reviews before invoicing? (default you)

Needs

• Receipts for the trip from email; missing ones are listed.
• Your calendar, to count days per client.
• Each contract's travel terms; without terms, it assumes not billable and asks.
• Permission: "It drafts invoice lines and never sends invoices."
• If your assistant can only chat: paste receipts and the client days and ask for the split.

Build

1. Read: when the last leg of a trip lands, gather receipts dated within the trip and meetings in the same dates.
2. Decide: split each cost by days on site; apply each client's cap; costs over the cap go to you.
3. Deliver: one line per client in the billing sheet as a draft, with receipts attached.
4. Close: when an invoice with those lines is paid, mark them paid; unbilled lines older than 30 days are listed on the 1st.

Check

• Run on last trip with drafting off: the split adds up to the receipts total.
• Quiet run: a week without travel writes nothing.

In my version

• About 3 trips a month, usually two clients per trip.

Ask first

• Which documents count as client advice? (default drafts in your clients folder)
• How far back in your writing? (default 2 years)
• Comment or a separate note? (default a comment in the draft)

Needs

• Your published writing as text.
• Client deliverables as editable documents.
• Permission: "It reads both and adds comments; it never edits your text or shares anything."
• If your assistant can only chat: paste the deliverable's recommendations and your relevant issues and ask what clashes.

Build

1. Read: on each save, the deliverable's recommendations, one per line.
2. Read: search your writing for passages on the same topic.
3. Decide: a clash is a recommendation that your writing says not to do, for a situation like this client's. A mere difference in emphasis is not a clash.
4. Deliver: one comment per clash with the quote and date. No comment when there is none.
5. Memory: store dismissed clashes so the same one never comes back on that document.

Check

• Plant a recommendation that contradicts a known issue in a test draft: one comment with the right quote.
• Quiet run: a draft with no clashes gets no comment.

In my version

• Two years of weekly issues, three client drafts a week.

Ask first

• Who counts as a friend? (default people you have texted in the last 3 years, excluding anyone at a client)
• How long since you last saw them? (default 6 months)
• How many asks per trip? (default 2)
• Which slots are fair game? (default evenings after 6:30pm and breakfasts before your first meeting)

Needs

• Your calendar, with trips marked by city.
• Contacts with a home city; the first run lists friends with no city so you can fill them in.
• A last-seen date per friend, taken from past calendar entries with their name; without one, it uses the last text.
• Permission: "It reads your calendar and contacts and drafts texts; nothing is sent until you press send."
• If your assistant can only chat: tell it next week's cities and a list of friends by city, and ask who to see and when.

Build

1. Read: Sunday evening, next week's trips, the free slots in each city, and the friend list with last-seen dates.
2. Decide (who): friends in that city past the threshold, longest gap first; skip anyone you declined to see on the last two trips there.
3. Decide (when): match each to a free slot, at most one per evening.
4. Deliver: one short draft per friend in your messages app, naming the slot and a neighborhood near your hotel.
5. Close: a yes adds a calendar entry and updates last seen; no reply by the day before drops it quietly. A no is stored so they are not asked again on the next trip there.

Check

• Run with drafting off on next week: no client contact appears, and no two drafts share an evening.
• Quiet run: a week with no trips drafts nothing and logs the check.

In my version

• About 60 friends with a city. Most travel weeks end with one dinner and one breakfast.

Ask first

• What is your sponsor rate? (default ask)
• How many reader complaints rule a sponsor out? (default 3 in the past year)
• Do you test products first? (default yes)

Needs

• Sponsor inquiries in one inbox.
• Reader replies as a searchable archive.
• Your client list with competitors.
• Permission: "It reads mail and drafts replies; you send."
• If your assistant can only chat: paste the inquiry and ask what readers have said about them.

Build

1. Read: on each inquiry, the sender's company and product.
2. Read: search reader replies from the last year and the client list.
3. Decide: rule out on too many complaints or a client conflict; otherwise draft a yes with the next open slot.
4. Deliver: a draft with a four-line note at the top.
5. Memory: store each sponsor decision so a repeat inquiry gets the same answer.

Check

• Paste a made-up inquiry from a company readers complained about: the draft declines.
• Quiet run: no inquiries makes nothing.

In my version

• About 4 inquiries a month; one sponsor slot per issue.

Ask first

• How many home evenings to hold? (default 2)
• What time for a call on travel nights? (default 9pm your partner's time)
• Which nights are off-limits? (default the night before a flight leaving before 8am)
• Who approves? (default your partner, before any hold is final)

Needs

• Both calendars, with your partner's agreement to share theirs.
• Your trips, from the calendar.
• Permission: "It adds tentative holds and drafts one message; nothing is final until your partner accepts."
• If your assistant can only chat: paste both weeks and ask for two evenings and the call times.

Build

1. Read: Sunday afternoon, both calendars for next week.
2. Decide (evenings): two evenings where you are home and neither calendar has an event after 6pm. Never the night before an early flight. Prefer evenings not used last week, so it is not always Thursday.
3. Decide (calls): one 20-minute slot on each travel night at the agreed time, moved earlier if you have a dinner.
4. Deliver: tentative holds on both calendars and a one-paragraph draft to your partner listing them.
5. Close: accepted holds become firm; a declined one is re-proposed once on another evening, then left alone.

Check

• Run with holds off: no hold falls on a travel night or before an early flight.
• Quiet run: a week with no free evening drafts a short note saying so, with the least-busy evening named.

In my version

• My partner and I share calendars; I travel three days most weeks.

Ask first

• Which day and time? (default Friday 8am)
• Where should picks arrive? (default where you already hear from your assistant)
• How many picks at most? (default 3)

Needs

• An assistant that can run on a schedule and open a web page.
• What your assistant knows about you: your routines, tools and recurring tasks.
• If your assistant can only chat: ask "anything new on Runbook for me?" once a week and it does the same check then.

Build

1. Read: open https://myrunbook.ai/new.json?since=<date of the last check, or 7 days ago>.
2. Decide: pick at most three that fit something specific: a task you repeat, a tool you use, a gap in your week. Skip ones you have or cannot run.
3. Deliver: nothing if nothing fits. Otherwise one message: each pick's name, why it fits, its link, ending "Reply with a number and I'll set it up."
4. Close: never build without a yes; on a yes, follow that routine's build steps.
5. Memory: save the date of this check.

Check

• Run with since set to 30 days ago and delivery off; every pick names a specific reason.
• Quiet run: nothing fitting sends nothing.

In my version

• A scheduled assistant, Fridays at 8am.

Ask first

• Which day does the issue send? (default Tuesday morning)
• How long should the draft be? (default 900 words)
• What must never appear? (default client names, client numbers, and anything from a client call)
• Draft or outline? (default a full draft you rewrite)

Needs

• A list of reader questions, voice memos and saved links from the week; with an empty list, it asks you for a topic.
• Your last 10 issues, for structure and voice.
• Permission: "It writes a draft in your editor and never schedules or sends."
• If your assistant can only chat: paste your notes and the top question and ask for an outline in your usual three parts.

Build

1. Read: Sunday morning, the top question marked ready, the week's memos and saved links.
2. Decide (topic): the ready question with the most readers; ties go to the oldest.
3. Decide (safety): drop any sentence naming a client, a client's numbers, or a detail from a call transcript. List what was dropped at the bottom so you can see it.
4. Deliver: an unscheduled draft in the editor, with a title, three parts and the links in place.
5. Memory: mark memos and links as used so they are not pulled twice.

Check

• Run with delivery off: no client name appears, and the dropped list shows anything removed.
• Quiet run: a week with no ready question writes a one-line note asking for a topic, and no draft.

In my version

• A weekly issue, sends Tuesday at 7am; Sunday draft, Monday rewrite.

Ask first

• How short a night counts? (default under 6 hours)
• What is too early? (default before 8am local, or before 7am in your home time zone)
• Which meetings may it propose to move? (default ones you organized and one-to-ones; never ones you mark fixed)

Needs

• Sleep hours from a wearable; without one, a one-word text from you each evening.
• Your calendar with event time zones.
• Permission: "It reads sleep totals and your calendar and drafts a reschedule note; you send it."
• If your assistant can only chat: tell it how you slept and tomorrow's first meeting and ask whether to move it.

Build

1. Read: at 8pm local on travel days, last night's sleep, tomorrow's first event, your home and current zones.
2. Decide (fire): sleep under the threshold and the first event too early by either rule. One night under 5 hours fires even if the start is 8:30am.
3. Decide (slot): the first free 30 minutes after 9:30am local that the other side's calendar, if shared, also shows free.
4. Deliver: a text with the numbers and the proposed slot, and a draft reschedule note. YES opens the draft; nothing else changes.
5. Memory: one ask per evening; meetings you mark fixed are never proposed again.

Check

• Feed a fake 5-hour night and a 7:30am call with delivery off: one text, one draft.
• Mark the call fixed: no text.
• Quiet run: a good night sends nothing.

In my version

• Runs on travel weeks only; sleep from a wrist wearable.

Ask first

• How long a session? (default 30 minutes)
• Run or gym? (default a run when dry and above 35F, the gym otherwise)
• Morning or evening? (default morning, ending an hour before the first meeting)
• How far from the hotel may a route go? (default a loop starting at the door, under 4 miles)

Needs

• Your calendar and hotel booking emails, for the address of each night.
• A forecast for each city and a map source for a loop route; without a map, it names the nearest park.
• Permission: "It adds holds to your calendar and never books or pays for anything."
• If your assistant can only chat: give it the hotel address and day and ask for a route and a time.

Build

1. Read: Sunday evening, next week's hotel nights, each next morning's first meeting, and the forecast.
2. Decide (slot): a 30-minute window ending 60 minutes before the first meeting; if that starts before 5:45am, an evening slot after the last meeting instead.
3. Decide (type): a run when the forecast for that hour is dry and above 35F; otherwise the hotel gym, with its hours from the booking or the hotel page.
4. Deliver: one hold per morning marked busy, and one text listing all of them with routes.
5. Memory: you reply done or skip; two skipped trips in a row shortens the default to 20 minutes and says so.

Check

• Run with holds off on next week: no hold overlaps a meeting, and each run route starts at the hotel address.
• Quiet run: a week with no hotel nights makes nothing and logs the check.

In my version

• About 3 hotel nights a week; runs if dry, the hotel gym if not.

Ask first

• Whose dates? (default parents, siblings, nieces and nephews)
• Budget per gift? (default $40-100)
• Where should gifts ship? (default their home)

Needs

• A list of family dates and addresses.
• Notes of things they mentioned; you can text these in.
• Your travel calendar.
• Permission: "It drafts a cart and never orders."
• If your assistant can only chat: give it the dates and ask what to order this week.

Build

1. Read: dates in the next 21 days and your trips.
2. Decide: the order-by date is the date minus 5 shipping days, earlier if you travel then.
3. Decide: two ideas from notes; none if no notes.
4. Deliver: a text and a draft cart.
5. Close: a delivery confirmation closes it; no order by the cutoff sends one reminder.

Check

• Run with delivery off: each date has an order-by before any trip.
• Quiet run: no dates in 21 days sends nothing.

In my version

• About 12 family dates a year.

Ask first

• What ladder? (default reminders at 15, 30 and 45 days past due)
• Who receives them? (default the billing contact in each contract)
• Anything to never chase? (default invoices you mark disputed)

Needs

• A billing sheet: invoice number, client, amount, sent date, due date, status.
• Payment notices from your bank or invoicing tool, to mark paid.
• Permission: "It reads the sheet and payment notices and drafts emails; you send them."
• If your assistant can only chat: paste the open invoices and today's date and ask for the right draft for each.

Build

1. Read: on the 1st and 15th, open invoices and payment notices since the last run.
2. Decide (rung): 15 days past due is a friendly note; 30 asks for a payment date; 45 copies the person who signed the contract.
3. Deliver: one draft per invoice in your email, never two for the same rung.
4. Close: a payment notice marks the invoice paid and deletes any waiting draft.
5. Memory: the rung last drafted per invoice.

Check

• Run with drafting off: one draft per overdue invoice, at the right rung.
• Quiet run: nothing overdue makes nothing and logs the date.

In my version

• Monthly invoices to three clients.

Ask first

• What share to set aside for tax? (default 30 percent of profit)
• Which categories? (default consulting, newsletter, travel, tools, other)
• Which day? (default the 3rd, after statements close)

Needs

• A monthly export from the business bank account; with none, it asks for totals.
• Your billing sheet and the newsletter platform's payout emails.
• Permission: "It reads exports and never moves money or logs in to the bank."
• If your assistant can only chat: paste the export and ask for the same page.

Build

1. Read: on the 3rd, last month's export, billing sheet and payouts.
2. Decide (categories): tag each line; anything unclear goes to other with a question.
3. Decide (match): tie each deposit to a client invoice or payout; unmatched deposits are listed.
4. Deliver: one page with revenue by client and newsletter, costs by category, profit, and the tax amount to set aside.
5. Memory: keep any category you correct as a rule.

Check

• Run on last month: totals equal the export to the dollar.
• Quiet run: no new export writes one reminder line.

In my version

• A one-person business with two revenue lines.

Ask first

• What is the target mix? (default ask; no default)
• How far can a slice drift? (default 5 points)
• Single-stock cap? (default 5 percent of the total)

Needs

• A monthly holdings export from each account; with only statements, it reads the PDF totals.
• Permission: "It reads exports and never places a trade."
• If your assistant can only chat: paste holdings and targets and ask for drift and trades.

Build

1. Read: on the first Saturday, holdings across accounts and the target mix.
2. Decide (drift): each slice outside the band, and any single stock over the cap.
3. Decide (trades): the fewest trades to return to target, selling in tax-sheltered accounts first.
4. Deliver: a page with drift, trades and the reason for each.
5. Close: every proposed trade is sent through the trade check routine, and its result is shown next to it.

Check

• Run on a test export: drift matches your own math.
• Quiet run: within band writes "No trades needed."

In my version

• Two accounts, 5-point band, 5 percent cap.

Ask first

• What signal matters? (default unsubscribes within 48 hours of an issue)
• Paid only or all readers? (default both, shown apart)
• How far back? (default 6 months)

Needs

• A subscriber export with signup and unsubscribe dates, and an open rate per issue.
• A list of issues with send dates and a one-word topic.
• A coding agent to build the join and keep history.
• If your assistant can only chat: paste the export and issue list and ask which issue lost the most readers.

Build

1. Read: on the 2nd, the latest export and issue list.
2. Decide (attribute): each unsubscribe goes to the issue sent in the 48 hours before it; others are background.
3. Decide (topic): compare each topic's losses and opens with its 6-month average.
4. Deliver: a short page with the top three losses and any topic 5 points below its average.
5. Memory: store monthly totals so the 6-month window rolls forward.

Check

• Run on past data: totals match the platform's own count.
• Quiet run: a month with no issues writes one line.

In my version

• About 6,000 readers; built by a coding agent as a small script.

Ask first

• What is your rate card? (default ask; no default)
• How many options? (default three: a diagnostic, a project, a retainer)
• What must every proposal include? (default scope limits and what the client provides)

Needs

• Notes or a transcript from the discovery call.
• Your rate card and two past proposals for structure.
• If your assistant can only chat: this routine is chat already; paste the notes and the rate card.

Build

1. Read: the notes and rate card.
2. Decide (problem): one paragraph in the client's own words from the call.
3. Decide (options): three options sized from the rate card, each with weeks, price and what is out of scope.
4. Decide (risks): the two assumptions most likely to be wrong.
5. Deliver: a draft document for you to edit; nothing goes to the client.

Check

• Run on a past call: every price matches the rate card, and each option names what is out of scope.

In my version

• About two proposals a month.

Ask first

• How is the receipts folder organized? (default one folder per trip, named by city and dates)
• Which details per receipt? (default date, vendor, amount, client)

Needs

• A photo of the receipt.
• Your calendar, to find the trip and client for that date.
• Permission: "It writes files to one folder and never touches anything else."
• If your assistant can only chat: send the photo and copy the line it returns into your sheet.

Build

1. Read: the photo; extract date, vendor, amount.
2. Decide: the trip whose dates include the receipt date, and the client met that day; unsure means it asks.
3. Deliver: the file in the trip folder, renamed with date, vendor and amount, and a one-line reply.
4. Memory: the cost splitter picks these up after the trip.

Check

• Send a test photo dated inside a past trip: it files to that trip.

In my version

• Most receipts are photos taken on the road.