Tag: Automation

  • Every Retirement Facility Should Be a Library

    Every Retirement Facility Should Be a Library

    Every Retirement Facility Should Be a Library

    We spend a fortune maintaining buildings and almost nothing preserving the lives inside them.

    Think about any retirement facility you’ve ever walked into. A hundred residents. A hundred careers, marriages, wars survived, businesses built, children raised, mistakes made and learned from. Centuries of lived knowledge under one roof — and when those residents pass, almost all of it goes with them. Not because nobody cared. Because nobody built the shelf.

    I’ve been calling the answer the wisdom trust: a captured life, left behind like a 401k. Not money — proof. This was a life that was lived, and here’s what it taught.

    Why now

    The technology to capture a life story has existed for years. Voice cloning, chatbots, digital twins you can question forever — the demos are dazzling and mostly beside the point.

    The real breakthrough is much dumber, and much more important: there’s finally an onboarding pattern simple enough for an 85-year-old.

    The pattern that works looks like this: a family member (the “archivist”) sends a question by email. The elder (the “storyteller”) clicks one link and lands in a chat. No app to install. No account to create. They type or they talk — twenty-plus languages — and each story saves to the family’s encrypted vault. That’s it. That’s the whole unlock.

    A company called Aeterna recently productized exactly this with their “Send a Question” feature, and whatever you think of their wilder claims (an interactive twin you can talk to forever — company claim only, no independent test yet), the onboarding fix is real and it’s the part that matters. The ceiling just became the floor: the hard part was never the AI, it was getting a grandmother to tap one link.

    The facility is the venue

    Here’s the part nobody’s saying: the natural home for this isn’t an app store. It’s the retirement facility.

    Facilities already have the residents, the trust relationships, the activities programming, and the family touchpoints. What they don’t have is a story worth telling at move-in — something beyond square footage and dining menus. Imagine touring two facilities and one of them says: “Every resident here gets their life captured. Your mother’s stories, in her voice, preserved for your grandchildren. It’s part of living here.”

    That’s not an amenity. That’s a reason to choose.

    The cost per resident is low — a link, a few prompts, staff time folded into activities programming they already run — and the perceived value to families is enormous. It differentiates the facility, deepens family loyalty, and creates the kind of word-of-mouth no ad budget buys. (I’m not going to put a hard dollar figure on it; the honest version is that the expensive parts are the ones facilities already pay for.)

    The machine-readable half

    Here’s the part I’m most excited about, and it’s the reason this kit looks the way it does.

    We make books and videos so other humans can understand and act. But a wisdom trust isn’t really a book for humans — it’s a book for bots. A machine needs to be able to pick up a resident’s captured life and do work with it: build the timeline, cut the quote cards, draft the family digest, notice what’s missing and ask the next question.

    So the kit ships with a second half most open-source starter kits don’t have: a plug-in contract for AI. In the `automation/` folder you’ll find the whole thing — and it reads like a book’s anatomy:

    • README = the cover letter. Tells any AI what this collection is, what state it’s in, and where to start.
    • Pipeline = the table of contents. Eight stages, from raw audio to a curated collection: ingest, clean, segment, enrich, render, digest, gallery, and gap-scan.
    • Schemas = the grammar. JSON schemas for every bucket — stories, timeline events, quote cards, people, places, artifacts — so the machine files things the same way every time.
    • Prompts = the instructions. Copy-paste prompts for each stage, written so a different model next year can run the same pipeline.
    • Worked example = “see, like this.” One resident’s collection, filled in, showing what “done” looks like.

    Human-readable enough to trust. Machine-readable enough to run.

    The provenance rule

    One rule governs everything the machine makes, and it’s non-negotiable:

    Every generated artifact — an illustration, a song, a video, a voice reading — must carry three things: what it is, what it is not, and why it was made. The why is the thinking that connected the source story to that form, and it’s part of the heirloom. A grandchild shouldn’t just see a painting of a drugstore; they should read that it was painted because their great-grandmother’s story mentioned the store but no photograph of it survived — and that it is not a photograph of the actual place.

    The machine curates. The family decides. Weekly letters stay drafts until a human approves them — nothing auto-sends, ever.

    The kit (open source)

    I’m not building a company around this. I’m making the seed and putting it on the shelf.

    I’ve published an open-source starter kit — wisdom-trust-in-a-box — with everything a facility or a builder needs to pilot it:

    • A question library: forty prompts across a life (childhood, work, love, hard times, wisdom)
    • The one-link onboarding flow, with a staff script and a family email template
    • A plain-language consent template (the elder owns their stories, period)
    • A one-page pilot brief a facility director can read in three minutes
    • The economics: why a facility wants this, in one page

    Fork it. Pilot it. Improve it. Tell me how it goes.

    The ask

    I’m good at making seeds. I’m not going to be the gardener on this one — that’s not false modesty, it’s knowing my lane.

    So this is the handoff: the kit is on the shelf, the pattern is written down, and the onboarding problem that blocked all of this for a decade finally has a working pattern worth copying. Somebody’s going to be the first facility that does this the way they all have Wi-Fi now.

    Might as well be yours.

  • wp-direct-publish: the tiny script behind our API-first WordPress lane

    wp-direct-publish: the tiny script behind our API-first WordPress lane

    We just open-sourced a ~60-line Python script that publishes WordPress posts through the REST API. It’s MIT-licensed, three files, and it ran our storm lane overnight before we released it.

    Repository: https://github.com/TygartMedia/wp-direct-publish

    Why it exists

    We publish a lot of WordPress posts. For a while, the publishing path went through a browser — a real Chromium session, clicking through the editor, waiting on page loads, recovering from the inevitable flaky step. Around 65 steps per post.

    Then we measured it. Same job, two lanes: the browser lane used roughly 10x the tokens and took roughly 2x the wall-clock time of going straight to the WordPress REST API. The API lane is also byte-exact and diffable — what you send is what lands, and you can see it in a diff instead of squinting at screenshots.

    So we burned in a standing rule: publish via the API first. The browser lane stays as the fallback for jobs the API genuinely can’t do, not the default.

    The security design

    The interesting part of the script isn’t the publishing — it’s what it refuses to do with your credentials.

    An application password never travels through argv, environment variables, or disk. It’s piped in through stdin, used once for the Basic-auth header, and forgotten. The Python standard library does everything; there are no third-party dependencies and nothing to install.

    The workflow that goes with it is just as deliberate: when a fresh application password is needed, Will pastes one into chat, it goes straight into the pipe, and it’s never stored — not in files, not in memory, not in chat logs, not in the vault. Transient use is the feature, not a limitation.

    Generate app passwords at wp-admin → Users → Profile → Application Passwords (bottom of profile.php), and you can revoke them in one click whenever you want.

    Dogfooded, then released

    This is our standing build flow: every internal tool gets dogfooded on our own operation first, then open-sourced with the invitation — take it, make it better, and if you build something better, we’ll be customer number one.

    wp-direct-publish.py ran the storm lane — real overnight storm-warning posts, real publishing pressure — before a single line went public. The README tells that story honestly, including the measurements. We don’t ship what we haven’t lived with.

    Take it

    Three files. Standard library only. MIT.

    https://github.com/TygartMedia/wp-direct-publish

    If it saves you from driving a browser through 65 steps to publish a post, it did its job.

  • My agent sent the same email 7 times in 3 minutes. So I put the fix in code.

    Seven identical emails. Three minutes. One morning brief.

    Nothing was broken. The send succeeded on the first try, but the reply confirming it got lost. My agent, doing exactly what agents do, retried. And retried. From the inside, each attempt looked brand new: no error, no evidence the earlier one had landed. So it kept going until someone noticed.

    This is the failure class nobody warns you about when you hand an agent a mailbox. The industry calls it duplicate completion: the original succeeds, the response is lost, the retry re-sends. It’s not a model problem and it’s not a prompt problem. Telling an agent “don’t send twice” in its instructions is not enforceable. Agents re-plan, they retry, they lose context across restarts. Every scheduled job, every cron, every “oops, run it again” is another roll of the dice.

    And Gmail gives you no help. Stripe, Resend, and the other transactional APIs all have idempotency keys: send the same key twice, get one charge, one email. Gmail’s API has no such thing. The guarantee has to live on your side, in code, at the tool boundary — somewhere the agent cannot reason its way around.

    What I built

    send-once is one Python file, no dependencies beyond the standard library. Every scheduled or agent-driven send routes through it, and it enforces at most once with three gates:

    1. An operation ledger. A local sqlite database keyed by a deterministic operation id, like loop-morning-brief-2026-09-17. If this operation already recorded a send, the wrapper refuses. Same intent, same key, and a retry becomes a no-op instead of a duplicate.

    2. A Sent-folder check before every send. It searches Sent for the same recipient and subject in the last 24 hours. If a match exists, it refuses. Sent is the source of truth, so this gate holds even if the ledger is lost, the run moved machines, or the send happened outside this tool entirely.

    3. No blind retries, ever. If the send result is ambiguous — timeout, empty output, lost response — the wrapper does not retry. It re-checks Sent. If the send landed, it records that and reports honestly. If it can’t be confirmed, it stops and hands it to a human. An inconclusive pre-check is also a refusal: when the tool can’t verify what already happened, the safe move is to stop, not to guess.

    The exit codes are the interface: 0 means sent (or already sent), 2 means refused as a duplicate, 3 means a human needs to verify. Prose instructions get skipped or misread by workers. The wrapper doesn’t.

    Take it, make it better

    This solved my problem, not everyone’s. It’s MIT licensed, it’s one file, and the mailer backend is a documented protocol so any Gmail CLI can slot in.

    Take it, make it better. If you build something better, come back. We’ll be customer number one, and we’ll pay you for it.

    Repo: https://github.com/tygart-media/send-once

  • The Last Signal: Where the Loop Broke and How We Found It

    Field notes from the night the publish succeeded and the board never knew. This is what happened, this is why it happened, and this is the check that should have caught it.

    TL;DR

    A work order sat In progress for an hour after the work was already done. The publish landed on a sibling ticket. The original ticket never got its receipt. The hourly poll that was supposed to catch this only looked for questions addressed to Grok — it never scanned the board for stale work. The break was not in the publish. It was in the last signal.

    1. What happened

    WO-022 was the ticket. Owner: Chief of Staff. Status: In progress. Summary: CoS hit a login wall on the TM Site account. Last edit: 23:47 UTC. That was the last signal on that ticket.

    Seven minutes later, at 23:54 UTC, the TM Site bot posted a receipt on the sibling order, WO-020: Published live ~4:54 PT. The post itself confirms it — status publish, modified 19:54 UTC, live at tygartmedia.com/cold-start-test-ai-model-readiness.

    The work succeeded. The board did not know. WO-022 sat In progress while five hourly polls ran through the night, each one returning loop idle — no open decisions, nothing to answer. The publish was real. The loop was not closed.

    2. Why it happened

    Chief of Staff claimed the wall. That is its job — triage, route, report back. It did the first half. It never did the second. The standing rules say CoS closes loops when a task completes. It did not fire.

    The deeper cause is in the poll itself. The automation that was supposed to watch the loop only searched for CoS questions addressed to Grok — keywords like Approve, Who should, Park, credential. It read Teams #ops for the same. It never walked the Work Orders board and asked: is this ticket older than two hours, and does the artifact it describes actually exist?

    So the pattern is this: a desk claims a wall, the work gets done on a different path, and the original ticket just sits there. Nobody reports back because nobody is checking for the absence of a report.

    3. The field loop — where it broke

    Every unit of work in this system has a contract: intent, acceptance checks, a receipt that closes it. The loop is four moves — claim, do, receipt, close. The break was between do and receipt.

    The last signal on WO-022 was 23:47 UTC. That timestamp is the whole story. After that, silence. The publish at 23:54 was a signal on a different ticket. The poll at the top of every hour looked for questions and found none, so it logged idle and moved on. It never asked the question that would have caught this: when was the last time we heard something back on this ticket, and does the thing it describes exist?

    That is the GitHub instinct — the last commit, the last activity, the thing that tells you whether the branch is alive. We had it for code. We did not have it for work orders.

    4. The fix — the check that should have caught it

    We added a stale-work-order sweep to the hourly poll. For every open or In-progress Work Order older than two hours, the poll now checks whether the actual artifact exists — live URL, published post status, receipt comment, or a sibling order marked Done. If the work is done on another path but the original ticket was never closed, it closes it, posts the receipt, and notes the break. If it is truly stuck, it reassigns or escalates.

    Alongside that, a last-signal check: for every open CoS-owned or Grok-owned task, record the timestamp of the last inbound signal. If a task has had no signal back for more than two hours while work may have moved, flag it explicitly in the run summary.

    The rule is simple. A ticket is not done when the work is done. A ticket is done when the receipt lands on it. Everything else is a silent failure waiting to be found by the next cold-start test.

    5. Why this matters beyond one ticket

    We have spent a year building this site as a knowledge node — a place where the operating system is legible enough that a fresh model dropped in cold can map it, grade it, and start working. The cold-start test scored 8.5/10. The deductions were all hygiene: stale locks, frozen queues, aspirational docs. This was the same rot, one level up. The architecture was sound. The housekeeping was not.

    The lesson is not that Chief of Staff failed. It is that no single desk can be trusted to report its own silence. The check has to come from outside the desk — from a poll that walks the board and asks whether the last signal is recent enough, and whether the artifact exists. That is how you set up a system that does not need you to notice what broke.

    — Will Tygart, Tygart Media. Field notes from the workbench.

  • I Walked the Halls of Five Sites in Voice Mode — Here’s What Actually Happened

    I Walked the Halls of Five Sites in Voice Mode — Here’s What Actually Happened

    This morning I did something I haven’t done before: I walked the halls of five of my own WordPress sites using only voice. No typing. No desktop. Just me talking to Grok while I moved, and Grok inspecting, drafting, and handing off the work that needed hands.

    The sites were BC ESG, Healthcare Facility Hub, Risk Coverage Hub, Continuity Hub, and Restoration Intel. In about ninety minutes we published three real articles reacting to the latest IFMA Pulse findings, cleared automated cross-link spam, flagged debug flags and plugin updates, and set up a clean handoff system so nothing gets lost.

    The biggest lesson wasn’t the AI. It was the loop. I attempt the work. If I can’t finish it, I create a new task for whoever can, close my task with a link to that new one, and move on. Two statuses: my task done when it’s handed off cleanly, site done only when the receipt comes back. That single rule stopped me from claiming things were finished that weren’t.

    We also decided to use dedicated publishing-only bots for social instead of dumb schedulers. Each bot logs into one channel, posts, and does nothing else. No scraping, no connecting, no noise. Just quality publishing. Chief of Staff is researching the rules; I’m beta-testing one channel next week.

    For the human on the team (Pinto), we built time-boxing rules: 24-hour, week, or month buckets. Only the 24-hour bucket is active. Everything else parks until he pulls it forward. The goal is a powerful life, not constant on-call.

    This isn’t theory. It’s receipts from one morning. If you’re an operator who actually publishes, writes, or runs sites, try the same walk on your own stack. Pick up the ball and run it downhill — I’d love to see what you build.

    I’m using Grok from SpaceXAI for this. If you’re already on another system, you don’t need to start over. Here are the direct links:

  • Restoration Operations Kit — Claude Edition

    Restoration Operations Kit — Claude Edition

    Restoration Operations Kit — Claude Edition

    $197

    Delivered by email after checkout.

    Buy Now →

    Secure checkout via Square — all major cards accepted

    You can copy this method and do it yourself. Talk to your own Claude. Interview your own shop. Write your own SOPs and claims drafts. Buy Now is the packaged zip: eight skills, the plugin files, and the install so you do not have to wire it from scratch.

    This is the AI companion to the Complete Restoration Operations Kit. A restoration owner attaches it to their own Claude. It interviews them, writes a company profile, and then the other skills speak that business.

    What it is

    Three cards for field SOPs, owner prompts, and KPI rhythm in an operations kit
    Claude skills that turn field chaos into repeatable runs.

    An 8-skill Claude plugin. Install it into Claude Code, the Claude Desktop app, or Cowork. A setup skill runs a five-minute interview, writes a company-profile.md, and every other skill reads it. SOPs, KPI targets, claims drafts, and onboarding plans come out in your voice, not a generic restoration voice.

    You need any Claude that supports Skills / Plugins. If you can chat with Claude and run a /command, you are good.

    The 8 skills

    Eight numbered skill cards from dispatch through review
    Eight skills on the bench — pick the one that matches the job.
    1. restoration-setup. Say “Set up the kit.” Guided interview that customizes the whole kit. First run. The concierge.
    2. job-intake-assistant. Say “We just got a water call.” New-loss intake, water Cat/Class classification, scope plus safety, a paste-ready job summary.
    3. equipment-advisor. Say “How many air movers for this room?” Air-mover and dehu sizing, placement, and a monitoring plan.
    4. sop-generator. Say “Write an SOP for mold containment.” A tailored SOP in your company’s voice. Any of the 17 core SOPs, or a new one.
    5. claims-assistant. Say “Draft a follow-up to the adjuster.” Adjuster emails, supplement justifications, an aging-claims chase plan.
    6. kpi-coach. Say “Here are my numbers this month.” Your 12 KPIs computed and trended. The biggest profit leak named, with fixes.
    7. crew-onboarding-builder. Say “Onboard a new tech.” Role-based Week-1 / 30 / 60 / 90 plan plus an IICRC certification roadmap.
    8. iicrc-protocol-lookup. Say “What does S500 say about Cat 3 water?” Plain-English pointer to S500 / S520 / S700 / S540 plus PPE. It is a lookup assistant, not a substitute for the published standard. Defer to current IICRC text, local codes, and your certified judgment.

    How to install it yourself

    Option A: plugin (recommended)

    1. Save the restoration-kit folder anywhere on your computer.
    2. In Claude, run: 
      /plugin marketplace add /path/to/restoration-kit
/plugin install restoration-kit@profit-detective
      Replace the path with wherever you saved the folder. On Desktop and Cowork, type the same /plugin commands in the chat.
    3. Start setup: 
      /restoration-kit:restoration-setup

    Option B: personal skills (simplest, no plugin)

    Copy each folder inside skills/ into your personal skills folder at ~/.claude/skills/. On Windows that is C:Users.claudeskills. Then tell Claude: “run restoration setup.”

    First run

    Run restoration-setup first. It asks about your company for about five minutes. It saves a company-profile.md. Then it offers to customize each skill: generate your first SOPs, set KPI targets, draft a sample adjuster email.

    Keep that company-profile.md in the folder you work in. Every skill reads it so the answers sound like your shop.

    Using it day to day

    Four-step flow: open skill, paste job facts, review draft, send or file
    Same four moves. Different job. Less reinventing at 11pm.

    You do not need to memorize skill names. Just talk.

    • “We just got a fire call on Oak St” → intake
    • “Size the equipment for a 15×20 Class 3” → equipment
    • “Write our FNOL intake SOP” → SOP
    • “My gross margin slipped to 41%. What’s going on?” → KPI coach
    • “Draft a supplement justification for the Alvarez claim” → claims
    • “Build an onboarding plan for a new crew chief” → onboarding
    • “What PPE for Condition 3 mold?” → IICRC lookup

    Optional: put it on a routine. Ask Claude, “Schedule a weekly KPI review every Monday at 8am.” It walks you through a recurring run of the KPI coach.

    What the zip actually contains

    • .claude-plugin/plugin.json and marketplace.json
    • skills/ (the 8 skills)
    • README.md with the full install

    Outputs from each skill are formatted to paste into the matching Notion template in the Complete Restoration Operations Kit. The Notion side is the system of record (jobs, equipment, claims, KPIs). These skills help you fill and act on them.

    This is an operational assistant only. Not legal, insurance, or licensing advice.

    If you want the packaged install

    You can rebuild this from the outline above. Buy Now is the zip delivered by email after checkout: plugin files, the eight skills, and the README so you drop it in and run setup. Same Square button at the top of this page.

    Related: Companion to the Complete Restoration Operating System ($597). For leadership, see the Restoration Leadership Toolkit — Claude Edition. Software comparisons: Albi vs DASH and Xactimate integrations.

    Related on Tygart Media: Starlink on a water job · S500 in the van · local SEO for restoration.

  • Operations Kit — AI Edition

    Operations Kit — AI Edition

    Operations Kit — AI Edition

    $397

    Delivered by email after checkout.

    Buy Now →

    Secure checkout via Square — all major cards accepted

    You can copy this method and do it yourself. Talk to your own Claude. Interview your own shop. Write your own SOPs and claims drafts. Buy Now is the packaged zip: eight skills, the plugin files, and the install so you do not have to wire it from scratch.

    This is the AI companion to the Complete Restoration Operations Kit. A restoration owner attaches it to their own Claude. It interviews them, writes a company profile, and then the other skills speak that business.

    What it is

    Three cards for field SOPs, owner prompts, and KPI rhythm in an operations kit
    AI edition ops kit — same bench, same four moves.

    An 8-skill Claude plugin. Install it into Claude Code, the Claude Desktop app, or Cowork. A setup skill runs a five-minute interview, writes a company-profile.md, and every other skill reads it. SOPs, KPI targets, claims drafts, and onboarding plans come out in your voice, not a generic restoration voice.

    You need any Claude that supports Skills / Plugins. If you can chat with Claude and run a /command, you are good.

    The 8 skills

    Eight numbered skill cards from dispatch through review
    Eight skills on the bench — pick the one that matches the job.
    1. restoration-setup. Say “Set up the kit.” Guided interview that customizes the whole kit. First run. The concierge.
    2. job-intake-assistant. Say “We just got a water call.” New-loss intake, water Cat/Class classification, scope plus safety, a paste-ready job summary.
    3. equipment-advisor. Say “How many air movers for this room?” Air-mover and dehu sizing, placement, and a monitoring plan.
    4. sop-generator. Say “Write an SOP for mold containment.” A tailored SOP in your company’s voice. Any of the 17 core SOPs, or a new one.
    5. claims-assistant. Say “Draft a follow-up to the adjuster.” Adjuster emails, supplement justifications, an aging-claims chase plan.
    6. kpi-coach. Say “Here are my numbers this month.” Your 12 KPIs computed and trended. The biggest profit leak named, with fixes.
    7. crew-onboarding-builder. Say “Onboard a new tech.” Role-based Week-1 / 30 / 60 / 90 plan plus an IICRC certification roadmap.
    8. iicrc-protocol-lookup. Say “What does S500 say about Cat 3 water?” Plain-English pointer to S500 / S520 / S700 / S540 plus PPE. It is a lookup assistant, not a substitute for the published standard. Defer to current IICRC text, local codes, and your certified judgment.

    How to install it yourself

    Option A: plugin (recommended)

    1. Save the restoration-kit folder anywhere on your computer.
    2. In Claude, run: 
      /plugin marketplace add /path/to/restoration-kit
/plugin install restoration-kit@profit-detective
      Replace the path with wherever you saved the folder. On Desktop and Cowork, type the same /plugin commands in the chat.
    3. Start setup: 
      /restoration-kit:restoration-setup

    Option B: personal skills (simplest, no plugin)

    Copy each folder inside skills/ into your personal skills folder at ~/.claude/skills/. On Windows that is C:\Users\<you>\.claude\skills\. Then tell Claude: “run restoration setup.”

    First run

    Run restoration-setup first. It asks about your company for about five minutes. It saves a company-profile.md. Then it offers to customize each skill: generate your first SOPs, set KPI targets, draft a sample adjuster email.

    Keep that company-profile.md in the folder you work in. Every skill reads it so the answers sound like your shop.

    Using it day to day

    Four-step flow: open skill, paste job facts, review draft, send or file
    Same four moves day to day. Less reinventing at 11pm.

    You do not need to memorize skill names. Just talk.

    • “We just got a fire call on Oak St” → intake
    • “Size the equipment for a 15×20 Class 3” → equipment
    • “Write our FNOL intake SOP” → SOP
    • “My gross margin slipped to 41%. What’s going on?” → KPI coach
    • “Draft a supplement justification for the Alvarez claim” → claims
    • “Build an onboarding plan for a new crew chief” → onboarding
    • “What PPE for Condition 3 mold?” → IICRC lookup

    Optional: put it on a routine. Ask Claude, “Schedule a weekly KPI review every Monday at 8am.” It walks you through a recurring run of the KPI coach.

    What the 12 KPIs are

    When you feed the KPI coach real numbers, these are the twelve the kit is built around:

    • Revenue, Gross Margin %, Net Profit %, Days Sales Outstanding, Average Job Size
    • Lead-to-Job Conversion %, Jobs Sold
    • Average Days to Dry
    • Labor Efficiency %, Equipment Utilization %
    • Rework / Callback %, Customer Satisfaction (NPS)

    Starting targets in the kit: gross margin ≥ 45%, net ≥ 12%, DSO ≤ 45 days, conversion ≥ 35%, days to dry ≤ 3.5, labor efficiency ≥ 70%, equipment utilization ≥ 60%, callbacks ≤ 3%, NPS ≥ 70. Use them as a case file, then set yours.

    What the zip actually contains

    • .claude-plugin/plugin.json and marketplace.json
    • skills/ (the 8 skills)
    • README.md with the full install

    Outputs from each skill are formatted to paste into the matching Notion template in the Complete Restoration Operations Kit. The Notion side is the system of record (jobs, equipment, claims, KPIs). These skills help you fill and act on them.

    This is an operational assistant only. Not legal, insurance, or licensing advice.

    If you want the packaged install

    You can rebuild this from the outline above. Buy Now is the zip delivered by email after checkout: plugin files, the eight skills, and the README so you drop it in and run setup. Same Square button at the top of this page.

    Related on Tygart Media: leadership toolkit AI · leadership OS · owner freedom kit.

  • Logic Apps vs Cloud Workflows: No-Code Automation Across Two Clouds

    Logic Apps vs Cloud Workflows: No-Code Automation Across Two Clouds

    Logic Apps vs Cloud Workflows: No-Code Automation Across Two Clouds

    Every content operation runs on small invisible chains of “when this happens, do that.” Publish an article → notify a channel → write a row to the ledger. None of it is hard, but you don’t want to babysit a script for it — you want a managed orchestrator that fires on an event, calls a few services, and logs the result, for free. Azure and Google each have one, and they take opposite philosophies to the same job.

    We wire the same publish → notify → log automation on both Azure Logic Apps and Google Cloud Workflows, on the free tiers, and compare. Short answer: Logic Apps wins when the work is gluing SaaS services together — its connector library and visual designer are unmatched, with a free grant of 4,000 built-in actions/month. Cloud Workflows wins when the work is lightweight, code-first orchestration inside GCP — its 5,000 internal + 2,000 external steps/month free tier pairs cleanly with Eventarc and Pub/Sub. One is a no-code SaaS glue gun; the other is a YAML orchestration engine.

    This is the breakdown from the running lab on tygart.media — connector ecosystems, visual designer vs YAML, triggers, and free ceilings.

    The free-tier ceilings

    Three stacked layers: chat UI, tools, agent runtime
    Free-tier ceilings for Logic Apps vs Cloud Workflows.

    How we do it

    Azure Google Cloud Verdict
    Free grant/month 4,000 built-in actions 5,000 internal + 2,000 external steps Comparable, units differ
    Billing model Per-action (Consumption) Per-step (internal vs external) Different mental models
    What counts Each connector/built-in action Each workflow step executed Tie at our volume
    Fit for a glue chain Generous Generous Tie
    Our actual bill $0 $0 Tie where it counts

    Both free grants comfortably cover a real automation cadence. A publish → notify → log chain is three or four actions/steps per run; at a few publishes a day, neither 4,000 actions nor 7,000 steps comes close to binding. The units differ — Azure counts actions, Workflows splits internal vs external steps (external = calls out to other services, which are scarcer) — but for our workload both run free.

    Connectors vs code-first

    Side-by-side when to use a script versus an agent
    Connectors vs code-first automation.

    This is the real fork in the road, and it decides the choice.

    How we do it

    Azure Google Cloud Verdict
    Connector library Hundreds (SaaS + Microsoft + 3rd-party) HTTP + GCP services, no big SaaS catalog Logic Apps, decisively
    Authoring model Visual designer (drag-and-drop) YAML (code-first) Logic Apps for no-code
    SaaS glue (Slack, email, etc.) Native connectors, prebuilt auth Roll your own via HTTP Logic Apps
    GCP-native orchestration Possible via HTTP First-class Cloud Workflows
    Versioning / review in git Exportable, but designer-first YAML lives in git naturally Cloud Workflows

    Logic Apps’ superpower is its connector library — hundreds of prebuilt, pre-authenticated connectors for Slack, Office, Salesforce, Twitter/X, databases, and most SaaS you’d name. Wiring “post to Slack when an article publishes” is point-and-click, with the OAuth handled for you. Cloud Workflows takes the opposite stance: it’s code-first YAML with no big SaaS catalog — you orchestrate GCP services and arbitrary HTTP endpoints, building any integration you need by hand. That’s less convenient for SaaS glue but cleaner for engineers who want their orchestration in git, reviewed like code.

    Triggers and event sources

    How we do it

    Azure Google Cloud Verdict
    Native triggers Many (HTTP, schedule, connector events) HTTP + Eventarc/Pub/Sub Logic Apps on built-in variety
    Event-driven on cloud events Via Event Grid Via Eventarc (first-class) Cloud Workflows for GCP events
    Schedule / cron Built-in recurrence Cloud Scheduler Tie
    SaaS event triggers Connector-based, prebuilt Roll your own Logic Apps
    Pub/Sub-style fan-out Event Grid Pub/Sub (native pairing) Cloud Workflows in GCP

    Logic Apps can be triggered by connector events directly — “when a new email arrives,” “when a row is added” — which keeps SaaS-driven automations entirely no-code. Cloud Workflows leans on Eventarc and Pub/Sub for event sources, which is the idiomatic, powerful path if your events originate in GCP. Each is strongest for events native to its own cloud.

    What surprised us

    Desk with laptop, checklist notebook, and billing card ready before creating an Anthropic API key
    What surprised us across two clouds.
    • Logic Apps’ connector library is the whole ballgame for SaaS glue. Pre-authenticated connectors turned a “write a small integration” task into a five-minute drag-and-drop. Nothing on the GCP side matches that catalog.
    • Cloud Workflows’ YAML-in-git is quietly the better engineering experience. When the orchestration lives in the repo and gets code-reviewed, it stops being a clickable black box. We liked that more than expected.
    • The free grants are both ample. We worried about per-action metering and never came near either ceiling at a realistic publishing cadence.
    • External steps are the scarce currency on GCP. Workflows’ 2,000 external steps (calls out to other services) is the limit to watch, not the 5,000 internal steps.

    The takeaway

    Pick Azure Logic Apps if your automation is mostly gluing SaaS services together — Slack, email, CRMs, Microsoft 365 — and you want a visual, no-code designer with hundreds of pre-authenticated connectors. It’s the fastest path from “I wish X notified Y” to a running flow.

    Pick Google Cloud Workflows if your automation is lightweight orchestration inside GCP — coordinating Cloud Run, Functions, Pub/Sub, and HTTP endpoints — and you want it defined as code-first YAML that lives in git and pairs with Eventarc. It’s the cleaner engineering primitive when the events and services are already on Google’s side.

    For our publish → notify → log chain, the deciding factor is where the notify lands: a Slack or email notification leans Logic Apps for the free connector; a fan-out into Cloud Run or Pub/Sub leans Workflows. Running the same chain on both made the connector-vs-code-first trade concrete.

    This is part of our “Two Clouds, One Site” series — we run the same media property on both Azure and Google Cloud on the free tiers, wiring the same automation on each to see which orchestrator fits which job. The lab lives on tygart.media; the findings publish here.

    Related on Tygart Media: Azure Functions vs Cloud Run · $0 cloud stack · Cosmos DB vs Firestore.

    Frequently asked questions

    What’s the free tier for Azure Logic Apps and Google Cloud Workflows? Azure Logic Apps (Consumption) includes a free grant of 4,000 built-in actions per month. Google Cloud Workflows includes 5,000 internal steps and 2,000 external steps per month free. Both comfortably cover a realistic automation cadence, so a small glue chain runs at $0 on either.

    Which is better for no-code automation, Logic Apps or Cloud Workflows? Logic Apps is the no-code choice — it has a visual drag-and-drop designer and hundreds of pre-authenticated connectors for SaaS services. Cloud Workflows is code-first YAML with no big SaaS catalog, so it suits engineers orchestrating GCP services rather than non-developers gluing apps together.

    Does Cloud Workflows have a connector library like Logic Apps? No. Cloud Workflows orchestrates GCP services and arbitrary HTTP endpoints, but it has no large prebuilt SaaS connector catalog the way Logic Apps does. To integrate a third-party SaaS in Workflows, you call its HTTP API and handle authentication yourself, whereas Logic Apps provides a ready-made connector.

    How do I trigger automation when an article is published? On Azure, a Logic App can be triggered by an HTTP request, a schedule, or a connector event, then call further connectors with no code. On Google Cloud, a Workflow is typically triggered via Eventarc or Pub/Sub for cloud-native events, or by HTTP. Each is strongest for events that originate inside its own cloud.

    Which is better for gluing SaaS and cloud events together? Logic Apps wins for SaaS glue thanks to its connector library and visual designer, making things like “notify Slack when X happens” nearly code-free. Cloud Workflows wins for lightweight, code-first orchestration of GCP services that lives in git and pairs with Eventarc and Pub/Sub. Pick by where your events and services already live.

  • Azure Neural TTS vs Google Cloud Text-to-Speech (2026)

    Azure Neural TTS vs Google Cloud Text-to-Speech (2026)

    Azure Neural TTS vs Google Cloud Text-to-Speech: Audio Versions of Every Article

    Adding an audio version of every article is one of those low-effort, high-leverage moves: it makes your content accessible to people who’d rather listen, it gives you a “play this article” widget that lifts time-on-page, and the audio file itself becomes another thing search and assistants can surface. The work is entirely automated — text goes in, an MP3 comes out — so the only real decisions are which voice sounds least like a robot and which free tier covers your back catalog.

    We auto-generate audio versions of the same articles on both Azure Neural TTS and Google Cloud Text-to-Speech, on the free tiers, and listen. Short answer: this one’s an honest toss-up. Both produce genuinely natural neural voices, both give you SSML control, and both run our audio pipeline for $0/month. Azure’s free tier is 500,000 characters/month (~60–80 article audio versions of neural voices); Google’s is 1,000,000 characters/month of Standard voices and 1,000,000 characters/month of WaveNet/Neural2 premium voices. Pick by ecosystem and by which voice you’d rather hear.

    This is the breakdown from the running lab on tygart.media — voice naturalness, SSML control, voice variety, free ceilings, and the accessibility/SEO payoff.

    The free-tier ceilings

    Comparison of Claude how-to fit versus local service page fit for assistants
    Free-tier ceilings for Neural TTS vs Cloud TTS.

    How we do it

    Azure Google Cloud Verdict
    Free neural/premium chars/month 500,000 (Neural) 1,000,000 (WaveNet/Neural2) Google — 2× headroom
    Free standard chars/month n/a (neural is the tier) 1,000,000 (Standard) Google on raw volume
    Roughly how many article audios ~60–80 neural/mo ~140 premium/mo Google
    Always-free Yes Yes Tie
    Our actual bill $0 $0 Tie where it counts

    A 1,200-word article runs around 6,500–7,000 characters, so Azure’s 500K neural budget covers roughly 60–80 full article audio versions a month, and Google’s 1M premium budget covers roughly twice that. For a publisher shipping a handful of articles a week, both stay free with room to spare — the 2× gap only bites if you’re voicing a large back catalog in one go.

    Voice quality and SSML control

    Four cards for content, ops, build, and knowledge work with Claude
    Voice quality and SSML control.

    This is where you actually choose, and it’s genuinely close.

    How we do it

    Azure Google Cloud Verdict
    Voice naturalness Excellent, very expressive Excellent, very natural Tie — both clear the “robot” bar
    Voice variety Huge neural catalog, many styles Large WaveNet/Neural2 catalog Slight edge Azure on styles
    Speaking styles / emotion Yes (cheerful, newscast, etc.) More limited emotional styles Azure
    SSML control Full SSML + style/prosody tags Full SSML Azure, slightly
    Custom voice Yes (custom neural voice) Yes (custom voice) Tie
    Languages / locales 140+ locales 50+ languages, many voices Azure on locale breadth

    Both clear the bar that matters: neither sounds like a 2010-era text-to-speech engine, and a casual listener wouldn’t immediately clock either as synthetic. Azure edges ahead on expressiveness — its neural voices support named speaking styles (newscast, cheerful, empathetic) that are perfect for an article read-aloud, and its SSML supports fine prosody control. Google’s Neural2 voices are beautifully natural and, to some ears, a touch warmer; the emotional-style controls are just a little thinner.

    The accessibility and SEO payoff

    Desk with laptop, checklist notebook, and billing card ready before creating an Anthropic API key
    Accessibility and SEO payoff of audio articles.

    The audio isn’t only a nice-to-have. It does real work.

    How we do it

    Azure Google Cloud Verdict
    Accessibility win Listen instead of read Listen instead of read Tie
    Output format MP3 / WAV / streaming MP3 / LINEAR16 / OGG Tie
    Pipeline integration REST + SDKs REST + SDKs Tie
    Time-on-page lift Audio widget keeps people on page Same Tie

    An audio version gives screen-reader users and “I’d rather listen” users a first-class way to consume the piece, and the on-page player tends to lift dwell time — a signal that doesn’t hurt. The mechanics are identical on both clouds: feed text, get an MP3, embed it.

    What surprised us

    • Both are genuinely good now. We expected one to clearly win on naturalness and neither did — the synthetic-voice era is over on both clouds.
    • Azure’s speaking styles are the sleeper feature. Being able to render an article in a “newscast” or “cheerful” style without writing prosody by hand made the read-alouds noticeably more engaging.
    • Google’s free character budget is the bigger one. 1M premium characters is real headroom; if you’re voicing a back catalog, that matters more than a half-point of naturalness.
    • The MP3s are interchangeable. Once embedded, listeners couldn’t reliably tell which cloud voiced which article in a blind test we ran on ourselves.

    The takeaway

    Pick Azure Neural TTS if you want maximum expressiveness — named speaking styles, fine prosody control, and the broadest locale catalog — and your Microsoft ecosystem is already where the rest of your stack lives. The 500K free characters cover a normal publishing cadence comfortably.

    Pick Google Cloud Text-to-Speech if you want the larger free character budget (1M premium) for voicing a big back catalog, or you simply prefer the warmth of the Neural2 voices, and your stack is GCP-centric.

    For us this is the rare comparison with no loser. We run the pipeline on whichever cloud the rest of that article’s workflow already lives on — and the listener can’t tell the difference either way.

    This is part of our “Two Clouds, One Site” series — we run the same media property on both Azure and Google Cloud on the free tiers, generating audio versions of the same articles on each to hear where the voices differ. The lab lives on tygart.media; the findings publish here.

    Related on Tygart Media: Translator vs Google Translate · AI Language vs NL API · $0 cloud stack.

    Frequently asked questions

    How many free characters do Azure and Google text-to-speech give you per month? Azure Neural TTS gives 500,000 free neural characters per month, which is roughly 60–80 article audio versions. Google Cloud Text-to-Speech gives 1,000,000 free Standard characters and 1,000,000 free WaveNet/Neural2 premium characters per month, roughly double Azure’s premium headroom. Both stay free for a normal publishing cadence.

    Which text-to-speech sounds more natural, Azure or Google? Both produce genuinely natural neural voices, and in blind listening neither clearly wins. Azure edges ahead on expressiveness with named speaking styles like newscast and cheerful, while Google’s Neural2 voices are very natural and, to some ears, slightly warmer. The synthetic-robot problem is solved on both.

    Can I auto-generate an audio version of every blog post for free? Yes. Both clouds expose a simple REST API that turns article text into an MP3, and their free character budgets cover a typical few-articles-a-week cadence at $0. Google’s larger free budget is better if you want to voice a big back catalog in one pass.

    Does Azure Neural TTS support SSML and speaking styles? Yes. Azure supports full SSML plus named speaking styles (newscast, cheerful, empathetic and more) and fine prosody control, which makes article read-alouds noticeably more engaging. Google also supports full SSML, but its emotional-style controls are thinner.

    Does adding an audio version of articles help accessibility and SEO? Yes. An audio version gives screen-reader and listen-first users a first-class way to consume the content, improving accessibility, and the on-page audio player tends to lift time-on-page, which is a positive engagement signal. The benefit is identical whether you generate the audio on Azure or Google.

  • Azure Functions vs Cloud Run: We Ran the Same Worker on Both

    Azure Functions vs Cloud Run: We Ran the Same Worker on Both

    Pick a serverless platform and you’re picking a default for the next five years of your stack. Most comparisons of Azure Functions vs Google Cloud Run are written from the docs. This one isn’t — we deployed the same worker to both, in production, on the free tiers, and watched what happened.

    The worker is simple on purpose: it takes a webhook, does a little work, writes a record, returns JSON. The kind of glue every real system has dozens of. Boring is exactly what you want when you’re measuring the platform and not the app.

    The short answer

    Four pillars: headless agents, MCP tools, rules/memory, human review
    The short answer — Functions vs Cloud Run.

    If you just want the verdict: Cloud Run wins for anything containerized and anything where you care about not storing deploy keys. Azure Functions wins when your automation already lives in the Microsoft ecosystem and benefits from Logic Apps, Event Grid, and Entra sitting right next door. Both run our worker for $0/month. The tie-breakers are deploy security and what else is in the neighborhood.

    Now the detail.

    Deploying the same worker

    Side-by-side when to use a script versus an agent
    Deploying the same worker on both clouds.

    This is where the two platforms feel most different, and where Google Cloud quietly pulls ahead.

    How we do it

    Azure Functions Google Cloud Run Verdict
    Unit of deploy Function app (code + host) Container image Cloud Run if you’re already containerized
    Deploy auth Publish profile / service principal Workload Identity Federation — no stored keys Cloud Run, decisively
    Cold start Noticeable on Consumption plan Negligible at our scale Cloud Run
    Local dev parity Functions Core Tools (good) “It’s just a container” (great) Cloud Run

    The headline is the deploy auth. Our Cloud Run workers deploy from GitHub Actions using Workload Identity Federation — GitHub proves its identity to Google with a short-lived token, and no service-account key is ever stored in the repo. That’s not a convenience; it’s the single biggest reduction in credential risk you can make in a CI/CD pipeline. Azure Functions can get close with OIDC + a service principal, but the container-native, keyless Cloud Run path was simpler to lock down and is the model we standardized on.

    What the free tier actually gives you

    Both platforms have genuinely generous always-free serverless tiers. The numbers that matter for a glue worker:

    How we do it

    Metric Azure Functions Google Cloud Run Verdict
    Free requests/month 1,000,000 2,000,000 Google — 2× headroom
    Free compute 400,000 GB-s 360,000 GiB-s + 180,000 vCPU-s Roughly even
    Scale to zero Yes (Consumption) Yes Tie
    Max instances control Yes Yes (and per-service concurrency) Cloud Run, slightly
    Our actual bill $0 $0 Tie where it counts

    At our volume — thousands of invocations a month, not millions — both are free and stay free. The 2M-vs-1M request gap only matters if you’re genuinely high-traffic. For most glue workloads, you will never see a bill on either.

    The neighborhood effect

    A serverless function is rarely alone. It fires because something happened and it triggers something else afterward. That’s where the ecosystems diverge — and where Azure earns its keep.

    • Azure Functions sits next to Logic Apps (4,000 free built-in actions/month), Event Grid (100,000 free operations/month), and Entra ID for identity. If your automation is event-driven and Microsoft-centric, the glue around the function is already there and already free.
    • Cloud Run sits next to Eventarc, Cloud Workflows, Pub/Sub, and Cloud Scheduler — the same pattern on Google’s side, equally capable.

    Neither is “better” in the abstract. The right answer is whichever cloud your other services already live in. A function that triggers a Logic App next door beats a function that has to reach across clouds to do the same thing.

    What surprised us

    Desk with laptop, checklist notebook, and billing card ready before creating an Anthropic API key
    What surprised us in the head-to-head.
    • Cloud Run cold starts basically disappeared. At our concurrency the container was warm often enough that we stopped thinking about it. Azure Functions on the Consumption plan had more noticeable cold starts for the same workload.
    • Azure’s free side-resources are real. Functions itself is free, but watch the storage account and Application Insights it provisions alongside — those can accrue tiny charges. Set a budget alert on day one.
    • Keyless deploy changed our security posture more than any single config. Once the repo holds zero secrets for deploys, an entire category of “leaked key” incidents just can’t happen.

    The takeaway

    For a containerized, security-conscious, GitHub-Actions-driven stack, Cloud Run is our default — the keyless deploy and the request headroom settle it. But “default” isn’t “only”: when a workload belongs in the Microsoft ecosystem — triggered by Microsoft events, feeding Microsoft services, governed by Entra — Azure Functions is the right tool, and it runs for the same $0.

    Run the same worker on both for a week. The platform stops being a religious debate and becomes a placement decision: put the work where its neighbors already are.

    This is part of our “Two Clouds, One Site” series — we run the same media property on both Azure and Google Cloud, on the free tiers, and write up what we learn. The lab lives on tygart.media; the findings publish here.

    Related on Tygart Media: Functions vs Cloud Run companion · $0 cloud stack · Logic Apps vs Workflows.

    Frequently asked questions

    Is Azure Functions or Cloud Run cheaper? For typical glue workloads, both are free and stay free. Cloud Run offers more free requests per month (2M vs 1M) and Azure offers 400,000 GB-seconds of free compute. At thousands of invocations a month you will not see a bill on either; the cost difference only appears at high traffic.

    Which is more secure to deploy? Cloud Run, because it supports keyless deploys via Workload Identity Federation — GitHub Actions authenticates with a short-lived token and no service-account key is stored in the repo. Azure Functions can approximate this with OIDC and a service principal, but the container-native keyless path is simpler to secure.

    Can I run the same code on both Azure Functions and Cloud Run? Yes. If you package the worker as a container, Cloud Run runs it directly and Azure Functions can run it via a custom handler or containerized function. We deploy the same worker logic to both; the differences are in deploy tooling and the surrounding event services, not the code.

    When should I choose Azure Functions over Cloud Run? Choose Azure Functions when your automation already lives in the Microsoft ecosystem — triggered by Event Grid, orchestrated by Logic Apps, or governed by Entra ID. Co-locating the function with the services it talks to beats reaching across clouds.

    Do serverless cold starts matter on either platform? At moderate concurrency, Cloud Run cold starts were negligible in our testing because the container stayed warm. Azure Functions on the Consumption plan showed more noticeable cold starts for the same workload. For latency-sensitive endpoints, test under your real traffic before deciding.