Tygart Media

Author: will_tygart

  • I Indexed 468 Files Into a Local Vector Database. Now My Laptop Answers Questions About My Business.

    The Problem With Having Too Many Files

    I have 468 files that define how my businesses operate. Skill files that tell AI how to connect to WordPress sites. Session transcripts from hundreds of Cowork conversations. Notion exports. API documentation. Configuration files. Project briefs. Meeting notes. Operational playbooks.

    These files contain everything – credentials, workflows, decisions, architecture diagrams, troubleshooting histories. The knowledge is comprehensive. The problem is retrieval. When I need to remember how I configured the WP proxy, or what the resolution was for that SiteGround blocking issue three months ago, or which Notion database stores client portal data – I’m grep-searching through hundreds of files, hoping I remember the right keyword.

    Grep works when you know exactly what you’re looking for. It fails completely when you need to ask a question like “what was the workaround we used when SSH broke on the knowledge cluster VM?” That’s a semantic query. It requires understanding, not string matching.

    So I built a local vector search system. Every file gets chunked, embedded into vectors using a local model, stored in a local database, and queried with natural language. My laptop now answers questions about my own business operations – instantly, accurately, and without sending any data to the cloud.

    The Architecture: Ollama + ChromaDB + Python

    The stack is deliberately minimal. Three components, all running locally, zero cloud dependencies.

    Ollama with nomic-embed-text handles the embedding. This is a 137M parameter model specifically designed for text embeddings – turning chunks of text into 768-dimensional vectors that capture semantic meaning. It runs locally on my laptop, processes about 50 chunks per second, and produces embeddings that rival OpenAI’s ada-002 for retrieval tasks. The entire model is 274MB on disk.

    ChromaDB is the vector database. It’s an open-source, embedded vector store that runs as a Python library – no server process, no Docker container, no infrastructure. Data is persisted to a local directory. The entire 468-file index, with all embeddings and metadata, takes up 180MB on disk. Queries return results in under 100 milliseconds.

    A Python script ties it together. The indexer walks through designated directories, reads each file, splits it into chunks of ~500 tokens with 50-token overlap, generates embeddings via Ollama, and stores them in ChromaDB with metadata (file path, chunk number, file type, last modified date). The query interface takes a natural language question, embeds it, searches for the 5 most similar chunks, and returns the relevant passages with source attribution.

    What Gets Indexed

    I index four categories of files:

    Skills (60+ files): Every SKILL.md file in my skills directory. These contain operational instructions for WordPress publishing, SEO optimization, content generation, site auditing, Notion logging, and more. When I ask “how do I connect to the a luxury asset lender WordPress site?” the system retrieves the exact credentials and connection method from the wp-site-registry skill.

    Session transcripts (200+ files): Exported transcripts from Cowork sessions. These contain the full history of decisions, troubleshooting, and solutions. When I ask “what was the fix for the WinError 206 issue?” it retrieves the exact conversation where we diagnosed and solved that problem – publish one article per PowerShell call, never combine multiple article bodies in a single command.

    Project documentation (100+ files): Architecture documents, API documentation, configuration files, and project briefs. Technical reference material that I wrote once and need to recall later.

    Notion exports (50+ files): Periodic exports of key Notion databases – the task board, client records, content calendars, and operational notes. This bridges the gap between Notion (where I plan) and local files (where I execute).

    How the Chunking Strategy Matters

    The most underrated part of building a RAG system is chunking – how you split documents into pieces before embedding them. Get this wrong and your retrieval is useless regardless of how good your embedding model is.

    I tested three approaches:

    Fixed-size chunks (500 tokens): Simple but crude. Splits mid-sentence, mid-paragraph, sometimes mid-code-block. Retrieval accuracy was around 65% on my test queries – too many chunks lacked enough context to be useful.

    Paragraph-based chunks: Split on double newlines. Better for prose documents but terrible for skill files and code, where a single paragraph might be 2,000 tokens (too large) or 10 tokens (too small). Retrieval accuracy improved to about 72%.

    Semantic chunking with overlap: Split at ~500 tokens but respect sentence boundaries, and include 50 tokens of overlap between consecutive chunks. This means the end of chunk N appears at the beginning of chunk N+1, providing continuity. Additionally, each chunk gets prepended with the document title and the nearest H2 heading for context. Retrieval accuracy jumped to 89%.

    The overlap and heading prepend were the critical improvements. Without overlap, answers that span two chunks get lost. Without heading context, a chunk about “connection method” could be about any of 18 sites – the heading tells the model which site it’s about.

    Real Queries I Run Daily

    This isn’t a science project. I use this system every day. Here are actual queries from the past week:

    “What are the credentials for the an events platform WordPress site?” – Returns the exact username (will@engagesimply.com), app password, and the note that an events platform uses an email as username, not “Will.” Found in the wp-site-registry skill file.

    “How does the 247RS GCP publisher work?” – Returns the service URL, auth header format, and the explanation that SiteGround blocks all direct and proxy calls, requiring the dedicated Cloud Run publisher. Pulled from both the 247rs-site-operations skill and a session transcript where we built it.

    “What was the disk space issue on the knowledge cluster VM?” – Returns the session transcript passage about SSH dying because the 20GB boot disk filled to 98%, the startup script workaround, and the IAP tunneling backup method we configured afterward.

    “Which sites use Flywheel hosting?” – Returns a list: a flooring company (a flooring company.com), a live comedy platform (a comedy streaming site), an events platform (an events platform.com). Cross-referenced across multiple skill files and assembled by the retrieval system.

    Each query takes under 2 seconds – embedding the question (~50ms), vector search (~80ms), and displaying results with source file paths. No API call. No internet required. No data leaves my machine.

    Why Local Beats Cloud for This Use Case

    Security is absolute. These files contain API credentials, client information, business strategies, and operational playbooks. Uploading them to a cloud embedding service – even a reputable one – introduces a data handling surface I don’t need. Local means the data never leaves the machine. Period.

    Speed is consistent. Cloud API calls for embeddings add 200-500ms of latency per query, plus they’re subject to rate limits and service availability. Local embedding via Ollama is 50ms every time. When I’m mid-session and need an answer fast, consistent sub-second response matters.

    Cost is zero. OpenAI charges .0001 per 1K tokens for ada-002 embeddings. That sounds cheap until you’re re-indexing 468 files (roughly 2M tokens) every week – .20 per re-index, /year. Trivial in isolation, but when every tool in my stack has a small recurring cost, they compound. Local eliminates the line item entirely.

    Availability is guaranteed. The system works on an airplane, in a coffee shop with no WiFi, during a cloud provider outage. My operational knowledge base is always accessible because it runs on the same machine I’m working on.

    Frequently Asked Questions

    Can this replace a full knowledge management system like Confluence or Notion?

    No – it complements them. Notion is where I create and organize information. The local vector system is where I retrieve it instantly. They serve different functions. Notion is the authoring environment; the vector database is the search layer. I export from Notion periodically and re-index to keep the retrieval system current.

    How often do you re-index the files?

    Weekly for a full re-index, which takes about 4 minutes for all 468 files. I also run incremental indexing – only re-embedding files modified since the last index – as part of my daily morning script. Incremental indexing typically processes 5-15 files and takes under 30 seconds.

    What hardware do you need to run this?

    Surprisingly modest. My Windows laptop has 16GB RAM and an Intel i7. The nomic-embed-text model uses about 600MB of RAM while running. ChromaDB adds another 200MB for the index. Total memory overhead: under 1GB. Any modern laptop from the last 3-4 years can handle this comfortably. No GPU required for embeddings – CPU performance is more than adequate.

    How does this compare to just using Ctrl+F or grep?

    Grep finds exact text matches. Vector search finds semantic matches. If I search for “SiteGround blocking” with grep, I find files that contain those exact words. If I search for “why can’t I connect to the a restoration company site” with vector search, I find the explanation about SiteGround’s WAF blocking API calls – even though the passage might not contain the words “connect” or “a restoration company site” explicitly. The difference is understanding context vs. matching strings.

    The Compound Effect

    Every file I create makes the system smarter. Every session transcript adds to the searchable history. Every skill I write becomes instantly retrievable. The vector database is a living index of accumulated operational knowledge – and it grows automatically as I work.

    Three months ago, the answer to “how did we solve X?” was “let me search through my files for 10 minutes.” Today, the answer takes 2 seconds. Multiply that time savings across 20-30 lookups per week, and the ROI is measured in hours reclaimed – hours that go back into building, not searching.

  • Content Swarm: How One Brief Becomes 15 Articles Across 5 Personas

    One Article Is a Missed Opportunity

    Here’s how most content marketing works: identify a keyword, write an article, publish it, move on. One keyword, one article, one audience. The entire content calendar is a list of keywords mapped to publication dates.

    This approach leaves enormous value on the table. Because the same topic matters to completely different people for completely different reasons, and a single article can only speak to one of them effectively.

    Take “water damage restoration cost.” A homeowner experiencing their first flood needs reassurance and a step-by-step guide. An insurance adjuster needs documentation requirements and estimate breakdowns. A property manager needs commercial-scale pricing and response time guarantees. A comparison shopper needs a “Company A vs. Company B” analysis. A prevention-focused homeowner needs “how to avoid water damage” content that links to restoration as a backup.

    One article cannot serve all five of these people. But one brief – one core research investment – can produce five articles that do. That’s what I call a content swarm.

    The Swarm Architecture

    A content swarm starts with a single content brief and produces multiple differentiated articles, each targeting a specific persona at a specific stage of the buyer’s journey. The architecture has four stages:

    Stage 1: Brief Creation. The content-brief-builder skill takes a target keyword, analyzes SERP competition, identifies search intent variations, and produces a structured brief with the core facts, statistics, and angles needed to write about the topic authoritatively. This brief is the shared knowledge foundation – researched once, used many times.

    Stage 2: Persona Detection. The persona-detection framework analyzes the brief and the target site’s existing content to identify which personas are underserved. For a restoration site, it might identify: first-time homeowner, insurance professional, property manager, emergency searcher, and prevention-focused homeowner. For a lending site: first-time a luxury asset lenderwer, high-net-worth client, bad-credit applicant, comparison shopper, and repeat a luxury asset lenderwer.

    Stage 3: Differentiation. This is where most content multiplication fails. Simply rewriting the same article five times with different introductions is not differentiation – it’s duplication. True differentiation requires changing the angle (what aspect of the topic this persona cares about), the depth (expert vs. beginner), the tone (urgent vs. educational vs. reassuring), the CTA (call now vs. learn more vs. compare options), and the structure (how-to guide vs. comparison vs. FAQ-heavy explainer).

    The adaptive-variant-pipeline handles this. It doesn’t produce a fixed number of variants. It analyzes the brief and determines how many genuinely distinct personas exist for this topic. Sometimes that’s 3. Sometimes it’s 7. The pipeline produces exactly as many variants as the topic demands – no more, no less.

    Stage 4: Publishing. Each variant gets full SEO/AEO/GEO treatment – optimized title, meta description, FAQ section, schema markup, internal links to existing site content, and proper taxonomy assignment. Then it’s published via the WordPress REST API through my proxy. One brief becomes a cluster of interlinked, persona-specific articles that collectively own the entire keyword space around that topic.

    Why Differentiation Is the Hard Part

    The Constancy Contract is the concept that makes this work. It’s a set of rules that governs what stays constant across all variants and what must change.

    Constant across all variants: Core facts, statistics, and technical accuracy. If the average water damage restoration cost is ,000-,000, every variant cites that range. No variant invents different numbers or contradicts another. The factual foundation is shared.

    Must change across variants: The opening hook, the angle of approach, the reading level, the CTA, the examples used, the section emphasis, and the FAQ questions. A variant for insurance adjusters opens with documentation requirements and uses industry terminology. A variant for first-time homeowners opens with “don’t panic” reassurance and uses plain language. Same topic, completely different experience.

    The differentiation mandate is enforced programmatically. Before a variant is finalized, it’s checked against all other variants in the swarm for similarity. If two variants share more than 30% of their sentence structures or phrasing, the second one gets rewritten. This prevents the lazy pattern of changing a few words and calling it a new article.

    The Math That Makes This Compelling

    Traditional content production: 1 keyword = 1 brief = 1 article. Cost: ~-400 for research and writing. Coverage: 1 persona, 1 search intent.

    Content swarm production: 1 keyword = 1 brief = 5 articles. Cost: ~-400 for the brief + -100 per variant (since the research is already done). Total: -900. Coverage: 5 personas, 5 search intents, 5 sets of long-tail keywords.

    The per-keyword cost roughly doubles. The coverage quintuples. The internal linking opportunities between variants create a topical cluster that signals authority to Google far more effectively than a single standalone article.

    Across a 12-month content campaign, the compound effect is massive. A traditional approach producing 4 articles per month gives you 48 articles covering 48 keywords. A swarm approach producing 1 brief per week with 5 variants gives you roughly 240 articles covering 48 core keywords but capturing hundreds of long-tail variations. Same research investment, 5x the content surface area.

    How This Works in Practice: A Real Example

    For a luxury lending client, the brief targeted “asset-based lending.” The swarm produced:

    Variant 1 – First-time a luxury asset lenderwer: “How Asset-Based Lending Works: A Complete Guide for First-Time a luxury asset lenderwers.” Plain language, step-by-step process, FAQ-heavy, CTA: “See if you qualify.”

    Variant 2 – High-net-worth client: “Asset-Based Lending for High-Value Collections: Fine Art, Jewelry, and Rare Assets.” Technical, detailed asset categories, valuation process, CTA: “Request a confidential appraisal.”

    Variant 3 – Comparison shopper: “Asset-Based Lending vs. Traditional Bank Loans: Which Is Right for Your Situation?” Side-by-side comparison, pros and cons, scenario-based recommendation, CTA: “Compare your options.”

    Variant 4 – Bad credit a luxury asset lenderwer: “Can You Get an Asset-Based Loan With Bad Credit? What Actually Matters.” Addresses the #1 objection directly, explains why credit score matters less in asset-based lending, CTA: “Your assets matter more than your score.”

    Variant 5 – Repeat a luxury asset lenderwer: “Returning a luxury asset lenderwers: How to Streamline Your Next Asset-Based Loan.” Shorter, more direct, assumes knowledge of the process, focuses on speed and convenience, CTA: “Start your repeat application.”

    Five articles, one research investment, five different people served, five different search intents captured, and all five internally linked to each other and to the main service page.

    Frequently Asked Questions

    Doesn’t publishing multiple articles on the same topic cause keyword cannibalization?

    Not if the variants are properly differentiated. Cannibalization happens when two pages target the same keyword with the same intent. In a content swarm, each variant targets different long-tail variations and different search intents. “Asset-based lending guide” and “asset-based lending with bad credit” are not competing – they’re complementary. Google is sophisticated enough to understand intent differentiation.

    How do you decide how many variants to produce?

    The adaptive pipeline decides based on how many genuinely distinct personas exist for the topic. A highly technical B2B topic might only support 2-3 meaningful variants. A consumer-facing topic with broad appeal might support 6-7. The rule is: if you can’t change the angle, tone, AND structure meaningfully, don’t create the variant. Quality over quantity.

    Can small businesses with one site use this approach?

    Absolutely – and arguably they benefit most. A small business competing against larger companies can’t outspend them on content volume. But they can out-target them by covering every persona in their niche while competitors publish one generic article per keyword. A local plumber with 5 persona-specific articles about “burst pipe repair” will outrank a national chain with one generic article, because the local plumber’s content matches more search intents.

    How long does the full swarm process take?

    Brief creation: 15-20 minutes. Persona detection: automated, under 2 minutes. Variant generation: 10-15 minutes per variant. Publishing with full optimization: 5 minutes per variant. Total for a 5-variant swarm: approximately 90 minutes from keyword to live content. Compare that to 3-4 hours for a single traditionally-produced article.

    The Future of Content Is Multiplied, Not Multiplied

    Content swarms aren’t about producing more content for the sake of volume. They’re about recognizing that every topic has multiple audiences, and each audience deserves content that speaks directly to their situation, language, and intent.

    The technology to do this at scale exists today. The frameworks are built. The workflows are proven. The only question is whether you continue writing one article per keyword and hoping it resonates with everyone, or whether you build the system that ensures every potential reader finds exactly the article they need.

  • MP-04: The Agent That Turns Every Meeting Into Action Items Before I Close the Tab

    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.

  • Plugins, Skills, and MCPs: The Three Layers That Make AI Actually Useful

    Prompts Are Not a Strategy

    The entire AI productivity discourse is stuck on prompts. Write better prompts. Use this template. Here is my secret prompt. It is the equivalent of teaching someone to type faster when what they need is a computer.

    Prompts are inputs. A command is worthless without an operating system to execute it, tools to interact with, and persistent memory to build on. The gap between AI as a chatbot and AI as a business tool is not better prompts. It is infrastructure.

    After 387+ Cowork sessions of AI-powered operations, I have identified three infrastructure layers that transform AI from fancy autocomplete into a genuine operational partner.

    Layer 1: MCP Servers – The Connections

    MCP stands for Model Context Protocol. An MCP server is a bridge between AI and an external system. It gives AI the ability to read from and write to tools outside its conversation window.

    Without MCP servers, AI only works with what you paste into chat. With them, AI can query Notion databases, read Gmail, check Google Calendar, interact with Figma, pull analytics, and manage local files.

    I run MCP connections to Notion, Gmail, Google Calendar, Metricool, Figma, and Windows MCP for PowerShell execution. Each server exposes tools the AI can take as actions. MCP servers are connection infrastructure, not intelligence. They make AI more capable, not smarter.

    Layer 2: Skills – The Knowledge

    If MCP servers are roads, skills are maps. A skill is a structured SKILL.md file that tells AI how to do something specific using available tools.

    Without skills, AI knows it can connect to WordPress but not your URL, credentials, content strategy, or publishing workflow. With skills, one sentence triggers a complete operation. I have 60+ skills covering WordPress connections, site auditing, SEO optimization, content generation, Notion operations, social media publishing, and more.

    Every hour spent writing skills saves 10+ hours of future session time.

    Layer 3: Plugins – The Packages

    Plugins bundle skills, MCP configurations, and tools into installable capability packages. A WordPress optimization plugin bundles 15+ skills with reference files and configurations.

    Plugins solve distribution. Building 60+ skills took months. A plugin lets someone install an entire workflow domain in minutes. The architecture enables composability – each plugin handles its domain and connects cleanly to others.

    How the Three Layers Work Together

    I say: Run the content intelligence audit on a luxury asset lender.com and generate 15 draft articles.

    Plugin layer: The wp-content-intelligence plugin activates with its audit and batch creator skills.

    Skill layer: The audit skill loads credentials from the site registry and understands the full methodology.

    MCP layer: Windows MCP executes PowerShell commands calling WordPress REST API through the proxy.

    Three layers, one sentence trigger. Remove any layer and the workflow breaks.

    The Maturity Model

    Level 1 – Prompts: Raw chat, no infrastructure. Where 95% of AI users are.

    Level 2 – MCP Connections: AI reads and writes to your systems. Dramatically more useful.

    Level 3 – Skills: Instruction files capture workflows and credentials. Operational AI begins.

    Level 4 – Plugins: Packaged capability bundles. Workflows become portable and composable.

    Level 5 – Autonomous Agents: Skills run on schedules without human triggers. AI becomes a colleague.

    Frequently Asked Questions

    Do I need to be a developer to build skills?

    No. Skills are markdown files. If you can write clear instructions for a task, you can write a skill. No code required.

    How do MCP servers handle authentication?

    Each has its own mechanism. Notion uses integration tokens. Gmail uses OAuth2. You authenticate once and the connection persists across sessions.

    Can skills call other skills?

    Yes. The wp-full-refresh skill calls wp-seo-refresh, wp-aeo-refresh, wp-geo-refresh, wp-schema-inject, and wp-interlink in sequence. Complex workflows from modular single-purpose skills.

    What is the difference between a skill and a prompt template?

    Scope and persistence. A prompt template is a text string. A skill is a persistent file with context, credentials, reference data, quality standards, and step-by-step procedures. The difference is between a recipe and a kitchen.

    Start Building Infrastructure, Not Prompts

    The next time you spend 10 minutes explaining context to AI, write a skill instead. The next time you manually copy data between platforms, set up an MCP connection. Prompts are disposable. Infrastructure compounds.

  • The Client Name Guardrail: What Happens When AI Publishes Too Fast for Human Review

    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.

  • I Reorganized My Entire Notion Workspace in One Session. Here Is the Architecture.

    The Workspace Was Collapsing Under Its Own Weight

    My Notion workspace had grown organically for two years. Pages nested inside pages nested inside pages. Duplicate databases. Orphaned notes. Three different task lists that each tracked a subset of the same tasks. A page hierarchy so deep that finding anything required knowing the exact path – or giving up and using search.

    The workspace worked when I ran two businesses. At seven businesses with 18 managed websites, it was actively slowing me down. Every search returned duplicates. Every new entry required deciding which of three databases to put it in. The structure that was supposed to organize my work was generating more overhead than the work itself.

    So I burned it down and rebuilt it. One Cowork session. New architecture from the ground up. Six core databases, three operational layers, and a design philosophy that scales to 20 businesses without adding structural complexity.

    The Three-Layer Architecture

    Layer 1: Master Databases. Six databases that hold every record across every business: Master Actions (tasks), Content Calendar, Master Entities (clients and businesses), Knowledge Lab, Contact Profiles, and Agent Registry. These are the canonical data stores. Every record lives in exactly one place.

    Layer 2: Autonomous Engine. The automation layer – triage agent configuration, air-gap sync agent rules, scheduled task definitions, and agent monitoring dashboards. This layer reads from and writes to the master databases but operates independently. It is where the AI agents interface with the workspace.

    Layer 3: Command Centers. Focus rooms for each business entity – Tygart Media, Engage Simply, a restoration company, a restoration company, Restoration Golf League, BCESG, and Personal. Each focus room contains filtered views of the master databases showing only records tagged with that entity. Plus client portals accessed from this layer.

    The key principle: data lives in Layer 1, automation lives in Layer 2, and humans interact through Layer 3. No layer duplicates another. Every view is a window into the same underlying data, filtered by context.

    The Entity Tag System

    Every record in every database has an Entity property – a relation to the Master Entities database. This single property is what makes the entire architecture work. When I create a task, I tag it with an entity. When content is published, it is tagged with an entity. When an agent logs activity, it is tagged with an entity.

    The entity tag enables three capabilities: filtered views per business (Layer 3 focus rooms show only their entity’s records), air-gapped client portals (sync only records matching the client’s entity), and cross-business reporting (roll up all entities for portfolio-level metrics).

    Before the reorg, switching between businesses meant navigating to different sections of the workspace. After the reorg, switching is a single click – each focus room is a filtered lens on the same unified data.

    The Triage Agent

    New records entering the system need to be classified. The Triage Agent is a Notion automation that watches for new entries in Master Actions and auto-assigns entity, priority, and status based on content analysis. A task mentioning “golf” or “restoration golf” gets tagged to Restoration Golf League. A task referencing “engage” gets tagged to Engage Simply.

    The triage agent handles approximately 70% of record classification automatically. The remaining 30% are ambiguous entries that get flagged for manual entity assignment. This means most of my task creation workflow is: describe the task in one sentence, let the triage agent classify it, and move on.

    What the Reorg Eliminated

    Duplicate databases: from 14 to 6. Orphaned pages: 40+ archived or deleted. Average depth of page hierarchy: from 7 levels to 3. Time to find a specific record: from 2-3 minutes of searching to under 10 seconds via entity-filtered views. Weekly overhead maintaining the workspace: from approximately 3 hours to under 30 minutes.

    The reorg also eliminated the psychological overhead of a messy system. When your workspace is disorganized, every interaction carries a tiny cognitive tax – “where does this go? Did I already capture this somewhere else? Is this the current version?” Multiply that by hundreds of daily interactions and the cumulative drain is significant. A clean architecture removes the tax entirely.

    Frequently Asked Questions

    How long did the full reorganization take?

    One extended Cowork session, approximately 4 hours of active work. This included architecting the new structure, creating the six databases with proper schemas, migrating critical records from old databases, configuring the triage agent, setting up entity tags, and creating the Layer 3 focus rooms. The archive of old pages was done in a separate cleanup pass.

    Can this architecture work for a single business?

    Yes – and it is simpler. A single business needs the same six databases but without the entity tag complexity. The three-layer architecture still applies: data in master databases, automation in the engine layer, and human interaction through focused views. The architecture is the same regardless of scale.

    What tool did you use for the migration?

    Notion’s native relation properties and the Notion API via Cowork mode. The API allowed bulk operations – creating database entries, updating properties, moving pages – that would have taken days to do manually through the UI. The Cowork session treated the reorg as a technical migration, not a manual reorganization.

    Architecture Is Strategy

    Most people treat their workspace as a filing cabinet – a place to put things so they can find them later. That model breaks at scale. A workspace that manages seven businesses needs to be an operating system, not a filing cabinet. The three-layer architecture, entity tagging, and autonomous triage agent transform Notion from a note-taking app into a business operating system that scales horizontally without adding complexity. The architecture is the strategy. Everything else is just typing.

  • The Monday Status Report: How a Weekly Operating Rhythm Keeps a Multi-Business Portfolio on Track

    Monday Morning Is Not for Email

    Every Monday morning at 7 AM, before I open email, before I check Slack, before I look at a single notification, I read one document: the Weekly Executive Briefing. It is a synthesized status report that covers every business in the portfolio, every active project, every metric that matters, and every decision that needs my attention that week.

    I do not write this report. An AI agent writes it. It pulls data from Notion, cross-references project statuses, flags overdue tasks, summarizes completed work from the previous week, and identifies the three to five decisions that will have the most impact in the coming seven days.

    This single document replaced six separate status meetings, four different dashboards, and approximately ten hours per week of context-gathering that I used to do manually.

    What the Briefing Contains

    The briefing follows a rigid structure. First section: portfolio health. A one-line status for each business entity – green, yellow, or red – with a two-sentence explanation of why. If a restoration company had a record week in leads, that shows up as green with the number. If a client site had a technical issue, that shows up as yellow with the remediation status.

    Second section: completed work. Every task that was marked done in Notion during the previous week, grouped by business and project. This is not a vanity list. It is an accountability record. I can see exactly what the AI agents accomplished, what I accomplished, and what fell through the cracks.

    Third section: priority decisions. These are the items that require my judgment – not my labor. Should we publish the next content batch for this client? Should we escalate this technical issue? Should we accept this new project? The briefing presents the context and options. I make the call.

    Fourth section: metrics. Revenue, traffic, content output, optimization scores, and any anomalies in the data. The agent highlights anything that deviated more than 15 percent from the trailing four-week average in either direction.

    Why Structure Beats Hustle

    I spent years running businesses on adrenaline and reactive energy. Something would break, I would fix it. A client would call, I would drop everything. An opportunity would appear, I would chase it without evaluating whether it fit the strategy.

    The Monday briefing killed that pattern. When you start every week with a clear picture of where everything stands, you stop reacting and start deciding. The difference is enormous. Reactive operators work harder and accomplish less. Structured operators work fewer hours and accomplish more because every action is aligned with the highest-leverage opportunity.

    The Notion Architecture Behind It

    The briefing is powered by a six-database Notion architecture that tracks projects, tasks, contacts, content, metrics, and decisions across all seven business entities. Every database uses consistent properties – status, priority, entity tag, due date, owner – so the AI agent can query across the entire system with uniform logic.

    The agent runs a series of database queries every Sunday night. It pulls incomplete tasks, recently completed tasks, upcoming deadlines, and flagged items. It then synthesizes these into the briefing format and drops it into a dedicated Notion page that I read Monday morning.

    The key insight is that the Notion architecture was designed for machine readability from the start. Most people build Notion workspaces for human consumption – pretty pages, nested toggles, visual dashboards. I built mine for agent consumption. Clean properties, consistent naming, no nested complexity. The visual layer is secondary to the data layer.

    The Decision Log

    Every decision I make from the Monday briefing gets logged. Not in a meeting note. Not in an email. In a dedicated decision database with the date, the context, the options considered, and the rationale. Six months later, when I want to understand why we took a particular direction, the answer is there.

    This is institutional memory that does not depend on my memory. The AI agent can reference past decisions when generating future briefings. If I decided three months ago to pause content production on a particular site, the agent knows that and factors it into current recommendations.

    Replicating the Rhythm

    The Monday briefing is not a product. It is a pattern. Any operator managing multiple projects, businesses, or teams can build a version of this with Notion and an AI agent. The requirements are simple: structured data, consistent properties, and a synthesis prompt that knows how to prioritize.

    The hard part is not the technology. It is the discipline to read the briefing every Monday and actually make the decisions it surfaces. Most people would rather stay busy than be strategic. The briefing forces strategy by putting the right information in front of you at the right time.

    FAQ

    How long does it take to read the Monday briefing?
    Fifteen to twenty minutes. It is designed to be comprehensive but scannable. The priority decisions section is usually three to five items.

    What happens when the briefing flags something urgent?
    Urgent items get a red flag and move to the top of the priority decisions section. I address those first, before anything else that week.

    Can this work for a single business?
    Yes. The structure scales down. Even a single-business operator benefits from a weekly synthesis that separates signal from noise.

  • Why We Stopped Hiring Writers and Built a Content Engine

    The Freelance Writer Problem at Scale

    When you manage content for 23 WordPress sites across industries as different as luxury lending, property restoration, cold storage logistics, and live comedy – freelance writers become a bottleneck, not a solution. Finding writers who understand even one of these niches is hard. Finding writers who can produce at the volume and quality you need across all of them is nearly impossible.

    We tried the traditional approach for two years. Content agencies, freelance marketplaces, subject matter experts hired per-article. The results were inconsistent: brilliant pieces mixed with generic filler, missed deadlines, and constant back-and-forth on revisions that often took longer than writing from scratch.

    The math was simple. At an average cost of $250 per article and a need for 50+ articles per month across all sites, we were looking at $12,500/month in content production alone – before editing, optimization, and publishing costs.

    What a Content Engine Actually Looks Like

    A content engine isn’t just using AI to write articles. That’s the lazy version, and it produces lazy content. A real content engine is an end-to-end system that handles ideation, research, drafting, optimization, publishing, and performance tracking with minimal human intervention for routine content.

    Our engine runs on four layers. The Intelligence Layer analyzes each site’s existing content, identifies gaps, and generates prioritized topic lists using DataForSEO keyword data and our own gap analysis framework. The Generation Layer produces articles using Claude with site-specific voice profiles, SEO targets, and persona specifications. The Optimization Layer applies our SEO/AEO/GEO stack to every piece before it touches WordPress. The Publishing Layer pushes content through our WordPress REST API proxy with proper taxonomy, schema markup, and internal linking.

    A human reviews every article before it goes live. The engine handles everything else.

    The Quality Difference Nobody Expects

    Here’s the counterintuitive finding: our AI-generated content consistently outperforms the freelance content it replaced – not because AI writes better prose, but because the engine enforces consistency that humans can’t maintain at scale.

    Every article gets the same SEO treatment. Every article follows the same structural template optimized for featured snippets. Every article includes FAQ sections with proper schema markup. Every article gets internal links to related content on the same site. No freelancer, no matter how talented, maintains that level of consistency across 50 articles per month.

    Cost Comparison: Engine vs. Freelance

    Our content engine produces 50-75 optimized articles per month across all sites. The marginal cost per article is under $5 in API calls, compared to $200-400 per article from quality freelancers. Even accounting for the development investment in building the engine, the ROI turned positive in month two.

    But cost isn’t the real win. Speed is. The engine can produce a fully optimized, publish-ready article in under 10 minutes. A freelance workflow – brief, draft, review, revision, optimization, publishing – takes 5-10 business days. When Google rolls out an algorithm update and you need to refresh 30 articles this week, the engine makes it possible.

    Frequently Asked Questions

    Does AI-generated content rank as well as human-written content?

    In our experience, yes – and often better. Google’s helpful content guidelines care about quality, accuracy, and user value, not who or what produced the content. Our engine produces content that meets all those criteria because the optimization is systematic, not ad hoc.

    Don’t you lose the human voice and personality?

    We use site-specific voice profiles that capture the tone, vocabulary, and perspective of each brand. The human review step ensures personality comes through.

    What about industries that require deep expertise?

    AI models trained on broad datasets have surprisingly deep knowledge of most industries. For highly technical content, we supplement with proprietary knowledge bases and subject matter expert review. The engine drafts; the expert validates.

    How do you handle content that needs original research?

    The engine handles informational, educational, and commercial content. Original research pieces and interview-based articles still involve humans. The engine frees up time for these high-value pieces by handling the volume content.

    The Future Is Hybrid

    We haven’t eliminated human involvement in content – we’ve elevated it. Humans now focus on strategy, quality control, and the creative work that actually requires human judgment. The engine handles the production work that was always more about process than creativity.

  • The Death of the Marketing Retainer: How AI Changes Everything

    The Retainer Model Is Cracking

    For two decades, the marketing agency business model has been simple: charge clients a monthly retainer, deliver a package of services, and scale revenue by stacking more retainers. It worked because marketing execution required human hours, and human hours have a predictable cost.

    AI breaks that equation. When a task that took a junior strategist four hours can be completed in four minutes by an AI agent, the hourly-rate math that underpins retainer pricing collapses. Clients are starting to notice – and they’re asking hard questions about what they’re actually paying for.

    What AI Actually Automates in a Marketing Agency

    Let’s be specific about what’s changing. These are the tasks that AI can now handle at production quality:

    Content production: First drafts, SEO optimization, meta descriptions, FAQ sections, and schema markup. What used to take a writer plus an SEO specialist a full day now runs through our pipeline in minutes.

    SEO audits: Site-wide technical audits, content gap analysis, keyword research, and competitor analysis. Our AI stack produces audit reports that match or exceed what junior analysts deliver – with better consistency.

    Reporting: Monthly performance reports with data visualization, trend analysis, and strategic recommendations. AI pulls the data, formats the report, and drafts the narrative.

    Social media management: Post drafting, scheduling, hashtag research, and engagement analysis. The creative strategy remains human; the execution is increasingly automated.

    That’s roughly 60-70% of what a typical marketing retainer covers.

    Three Models That Replace the Traditional Retainer

    The Performance Model: Instead of paying for hours, clients pay for outcomes. Rankings achieved, traffic milestones hit, leads generated. AI makes this viable because agencies can deliver outcomes at lower internal cost while sharing the upside.

    The Fractional Model: Senior strategists embedded part-time across multiple clients, supported by AI for execution. Clients get expert-level thinking without paying for execution labor that AI handles. This is how Tygart Media operates – fractional CMO services powered by an AI operations layer.

    The Platform Model: Agencies build proprietary tools and offer them as managed services. The tool does the work; the agency provides expertise to configure, monitor, and optimize.

    Why This Is Good for Agencies (Not Just Clients)

    The knee-jerk reaction from agency owners is fear. The reality is the opposite – AI destroys the ceiling on agency margins. When your cost to deliver drops by 60%, you can maintain prices while delivering dramatically better results.

    Agencies that embrace AI as an operational layer will serve more clients, deliver better outcomes, and earn higher per-client profit. Agencies that ignore it will be undercut by competitors who adopted AI two years ago.

    The window for competitive advantage is narrow. By 2027, AI-assisted marketing execution will be table stakes, not a differentiator.

    Frequently Asked Questions

    Will AI eliminate the need for marketing agencies entirely?

    No. AI eliminates the need for agencies that only provide execution. Strategy, creative direction, brand positioning, and client relationship management require human judgment. The agencies that survive will be smaller, more strategic, and more profitable.

    How should agencies price their services in an AI world?

    Move away from hourly billing toward value-based or outcome-based pricing. Your cost to deliver has dropped, but the value to the client hasn’t. Price for the outcome.

    What skills should agency employees develop to stay relevant?

    Strategic thinking, client communication, AI prompt engineering, and data interpretation. The ability to direct AI systems effectively is becoming the most valuable skill in marketing.

    When will most agencies adopt AI operationally?

    By mid-2026, the majority of agencies with 10+ employees will use AI for content production. Full operational AI will take another 12-18 months to become mainstream. Early movers have a significant head start.

    Adapt or Become the Case Study

    The marketing retainer isn’t dead yet, but it’s on life support. The agencies that thrive will be the ones that treated AI not as a threat but as the foundation for a better model.

  • We Manage 23 WordPress Sites. Here’s the Exact Stack.

    The Scale Problem Nobody Talks About

    Managing one WordPress site is straightforward. Managing five gets complicated. Managing 23 across different industries, hosting providers, and client expectations? That’s an engineering problem disguised as a marketing job.

    Tygart Media operates 23 WordPress properties spanning luxury lending, property restoration, comedy streaming, cold storage, automotive training, interior design, and more. Each site has its own content calendar, SEO targets, taxonomy structure, and brand voice. Without automation, this operation would require a team of 8-10 people. We run it with three.

    The WordPress REST API Proxy

    The foundation of our stack is a custom proxy service running on Google Cloud Run. Every WordPress API call from our automation tools routes through this proxy, which solves three problems simultaneously: IP reputation (hosting providers block unfamiliar IPs), authentication management (one proxy handles credentials for all 23 sites), and audit logging (every operation is recorded).

    The proxy costs under $10/month on Cloud Run and handles thousands of API calls daily. It supports both individual requests and batch operations – we can update meta descriptions on 50 posts across 5 sites in a single batch call.

    The Skill Library: 30+ WordPress Operations

    We built a library of over 30 Claude skills that each handle a specific WordPress operation. wp-seo-refresh optimizes on-page SEO. wp-schema-inject adds structured data markup. wp-interlink builds internal link graphs. wp-aeo-refresh optimizes for answer engines. wp-geo-refresh optimizes for generative AI citations.

    Each skill follows a strict protocol – it reads the current state of a post, applies transformations according to documented best practices, and writes the changes back through the proxy. Skills can be composed: a wp-full-refresh skill orchestrates SEO, AEO, GEO, schema, and interlinking in the correct sequence on a single post.

    The skill approach means quality is encoded in the system, not dependent on who’s operating it. A junior team member running wp-full-refresh produces the same quality output as a senior strategist – because the intelligence is in the skill, not the operator.

    Content Intelligence and Gap Analysis

    Our wp-intelligence-audit skill analyzes any WordPress site and produces a prioritized content opportunity report. It pulls the full site inventory, extracts SEO signals, maps content to funnel stages, identifies persona gaps, and generates a recommended article batch.

    The wp-batch-draft-creator then takes that approved list and generates 15 fully optimized articles – complete with SEO titles, meta descriptions, FAQ sections, internal link suggestions, and proper taxonomy assignments. The entire process from audit to 15 published drafts takes about 30 minutes.

    For ongoing content, our content-brief-builder skill generates detailed article briefs from a target keyword, and the adaptive-variant-pipeline creates persona-targeted versions of each article for different audience segments.

    Monitoring and Maintenance

    Automation doesn’t mean set-it-and-forget-it. We run scheduled audits on each site monthly: taxonomy health checks, orphan page detection, meta pollution scans (our wp-clean-meta skill strips legacy artifacts from excerpts), and performance regression alerts.

    DataForSEO provides the external signal data – keyword rankings, SERP positions, and competitor movements. SpyFu fills in the competitive intelligence layer. Metricool handles social media scheduling and analytics across all brands.

    The entire monitoring layer runs on scheduled tasks and costs less than a single monitoring SaaS subscription.

    Frequently Asked Questions

    Does this stack work with any WordPress hosting provider?

    Yes. The proxy layer abstracts away hosting differences. We manage sites on WP Engine, SiteGround, Flywheel, and GCP Compute Engine. The proxy handles authentication and IP reputation for all of them.

    How long does it take to onboard a new WordPress site?

    About 20 minutes. Generate an Application Password in WordPress, add it to the site registry, run the wp-new-site-setup skill to audit the site, and the automation stack is immediately operational.

    What happens if the proxy goes down?

    Cloud Run has a 99.95% uptime SLA. In 6+ months of operation, we’ve had zero unplanned downtime. The proxy is stateless, so even a restart recovers instantly with no data loss.

    Can a non-technical person use this stack?

    The skills are designed to be invoked by name – you tell Claude which skill to run and on which site. You don’t need to understand the underlying API calls. Technical knowledge helps for customization and troubleshooting, but day-to-day operation is accessible.

    The Compound Effect

    Each individual automation saves 15-30 minutes. Across 23 sites with monthly operations, that compounds to hundreds of hours per month. But the real value isn’t time saved – it’s consistency achieved. Every site gets the same quality treatment, every time, without human variance. That’s the actual competitive advantage.