Tygart Media

Tag: AI Agents

  • AI for Insurance Agents: Free Claude Skills and Prompts

    AI for Insurance Agents: Free Claude Skills and Prompts

    Last refreshed: May 15, 2026

    Insurance agents spend a significant portion of their week on follow-ups, coverage explanations, and proposal writing — work that’s relationship-critical but time-intensive. Claude handles the communication layer so you can spend more time on conversations that actually close. Everything here is free.

    How to Use This Page

    Claude Skills go into Claude Project Instructions. Books for Bots are PDFs you upload to Claude Projects. Prompts work in any Claude conversation.

    Claude Skills for Insurance Agents

    Skill 1: Coverage Explanation Writer

    Translates insurance policy terms, coverage types, and exclusions into plain English clients can actually understand — before, during, and after the sale.

    Paste into Claude Project Instructions:

    You are an insurance education assistant for an independent insurance agency.

When I describe a coverage type, policy term, or exclusion, explain it in plain English:
1. One-sentence answer to "what is this?"
2. What it protects against (concrete example)
3. What it does NOT cover (common misconception)
4. Why it matters for this specific client's situation (I'll provide context)

Never give specific premium quotes or guarantee coverage outcomes — that requires a licensed review. Always flag: "Your agent can confirm exactly how this applies to your policy."

If I ask for a client-facing handout version, format as a simple two-column table: COVERED / NOT COVERED.

Ask me: coverage type, client situation, product line (auto/home/commercial/life).

    Skill 2: Follow-Up and Pipeline Email Writer

    Drafts the follow-up sequence after a quote, renewal conversation, or claim interaction — professional, persistent without being pushy.

    Paste into Claude Project Instructions:

    You are a sales and retention communication assistant for an insurance agency.

When I describe a pipeline situation, draft the appropriate follow-up:

QUOTE FOLLOW-UP (Day 1): Thank them for their time, summarize key coverage points, offer to answer questions. Under 100 words.

QUOTE FOLLOW-UP (Day 5): Light check-in. Add one relevant reason to move forward (coverage gap they mentioned, renewal deadline). Under 75 words.

QUOTE FOLLOW-UP (Day 10): Final touch. Keep the door open. No pressure. Under 60 words.

RENEWAL CHECK-IN: Review is coming up, here's what we found, do you want to talk through options?

POST-CLAIM CHECK-IN: How did the claims experience go, anything else we can help with?

Tone: helpful, never pushy. You're a trusted advisor, not a salesperson running a drip sequence.

Ask me: situation, client name, key context from prior conversation.

    Skill 3: Proposal Narrative Writer

    Adds the plain-English narrative layer to your proposal — the “why this coverage, why this amount, why now” that a spreadsheet of options can’t explain.

    Paste into Claude Project Instructions:

    You are a proposal writing assistant for an insurance agency.

When I describe a client and the coverage being proposed, write the narrative section of the proposal that:
- Opens with what we heard from the client (their situation and concerns)
- Explains why these specific coverages address those concerns
- Calls out any coverage gaps they currently have that this fills
- Notes one or two things they told us they wanted to protect most
- Closes with the recommended next step

This goes alongside the technical specs — I'll provide those separately. Your job is the human story that explains the recommendation.

Under 300 words. Avoid industry jargon. Write like you're explaining it to a smart friend.

Ask me: client type, what they told you, what you're proposing and why.

    Skill 4: Referral and Review Request Writer

    Drafts the asks that most agents put off because they feel awkward — referral requests, review asks, and re-engagement messages for dormant clients.

    Paste into Claude Project Instructions:

    You are a relationship marketing assistant for an insurance agent.

When I describe a client relationship and what I want to ask, write it so it doesn't feel like a form letter:

REFERRAL ASK: Brief, genuine, specific about who I help. Under 80 words. Reference something specific about working with this client.

GOOGLE REVIEW REQUEST: Ask once, make it easy, include the link placeholder [LINK]. Never incentivize. Under 60 words.

RE-ENGAGEMENT (dormant client): Acknowledge it's been a while, offer something useful (free review, market update), no pressure. Under 100 words.

ANNIVERSARY TOUCHPOINT: Mark the policy anniversary, offer a quick review, keep it warm. Under 75 words.

None of these should sound like they came from a CRM. They should sound like a real person who remembers this client.

Ask me: client name, relationship history, specific ask.

    Books for Bots

    Upload to a Claude Project. Claude reads them in every conversation.

    PDFs coming soon. Email will@tygartmedia.com to get on the list.

    Book 1: Agency Context Sheet — Your agency name, carriers you work with, lines of business, service area, and communication philosophy. Claude uses this to produce communications that match your agency’s actual positioning.

    Book 2: Coverage Comparison Reference — Your standard explanations of the coverage types you sell most often — in your words, not the carrier’s. Claude uses this so client explanations are consistent with how you actually talk about coverage.

    Book 3: Common Objection Reference — The objections you hear most often (“I’ll just go with the cheapest,” “I’ll check with my current agent,” “I need to think about it”) with your preferred responses. Claude uses this to help you prepare and draft follow-up communications.

    Ready-to-Use Prompts

    For explaining a claim denial: A client received a claim denial for [reason]. Write a plain-English explanation of why this happened and what their options are. Be honest and clear. Don’t minimize it. Under 150 words, and flag anything I should verify with the carrier before sending.

    For a commercial prospect: Write a prospecting email to a [business type] in [city] who has not yet worked with us. Lead with a specific risk they face that is commonly underinsured. No insurance jargon. Under 120 words with a clear call to action.

    For a life insurance conversation: Write talking points for a conversation with a client who said they “don’t really think about life insurance.” Not a sales pitch — a conversation starter that makes the topic feel relevant and personal, not morbid. 5-6 bullet points I can use naturally.

    For a renewal that’s going up: A client’s premium is renewing at [X]% higher. Write an email that gets ahead of it, explains briefly why rates have moved in the market, and offers to review their coverage to see if anything can be adjusted. Honest and proactive.

    Free. Custom builds at tygartmedia.com/systems/operating-layer/.

  • AI for Real Estate Agents: Free Claude Skills and Prompts

    AI for Real Estate Agents: Free Claude Skills and Prompts

    Last refreshed: May 15, 2026

    Real estate agents write constantly — listing descriptions, buyer emails, offer summaries, follow-up sequences, market updates. Most of it follows the same patterns and doesn’t need to take as long as it does. Claude handles the repetitive writing so you can focus on relationships and deals. Everything here is free.

    How to Use This Page

    Claude Skills are system prompts — paste into a Claude Project (Settings → Projects → New Project → Instructions). Books for Bots are PDFs you upload so Claude knows your market and style. Prompts work in any Claude conversation.

    Claude Skills for Real Estate Agents

    Skill 1: Listing Description Writer

    Writes compelling, accurate listing descriptions that lead with the home’s best feature — not the address. Works for MLS, Zillow, social posts, and email campaigns.

    Paste into Claude Project Instructions:

    You are a real estate listing copywriter.

When I describe a property, write a listing description that:
- Opens with the home's single most compelling feature (not "Welcome to..." or the address)
- Flows from curb appeal → interior highlights → kitchen/primary suite → outdoor/lot → location/neighborhood
- Uses active, specific language — "vaulted ceilings" not "nice ceilings"
- Ends with a lifestyle statement, not a sales pitch
- MLS version: 250 words. Social version: 100 words. Email version: 150 words.

Never make claims about schools, demographics, or neighborhood character — Fair Housing applies.
Never invent features I haven't mentioned.

Ask me: property type, key features, price point, target buyer profile, any unique story behind the home.

    Skill 2: Buyer and Seller Email Sequences

    Drafts the full communication sequence for buyers and sellers at every stage — from first contact through closing and beyond.

    Paste into Claude Project Instructions:

    You are a real estate communication assistant. Your job is to draft emails that move clients through the transaction and build the relationship.

When I tell you the stage and situation, write the appropriate email:

BUYER stages: initial response, post-showing follow-up, offer submission, under contract update, closing countdown, post-closing check-in

SELLER stages: listing presentation follow-up, price reduction conversation, showing feedback summary, offer received, under contract update, closing day message

Each email should:
- Reference the specific situation (not generic)
- Explain what just happened and what comes next
- End with one clear action or next step
- Sound like a real person who knows this client

Under 200 words unless the situation requires more. Ask me: stage, client name, key details.

    Skill 3: Market Update Writer

    Turns raw MLS stats into readable market updates for your sphere — monthly newsletters, social posts, and client-specific summaries.

    Paste into Claude Project Instructions:

    You are a real estate market analyst and writer. Your job is to translate MLS data into market updates a non-agent can understand and actually find useful.

When I give you numbers (days on market, list-to-sale ratio, inventory levels, median price), write:

MONTHLY NEWSLETTER SECTION: 150 words, plain English, answers "what does this mean for buyers/sellers right now?" — no jargon.

SOCIAL POST: 80 words max. One key takeaway + what it means for someone thinking about buying or selling.

CLIENT-SPECIFIC SUMMARY: When I describe a client's situation, explain the market in terms of what it means for them specifically.

Never editorialize beyond what the data supports. If the market is mixed, say so.

Ask me: data points, neighborhood or city, whether audience is buyers, sellers, or general.

    Skill 4: Sphere of Influence Touchpoint Writer

    Drafts the low-pressure, relationship-building touchpoints that keep you top of mind without feeling like spam — check-ins, home anniversaries, market alerts, and referral asks.

    Paste into Claude Project Instructions:

    You are a relationship marketing assistant for a real estate agent.

When I describe a touchpoint I want to send, write it so it sounds like a real person — not a CRM sequence.

CATEGORIES:
- HOME ANNIVERSARY: Acknowledge the date, ask how they love the home, no sales pitch
- MARKET ALERT: One relevant stat, one sentence on what it means for them, no CTA beyond "let me know if you have questions"
- REFERRAL ASK: Genuine, brief, not awkward. Under 80 words.
- CHECK-IN: For past clients or warm leads. Reference something specific we talked about.
- SEASONAL: Holiday or season-relevant, keeps connection warm without a pitch

Every message should feel like it could only come from an agent who actually knows this person. Nothing mass-market.

Ask me: contact name, relationship history, specific reason for reaching out.

    Books for Bots

    Upload to a Claude Project. Claude reads them automatically.

    PDFs coming soon. Email will@tygartmedia.com to get on the list.

    Book 1: Agent Context Sheet — Your name, brokerage, market areas, specialties (buyers/sellers/investors/relocation), and communication style. Claude uses this so every email sounds like you — not a template.

    Book 2: Market Area Reference — The neighborhoods and cities you cover, with key selling points, typical price ranges, and buyer profiles for each. Claude uses this to write accurate, specific content about your actual market.

    Book 3: Objection and Conversation Reference — The most common objections you hear from buyers and sellers at each stage, with your preferred responses. Claude uses this to help you prep for tough conversations and draft responses to difficult client emails.

    Ready-to-Use Prompts

    For expired listing outreach: Write a prospecting letter for an expired listing at [address]. The home was on the market for [days] and didn’t sell. Don’t criticize the previous agent. Focus on what we’d do differently and why now is still a good time to sell. Under 200 words.

    For a price reduction conversation: I need to have a price reduction conversation with a seller. Their home has been on market [X] days with [Y] showings and [Z] offers. Write a talking points outline I can use in the call, and a follow-up email summarizing what we agreed to. Professional but direct.

    For buyer education: Write a plain-English explanation of [contingency / earnest money / appraisal gap / inspection period] for a first-time buyer. They are nervous and not sure what they’re signing. Under 150 words. No jargon.

    For social proof: I just closed a deal where [brief story — multiple offers, difficult situation, good outcome for client]. Write a social post (Instagram + Facebook versions) that tells the story without disclosing client details. Focuses on the process and outcome, not self-promotion.

    Free. No pitch. Custom agent-specific builds available at tygartmedia.com/systems/operating-layer/.

  • Managed Agents Now Have Built-In Memory — What Builders Should Test Before OpenAI Ships Its Version

    Managed Agents Now Have Built-In Memory — What Builders Should Test Before OpenAI Ships Its Version

    Last refreshed: May 15, 2026

    Anthropic’s Managed Agents service entered public beta with built-in persistent memory on April 23, 2026. The feature allows agents to retain context, user preferences, and state information across sessions — a capability that has been among the most-requested additions to the platform since Managed Agents launched. The timing matters: this ships during a window where OpenAI’s flagship memory features remain incomplete in their own agent frameworks, giving Claude developers a meaningful head start on production deployments that depend on memory.

    What Built-In Memory Actually Does

    Without memory, every agent session starts from zero. The agent knows what you’ve told it in the current conversation and nothing else. This is workable for single-session tasks — “summarize this document,” “write this draft” — but it breaks down for anything that involves ongoing relationships, accumulated preferences, or multi-session workflows. A customer service agent that can’t remember a user’s previous issues, a research assistant that can’t build on yesterday’s work, a scheduling agent that doesn’t know your standing preferences — all of these require memory to deliver the experience their use cases promise.

    Anthropic’s implementation provides persistence at the agent level, meaning the memory travels with the agent across sessions rather than requiring the developer to implement their own memory layer through external databases or custom retrieval logic. For builders who have been working around this limitation manually, the built-in version should substantially reduce implementation complexity.

    Why the Timing Against OpenAI Matters

    OpenAI has memory features in ChatGPT — the consumer product — but the developer-facing memory story for agents is less complete. The gap between what’s available to end users and what’s available to developers building on the platform has been a consistent criticism of OpenAI’s agent framework. Anthropic shipping built-in agent memory in public beta now, before OpenAI has an equivalent production-ready solution for agent builders, is a genuine competitive window.

    Public beta is not GA — there will be limitations, rough edges, and potential breaking changes before the feature stabilizes. But for developers who want to test and start building production workflows around persistent memory, this is the moment to start. Early adoption of beta features in platform infrastructure tends to compound: the teams that build on memory-enabled agents now will have a significant head start on the ones that wait for GA.

    What to Test Today

    The highest-value test cases for built-in memory in the current beta are: (1) customer-facing agents that need to remember user identity and history across sessions, (2) research or content agents that build knowledge bases over time, and (3) workflow agents that manage recurring tasks and need to track state between runs. These are the use cases where the absence of memory was most painful before, and where the new capability will show the largest delta in usefulness.

    Pair the memory beta with the new “Building production agents with MCP” guide published on April 22 — Anthropic’s documentation for hardening MCP-based agents for production deployments. The combination of persistent memory and production-hardening guidance suggests the platform team is intentionally building toward a moment when Managed Agents are ready for high-stakes, customer-facing production deployments. Test now, build with confidence later.

    Note on the 1M Token Context Beta

    Separately, the 1 million token context beta ends today, April 30. Developers who have been building on extended context should check the release notes for migration guidance before the beta window closes. This is the kind of quiet sunset that catches teams off-guard — worth a direct check against your current deployments today.

    Source: Anthropic Platform Release Notes

  • The Trust Gap in Agent-Generated Output: Closing It Without Killing the Speed

    The Trust Gap in Agent-Generated Output: Closing It Without Killing the Speed

    The Trust Gap in Agent-Generated Output: Closing It Without Killing the Speed

    The 60-second version

    Speed without trust is theater. Agents that produce output you can’t ship aren’t saving time — they’re shifting time from doing to checking. The trust gap is real, and most operators handle it badly: either they review everything (which negates speed) or they trust everything (which propagates bad output until something breaks). The operator move is sampled review on a defined rubric with source attribution. Pick a percentage you can sustain. Make the rubric explicit. Demand the agent show its sources. That’s how trust scales.

    What the trust gap is made of

    Four components:
    1. Factual accuracy uncertainty. Did the agent invent facts?
    2. Voice mismatch. Does it sound like us or like ChatGPT?
    3. Context blindness. Did it miss something only a human would catch?
    4. Edge case fragility. Does it handle the 5% of cases that don’t fit the pattern?
    Different agents have different gaps. A weekly digest agent’s gap is mostly voice. A lead-scoring agent’s gap is mostly accuracy. Diagnose the specific gap before designing the trust mechanism.

    Three mechanisms that close the gap

    1. The explicit rubric. Tell the agent the criteria for “good enough.” A 5-dimension scoring rubric (factual, voice, usefulness, coherence, format) makes “good” measurable. Agents can self-score. Humans can verify the score in 30 seconds instead of re-reading the whole output.
    2. Sampled review. Don’t review everything. Review 10-20% randomly. Track what you find. If the failure rate is below threshold, the system is trustworthy at that volume.
    3. Source attribution. Demand the agent cite sources for every factual claim. Page references inside Notion. URLs for external. This converts “is this right?” from a research task into a click. A trust gap closed in 5 seconds is functionally no gap.

    The pattern that fails

    Many operators try to close the trust gap with longer prompts (“be more careful, double-check, don’t hallucinate”). This doesn’t work. The agent already thinks it’s being careful. Adding adjectives doesn’t change behavior. Structural changes — rubrics, sampling, attribution — work. Adjectival prompts don’t.

    How to operationalize this

    Three steps:
    1. Pick one agent. Not all of them. Start with the highest-volume one.
    2. Define its rubric and threshold. Five dimensions, 0-2 scoring, lock at 8.5/10 average.
    3. Set a 4-week observation window. Sample 20% of output, score it, log failures. At week 4, decide: tighten prompt, reduce sampling rate, or retire.
    Repeat for the next agent. Don’t try to do this for the whole fleet at once.

    The relationship to Editorial Surface Area

    Trust gaps shrink when editorial surface area widens. An agent reading from a clean substrate makes fewer mistakes. The trust gap and the substrate are the same problem from two angles. Fix one and the other improves.

    What to read next

    Editorial Surface Area, Gates Before Volume, ROI Math.

  • Second-Brain Architecture in the Age of Notion Agents

    Second-Brain Architecture in the Age of Notion Agents

    Second-Brain Architecture in the Age of Notion Agents

    The 60-second version

    The pre-AI second brain was a personal information system. The post-AI second brain is a personal information system that an agent can also navigate. The two are different. A pile of brilliant unstructured notes is great for human recall and useless for agent synthesis. The shift is structural: more databases, fewer floating pages; controlled tags instead of free-text; cross-links between related items; an explicit glossary. Most second brains need to be partially rebuilt to work as agent substrate.

    What changes with agents in the picture

    Pre-agent, the second brain optimization was retrieval-for-humans: how fast can I find the thing I’m looking for. Post-agent, it’s retrieval-for-agents: how reliably can the agent find and synthesize across the right things without human guidance.
    These are different optimizations. Humans use intuition, recent memory, and visual scanning. Agents use semantic search, structured queries, and link traversal. A second brain optimized for one isn’t optimized for the other.

    Five structural shifts

    1. Pages → Databases. Floating pages don’t query well. Databases with consistent properties do. If you have a “books I’ve read” pile of pages, convert it to a database with author, genre, key insight, related-projects properties.
    2. Free tags → Controlled vocabulary. Twenty variations of “client” produces an agent that misses things. One canonical “Client” tag with defined scope works.
    3. Standalone pages → Cross-linked graph. Notion’s link system is the agent’s navigation. A new page should link to at least 2-3 related existing pages. Pages with no inbound or outbound links are dead to the agent.
    4. Implicit conventions → Explicit glossary. A page that captures “this is what we call things and how we structure projects” gives the agent rules instead of guesses.
    5. Recent-memory archives → Continuously enriched archives. Old projects shouldn’t decay. AI Autofill can re-summarize, re-tag, and re-cross-link old pages so they stay queryable.

    The agent-aware folder structure

    A workable shape for an agent-friendly second brain:
    – Daily notes (database, dated, freeform — agent reads these for context)
    – Projects (database, named, with status, owner, timeline — agent works against these)
    – People (database, names, relationships, last interaction — agent uses for personalization)
    – Sources (database, URLs, key insights, related-projects — agent cites these)
    – Glossary (single page or small database — agent’s vocabulary anchor)
    – Decisions log (database, dated, with context — agent’s history)
    Six structures. That’s it. Most second-brain sprawl can be consolidated to this.

    What this enables

    Once the structure is in place, agents do things that feel like magic:
    – “What did we decide about X six months ago?” returns the actual decision plus the context.
    – “Summarize what I’ve learned about Y this year” produces a real synthesis.
    – “Draft a brief on Z” pulls from sources, projects, decisions, and prior work.
    None of this works without the substrate. All of it is trivial with it.

    What to read next

    Editorial Surface Area, Gates Before Volume, AI-Native Company Patterns.

  • Multi-Agent Orchestration in Notion: When One Agent Hands Off to Another

    Multi-Agent Orchestration in Notion: When One Agent Hands Off to Another

    Multi-Agent Orchestration in Notion: When One Agent Hands Off to Another

    The 60-second version

    Single mega-agents are tempting and bad. Specialized agents in a sequence with clear handoffs are harder to design but much more reliable. The principle: each agent does one thing well and hands a structured result to the next. Three handoffs is about the practical limit before debugging becomes painful. Beyond three, refactor.

    Three orchestration patterns that work

    1. The pipeline pattern.
    Agent A produces structured output → Agent B consumes and produces → Agent C consumes and produces final result. Each agent’s output schema matches the next agent’s input schema. Clear linear flow.
    2. The router pattern.
    A routing agent decides which specialist agent should handle the request, then dispatches. Specialists are scoped tightly to their domain. The router doesn’t do work itself; it just routes.
    3. The reviewer pattern.
    A producer agent generates output. A reviewer agent checks against criteria and either approves or returns specific feedback. Iterates until approved or max-attempts hit.

    Three patterns that fail

    1. Recursive agent chains. Agent A calls Agent B which calls Agent A again. Debugging is awful. Don’t.
    2. Shared mutable state. Two agents writing to the same database row simultaneously. Race conditions and overwrites. Don’t.
    3. Implicit handoffs. Agent A produces unstructured text; Agent B parses it. The first format change breaks everything. Use structured handoffs.

    Designing the handoff contract

    The handoff between agents is the highest-risk surface. Three rules:
    – Define the schema explicitly. The output of Agent A is JSON-schema-validated input to Agent B.
    – Version the schema. Schema changes are breaking changes. Version like APIs.
    – Test the handoff in isolation. Mock Agent A’s output; test Agent B’s handling. Mock Agent B’s expected input; test Agent A’s production.

    Where orchestration goes wrong in production

    1. Cost compounds with depth. Each agent call consumes credits. A three-handoff workflow costs roughly 3x a single-agent workflow. Budget accordingly.
    2. Latency compounds too. A 5-second agent x 3 handoffs is 15 seconds end-to-end.
    3. Failure modes multiply. Agent A succeeds, Agent B fails, what happens? Define the failure handling explicitly.

    What to read next

    Workers for Agents in TypeScript, Building Your First Skill, Error Handling in Notion AI Workflows, Custom Agents vs Basic.

  • Workers for Agents in TypeScript: Patterns That Hold Up in Production

    Workers for Agents in TypeScript: Patterns That Hold Up in Production

    Workers for Agents in TypeScript: Patterns That Hold Up in Production

    The 60-second version

    Workers reward a specific style of TypeScript: small, single-purpose, structured-input-and-output, well-typed. The constraints (30 seconds, 128MB, no state) push you toward this style automatically. Workers that hold up in production share patterns: typed input/output schemas, defensive HTTP calls with timeouts, structured error returns, no hidden side effects.

    Five production patterns

    1. Type your input and output.
    Type strictly. The agent works against the schema. Schema drift breaks the agent silently.
    2. Defensive HTTP with timeouts.
    External API calls inside a 30-second budget need their own timeouts. A 25-second API call leaves 5 seconds for everything else. Set explicit fetch timeouts shorter than the Worker timeout.
    3. Structured error returns instead of throws.
    Throw inside a Worker and the agent gets opaque failure. Return structured error objects and the agent can reason about the failure and respond gracefully.
    4. Idempotency where state matters.
    Workers have no persistent state, but they can hit external systems that do. If the external call is non-idempotent (e.g., creates a record), include an idempotency key derived from input. Calling the Worker twice should produce one record, not two.
    5. Approved domains as a deployment artifact.
    Track domain approvals in code. When a Worker stops working in production, “did the approved domains change” is the first thing to check.

    Three production failures to design around

    1. The 30-second wall. Aim for under 5 seconds typical, under 15 worst case. Long calls fail under retry loads.
    2. Silent domain blocks. A Worker calling a non-approved domain fails with an error that isn’t always obvious. Log every outbound destination.
    3. Memory leaks via large responses. Don’t pull a 50MB JSON response into a 128MB Worker. Stream, paginate, or pre-filter at the source.

    Testing strategy

    Unit-test the Worker logic separately from the agent. Use mock HTTP. Then integration-test with the actual agent calling the Worker. The two test layers catch different bugs.

    What to read next

    Workers + External APIs, Notion AI Meets MCP, Workers for Agents foundation piece, Security Posture.

  • Building Your First Notion Skill: A Step-By-Step Walkthrough

    Building Your First Notion Skill: A Step-By-Step Walkthrough

    Building Your First Notion Skill: A Step-By-Step Walkthrough

    The 60-second version

    Building a skill that works on the first try is rare. Building a skill that works after three iterations is normal. The discipline is starting with a narrow scope, writing specific instructions, testing against real inputs, and tightening based on what fails. Most operators build skills that are too broad and too vague. The fix is the opposite of intuition — narrower, more specific, more bounded.

    Step-by-step

    Step 1 — Pick the right first skill. Not the most ambitious one. The most repetitive one. “Weekly digest from project database” is a great first skill. “Generate our entire content strategy” is a terrible first skill.
    Step 2 — Write the instructions. Specific format. Specific sections. Specific length. Specific tone. “Summarize” produces variance; “Produce a one-page summary with these five sections in this order, max two sentences per section, in active voice” produces consistency.
    Step 3 — Bound the context. Which database does it read? Which pages? Which fields? Pin tightly. Expand only when needed.
    Step 4 — Test five times. Run the skill against five different real inputs. Look at outputs side by side. The variance you see is the variance you’ll get in production.
    Step 5 — Tighten based on failures. What was wrong in any output? Update the instructions to prevent that. Re-test. Loop.
    Step 6 — Document the skill. Note what it does, when to call it, and what its known failure modes are.

    Three patterns that fail

    1. The mega-skill. A skill that “drafts the weekly report including stakeholder updates and exec summary and content calendar.” Break it into three skills.
    2. The vague skill. “Help me write.” Define what kind of help, what kind of writing, in what format.
    3. The unbounded skill. No context boundaries. The agent reads everything and produces something that sounds related to nothing.

    Where this goes wrong

    1. Skipping the five-test step. Skills that work once fail differently. Test variance early.
    2. Treating skills as static. Skills need maintenance. When a database schema changes, the skill changes.
    3. Building too many skills too fast. Three great skills beat ten mediocre ones.

    What to read next

    How Notion Skills Work, Custom Agents vs Basic, Workers for Agents, Prompt Patterns That Work Inside Notion.

  • Notion AI Meets MCP: What Model Context Protocol Unlocks Inside the Workspace

    Notion AI Meets MCP: What Model Context Protocol Unlocks Inside the Workspace

    Notion AI Meets MCP: What Model Context Protocol Unlocks Inside the Workspace

    The 60-second version

    MCP is the universal connector for AI agents. Where Workers let you write custom code for Notion agents, MCP lets you point agents at existing tool servers built to a standard. The result: less custom development, more reuse. Notion’s n8n MCP bridge is the most visible example, but the same pattern works for any MCP-compatible service. For developers, this changes the cost equation — you don’t build everything bespoke.

    Why this matters

    Three reasons MCP is more than just another integration mechanism:
    1. Standard interfaces compound. Every MCP server you connect adds capability without custom code. A library of MCP servers becomes a library of agent capabilities.
    2. Tool reuse across AI platforms. MCP servers work with Notion AI, Claude, and other MCP-compatible AI systems. Build once, use across platforms.
    3. Easier ecosystem development. Third parties can ship MCP servers that any MCP-compatible AI can use. The ecosystem grows faster than proprietary integration ecosystems.

    What MCP is and isn’t

    Is: A protocol specification. A way for AI clients to discover and call tools. A standard that makes tool servers portable across AI systems.
    Isn’t: A specific tool. A replacement for native APIs. A guarantee of quality — MCP servers vary widely in implementation quality.

    Three patterns to start with

    1. Adopt n8n MCP first. It’s the highest-leverage MCP integration for most operators because n8n already has hundreds of integrations.
    2. Look for MCP servers for your existing tools. Many SaaS products are shipping MCP servers. Check before writing a Worker.
    3. Build MCP servers for your own internal tools. If you have an internal API multiple agents will use, an MCP server is more reusable than a Notion Worker.

    Where this goes wrong

    1. Treating MCP as magic. A bad MCP server is still bad. Validate the server’s behavior before relying on it in production.
    2. Connecting too many MCP servers. Each connected server is potential surface area for the agent to use unpredictably. Curate.
    3. Skipping the security review. MCP servers can read and act on data. Treat connection like any other security-sensitive integration.

    What to read next

    n8n MCP Bridge, Workers + External APIs, Security Posture, Workers for Agents foundation piece.

  • The n8n MCP Bridge: Letting Notion Agents Run Your Existing Automations

    The n8n MCP Bridge: Letting Notion Agents Run Your Existing Automations

    The n8n MCP Bridge: Letting Notion Agents Run Your Existing Automations

    The 60-second version

    n8n is where many ops teams already run their cross-app automations. Notion’s n8n MCP bridge lets Custom Agents call those automations as tools. The agent decides what to do; n8n executes the cross-app work. This combines two strengths: Notion AI’s natural-language understanding and database fluency, and n8n’s mature integration library and workflow tooling. You don’t have to rebuild your n8n setup inside Notion.

    What this enables

    Three patterns that get easier:
    1. Agent-triggered cross-app workflows. Agent reads a Notion page, decides an action is needed, calls the relevant n8n workflow which handles the actual work (Salesforce update, Stripe charge, file move, whatever).
    2. Existing n8n investment compounds. Every n8n workflow you’ve built becomes a tool the agent can use. The library grows as your agent-callable surface grows.
    3. Workflow logic stays in n8n. When the workflow logic changes, you change it in n8n once. All agents using that workflow inherit the change automatically.

    When to use n8n vs Workers

    Notion has Workers (developer preview) for custom code. n8n is for cross-app workflows. The split:
    – Workers when you need custom logic that doesn’t exist as an integration
    – n8n when you need to coordinate across many existing apps with mature connectors
    – Both for complex flows where Workers handle specific computation and n8n handles app coordination
    For most ops teams, n8n is the right starting point. Workers are an advanced layer.

    Where this goes wrong

    1. Treating the agent as a smarter n8n trigger. The agent’s value is judgment about when to run the workflow. If you can express the trigger as a simple condition, just run n8n directly.
    2. Letting agents call destructive workflows without confirmation. Agent + n8n + Salesforce delete = potential disaster. Add human approval steps for destructive operations.
    3. Not versioning n8n workflows that agents call. When you change a workflow, agents don’t know. Version your workflows so agent prompts can pin to specific versions.

    What to read next

    Workers for Agents, MCP foundation piece, Notion Agents vs n8n Alone, The Solo Operator’s Stack.