Ops is where agents pay you back in hours, not dollars. Marketing scales output. Sales scales pipeline. Ops scales you — by killing the meta-work that sits between every revenueproducing thing you actually want to be doing. The pattern under every tip in this section: the agent reads everything you can't keep up with — meeting transcripts, Slack threads, Teams DMs, the long tail of follow-ups you "meant to do" — and turns it into a small number of things you actually have to look at. Decisions, blockers, drafts to approve. That's the whole job. A few principles up front: Meetings produce assets, not memories. A meeting that doesn't generate a transcript, a decision log, and a TODO update may as well not have happened. The agent is what turns the meeting into the asset. One source of truth for TODOs. Pick one system. Linear, Notion, Todoist, a markdown file — doesn't matter which one wins, matters that there's only one. The agent reads from and writes to that one place. Auto-check-off is the unlock. Most TODO systems die because nobody checks things off. The agent has to do this for you, by reading the same channels you live in. Cross-channel awareness > per-channel cleverness. A single sweep that scans Slack + Teams + email + your CRM beats any one of those tools' built-in "smart inbox" feature by a mile. The agent goes wide. Approval gates on anything sent externally. Auto-action on anything internal. Internal TODO updates, status digests, decision logs — the agent just does it. Anything that pings another human outside your company goes through you first, until you've watched it long enough to trust it.

1. Meeting Intelligence

The thesis: nobody remembers what was decided in the meeting three weeks ago. Nobody. And the cost of that — re-deciding, re-explaining, re-doing — is the single biggest tax on a fast-moving team. Meeting intelligence eliminates the tax. Every meeting becomes a structured artifact the agent can search, summarize, and act on.

Tip 1.1 — Team meeting transcription pipeline (Fathom is the winner)

What it does: Every call you take — sales, internal, client, coaching — gets recorded, transcribed, and dropped into a known location your agent reads from. Within minutes of the meeting ending, you have the transcript, an AI summary, the action items as the recorder caught them, and a permalink. Your agent has all of that and can compound on it. Why it wins: A transcript is the cheapest, highest-leverage asset in your ops stack. Once every meeting produces one automatically, every downstream tip in this section just works. Without transcripts, nothing else in section 1, 2, or 3 has anything to chew on. Tools: Pick one recorder, wire it up once. The honest ranking: Fathom — winner for most operators. Free tier is generous, the API is clean, summaries are reliable, and it auto-joins Zoom/Meet/Teams. This is what the operator uses in production. If you're starting from zero, install Fathom. Granola — best for in-person and Mac-first workflows. No bot joins your call — it just listens via the system mic. Great if you do a lot of coffee meetings. tl;dv — strong free tier, similar to Fathom, slightly weaker API. Reasonable backup. Otter — older incumbent, transcripts are fine, summary quality is behind the pack. Skip unless you're already on it. Read.ai — heavier on "meeting analytics" (talk time, sentiment), lighter on action-item extraction. Niche pick. Pick one. Don't run two. Two recorders means two sources of truth and the agent has to reconcile them every single call. How to wire it: 1. Sign up for a recorder (Fathom is the default). Then tell your agent: "I just signed up for Fathom — connect it to my calendar, turn on auto-join for external meetings, and toggle auto-recording on." 2. Tell your agent to do the API setup: "Pull the Fathom API key, store it safely, and verify you can list recent meetings." The API exposes recordings, transcripts, summaries, action items, and tags. 3. Tell your agent to poll the recorder on a cron (every 15 minutes works) for new completed recordings. For each one, pull the transcript + summary + action items. 4. Stage every meeting in a known structure: /meetings/YYYY-MM-DD//transcript.txt , summary.md , action-items.json , metadata.json (attendees, duration, calendar event link). 5. Index the meetings somewhere searchable — a simple Google Sheet with title, date, attendees, summary, link to the transcript file is plenty. Postgres + pgvector if you want fuzzy semantic search. Example prompt to your agent:

Set up a Fathom polling pipeline. Every 15 minutes, hit Fathom's API for completed recordings I haven't processed yet. For each one, pull the transcript, the AI summary, and the extracted action items. Save them under /meetings/YYYY-MM-DD// . Append a row to my "Meeting Log" sheet: date, title, attendees, length, one-paragraph summary, link to the transcript file. Save the whole thing as a skill called meetingingest . Tell me on Telegram every time a new meeting is processed with a 3-line digest: title, top decision, top action item. Watch out for: Recorder bots can land in meetings you didn't expect to be recorded (and shouldn't be). Always whitelist or default-off for external/sensitive calls. Get consent every time. Fathom's API rate limits are generous but not infinite — page through, don't pull a year of history in one shot. Transcripts have errors. Names, acronyms, technical terms. Build a glossary file the agent maintains as it sees repeat mistakes, and have it apply the glossary before downstream processing. Privacy: transcripts contain client names and internal discussions. Store them where you'd store the underlying client data. Don't pipe them to a public API or a model with training data retention turned on. Skill file: _skills-anonymized/fathom-transcripts/ — production-grade Fathom integration. Lift it.

Tip 1.2 — Post-meeting "who needs to do what" auto-post

What it does: Within 5 minutes of any meeting ending, your agent has read the transcript, identified every action item, mapped each one to a specific person, and posted the list to the right channel — Teams, Slack, email — tagging each owner. Why it wins: The "who-does-what" message after every meeting is the single most valuable internal communication a team can have. Most people skip it because they're tired after the call. The agent never gets tired. And because the action items are extracted from the actual transcript, nothing gets missed and nothing gets misremembered. Tools: Your transcript pipeline (Tip 1.1), Slack API (Web API + chat.postMessage ) or Microsoft Graph API for Teams ( /teams/{id}/channels/{id}/messages ), or Gmail API for email teams. A directory of who's on the team and which channels/handles are theirs. How to wire it: 1. Build a team-roster.json : name, email, Slack handle, Teams handle, role. The agent uses this to map "Andy will handle the contract" → @andy in Slack.

2. Hook into Tip 1.1's pipeline. On every new meeting processed, run an action-item extraction pass. Don't trust the recorder's built-in extraction alone — re-run with your own prompt, then merge. 3. For each extracted action item, the agent decides: who is the owner (from attendees + roster), what's the due date (look for explicit dates in the transcript, otherwise leave blank), and what's the surrounding context (the 2-3 lines around the moment it was assigned, for grounding). 4. Post a single message to the right channel: title is "Action items from [meeting title] — [date]." Body is one bullet per item, formatted @owner — [task] (context: [quote]) . 5. Approval gate the first 10 of these. Once they look right, auto-post. Example prompt to your agent: After every meeting processed by meeting-ingest , run a second pass to extract action items. Use my roster in team-roster.json to map each action item to an owner. For each action item, capture: owner, task description, due date (if mentioned), 2-line quote for context. Format as a single Slack message and post to the channel mapped to that meeting type in meeting-channel-map.json (e.g., internal-standups go to #standup, client calls go to #client-x). Tag owners by their Slack handle. For the first 10 messages, send them to me as a draft on Telegram first — once I approve 10 in a row, switch to auto-post. Watch out for: LLM-extracted action items hallucinate ownership when the transcript is ambiguous. Force the agent to quote the exact line where ownership was assigned — if it can't, mark the owner as "unassigned" and flag for human review. Channels with mixed internal/external members: don't auto-post action items to channels where clients can see them unless that's intentional. Default to a private internal channel and let the human cross-post if needed. People hate being @-mentioned for trivial items. Score action items by impact — "send the deck" is high; "think about it" is noise. Below-threshold items go in a separate "FYI" list at the bottom. Skill file: Composite — builds on fathom-transcripts + slack-formatting + (for Teams) a thin Microsoft Graph wrapper. Pattern only — no standalone skill in this version. Tell your agent to wire one from these.

Tip 1.3 — Auto-decision log (decisions ≠ action items)

What it does: Separate from action items, the agent maintains a running log of every decision made in your meetings. "We're going with vendor X." "We're pricing the tier at $499." "We're killing the LinkedIn ads experiment." Each decision gets a timestamp, the meeting it was made in, who agreed, and the rationale quoted from the transcript. Why it wins: Action items get done or dropped — both are visible. Decisions get forgotten. Three weeks later, somebody re-opens a debate that was settled, and now you're redeciding from scratch. A decision log eliminates this entirely. It's also the single most useful onboarding doc for anyone joining your team mid-project — "here's everything we've decided, and why." Tools: Same pipeline as 1.1/1.2 plus a decision-log file. Notion database is ideal; a markdown file works. How to wire it: 1. After action-item extraction (Tip 1.2), run a separate pass with a different prompt: "Find every decision made in this meeting. A decision is when the group commits to a course of action, rules out an option, or sets a constraint. Action items are who-does-what; decisions are what-is-true-going-forward." 2. For each decision, capture: the decision (one sentence), the rationale (one sentence from the transcript), the people who agreed (or pushed back), the meeting source, the timestamp. 3. Append to a Notion database or a decisions.md log. Tag by topic/project. 4. Weekly digest: every Friday, the agent posts the week's decisions to a dedicated #decisions channel or emails them to the team. Forces transparency. 5. Searchable from chat: "What did we decide about pricing?" → agent greps the decision log. Example prompt to your agent: After action-item extraction on every new meeting, run a decision-extraction pass. Find moments where the group committed to a course of action, ruled an option out, or set a constraint. For each decision: write a one-sentence statement, capture the oneline rationale quoted from the transcript, list who was present and any dissenters, and append to my Notion "Decisions" database (or /decisions/YYYY-MM.md if no Notion). Tag by project/topic. Every Friday at 4pm, post the week's decisions as a digest to the #decisions channel. Watch out for: The agent will over-extract early on. "We should think about pricing" is not a decision. Force it: "If the group did not commit to a specific action or specific exclusion, do not log it."

Conflicting decisions across meetings happen. When the agent sees a new decision that contradicts a previous one, surface both and ask the human which stands. Don't autosupersede. For client meetings, separate client-facing decisions from internal ones. Don't accidentally surface internal-only decisions in a shared decisions log. Skill file: Extends fathom-transcripts with a decision-extraction pass. Pattern only — no standalone skill in this version. Tell your agent to write one from this recipe.

2. The Living TODO System

The unfixed problem in every team's productivity stack: TODOs go in, but they don't always come out. Things get half-done, forgotten, re-discussed, and re-added. A living TODO system means the agent owns the list — adding things from meetings and messages automatically, checking things off when it hears they're done, and reminding you of the ones that are aging out without action.

Tip 2.1 — Agent-owned running TODO list

What it does: A single source-of-truth TODO list the agent maintains for you. Every action item from meetings flows into it. Every "remind me to..." you type goes in. Every commitment the agent sees you make in a Slack or Teams message goes in. The agent reminds you of stale items, surfaces what's urgent, and is the only thing that adds or removes items besides you. Why it wins: You stop juggling 6 places where TODOs live (sticky notes, Slack reminders, your phone, that one Google Doc, the back of your hand, what you remember). One place. The agent is the bouncer. Tools: Pick one system, one: Linear — winner if your team uses it for engineering anyway. API is excellent, GraphQL, free for small teams. The agent can create issues, assign, comment, close. Notion — winner if you live in Notion otherwise. API is clean, database model is flexible. Slightly slower API responses than Linear. Todoist — winner for solo / personal TODO. Best mobile experience by a mile. Plain markdown — winner if you're maximalist on simplicity. todo.md in your workspace, agent reads/writes directly. No API friction. Zero cost. Don't run two. Pick the one your team will actually open. How to wire it:

1. Initialize the list. Have the agent ingest your existing TODOs from wherever they currently live and consolidate into the chosen tool. 2. Define the schema: every TODO needs an owner, a created-at, a source ("from meeting X" / "from Slack thread Y" / "from the operator directly"), a priority (1-3), and a status (open/in-progress/done/won't-do). 3. Tell the agent it owns this list. New items can come from: (a) you, in chat, (b) action items from Tip 1.2, (c) other agent workflows (e.g. lead follow-up sweep adds "follow up with X"), (d) commitments the agent detects in your sent messages (Tip 2.3). 4. The agent never deletes — it closes with a status. History is preserved. 5. Wire up the rest of section 2 on top of this base. Example prompt to your agent: You own my TODO list, which lives in Linear (workspace: [URL], default project: "Personal"). Every TODO has: title, description (optional), owner (default: me), source (where it came from), priority (1-3, default 2), status (open/in-progress/done/wont-do). When I tell you a new task, you create the Linear issue. When meetings produce action items, you add them with source = "meeting [title]". You never delete — you close with status. Build a todo skill that wraps Linear API calls: create, list (with filters), update, close. From now on, when I say "add to my list" or "what's on my plate," use this skill. Watch out for: Sub-tasks balloon fast. Have the agent collapse anything more than 2 levels deep — the list should be scannable in 30 seconds. Privacy: the agent will see TODOs that mention real names, deal values, etc. Make sure the tool's permissions are right (Linear: workspace-scoped, not org-wide). Don't over-prioritize. If everything is P1, nothing is P1. Default new TODOs to P2 and force a justification for P1. Skill file: Pattern only — no skill in this version. Tell your agent to write one from this recipe (one variant per backend: todo-linear, todo-notion, todo-todoist, todo-md).

Tip 2.2 — Auto-add to TODO from meeting transcripts

What it does: Every action item extracted in Tip 1.2 also flows into the TODO list from Tip 2.1, with the meeting as the source and the assigned owner as the assignee. No copy-paste, no "let me add that to my list later." Why it wins: The gap between "we agreed in the meeting" and "it's on my list" is where 60%+ of action items die. Closing the gap to zero recovers all of them. Tools: Tip 1.2 (action item extraction) + Tip 2.1 (TODO system).

How to wire it: 1. After the post-meeting action items are extracted, the agent calls the todo skill to create one TODO per item. 2. Source field on the created TODO links back to the meeting in your Meeting Log + the exact transcript quote that produced it. 3. Owner field maps from the action item's assigned owner (already resolved in Tip 1.2) to the corresponding user in the TODO tool. 4. If the owner isn't a user in the TODO tool (e.g., external client), default to you with a note that this is on behalf of [external name]. 5. Dedupe — if the same action item appears across two meetings, link to the new meeting in the existing TODO rather than creating a duplicate. Example prompt to your agent: Extend the meeting-ingest skill: after action items are extracted and posted to Slack/Teams (Tip 1.2), also create a Linear issue for each action item using the todo skill. Set source = "meeting [meeting title]". Set owner = the resolved owner from the extraction (use team-roster.json to map names to Linear user IDs). Set priority based on language cues — "ASAP" or "urgent" or "today" → P1, default → P2. Include the 2-line transcript quote in the issue description. Before creating, dedupe against open issues with the same owner + similar title (cosine similarity > 0.85 on title). If a dupe is found, comment on the existing issue with "also discussed in [meeting]" instead of creating a new one. Watch out for: Action items extracted by the AI summary in Fathom (or any recorder) drift from the literal transcript. Use the transcript as the source of truth, not the summary, when extracting for TODO purposes. Hallucinated action items are worse than missed ones — you'll go do something nobody asked for. Force a quote. Closing the loop: when a Linear issue is closed, the agent should append a comment to the source meeting note that the action item is done. Bi-directional traceability matters when you audit. Skill file: Extends the meeting-ingest pattern (Tip 1.1) and the todo-system pattern (Tip 2.1). Pattern only — no skill in this version. Tell your agent to write one from this recipe.

Tip 2.3 — Auto-check-off when something's done (the killer move)

What it does: The agent closes TODOs automatically when it sees evidence the thing is done. Evidence comes from three sources: (1) you telling it, (2) a meeting transcript mentioning completion, (3) a Slack/Teams/email message indicating it's done. Why it wins: This is the difference between a TODO list that decays and one that stays clean. Manual check-off has roughly a 60% follow-through rate in most teams. Agent-driven auto-check-off pushes that to 95%+. Tools: All of section 1 (transcripts), Slack API search, Microsoft Graph (Teams message search), Gmail API. Your TODO tool. How to wire it: 1. Three triggers, three channels: - Direct: You say "the X thing is done" → agent closes any matching open TODO. - Meeting transcript: When ingesting a meeting, look for completion language tied to existing TODO titles. "Yeah, we shipped that yesterday" → close. - Slack/Teams message: On a cron (every 30-60 minutes), the agent scans messages from team members for completion language. "Just merged the PR" → if there's an open TODO about that PR, close. 1. Matching: don't rely on exact title match. Embed each open TODO and embed each candidate completion mention, match by cosine similarity above a threshold (0.75+ as a starting point). The agent should propose the close + show the matched evidence, not silently close, until you've validated 20-30 closes and bumped the auto-threshold up. 2. Log every close with: timestamp, source (direct/meeting/slack-msg), evidence quote, similarity score. 3. False-close protection: if the agent closes a TODO and you tell it "no, that's not done," it learns from the negative example and re-opens. Log it for future calibration. Example prompt to your agent: Build a todo-auto-close skill. Three trigger paths: 1. When I say something like "X is done" / "shipped X" / "closed the Y deal," look at my open TODOs, find the best match by semantic similarity (use OpenAI text-embedding-3-small), and close it if similarity > 0.75. Show me what you closed and the evidence. 2. When meeting-ingest processes a new meeting, after the action-items pass, run a completion-check pass: search the transcript for completion language tied to any open TODOs across the org. Same matching threshold. 3. Every 30 minutes, scan messages from the last 30 minutes across the channels in tracked-channels.json (Slack + Teams). For each message that contains completion language ("done," "shipped," "merged," "sent," "closed"), find the best-matching open TODO and propose a close. For the first 50

proposed closes, ask me to confirm. Once 50 in a row are correct, switch to auto-close with a daily summary. Watch out for: People use "done" loosely. "I'm done with that meeting." Filter by message intent before matching. Don't close TODOs that have sub-tasks still open. The TODO is only done when every child is done. The bidirectional bug: if a TODO gets closed by the agent, but the owner later realizes the work wasn't quite finished, they need a way to re-open easily. One-tap "re-open" command in the chat. Embedding spend: cheap but not free. Cache the embeddings of open TODOs; only reembed when a TODO is updated. Skill file: Pattern only — no skill in this version. Tell your agent to write one from this recipe.

Tip 2.4 — Cron the daily TODO digest (morning brief + EOD recap)

What it does: Two scheduled digests a day. Morning: what's on your plate today, what's stale, what just appeared. Evening: what got closed today, what's still open from this morning, what's at risk of slipping. Why it wins: A TODO list you check once a day at the start and once at the end is a TODO list you actually use. Both digests come to your phone — chat first, email backup — and take 30 seconds to read. Tools: Tips 2.1, 2.2, 2.3 plus your chat (Telegram, Slack DM, WhatsApp). How to wire it: 1. Define the cadence. 7am local for morning brief. 6pm local for EOD recap. 2. Morning brief contents: - Top 3 by priority that aren't done. - Anything created since yesterday's EOD. - Anything aging — open > 7 days without movement. - Any TODOs assigned to others that are now blocking you. 1. EOD recap contents: - Closed today (with completion source — direct/meeting/auto). - Still open from this morning's brief. - At-risk (open > 14 days, P1 still untouched, blocking someone else).

• One-line "what got added today." 1. Format for scannability: title, priority badge, age, source. 30 seconds to read or it won't get read. 2. End every digest with a single "one thing I'd prioritize next" suggestion from the agent. Optional — but it's the moment where the agent earns the most goodwill. Example prompt to your agent: Build a todo-digest skill. Cron every weekday at 7:00am and 6:00pm Bangkok time. Morning brief: "Top 3 priorities today" (P1s first, then P2s in order of age), "New since yesterday EOD" (1-3 lines per), "Aging" (anything open > 7 days, capped at 5), "Blocked on me" (anything assigned to others that's blocking me, with whose action is needed). EOD recap: "Closed today" (with completion source), "Carried over" (still open from this morning), "At risk" (P1 untouched, or open > 14 days, or blocking another team member), "Added today" (count + top 3). End every digest with "If you only do one thing next: [suggestion + rationale]." Send to Telegram. Watch out for: The brief turns into a wall of text the moment you have 30 open TODOs. Cap each section at 5. Force prioritization. Don't ping during the workday. The whole point is two bookends. Resist the urge to add a midday check-in — it becomes noise. Time zone alignment: digest fires in your local time, not server time. Bake the offset in. Skill file: Pattern only — no skill in this version. Tell your agent to write one from this recipe.

3. Cross-Channel Status Awareness

The thesis: every message that needs your attention is sitting in a different inbox. Slack DMs, Teams chats, Gmail, WhatsApp, sometimes a CRM thread. You're context-switching all day to find them. The agent doesn't context-switch. It reads everything every few minutes and gives you the one list you actually need.

Tip 3.1 — Cross-channel "you have unread/replies needed" sweep

What it does: Every 30-60 minutes (or on-demand when you ask "what do I need to reply to?"), the agent scans every channel — Slack DMs + channels you're tagged in, Teams chats, Gmail unread, WhatsApp threads — and returns a ranked list of things that actually need your reply (not just unread). Why it wins: Most "smart inbox" features inside individual tools (Slack's "Catch up," Gmail's priority inbox) are narrow and shallow. A cross-channel sweep with a real ranking

step beats them all because it sees the whole picture. Tools: Slack: Web API + users.conversations + conversations.history + users.info . OAuth as you (the user), not as a bot. Microsoft Teams: Microsoft Graph API — /me/chats , /me/teams/{id}/channels/{id}/messages . Requires a registered app and delegated permissions. Gmail: Gmail API — users.messages.list with q=is:unread . WhatsApp: If you're using the local SQLite path (your setup) — the whatsapp skill reads it directly. Otherwise, WhatsApp Business API. How to wire it:

1. Auth: OAuth each channel against your user account. Token storage in your secrets manager. Re-auth flow for token expiry should be one command.
2. Build a unified-inbox skill that fetches new/unread messages from each channel since last sweep. Save a high-water mark per channel.
3. For each message, classify:

• Direct ask of you? (question, request, decision needed)
• Mentioned by name/tag?
• Ongoing thread you're a participant in?
• Just FYI / channel noise?

4. Score by urgency: explicit deadline > question awaiting answer > tag in a thread > FYI.
5. Return a single ranked list with the channel, sender, 1-line message gist, urgency score, and a "draft reply" button (which calls your reply-drafter using your per-channel voice skills from the Marketing section).
6. Cron + on-demand. Run on cron for proactive pings; respond on-demand when you ask in chat. Example prompt to your agent: Build a unified-inbox skill. Channels to scan: Slack (workspace XYZ), Microsoft Teams (org ABC), Gmail (primary), WhatsApp (local DB). For each channel, fetch new messages since the last sweep timestamp. For each message, classify (direct-ask / tagged / participant / fyi) and score for urgency (1-5). Return a ranked list. Cron every hour during work hours (9am-7pm Bangkok). On-demand when I ask "what's on my plate" or "what do I need to reply to." For anything scoring 4+, ping me on Telegram with a one-line summary, channel/sender, and a "draft reply?" button. Use my perchannel voice skill if I say yes.

Watch out for: OAuth tokens for Microsoft Graph expire every hour. Refresh-token handling has to be bulletproof or the sweep silently dies. Slack "tagged in" doesn't always mean you should reply — sometimes you're tagged just for visibility. The classifier needs context, not just regex on <@you> . Gmail threading: don't surface every unread email separately when they're all in one long thread. Collapse to one entry per thread. Privacy / scope: the agent reads everything. Make sure the OAuth scopes are the minimum you need, and audit them quarterly. Skill file: Composite — builds on slack-formatting + google-workspace + whatsapp. Pattern only — no standalone skill in this version. Tell your agent to wire one from these.

Tip 3.2 — "Who's blocked on what" sweep (team-wide)

What it does: Same scan as 3.1, but instead of looking for your replies-needed, the agent looks across every channel for anyone on your team waiting on someone else. Output: "Andy is waiting on Maria for the API key (asked 3 days ago)." Then either nudge Maria or surface to you. Why it wins: Blockers are silent killers. A team member asks for something, doesn't get a reply, doesn't want to nag — and the work stops for days. A weekly (or daily) blocker sweep finds these and either nudges or escalates. Tools: Same as Tip 3.1, plus your team roster from Tip 1.2. How to wire it: 1. The agent scans every team channel + every shared DM thread. 2. Pattern-match for unanswered requests: a question or ask, then no reply (or only an FYI reply that doesn't address it) for > 24 hours. 3. Owner detection: who was asked. Use @-mentions where explicit, otherwise infer from message context. 4. Cluster by waiter — the person blocked. Output: "Andy is blocked on 3 things — 1 with Maria (3d), 1 with you (1d), 1 with a vendor (2d)." 5. Two actions per blocker: - Auto-nudge: agent drafts a friendly reminder in the blocker's voice and sends (with approval gate at first). - Escalate: surface to you with a recommendation. Example prompt to your agent:

Build a blocker-sweep skill. Daily at 9am Bangkok. Scan every channel in trackedchannels.json for the last 5 days. Find every unanswered direct question or request — defined as: an @-mention or direct ask, no reply that addresses the ask, > 24 hours old. Cluster by the person who is waiting. Output a digest: "Waiters → blockers." For each blocker > 48h old, draft a friendly nudge in the waiter's voice (use their voice skill if one exists, otherwise neutral). For blockers > 5 days old that involve me as the waiter, escalate with a "want me to call this out?" Send the digest to Telegram. Watch out for: Don't auto-nudge external people without approval. Internal nudges are usually fine; external = always human-in-the-loop. Sometimes "no reply" means "I'll do it, just didn't respond." Don't escalate every unanswered Slack DM at hour 25. Tune the threshold per channel — work email is slower than Slack. Day-of-week effects: don't count weekends. A Friday-afternoon ask isn't "blocked" by Monday morning. Skill file: Pattern only — no skill in this version. Tell your agent to write one from this recipe.

Tip 3.3 — Escalation rules (the agent decides when to ping you vs handle itself)

What it does: A configurable rules skill that decides, for each incoming message or detected event, whether the agent (a) handles it silently, (b) handles it and tells you, (c) drafts and waits for approval, or (d) escalates immediately and stops everything else. Most operators run their agent in mode (b) for everything by default — too noisy. Real escalation rules cut the noise by 80%. Why it wins: The most common failure mode of agent setups is overwhelming notifications. The fix is to make escalation explicit policy the agent enforces, not "feel free to ping me whenever." Tools: A config file. That's it. The rules engine is in the prompt. How to wire it: 1. Define four tiers in escalation-policy.md : - Tier 0 — silent: routine actions (closing a TODO it confirmed, posting an action-item digest the team has already seen, etc.). Logged, not pinged. - Tier 1 — daily digest only: anything that can wait until the morning brief. Most TODOrelated events. Most CRM updates. RSS-driven content drafts.

• Tier 2 — async ping: Telegram message, you reply when you can. Most cross-channel notifications. Sales follow-up drafts ready for review. - Tier 3 — interrupt: real-time chat ping with sound. New booking from a high-priority lead. A blocker on a P1 deal. A negative review. A meeting starting in 5 minutes you haven't prepped for. 1. For every action the agent considers taking that touches you, it consults the policy and routes. 2. Policy lives in version control. Iterate it weekly for the first month — every time you say "you didn't need to ping me about that" or "why didn't you tell me?", update the policy and commit. 3. The agent reads the policy at the start of every session and treats it as immutable for that session. Example prompt to your agent: Read escalation-policy.md at the start of every session. From now on, before any user-facing action (ping, digest, message), classify the event against the policy and route accordingly. Log every escalation decision to escalation-log.jsonl with: timestamp, event, tier classified, rationale. Weekly on Fridays, send me a summary of the week's escalations broken down by tier. If you're unsure of the tier, default to tier 1 (digest) and ask me to clarify in the next session — never default upward to interrupt. Watch out for: The first version of the policy will be wrong. That's fine. The point is you have something to iterate. Agents drift back to over-pinging without reinforcement. Run the weekly review religiously for the first 6 weeks. Don't let the agent self-modify the policy. Humans only. Skill file: Pattern only — no skill in this version. Pure config, no integrations. Tell your agent to write one from this recipe.

4. Recurring Ops Loops (the unglamorous wins)

This is the long tail. Most of the time/money saved in ops comes from a handful of weekly or monthly loops that nobody loves running but everybody needs. The agent runs them on cron, drops the output in your inbox, and you spend 10 minutes a week instead of 4 hours.

Tip 4.1 — Weekly team-update digest (cross-source synthesis)

What it does: Every Friday afternoon, the agent compiles a single team update by reading: meeting transcripts from the week, Slack and Teams highlights, GitHub PRs merged, CRM activity (deals moved, calls booked), and any major decisions from the decision log (Tip 1.3). Output: a 1-page weekly that goes to the team, investors, or wherever it needs to go. Why it wins: Weekly updates are a time sink that always slip. Letting the agent draft 90% of it means you spend 10 minutes editing instead of 90 minutes writing. Tools: Tips 1.1, 1.3, 3.1, plus GitHub API ( /repos/{owner}/{repo}/pulls?state=closed ), your CRM API (Attio is a clean one — see _skills-anonymized/attio-crm/ ). How to wire it: 1. Define sections of the weekly: Shipped, Decided, Closed (deals), Pipeline movement, Blockers, Next week's focus. 2. The agent pulls each section's data from the relevant source for the rolling 7 days. 3. Drafts a coherent 1-page document in your team's voice (use a team-update-voice skill trained on your past updates). 4. Drops it in your draft folder Friday at 2pm. You edit, send Friday EOD. 5. Cross-link everything: every decision links to its source meeting; every PR links to GitHub; every deal links to your CRM. Example prompt to your agent: Build a weekly-team-update skill. Cron every Friday at 2pm Bangkok. Pull data for the last 7 days from: meetings (decisions + key action items), GitHub (PRs merged across our repos in tracked-repos.json ), CRM (deals moved or closed in Attio), Slack/Teams highlights (anything tagged #wins or #weekly ). Draft a 1-page weekly with sections: Shipped / Decided / Closed (deals) / Pipeline / Blockers / Next week's focus. Use my team-update-voice skill for tone. Save to /weekly-updates/YYYYweek-NN.md . Tell me on Telegram with a link. I'll edit and send. Watch out for: Drafts will skew toward what's loudest in Slack, not what actually matters. Force the agent to weight decisions and closed deals higher than message volume. Don't auto-send. The weekly is high-trust output; humans approve. Linkrot: archive a copy of every linked source in case the source moves. Skill file: Composite — extends Tips 1.3 and 3.1, plus attio-crm. Pattern only — no standalone skill in this version. Tell your agent to wire one from these.

Tip 4.2 — Vendor / contract / renewal tracker

What it does: A skill that maintains a list of every vendor you pay, every contract end-date, every auto-renewal, and every price escalator. The agent reminds you 30 / 14 / 7 days before any renewal — with a one-line "should we renegotiate?" recommendation pulled from how much you've actually used the tool. Why it wins: SaaS bloat is real. Most operators are paying for tools they don't use, on contracts they don't remember, that renew automatically. A simple renewal tracker that flags 30 days out has paid for itself within the first quarter for every team that's actually run it. Tools: A spreadsheet or markdown file ( vendors.md ), plus optionally your bank feed (SimpleFin or similar) to catch new charges automatically. How to wire it: 1. Seed vendors.md with everything you currently pay. Name, monthly cost, annual cost, contract start, contract end (or "month-to-month"), auto-renewal Y/N, primary user, business purpose. 2. Optional but huge: connect SimpleFin Bridge ($1.50/mo) so the agent sees every recurring charge that hits your bank and can flag anything missing from vendors.md . 3. Daily cron: check for renewals within 30 days. Send a single weekly summary on Mondays with what's coming up. 4. For each upcoming renewal, the agent generates a "renegotiation prep" doc: how long you've been paying, total paid to date, your usage data (if available — pull from the tool's API), and a draft negotiation script. 5. Quarterly: a full audit. "Here are tools you haven't used in 90 days. Cancel?" Example prompt to your agent: Build a vendor-tracker skill. Source of truth is vendors.md . Schema per vendor: name, monthly_cost, annual_cost, contract_start, contract_end (or "month-to-month"), auto_renew, primary_user, purpose, last_used (if you can detect). Every Monday at 9am, send a digest: renewals in the next 30 days, renewals in the next 60 days, anomalies (new charges from bank feed that aren't in vendors.md , vendors not used in 90+ days). For each upcoming renewal, generate /vendors/renewalprep/.md with total paid to date, usage data, and a renegotiation script. Use my SimpleFin Bridge connection (creds in env) to cross-check. Watch out for: Auto-renewal dates are notoriously hard to find. Have the agent flag any vendor missing a contract_end so you can dig out the email. Some tools (Notion, Linear) are worth keeping even at low usage. Don't auto-cancel — recommend, you decide.

Bank feed will pick up personal charges if it's a personal card. Filter by account. Skill file: Pattern only — no skill in this version. Tell your agent to write one from this recipe.

Tip 4.3 — Internal SOP keeper

What it does: The agent watches your meetings + Slack for new processes you describe to teammates ("here's how we onboard new clients...", "the way we run our weekly..."). Whenever it hears a process described in enough detail, it drafts a SOP document, asks you to bless it, and files it in your docs system. Why it wins: Most teams have all their SOPs in someone's head. Onboarding new people then becomes a tax. Letting the agent capture the SOP the moment it's described — without anyone having to "stop and write it down" — closes the gap for free. Tools: Meeting transcripts (Tip 1.1), Slack/Teams scans, your docs system (Notion, Google Drive, or a sop/ folder). How to wire it: 1. After every meeting transcript is processed, run an sop-detection pass. Prompt: "Is there a multi-step process described in this transcript that didn't already exist as a written SOP? If yes, extract it." 2. Same for Slack/Teams — when you explain a process in a message thread, the agent flags it as a candidate SOP. 3. For each candidate, the agent drafts a SOP doc with: title, when this applies, steps, common pitfalls, who owns it. Format consistently — make a sop-template.md . 4. Drop drafts in /sops/drafts/ . Notify you weekly. You read, edit, approve. On approval, file in the docs system. 5. The agent also flags changes to existing SOPs when it hears a process described differently than the doc says. Surface the diff. Example prompt to your agent: Build an sop-keeper skill. After each new meeting in meeting-ingest , run sopdetection : scan the transcript for any multi-step process that's not already documented. Same on Slack/Teams threads from the last 7 days (weekly cron Sunday 6pm). For each detected SOP candidate: check against existing SOPs (in /sops/ ); if new, draft a SOP using sop-template.md ; if a change to an existing one, generate a diff. File drafts in /sops/drafts/ . Notify me Monday morning with: new candidates and proposed diffs. I approve in chat, you file in Notion. Watch out for:

Over-eager SOP detection. Not every "first I do X, then Y" deserves a doc. Force a 3step minimum and a reusability check. SOPs go stale. Re-run the detection on existing SOPs quarterly to catch drift between doc and reality. For sensitive processes (security, compliance), require explicit approval before the SOP is filed even in your private system. Skill file: Pattern only — no skill in this version. Tell your agent to write one from this recipe.

Tip 4.4 — Hiring + interview ops loop

What it does: When you have an open role, the agent owns the pipeline mechanics: scrapes applications from your ATS (or a shared inbox), screens against role rubric, schedules interviews against your calendar, drafts post-interview debrief notes from the recorded call, and maintains a running candidate scorecard. You spend time on the 3 candidates that matter, not the 50 that don't. Why it wins: Hiring is a part-time job superimposed on your full-time job. The repeatable parts — scheduling, screening, debriefing — are 80% of the time spent and 20% of the value. Hand them all to the agent. Tools: ATS API if you have one (Ashby, Lever, Greenhouse); a Gmail label + sheet if you don't. Calendar API (Google or Microsoft). Your meeting recorder (Tip 1.1). A role rubric markdown file. How to wire it: 1. Define the role rubric: must-haves, nice-to-haves, deal-breakers, scoring weights. One markdown file per role. 2. Daily pull from ATS / shared inbox of new applications. Agent reads each one, scores against the rubric, and ranks. 3. For top decile: agent drafts an outreach email in your voice and queues it. You approve, send. 4. Reply received → agent proposes interview slots via Calendly link or direct calendar API. 5. Interview happens → recorder pipeline (Tip 1.1) → agent generates a post-interview debrief: candidate strengths, gaps, scorecard, recommended next step. 6. Running pipeline view: all candidates, where they are, agent's recommendation, your decision. Example prompt to your agent: Build a hiring-pipeline skill. Per-role config: /hiring//rubric.md . Sources: pull applications from Ashby API daily (creds in env). For each new candidate,

score against the rubric and write /hiring//candidates/.md with: summary, score, evidence per rubric criterion, recommended action. For top 10% scoring candidates, draft an outreach email using my email-voice skill and queue in /hiring//drafts/ . After each scheduled interview is recorded by Fathom, generate a debrief in /hiring//candidates/interview-N.md with strengths, gaps, score update, recommended next step. Maintain a pipeline.md overview I can scan once a day. Watch out for: Bias in scoring: LLM rubrics can pick up patterns you don't want them to (school prestige, name patterns). Audit the scoring monthly for fairness, and force the rubric to weight on demonstrated skill, not credentials. Calendar fatigue: don't schedule more than 3 interviews a day from agent-driven outreach. Set the hard cap. Candidate experience: every email the agent drafts goes through you. A bad auto-sent email kills your hiring brand fast. Skill file: Pattern only — no skill in this version. Tell your agent to write one from this recipe.

Tip 4.5 — Finance / spend visibility (the "agent as CFO" play)

What it does: Read-only bank + card feed via SimpleFin Bridge ($1.50/mo for up to 25 institutions). Agent pulls transactions weekly, categorizes, flags anomalies, audits recurring charges against vendors.md (Tip 4.2), and builds a plain-English monthly P&L. Forecasts cash position 1-3 months out. Why it wins: your own setup — he wrote about it: "I just wired my agent up to my actual bank data and it's already paid for itself ten times over." First-line CFO work for the cost of a bad latte. Tools: SimpleFin Bridge ( beta-bridge.simplefin.org , $1.50/mo or $15/yr), your agent, optionally a Google Sheet or Notion database for the running P&L. How to wire it: 1. Sign up at SimpleFin and connect every institution (banks, cards, etc.) — bank logins are one of the few things that genuinely need you, not the agent. 2. Tell your agent: "I just connected SimpleFin — pull the setup token, store it safely, and verify you can read transactions." 3. Weekly cron: agent pulls the last 7 days of transactions, categorizes (business / personal, revenue / opex / cogs / one-time), and appends to your running ledger.

4. Anomaly detection: any new recurring charge not in vendors.md . Any single charge > 2x your weekly median spend. Any vendor double-billing. Any duplicate subscription. 5. Monthly: agent builds a plain-English P&L. Revenue, breakdown of expenses by category, net, runway at current burn. 6. Quarterly: forecast. "At current burn rate and assuming Y% revenue growth, you have N months of runway." Example prompt to your agent: Build a cfo-loop skill. Use my SimpleFin Bridge setup token (in env as SIMPLEFIN_TOKEN). Weekly cron Sunday 6pm: pull last 7 days of transactions from all connected institutions, categorize each (business/personal, revenue/opex/cogs/onetime, vendor mapping if recurring), append to /finance/ledger.csv . Run anomaly detection: new recurring charges not in vendors.md (cross-reference Tip 4.2), single charges > 2x weekly median, double-bills, duplicate subscriptions. Telegram me anomalies immediately. Monthly on the 1st at 9am: build /finance/pnl/YYYY-MM.md — revenue, opex by category, cogs, net, runway. Quarterly forecast. Watch out for: Categorization needs human review for the first 4-6 weeks. The agent learns from corrections. After ~50 corrected transactions, accuracy stabilizes. This isn't tax prep and isn't a replacement for an accountant. It's first-line visibility. US/Canada banks have best SimpleFin coverage. Outside North America, check before you wire it up. Bank feed downtime is a thing — surface "feed stale" alerts when no new transactions have appeared in 5+ days. Skill file: Pattern only — no skill in this version. Tell your agent to write one from this recipe.

Tip 4.6 — Client-pulse loop (for agencies and service businesses)

What it does: For every active client, the agent runs a weekly health check: when did we last touch them, what was the last sentiment in our communication, are we on track against their stated outcomes, is anyone on the team mentioning risk in internal channels. Output: a "client health" dashboard with red/yellow/green per account. Why it wins: Churn doesn't happen at the renewal call — it happens 3 months before, in the quiet drift between status meetings. A weekly pulse loop catches the drift while it's still fixable. Tools: Your CRM (Attio), email + Slack channel history per client, meeting transcripts (Tip 1.1), a client-health.md doc.

How to wire it: 1. Per client, build a config: stated outcomes, current health, last-touch date, primary contact, internal owner. 2. Weekly cron: for each active client, compute: - Days since last touch (any channel) - Sentiment of last 3 communications (positive / neutral / negative) - Mentions of the client in our internal channels in the last 7 days (positive/neutral/negative) - Progress against stated outcomes (manual update from the internal owner, or pulled from project trackers if integrated) 1. Score each → red/yellow/green. 2. Yellow or red → flag for outreach. Agent drafts a check-in message in your voice. You review, send. 3. Monthly: client review meeting prep — the agent compiles a 1-pager per client for your internal review. Example prompt to your agent: Build a client-pulse skill. Read /clients/active.md for the list of active clients. Per client, weekly on Mondays at 9am: compute days_since_last_touch (across email + Slack + meetings), sentiment of last 3 communications (use LLM classifier), internal channel mentions in last 7 days, progress against stated outcomes (read from /clients//outcomes.md last-updated note). Score red/yellow/green per client. Output /clients/pulse/YYYY-MM-DD.md with a single-table dashboard. For yellow/red clients, draft a check-in message in my voice and stage in /clients//drafts/ . Monthly on the 1st, generate per-client 1-pagers for our internal review. Watch out for: Sentiment classification on professional communication is noisy. Calibrate by feeding it 20-30 manually-labeled examples per client. Internal mentions can swing red unfairly when one teammate is venting on a bad day. Smooth with a 7-day rolling window, not single mentions. Don't auto-send check-ins. Especially to clients. Always human-approved. Skill file: Builds on attio-crm. Pattern only — no standalone skill in this version. Tell your agent to write one from this recipe.

Tip 4.7 — Onboarding ops loop (for new hires or new clients)

What it does: First-time onboardings always re-invent the wheel. The agent owns a checklist per onboarding type (new hire, new client), runs the checklist on cron, escalates anything that's stuck, and produces a "day-N report" so you know exactly where the new person/client is. Why it wins: Onboarding drift is invisible until someone churns or quits. A checklist agent that tracks every step keeps it honest. Tools: A markdown checklist per onboarding type, your TODO system (Tip 2.1), your CRM (for client onboarding), HRIS (for new hires) if you have one. How to wire it: 1. Define onboarding playbooks: /onboarding/new-client.md , /onboarding/newhire.md . Each is a numbered checklist with: step, owner, due date (relative — "day 3"), evidence-of-completion criteria. 2. When a new onboarding starts (trigger: client signed via CRM, or new hire added to roster), agent instantiates a copy of the playbook at /onboarding/// . 3. Daily cron: agent checks each open onboarding, marks steps complete based on evidence (using same auto-check-off logic as Tip 2.3), flags overdue steps. 4. Weekly: agent generates a status report per onboarding — green/yellow/red, what's overdue, what's coming up. 5. Day-30 / day-60 / day-90 reviews are scheduled automatically and the agent preps the review doc. Example prompt to your agent: Build an onboarding-loop skill. Playbook templates in /onboarding/templates/ . On trigger (new Attio "client signed" event, or new entry in team-roster.json ), instantiate the playbook at /onboarding///checklist.md . Daily 8am: check each open onboarding, mark steps complete using auto-check-off logic (Tip 2.3), flag overdue. Weekly Mondays: status report per active onboarding (green/yellow/red, overdue list, upcoming). Day-30/60/90 reviews auto-scheduled in my calendar with prep docs auto-generated. Watch out for: Different clients/hires move at different speeds. Don't auto-flag overdue without checking against the playbook's flexibility. Some steps require external action (the client signs a contract, the hire submits paperwork). Don't ping them — escalate to you, you handle the human comms. Playbooks rot. Quarterly: ask the agent "based on the onboardings of the last quarter, what would you change about the playbook?" Iterate.

Skill file: Builds on client-onboarding. Pattern only — no standalone skill in this version. Tell your agent to extend that one from this recipe.

How it all stacks

The ops section, like the marketing section, builds on a shared substrate. If you wire the substrate once, every tip above pays off:

1. The transcript pipeline (Tip 1.1). Without it, sections 1, 2.2, 2.3, 4.1, 4.3, 4.6, and 4.7 all lose their best input. Install this first.
2. The TODO system (Tip 2.1). One place. The agent's source of truth for everything action-shaped.
3. The cross-channel scanner (Tip 3.1). Every other "loop" tip reads from the same channel APIs. Wire each channel once; reuse everywhere.
4. The escalation policy (Tip 3.3). Without it, the agent will drown you in notifications and you'll mute everything. Install it before you turn anything on.
5. The team roster + channel map. Two small config files ( team-roster.json , tracked-channels.json , meeting-channel-map.json ). Every section 1, 2, and 3 tip uses them. Five minutes to set up. Skipping them costs you the next year. The order to install:
6. Meeting recorder + transcript pipeline (Tip 1.1). Day one. Everything compounds on this.
7. TODO system (Tip 2.1). Day two.
8. Auto-add from meetings + auto-check-off (2.2, 2.3). Within the first week.
9. Daily digest (2.4). Same week — this is the moment the system starts paying you back daily.
10. Cross-channel inbox + escalation policy (3.1, 3.3) — week 2.
11. Decision log + action-item auto-post (1.2, 1.3) — week 3.
12. Vendor tracker + CFO loop (4.2, 4.5) — anytime, low-effort, high-ROI.
13. SOP keeper (4.3), weekly update (4.1), client pulse (4.6), blocker sweep (3.2), hiring loop (4.4), onboarding loop (4.7) — pick the 1-2 most painful for your business this quarter. Don't try to install them all at once. A real ops setup is not 15 separate systems. It's one agent reading a small number of welldefined sources and writing into a small number of well-defined surfaces. Get the substrate right, and the tips compound. Get it wrong, and you'll have 15 broken automations. Pick three. Get them rock-solid. Move on.

Customer Success