Category: Local AI & Automation

This Is Not a Chatbot Story

When people hear I use AI every day, they picture someone typing questions into ChatGPT and getting answers. That’s not what this is. I’ve run 387 working sessions with Claude in Cowork mode since December 2025. Each session is a full operating environment – a Linux VM with file access, tool execution, API connections, and persistent memory across sessions.

These aren’t conversations. They’re deployments. Content publishes. Infrastructure builds. SEO audits across 18 WordPress sites. Notion database updates. Email monitors. Scheduled tasks. Real operational work that used to require a team of specialists.

The number 387 isn’t bragging. It’s data. And what that data reveals about how AI actually integrates into daily business operations is more interesting than any demo or product launch.

What a Typical Session Actually Looks Like

A session starts when I open Cowork mode and describe what I need done. Not a vague prompt – a specific operational task. “Run the content intelligence audit on a storm protection company.com and generate 15 draft articles.” “Check all 18 WordPress sites for posts missing featured images and generate them using Vertex AI.” “Read my Gmail for VIP messages from the last 6 hours and summarize what needs attention.”

Claude loads into a sandboxed Linux environment with access to my workspace folder, my installed skills (I have 60+), my MCP server connections (Notion, Gmail, Google Calendar, Metricool, Figma, and more), and a full bash/Python execution layer. It reads my CLAUDE.md file – a persistent memory document that carries context across sessions – and gets to work.

A single session might involve 50-200 tool calls. Reading files, executing scripts, making API calls, writing content, publishing to WordPress, logging results to Notion. The average session runs 15-45 minutes of active work. Some complex ones – like a full site optimization pass – run over two hours.

The Skill Layer Changed Everything

Early sessions were inefficient. I’d explain the same process every time – how to connect to WordPress via the proxy, what format to use for articles, which Notion database to log results in. Repetitive context-setting that ate 30% of every session.

Then I started building skills. A skill is a structured instruction file (SKILL.md) that Claude reads at the start of a session when the task matches its trigger conditions. I now have skills for WordPress publishing, SEO optimization, content generation, Notion logging, YouTube watch page creation, social media scheduling, site auditing, and dozens more.

The impact was immediate. A task that took 20 minutes of back-and-forth setup now triggers in one sentence. “Run the wp-intelligence-audit on a luxury asset lender.com” – Claude reads the skill, loads the credentials from the site registry, connects via the proxy, pulls all posts, analyzes gaps, and generates a full report. No explanation needed. The skill contains everything.

Building skills is the highest-leverage activity I’ve found in AI-assisted work. Every hour spent writing a skill saves 10+ hours across future sessions. At 387 sessions, the compound return is staggering.

What 387 Sessions Taught Me About AI Workflow

Specificity beats intelligence. The most productive sessions aren’t the ones where Claude is “smartest.” They’re the ones where I give the most specific instructions. “Optimize this post for SEO” produces mediocre results. “Run wp-seo-refresh on post 247 at a luxury asset lender.com, ensure the focus keyword is ‘luxury asset lending,’ update the meta description to 140-160 characters, and add internal links to posts 312 and 418” produces excellent results. AI amplifies clarity.

Persistent memory is the unlock. CLAUDE.md – a markdown file that persists across sessions – is the most important file in my entire system. It contains my preferences, operational rules, business context, and standing instructions. Without it, every session starts from zero. With it, session 387 has the accumulated context of all 386 before it. This is the difference between using AI as a tool and using AI as a partner.

Batch operations reveal true ROI. Publishing one article? AI saves maybe 30 minutes. Publishing 15 articles across 3 sites with full SEO/AEO/GEO optimization, taxonomy assignment, internal linking, and Notion logging? AI saves 15+ hours. The value curve is exponential with batch size. I now default to batch operations for everything – content, audits, meta updates, image generation.

Failures are cheap and informative. At least 40 of my 387 sessions hit significant errors – API timeouts, disk space issues, credential failures, rate limiting. Each failure taught me something that made the system more resilient. The SSH workaround. The WP proxy to avoid IP blocking. The WinError 206 fix for long PowerShell commands. Failure at high volume is the fastest path to robust systems.

The Numbers Behind 387 Sessions

I tracked the data because the data tells the real story:

Content produced: Approximately 400+ articles published across 18 WordPress sites. Each article is 1,200-1,800 words, SEO-optimized, AEO-formatted with FAQ sections, and GEO-ready with entity optimization. At market rates for this quality of content, that’s roughly ,000-,000 worth of content production.

Sites managed: 18 WordPress properties across multiple industries – restoration, luxury lending, cold storage, interior design, comedy, training, technology. Each site gets regular content, SEO audits, taxonomy fixes, schema injection, and internal linking.

Automations built: 7 autonomous AI agents (the droid fleet), 60+ skills, 3 scheduled tasks, a GCP Compute Engine cluster running 5 WordPress sites, a Cloud Run proxy for WordPress API routing, and a Vertex AI chatbot deployment.

Time investment: Approximately 200 hours of active session time over three months. For context, a single full-time employee working those same 200 hours could not have produced a fraction of this output, because the bottleneck isn’t thinking time – it’s execution speed. Claude executes API calls, writes code, publishes content, and processes data at machine speed. I provide direction at human speed. The combination is multiplicative.

Why Most People Won’t Do This

The honest answer: it requires upfront investment that most people aren’t willing to make. Building the skill library took weeks. Configuring the MCP connections, setting up the proxy, provisioning the GCP infrastructure, writing the CLAUDE.md context file – that’s real work before you see any return.

Most people want AI to be plug-and-play. Type a question, get an answer. And for simple tasks, it is. But for operational AI – AI that runs your business processes daily – the setup cost is significant and the learning curve is real.

The payoff, though, is not incremental. It’s categorical. I’m not 10% more productive than I was before Cowork mode. I’m operating at a fundamentally different scale. Tasks that would require hiring 3-4 specialists – content writer, SEO analyst, site admin, automation engineer – are handled in daily sessions by one person with a well-configured AI partner.

That’s not a productivity hack. That’s a structural advantage.

Frequently Asked Questions

What is Cowork mode and how is it different from regular Claude?

Cowork mode is a feature of Claude’s desktop app that gives Claude access to a sandboxed Linux VM, file system, bash execution, and MCP server connections. Regular Claude is a chat interface. Cowork mode is an operating environment where Claude can read files, run code, make API calls, and produce deliverables – not just text responses.

How much does running 387 sessions cost?

Cowork mode is included in the Claude Pro subscription at /month. The MCP connections (Notion, Gmail, etc.) use free API tiers. The GCP infrastructure runs about /month. Total cost for three months of operations: approximately . The value produced is orders of magnitude higher.

Can someone replicate this without technical skills?

Partially. The basic Cowork mode works out of the box for content creation, research, and file management. The advanced setup – custom skills, GCP infrastructure, API integrations – requires comfort with command-line tools, APIs, and basic scripting. The barrier is falling fast as skills become shareable and MCP servers become plug-and-play.

What’s the most impactful single skill you’ve built?

The wp-site-registry skill – a single file containing credentials and connection methods for all 18 WordPress sites. Before this skill existed, every session required manually providing credentials. After it, any wp- skill can connect to any site automatically. It turned 18 separate workflows into one unified system.

What Comes Next

Session 387 is not a milestone. It’s a Tuesday. The system compounds. Every skill I build makes future sessions faster. Every failure I fix makes the system more resilient. Every batch I run produces data that informs the next batch.

The question I get most often is “where do you start?” The answer is boring: start with one task you do repeatedly. Build one skill for it. Run it 10 times. Then build another. By session 50, you’ll have a system. By session 200, you’ll have an operating partner. By session 387, you’ll wonder how you ever worked without one.

{
“@context”: “https://schema.org”,
“@type”: “Article”,
“headline”: “387 Cowork Sessions and Counting: What Happens When AI Becomes Your Daily Operating Partner”,
“description”: “I’ve run 387 Cowork sessions with Claude in three months. Not chatbot conversations – full working sessions that build skills, publish content, mana”,
“datePublished”: “2026-03-21”,
“dateModified”: “2026-04-03”,
“author”: {
“@type”: “Person”,
“name”: “Will Tygart”,
“url”: “https://tygartmedia.com/about”
},
“publisher”: {
“@type”: “Organization”,
“name”: “Tygart Media”,
“url”: “https://tygartmedia.com”,
“logo”: {
“@type”: “ImageObject”,
“url”: “https://tygartmedia.com/wp-content/uploads/tygart-media-logo.png”
}
},
“mainEntityOfPage”: {
“@type”: “WebPage”,
“@id”: “https://tygartmedia.com/387-cowork-sessions-and-counting-what-happens-when-ai-becomes-your-daily-operating-partner/”
}
}

Meetings Produce Information. Most of It Evaporates.

I sat in a client call last month where we agreed on three specific deliverables, a revised timeline, and a budget adjustment. Everyone nodded. Everyone agreed. Three days later, nobody could remember the exact numbers or who owned what. I had to dig through a transcript to reconstruct the meeting.

This happens constantly. Meetings generate decisions, action items, and commitments at a rate that exceeds human note-taking capacity. Even when someone takes notes, the notes are incomplete, biased toward what the note-taker found interesting, and almost never get distributed in an actionable format. The transcript exists – most meetings are recorded now – but a 45-minute transcript is a 6,000-word wall of text that nobody will read.

MP-04 solves this. It’s the fourth agent in my autonomous fleet, and its job is simple: take any meeting transcript, extract everything actionable, and route it to the right systems before the meeting fades from memory.

What MP-04 Extracts

The agent processes meeting transcripts through Ollama’s Llama 3.2 model with a structured extraction prompt. It pulls five categories of information:

Action items: Anything that someone committed to doing. “I’ll send the proposal by Friday” becomes an action item assigned to the speaker with a Friday deadline. “We need to update the website copy” becomes an action item with no assignee – flagged for me to assign. The model distinguishes between firm commitments (someone said “I will”) and vague suggestions (“we should probably”) and tags them accordingly.

Decisions: Any point where the group reached agreement. “Let’s go with Option B” is a decision. “The budget is ,000” is a decision. These get logged as immutable records – what was decided, when, and by whom. Decisions are critical for accountability. When someone later says “we never agreed to that,” the decision log settles it.

Client mentions: Names of clients, companies, or projects discussed. Each mention gets cross-referenced against my client database to attach the meeting context to the right client record. If a client was discussed in three meetings this month, their record shows all three with relevant excerpts.

Deadlines and dates: Any temporal commitment. “The launch is March 15th.” “We need this by end of quarter.” “Let’s review next Tuesday.” These get extracted with enough context to create calendar-ready events or task due dates.

Open questions: Things raised but not resolved. “What’s the pricing for the enterprise tier?” with no answer in the transcript becomes an open question flagged for follow-up. These are the items that silently disappear after meetings if nobody tracks them.

The Routing Layer

Extraction is useful. Routing is what makes it operational.

After extracting the five categories, MP-04 routes each item to the appropriate system:

Action items become Notion tasks in my Tasks Database. Each task is pre-populated with the company (inferred from client mentions), priority (inferred from deadline proximity and language urgency), source (the meeting date and title), and a link back to the full transcript. I don’t create these tasks manually. They appear in my task board, ready to be triaged in my next planning session.

Decisions get logged to the Knowledge Database in Notion. This creates a searchable decision history. Three months from now, when I need to recall what was agreed about the Q2 content strategy, I search the decisions log instead of scrubbing through transcripts.

Client mentions update the Client Database with a meeting note. The note includes a 2-3 sentence summary of what was discussed about that client, automatically generated from the relevant transcript sections.

Deadlines get posted to Slack with a reminder. If the deadline is within 7 days, it goes to my priority channel. If it’s further out, it goes to the weekly planning channel.

Open questions become follow-up tasks in Notion, tagged with a “needs-answer” status that keeps them visible until resolved.

The Technical Reality

MP-04 runs locally on my Windows machine. The input is a text transcript – either pasted directly or loaded from a file. Most meeting platforms (Zoom, Google Meet, Teams) now generate transcripts automatically, so the input is free.

The Ollama call uses a detailed system prompt that defines the extraction schema with examples. The prompt is about 800 tokens of instructions that tell the model exactly how to format each extracted item – as JSON objects with specific fields for each category. This structured output means the routing script can parse the results programmatically without any ambiguity.

Processing time for a 45-minute meeting transcript (approximately 6,000 words): about 15 seconds on Llama 3.2 3B running locally. The Notion API calls to create tasks, update client records, and log decisions add another 5-10 seconds. Total time from transcript to fully routed outputs: under 30 seconds.

Compare that to the manual process: read the transcript (15 minutes), identify action items (10 minutes), create tasks in Notion (5 minutes), update client records (5 minutes), set reminders for deadlines (5 minutes). That’s 40 minutes of administrative work per meeting, reduced to 30 seconds.

The Client Name Guardrail Problem

One unexpected challenge: client names in transcripts are messy. People use first names, company names, project codenames, and abbreviations interchangeably. “The Beverly project” and “a luxury lending firm” and “Sarah’s account” might all refer to the same client.

I built a name resolution layer that maps common references to canonical client records. It’s a JSON lookup table: “Beverly” maps to “a luxury lending firm Company,” “Sarah” maps to “Sarah [Client Last Name] at a luxury lending firm,” “BL” maps to “a luxury lending firm.” The table has about 150 entries covering all active clients and common reference patterns.

When the extraction model identifies a client mention, the name resolver checks it against this table before routing. If there’s no match, it flags the mention as “unresolved client reference” for manual review rather than creating a misattributed record. The guardrail prevents the worst outcome – action items attached to the wrong client – at the cost of occasionally requiring a 10-second manual resolution.

What Changed After 60 Days of Running MP-04

The obvious win: I stopped losing action items. In the 60 days before MP-04, I estimate that about 20% of meeting commitments fell through the cracks – not from negligence, but from the gap between hearing a commitment and recording it in a system. In the 60 days after, that dropped to under 3% (the remaining 3% are items the model misclassifies or that I manually deprioritize).

The less obvious win: meeting quality improved. When you know every commitment will be automatically extracted and tracked, you’re more careful about what you commit to. Meetings became more precise. Fewer vague “we should probably” statements, more specific “I will deliver X by Y.” The agent didn’t just capture accountability – it created it.

The unexpected win: the decision log became a strategic asset. Having a searchable history of every decision across every client turned out to be invaluable for quarterly reviews, contract renewals, and scope discussions. “Based on the decisions log, we’ve expanded scope three times without adjusting the retainer” is a powerful conversation to have with data behind it.

Frequently Asked Questions

What meeting platforms does MP-04 work with?

Any platform that produces a text transcript. Zoom, Google Meet, Microsoft Teams, Otter.ai, and Fireflies all export transcripts. MP-04 doesn’t integrate with these platforms directly – it processes the transcript file. This keeps it platform-agnostic and avoids the complexity of OAuth integrations with every meeting tool.

How accurate is the action item extraction?

On my test set of 40 meeting transcripts, the model correctly identified 91% of action items I had manually tagged. The 9% it missed were typically very implicit commitments – things like “I’ll take care of that” without specifying what “that” refers to. It also occasionally generates false positives from hypothetical statements – “if we were to do X, we would need Y” getting tagged as a commitment. The false positive rate is about 5%, easily caught in the triage step.

Can this work for meetings I didn’t attend?

Yes – and that’s one of the most useful applications. Team members can drop a transcript into the processing queue and I get a structured summary with action items without having attended the meeting. This is especially valuable for the meetings I delegate but still need to track outcomes from.

What about sensitive meeting content?

Everything runs locally. The transcript is processed by Ollama on my machine, routed to my private Notion workspace, and posted to my private Slack channels. No third-party service sees the meeting content. This is critical for client meetings that discuss financials, legal issues, or strategic plans.

The Agent Philosophy

MP-04 embodies the principle that runs through my entire agent fleet: don’t automate decisions – automate the administrative overhead around decisions. The agent doesn’t decide what to prioritize or how to respond to a client request. It extracts the raw information, structures it, and routes it to where I can make those decisions quickly and with full context. The human judgment stays human. The administrative busywork disappears.

{
“@context”: “https://schema.org”,
“@type”: “Article”,
“headline”: “MP-04: The Agent That Turns Every Meeting Into Action Items Before I Close the Tab”,
“description”: “MP-04 processes meeting transcripts automatically – extracting action items, decisions, client mentions, and deadlines, then routing them to the right Not”,
“datePublished”: “2026-03-21”,
“dateModified”: “2026-04-03”,
“author”: {
“@type”: “Person”,
“name”: “Will Tygart”,
“url”: “https://tygartmedia.com/about”
},
“publisher”: {
“@type”: “Organization”,
“name”: “Tygart Media”,
“url”: “https://tygartmedia.com”,
“logo”: {
“@type”: “ImageObject”,
“url”: “https://tygartmedia.com/wp-content/uploads/tygart-media-logo.png”
}
},
“mainEntityOfPage”: {
“@type”: “WebPage”,
“@id”: “https://tygartmedia.com/mp-04-the-agent-that-turns-every-meeting-into-action-items-before-i-close-the-tab/”
}
}

The Mistake That Created the Rule

I published 12 articles to the agency blog in a single session. World-class content. Properly optimized. Well-structured. And scattered throughout them were real client names – actual companies we serve, mentioned by name in case studies, examples, and operational descriptions.

This was not malicious. It was the natural output of an AI that had access to my full operational context – including which companies I work with, what industries they are in, and what we have built for them. When I asked for content drawn from real work, the AI delivered exactly that. Including the parts that should have stayed confidential.

I caught it during review. Every article was scrubbed clean within the hour. But the incident exposed a fundamental gap in AI-assisted content publishing: when AI can publish at machine speed, human review becomes the bottleneck – and bottlenecks get skipped.

So I built the client name guardrail. A systematic prevention layer that catches confidential references before they reach a publish command, no matter how fast the content is being produced.

The Protected Entity List

The foundation is a maintained list of every client, company, and entity name that must never appear in published content without explicit approval. The list currently contains 20+ entries covering all active clients across every business entity.

But names are not simple strings. People reference the same company in multiple ways. “The restoration client in Colorado” is fine. “a restoration company” is not. “Our luxury lending partner” is fine. “a luxury lending firm Company” is not. The entity list includes not just official company names but common abbreviations, nicknames, and partial references that could identify a client.

The Genericization Table

Simply blocking client names would break the content. If the AI cannot reference specific work, the articles become generic and lose the authenticity that makes them valuable. The solution is a genericization table – a mapping of specific references to anonymous equivalents that preserve the insight without revealing the identity.

“a cold storage facility” becomes “our cold storage client.” “a luxury lending firm” becomes “a luxury lending partner.” “a restoration company” becomes “a restoration company in the Mountain West.” Each mapping is specific enough to be useful but generic enough to protect confidentiality.

The AI applies these substitutions automatically during content generation. It still draws from real operational experience. It still provides specific, authentic examples. But the identifying details are replaced before the content is written, not after.

The Pre-Publish Scan

The final layer is a regex-based scan that runs against every piece of content before a publish API call is made. The scan checks the title, body content, excerpt, and slug against the full protected entity list. If any match is found, the publish is blocked and the specific matches are surfaced for review.

This scan catches edge cases the genericization table misses – a client name that slipped through in a quote, a URL that contains a company domain, or a reference the AI constructed from context rather than the entity list. The scan is the safety net that ensures nothing gets through even when the primary prevention layer fails.

Why This Matters Beyond My Situation

Every agency, consultancy, and service provider using AI for content creation faces this risk. AI models are trained to be helpful and specific. When given access to client context, they will use that context to produce better content. That is exactly what you want – until the specificity includes information your clients did not consent to having published.

The risk scales with capability. A basic AI tool that generates generic blog posts will never mention your clients because it does not know about them. An AI system deeply integrated with your operations – reading your Notion databases, processing your email, accessing your WordPress sites – knows everything about your client relationships. That integration is what makes it powerful. It is also what makes it dangerous without guardrails.

The pattern I built is transferable to any agency: maintain a protected entity list, build a genericization mapping, and scan before publishing. The implementation takes about 2 hours. The alternative – publishing client names and discovering it after the content is indexed by Google – takes much longer to fix and costs trust that cannot be rebuilt with a quick edit.

Frequently Asked Questions

Does the guardrail slow down content production?

Negligibly. The genericization happens during content generation, adding zero time to the process. The pre-publish scan takes under 2 seconds per article. In a 15-article batch, that is 30 seconds of total overhead.

What about client names in internal documents vs. published content?

The guardrail only activates on publish workflows. Internal documents, Notion entries, and operational notes use real client names because they are not public-facing. The skill triggers specifically when content is being sent to a WordPress REST API endpoint or any other publishing channel.

Can clients opt in to being named?

Yes. The protected entity list supports an override flag. If a client explicitly approves being referenced by name – for a case study, testimonial, or co-marketing piece – their entry can be temporarily unflagged. The default is always protected. Opt-in is explicit.

Has the guardrail caught anything since the initial incident?

Yes – three times in the first week. All were subtle references the AI constructed from context rather than direct mentions. One was a geographic description specific enough to identify a client’s location. The scan caught it. Without the guardrail, all three would have been published.

Speed Needs Guardrails

The ability to publish 15 articles in a single session is a superpower. But superpowers without controls are liabilities. The client name guardrail is not about slowing down. It is about publishing at machine speed with human-grade judgment on confidentiality. The AI produces the content. The guardrail produces the trust.

{
“@context”: “https://schema.org”,
“@type”: “Article”,
“headline”: “The Client Name Guardrail: What Happens When AI Publishes Too Fast for Human Review”,
“description”: “After publishing 12 articles that accidentally contained real client names, I built a guardrail system with a protected entity list, genericization table, and p”,
“datePublished”: “2026-03-21”,
“dateModified”: “2026-04-03”,
“author”: {
“@type”: “Person”,
“name”: “Will Tygart”,
“url”: “https://tygartmedia.com/about”
},
“publisher”: {
“@type”: “Organization”,
“name”: “Tygart Media”,
“url”: “https://tygartmedia.com”,
“logo”: {
“@type”: “ImageObject”,
“url”: “https://tygartmedia.com/wp-content/uploads/tygart-media-logo.png”
}
},
“mainEntityOfPage”: {
“@type”: “WebPage”,
“@id”: “https://tygartmedia.com/the-client-name-guardrail-what-happens-when-ai-publishes-too-fast-for-human-review/”
}
}

The Worst Way to Find Out Your Site Is Down

A client calls. Their site has been returning a 503 error for four hours. You check – they are right. The hosting provider had a blip, the site went down, and nobody noticed because nobody was watching. Four hours of lost traffic, lost leads, and lost trust.

This happened to me once. It never happened again, because I built SM-01.

SM-01 is the first agent in my autonomous fleet. It runs every 60 minutes via Windows Task Scheduler, checks 23 websites across my client portfolio, and reports to Slack only when it finds a problem. No dashboard to check. No email digest to read. Silence means everything is fine. A Slack message means something needs attention.

What SM-01 Checks

HTTP status: Is the site returning 200? A 503, 502, or 500 triggers an immediate red alert. A 301 or 302 redirect chain triggers a yellow alert – the site works but something changed.

Response time: How long does the homepage take to respond? Baseline is established over 30 days of monitoring. If response time exceeds 2x the baseline, a yellow alert fires. If it exceeds 5x, red alert. Slow sites lose rankings and visitors before they fully go down – response time degradation is an early warning.

SSL certificate expiration: SM-01 checks the SSL certificate expiry date on every pass. If a certificate expires within 14 days, yellow alert. Within 3 days, red alert. Expired, critical alert. An expired SSL certificate turns your site into a browser warning page and kills organic traffic instantly.

Content integrity: The agent checks for the presence of specific strings on each homepage – the site name, a key heading, or a footer element. If these strings disappear, it means the homepage content changed unexpectedly – possibly a defacement, a bad deploy, or a theme crash. This catches the subtle failures that return a 200 status code but serve broken content.

The Architecture Is Deliberately Boring

SM-01 is a Python script. It uses the requests library for HTTP checks, the ssl and socket libraries for certificate inspection, and a Slack webhook for alerts. No monitoring platform. No subscription. No agent framework. Under 250 lines of code.

The site list is a JSON file with 23 entries. Each entry has the URL, expected status code, content check string, and baseline response time. Adding a new site takes 30 seconds – add an entry to the JSON file.

Results are stored in a local SQLite database for trend analysis. I can query historical uptime, average response time, and alert frequency for any site over any time period. The database is 12MB after six months of hourly checks across 23 sites.

What Six Months of Data Revealed

Across 23 sites monitored hourly for six months, SM-01 recorded 99.7% average uptime. The 0.3% downtime was concentrated in three sites on shared hosting – every other site on dedicated or managed hosting had 99.99%+ uptime.

SSL certificate alerts saved two near-misses where auto-renewal failed silently. Without SM-01, those certificates would have expired and the sites would have shown browser security warnings until someone manually noticed and renewed.

Response time trending caught one hosting degradation issue three weeks before it became a visible problem. A site’s response time crept from 400ms baseline to 900ms over 10 days. SM-01 flagged it at the 800ms mark. Investigation revealed a database table that needed optimization. Fixed in 20 minutes, before any traffic impact.

Frequently Asked Questions

Why not use UptimeRobot or Pingdom?

I have. They work well for basic uptime monitoring. SM-01 adds content integrity checking, custom response time baselines per site, and integration with my existing Slack alert ecosystem. The biggest advantage is cost at scale – monitoring 23 sites on UptimeRobot Pro costs about /month. SM-01 costs nothing.

Does hourly checking miss short outages?

Yes – an outage lasting 30 minutes between checks would be missed. For critical production sites, you could reduce the interval to 5 minutes. I chose hourly because my sites are content sites, not e-commerce or SaaS platforms where minutes of downtime have direct revenue impact. The monitoring frequency should match the cost of missed downtime.

How do you handle false positives from network issues?

SM-01 requires two consecutive failed checks before alerting. A single timeout or error is logged but not reported. This eliminates the vast majority of false positives from transient network blips or temporary DNS issues. If both the hourly check and the immediate recheck 60 seconds later fail, the alert fires.

Monitoring Is Not Optional

Every website you manage is a promise to a client. That promise includes being available when their customers look for them. SM-01 is how I keep that promise without manually checking 23 URLs every day. It is the simplest agent in my fleet and arguably the most important.

{
“@context”: “https://schema.org”,
“@type”: “Article”,
“headline”: “SM-01: How One Agent Monitors 23 Websites Every Hour Without Me”,
“description”: “SM-01 pings 23 websites every hour, checks HTTP status, SSL expiration, response time, and content integrity – then posts to Slack only when.”,
“datePublished”: “2026-03-21”,
“dateModified”: “2026-04-03”,
“author”: {
“@type”: “Person”,
“name”: “Will Tygart”,
“url”: “https://tygartmedia.com/about”
},
“publisher”: {
“@type”: “Organization”,
“name”: “Tygart Media”,
“url”: “https://tygartmedia.com”,
“logo”: {
“@type”: “ImageObject”,
“url”: “https://tygartmedia.com/wp-content/uploads/tygart-media-logo.png”
}
},
“mainEntityOfPage”: {
“@type”: “WebPage”,
“@id”: “https://tygartmedia.com/sm-01-how-one-agent-monitors-23-websites-every-hour-without-me/”
}
}

The Morning Ritual That Replaced Checking 12 Apps

My old morning routine: open Slack, scan 8 channels. Open Notion, check the task board. Open Gmail, triage the inbox. Open Google Analytics for each client site. Open the WordPress dashboard for any site that published overnight. Check the GCP console for VM health. That is 45 minutes of context-gathering before I do anything productive.

NB-02 replaced all of it with a single Slack message that arrives at 6 AM every morning.

The Nightly Brief Generator is the second agent in my fleet. It runs at 5:45 AM via scheduled task, aggregates activity from the previous 24 hours across every system I operate, and produces a structured briefing that takes 3 minutes to read. By the time I finish my coffee, I know exactly what happened, what needs attention, and what I should work on first.

What the Nightly Brief Contains

Agent Activity Summary: Which agents ran, how many times, success/failure counts. If SM-01 flagged a site issue overnight, it shows here. If the VIP Email Monitor caught an urgent message at 2 AM, it shows here. If SD-06 detected ranking drift on a client site, it shows here. One section, all agent activity, color-coded by severity.

Content Published: Any articles published or scheduled across all 18 WordPress sites in the last 24 hours. Title, site, status, word count. This matters because automated publishing pipelines sometimes run overnight, and I need to know what went live without manually checking each site.

Tasks Created: New tasks in the Notion database, grouped by source. Tasks from MP-04 meeting processing, tasks from agent alerts, tasks manually created by me or team members. The brief shows the count and highlights any marked as urgent.

Overdue Items: Any task past its due date. This is the accountability section. It is uncomfortable by design. If something was due yesterday and is not done, it appears in bold in my morning brief. No hiding from missed deadlines.

Infrastructure Health: Quick status of the GCP VMs, the WP proxy, and any scheduled tasks. Green/yellow/red indicators. If everything is green, this section is one line. If something is yellow or red, it expands with diagnostic details.

How NB-02 Aggregates Data

The agent pulls from four sources via API:

Slack API: Reads messages posted to agent-specific channels in the last 24 hours. Counts alerts by type and severity. Extracts any unresolved red alerts that need morning attention.

Notion API: Queries the Tasks Database for items created or modified in the last 24 hours. Queries the Content Database for recently published entries. Checks for overdue tasks.

WordPress REST API: Quick status check on each managed site – is the REST API responding? Any posts published in the last 24 hours? This runs through the WP proxy and takes about 30 seconds for all 18 sites.

GCP Monitoring: Instance status for the knowledge cluster VM and any Cloud Run services. Uses the Compute Engine API to check instance state and basic health metrics.

The aggregation script runs in Python, collects data from all sources into a structured object, then formats it as a Slack message using Block Kit for clean formatting with sections, dividers, and color-coded indicators. Total runtime: under 2 minutes.

The Behavioral Impact

The nightly brief changed how I start every day. Instead of reactive context-gathering across multiple apps, I start with a complete picture and move directly into action. The first 45 minutes of my day shifted from information archaeology to execution.

More importantly, the brief gives me confidence in my systems. When six agents are running autonomously overnight, processing emails, monitoring sites, tracking rankings, and generating content, you need a single point of verification that everything worked. NB-02 is that verification. If the morning brief arrives and everything is green, I know with certainty that my operations ran correctly while I slept.

On the days when something is yellow or red, I know immediately and can address it before it impacts clients or deadlines. The alternative – discovering a problem at 2 PM when a client asks why their site is slow – is the scenario NB-02 was built to prevent.

Frequently Asked Questions

Can the nightly brief be customized per day of the week?

Yes. Monday briefs include a weekly summary rollup in addition to the overnight report. Friday briefs include a weekend preparation section flagging anything that might need attention over the weekend. The template is configurable per day.

What happens if NB-02 itself fails to run?

If the brief does not arrive by 6:15 AM, that absence is itself the alert. I have a simple phone alarm at 6:15 that I dismiss only after reading the brief. If the brief is not there, I know the scheduled task failed and check the system. The absence of expected output is a signal.

How long did it take to build?

The first version took about 4 hours – API connections, data aggregation, Slack formatting. I have iterated on the format about 10 times over three months based on what information I actually use versus what I skip. The current version is tight – everything in the brief earns its place.

Start Your Day With Certainty

The nightly brief is the simplest concept in my agent fleet and the one with the most immediate quality-of-life impact. It replaces anxiety with data, replaces app-hopping with a single read, and gives you the operational confidence to start building instead of checking. If you build one agent, build this one first.

{
“@context”: “https://schema.org”,
“@type”: “Article”,
“headline”: “NB-02: The Nightly Brief That Tells Me What Happened Across Seven Businesses While I Was Living My Life”,
“description”: “Every morning at 6 AM, NB-02 compiles what happened overnight across all my businesses – agent activity, content published, alerts fired, tasks.”,
“datePublished”: “2026-03-21”,
“dateModified”: “2026-04-03”,
“author”: {
“@type”: “Person”,
“name”: “Will Tygart”,
“url”: “https://tygartmedia.com/about”
},
“publisher”: {
“@type”: “Organization”,
“name”: “Tygart Media”,
“url”: “https://tygartmedia.com”,
“logo”: {
“@type”: “ImageObject”,
“url”: “https://tygartmedia.com/wp-content/uploads/tygart-media-logo.png”
}
},
“mainEntityOfPage”: {
“@type”: “WebPage”,
“@id”: “https://tygartmedia.com/nb-02-the-nightly-brief-that-tells-me-what-happened-across-seven-businesses-while-i-was-living-my-life/”
}
}