Category: Agency Playbook

How we build, scale, and run a digital marketing agency. Behind the scenes, systems, processes.

  • Why We Run Content Intelligence Audits Before Writing a Single Word

    Why We Run Content Intelligence Audits Before Writing a Single Word

    The Machine Room · Under the Hood

    Before we write a single article for a client, we run a Content Intelligence Audit. This audit tells us what content already exists, where the gaps are, what our competitors are publishing, and exactly what we should write to fill those gaps profitably. It saves us from writing content nobody searches for.

    The Audit Process
    A Content Intelligence Audit has four layers:

    Layer 1: Existing Content Scan
    We scrape all existing content on the client’s site and categorize it by:
    – Topic cluster (what main themes do they cover?)
    – Keyword coverage (which keywords are they actually targeting?)
    – Content depth (how comprehensive is each topic?)
    – Publishing frequency (how often do they update?)
    – Performance data (which articles get traffic, which don’t?)

    This tells us their current state. A restoration company might have strong content on “water damage” but zero content on “mold remediation.”

    Layer 2: Competitor Content Analysis
    We analyze the top 10 ranking competitors:
    – What topics do they cover that the client doesn’t?
    – What content formats do they use? (Blog posts, guides, videos, FAQs)
    – How frequently are they publishing?
    – What keywords are they targeting?
    – How comprehensive is their coverage vs. the client’s?

    This reveals competitive gaps. If all top 10 competitors have “mold remediation” content and the client doesn’t, that’s a priority gap.

    Layer 3: Search Demand Analysis
    Using DataForSEO and Google Search Console, we identify:
    – What keywords have real search volume?
    – Which searches are the client currently missing? (queries that bring competitors traffic but not the client)
    – What’s the intent behind each search?
    – What content format ranks best?
    – Is there seasonality (winter water damage peak, summer mold peak)?

    This separates “topics competitors cover” from “topics people actually search for.”

    Layer 4: Strategic Recommendations
    We synthesize layers 1-3 into a content roadmap:

    – Highest priority: High-search-volume keywords with low client coverage and proven competitor presence (low hanging fruit)
    – Secondary: Emerging keywords with lower volume but high intent
    – Tertiary: Brand-building content (lower search volume but high authority signals)
    – Avoid: Topics with zero search volume (regardless of how cool they are)

    The Roadmap Output
    The audit produces a prioritized content calendar with 40-50 articles ranked by:

    1. Search volume
    2. Competitive difficulty (can we actually rank?)
    3. Commercial intent (will this drive revenue?)
    4. Client expertise (can they credibly speak to this?)
    5. Timeline (what should we write first to establish topical authority?)

    This prevents the common mistake: writing articles the client wants to write instead of articles people want to read.

    What This Prevents
    – Writing 50 articles about topics nobody searches for
    – Building authority in the wrong verticals
    – Publishing content that’s weaker than competitors (wasting effort)
    – Missing obvious opportunities that competitors exploit
    – Publishing on wrong cadence (could be faster/slower)

    The ROI
    Audits cost $2K-5K depending on vertical and complexity. They typically prevent $50K+ in wasted content spend.

    Without an audit, a content strategy might spend 12 months publishing 60 articles and only 30% rank. With an audit-driven strategy, maybe 70% rank because we’re writing what people actually search for.

    Real Example
    We audited a restoration client and found:
    – They had 20 articles on general water damage
    – Competitors had heavy coverage of specific restoration techniques (hardwood floors, drywall, carpet)
    – Search volume for specific techniques was 3x higher than general water damage
    – Their content was general; competitor content was specific

    The recommendation: Shift 60% of content to technique-specific guides. That changed their content strategy entirely, and within 6 months, their organic traffic tripled because they were finally writing what people searched for.

    When To Run An Audit
    – Before launching a new content strategy (required)
    – Before hiring a content team (understand the gap first)
    – When organic traffic plateaus (often a content strategy problem)
    – When competitors are outranking you significantly (they’re probably writing smarter content)

    The Competitive Advantage
    Most content teams skip audits and jump straight to writing. That’s why most content strategies underperform. The 5 hours spent on a Content Intelligence Audit prevents 200 wasted hours of content creation.

    If you’re building a content strategy, audit first. Know the landscape before you publish.

    {
    “@context”: “https://schema.org”,
    “@type”: “Article”,
    “headline”: “Why We Run Content Intelligence Audits Before Writing a Single Word”,
    “description”: “Before writing any article, we run a Content Intelligence Audit that maps existing content, competitor gaps, and search demand. It prevents months of wasted eff”,
    “datePublished”: “2026-03-30”,
    “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/why-we-run-content-intelligence-audits-before-writing-a-single-word/”
    }
    }

  • Service Account Keys, Vertex AI, and the GCP Fortress

    Service Account Keys, Vertex AI, and the GCP Fortress

    The Machine Room · Under the Hood

    For regulated verticals (HIPAA, financial services, legal), we build isolated AI infrastructure on Google Cloud using service accounts, VPCs, and restricted APIs. This gives us Vertex AI and Claude capabilities without compromising data isolation or compliance requirements.

    The Compliance Problem
    Some clients operate in verticals where data can’t flow through public APIs. A healthcare client can’t send patient information to Claude’s public API. A financial services client can’t route transaction data through external language models.

    But they still want AI capabilities: document analysis, content generation, data extraction, automation.

    The solution: isolated GCP infrastructure that clients own, that uses service accounts with restricted permissions, and that keeps data inside their VPC.

    The Architecture
    For each regulated client, we build:

    1. Isolated GCP Project
    Their own Google Cloud project, separate billing, separate service accounts, zero shared infrastructure with other clients.

    2. Service Account with Minimal Permissions
    A service account that can only:
    – Call Vertex AI APIs (nothing else)
    – Write to their specific Cloud Storage bucket
    – Log to their Cloud Logging instance
    – No ability to access other projects, no IAM changes, no network modifications

    3. Private VPC
    All Vertex AI calls happen inside their VPC. Data never leaves Google’s network to hit public internet.

    4. Vertex AI for Regulated Workloads
    We use Vertex AI’s enterprise models (Claude, Gemini) instead of the public APIs. These are deployed to their VPC and their service account. Zero external API calls for language model inference.

    The Data Flow
    Example: A healthcare client wants to analyze patient documents.
    – Client uploads PDF to their Cloud Storage bucket
    – Cloud Function (with restricted service account) triggers
    – Function reads the PDF
    – Function sends to Vertex AI Claude endpoint (inside their VPC)
    – Claude extracts structured data from the document
    – Function writes results back to client’s bucket
    – Everything stays inside the VPC, inside the project, inside the isolation boundary

    The client can audit every API call, every service account action, every network flow. Full compliance visibility.

    Why This Matters for Compliance
    HIPAA: Patient data never leaves the healthcare client’s infrastructure
    PCI-DSS: Payment data stays inside their isolated environment
    GDPR: EU data can be processed in their EU GCP region
    FedRAMP: For government clients, we can build on GCP’s FedRAMP-certified infrastructure

    The Service Account Model
    Service accounts are the key to this. Instead of giving Claude/Vertex AI direct access to client data, we create a bot account that:

    1. Has zero standing permissions
    2. Can only access specific resources (their bucket, their dataset)
    3. Can only run specific operations (Vertex AI API calls)
    4. Permissions are short-lived (can be revoked immediately)
    5. Every action is logged with the service account ID

    So even if Vertex AI were compromised, it couldn’t access other clients’ data. Even if the service account was compromised, it couldn’t do anything except Vertex AI calls on that specific bucket.

    The Cost Trade-off
    – Shared GCP account: ~$300/month for Claude/Vertex AI usage
    – Isolated GCP project per client: ~$400-600/month per client (slightly higher due to overhead)

    That premium ($100-300/month per client) is the cost of compliance. Most regulated clients are willing to pay it.

    What This Enables
    – Healthcare clients can use Claude for chart analysis, clinical note generation, patient data extraction
    – Financial clients can use Claude for document analysis, regulatory reporting, trade summarization
    – Legal clients can use Claude for contract analysis, case law research, document review
    – All without violating data residency, compliance, or isolation requirements

    The Enterprise Advantage
    This is where AI agencies diverge from freelancers. Most freelancers can’t build compliant AI infrastructure. You need GCP expertise, service account management knowledge, and regulatory understanding.

    But regulated verticals are where the money is. A healthcare data extraction project can be worth $50K+. A financial compliance project can be $100K+. The infrastructure investment pays for itself on the first client.

    If you’re only doing public API integrations, you’re leaving regulated verticals entirely on the table. Build the fortress. The clients are waiting.

    {
    “@context”: “https://schema.org”,
    “@type”: “Article”,
    “headline”: “Service Account Keys, Vertex AI, and the GCP Fortress”,
    “description”: “For regulated verticals, we build isolated GCP projects with service accounts and restricted Vertex AI access. Here’s the compliance architecture for heal”,
    “datePublished”: “2026-03-30”,
    “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/service-account-keys-vertex-ai-and-the-gcp-fortress/”
    }
    }

  • The Metricool Pipeline: WordPress to Social in One API Call

    The Metricool Pipeline: WordPress to Social in One API Call

    The Machine Room · Under the Hood

    Every article we publish goes to social media in 5+ platform-specific variations within 30 seconds of going live. We do this with a single Metricool API call that pulls the article, generates platform-optimized posts, and distributes them. Zero manual work per publication.

    The Problem We Solved
    Publishing an article was only step 1. You then needed to:
    – Write a Twitter/X version (280 characters, hook-first)
    – Write a LinkedIn version (professional, value-forward)
    – Write a Facebook post (longer context, emoji)
    – Write an Instagram caption (visual-first, hashtag-heavy)
    – Write a TikTok script (video-format thinking)
    – Schedule them for optimal times
    – Track which platforms perform best

    This was a 2-3 hour task per article. With 60 articles per month, that’s 120+ hours of manual social work.

    The Metricool Stack
    Metricool is a social media management API. We built an automation layer that:
    1. Watches WordPress for new posts
    2. Pulls the article content and featured image
    3. Sends to Claude with platform-specific prompts
    4. Claude generates optimized posts for each platform
    5. Posts via Metricool API to all platforms simultaneously
    6. Tracks engagement and optimizes posting time

    The Platform-Specific Generation
    Each platform has different rules and audiences:

    Twitter/X: Hook first, link second, 240 characters max
    “We eliminated SEO tool costs. Here’s the DataForSEO + Claude stack we’re using instead.” + link

    LinkedIn: Professional context, value proposition, longer format
    “After spending $600/month on SEO tools, we replaced them with DataForSEO API + Claude analysis. Here’s how the keyword research workflow changed…” + link

    Facebook: Community feel, multiple paragraphs, emojis accepted
    “Just published our full breakdown of how we replaced $600/month in SEO tools with a smarter, cheaper stack. If you’re managing multiple sites, you need to see this.” + link

    Instagram caption: Visual storytelling, hashtags, character limit consideration
    “$600/month in SEO tools just became $30/month in API costs + smarter analysis. The future of marketing is API-first intelligence. Link in bio for the full breakdown. #MarketingAutomation #SEO #ArtificialIntelligence”

    TikTok script: Entertainment-first, trending sounds, visual hooks
    “CapTok: I spent $600/month on SEO tools. Then I discovered I could use one API + Claude for better results. Here’s the stack…”

    The Implementation
    We use a Cloud Function that triggers on WordPress post publication:

    1. Function receives post data (title, content, featured image)
    2. Calls Claude with a prompt like: “Generate 5 platform-specific social posts for this article about DataForSEO”
    3. Claude returns JSON with posts for X, LinkedIn, Facebook, Instagram, TikTok
    4. Function calls Metricool API to post each one
    5. Function logs posting times and platform assignments

    The entire process takes 5-10 seconds. No human involvement.

    Optimization and Iteration
    Metricool tracks engagement for each post. We feed this back to the system:

    – Which posts got highest click-through rate?
    – Which platforms drive the most traffic back to WordPress?
    – What time of day gets best engagement?
    – What length/style performs best per platform?

    Claude learns from this data. Over time, the generated posts get smarter—longer on platforms that reward depth, shorter on platforms that favor speed, more hooks on platforms that compete for attention.

    The Results
    – Social posts publish within 30 seconds of article publication (vs. 2-3 hours manual)
    – Each platform gets optimized content (vs. repurposing the same post)
    – Engagement is 40% higher because posts are natively optimized
    – We track which content resonates across platforms
    – We’ve cut social media labor down to zero for post creation

    Cost and Scale
    – Claude API: ~$5-10/month for all post generation
    – Metricool: $30/month (their API tier)
    – Cloud Function: free tier
    – Time saved: 120+ hours per month

    At our volume (60 articles/month), the automation saves more than 1 FTE worth of labor. The tooling costs $35/month.

    What This Enables
    Every article gets distribution. Every article benefits from platform-specific optimization. Every article contributes to building audience across multiple channels. And it requires zero manual social work.

    If you’re publishing content at scale and still posting to social manually, you’re wasting 100+ hours per month. Automate it.

    {
    “@context”: “https://schema.org”,
    “@type”: “Article”,
    “headline”: “The Metricool Pipeline: WordPress to Social in One API Call”,
    “description”: “Every WordPress article auto-generates platform-optimized social posts and publishes within 30 seconds using Metricool API + Claude. Here’s how the pipeli”,
    “datePublished”: “2026-03-30”,
    “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-metricool-pipeline-wordpress-to-social-in-one-api-call/”
    }
    }

  • The Three-Layer Content Quality Gate

    The Three-Layer Content Quality Gate

    The Machine Room · Under the Hood

    Before any article goes live on any of our 19 WordPress sites, it passes through three independent quality gates. This system has caught hundreds of AI hallucinations, unsourced claims, and fabricated statistics before they were published.

    Why This Matters
    AI-generated content is fast, but it’s also confident about things that aren’t true. A Claude-generated article about restoration processes might sound credible but invent a statistic. A AI-written comparison might fabricate a feature that doesn’t exist. These errors destroy credibility and trigger negative SEO consequences.

    We publish 60+ articles per month across our network. The cost of even a 2% error rate is unacceptable. So we built a three-layer system.

    Layer 1: Claim Verification Gate
    Before an article is even submitted for human review, Claude re-reads it looking specifically for claims that require sources:

    – Statistics (“90% of homeowners experience water damage by age 40”)
    – Causal relationships (“this causes that”)
    – Industry standards (“OSHA requires…”)
    – Product specifications
    – Cost figures or market data

    For each claim, Claude asks: Is this sourced? Is this common knowledge? Is this likely to be contested?

    If a claim lacks a source and isn’t general knowledge, the article is flagged for human research. The author has to either:
    – Add a source (with URL or citation)
    – Rewrite the claim as opinion (“we believe” instead of “it is”)
    – Remove it entirely

    This catches about 40% of unsourced claims before they ever reach a human editor.

    Layer 2: Human Fact Check
    A human editor (who knows the vertical and the client) reads the article specifically for accuracy. This isn’t copy-editing—it’s fact validation.

    The editor has a checklist:
    – Does this match what I know about this industry?
    – Are statistics realistic given the sources?
    – Does the logic hold up? Is the reasoning circular?
    – Is this client’s process accurately described?
    – Would a competitor or expert find holes in this?

    The human gut-check catches contextual errors that an automated system might miss. A claim might be technically true but misleading in context.

    Layer 3: Post-Publication Monitoring
    Even after publication, we monitor for errors. We have a Slack integration that tracks:
    – Reader comments (are people pointing out inaccuracies?)
    – Search ranking changes (did the article tank in impressions due to trust signals?)
    – User feedback forms
    – Related article comments (do linked articles contradict this one?)

    If an error surfaces post-publication, we add a correction note at the top of the article with a timestamp. We never ghost-edit published content—corrections are transparent and visible.

    What This Prevents
    – Fabricated statistics (caught by Layer 1 automation)
    – Logical fallacies and circular reasoning (caught by Layer 2 human review)
    – Domain-specific errors (caught by Layer 2 vertical expert)
    – Misleading framing (caught by Layer 2 contextual review)
    – Post-publication reputation damage (Layer 3 monitoring)

    The Cost
    Layer 1 is automated and costs essentially zero (just Claude API calls for re-review). Layer 2 is human time—about 30-45 minutes per article. Layer 3 is passive monitoring infrastructure we’d build anyway.

    We publish 60 articles/month. That’s 30-45 hours/month of human fact-checking. Worth every minute. A single article with a fabricated statistic that gets cited and reshared could damage our reputation across an entire vertical.

    The Competitive Advantage
    Most AI content operations have zero fact-checking. They publish, optimize, and hope. We have three layers of error prevention, which means our articles become the ones cited by others, the ones trusted by readers, and the ones that don’t get penalized by Google for YMYL concerns.

    If you’re publishing AI content at scale, a three-layer quality gate isn’t overhead—it’s your competitive advantage.

    {
    “@context”: “https://schema.org”,
    “@type”: “Article”,
    “headline”: “The Three-Layer Content Quality Gate”,
    “description”: “Our three-layer content quality system catches AI hallucinations, unsourced claims, and fabricated stats before publication. Here’s how automated verifica”,
    “datePublished”: “2026-03-30”,
    “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-three-layer-content-quality-gate/”
    }
    }

  • DataForSEO + Claude: The Keyword Research Stack That Replaced 3 Tools

    DataForSEO + Claude: The Keyword Research Stack That Replaced 3 Tools

    The Machine Room · Under the Hood

    We used to pay for SEMrush, Ahrefs, and Moz. Then we discovered we could use the DataForSEO API with Claude to do better keyword research, at 1/10th the cost, with more control over the analysis.

    The Old Stack (and Why It Broke)
    We were paying $600+ monthly across three platforms. Each had different strengths—Ahrefs for backlink data, SEMrush for SERP features, Moz for authority metrics—but also massive overlap. And none of them understood our specific context: managing 19 WordPress sites with different verticals and different SEO strategies.

    The tools gave us data. Claude gives us intelligence.

    DataForSEO + Claude: The New Stack
    DataForSEO is an API that pulls real search data. We hit their endpoints for:
    – Keyword search volume and trend data
    – SERP features (snippets, People Also Ask, related searches)
    – Ranking difficulty and opportunity scores
    – Competitor keyword analysis
    – Local search data (essential for restoration verticals)

    We pay $300/month for enough API calls to cover all 19 sites’ keyword research. That’s it.

    Where Claude Comes In
    DataForSEO gives us raw data. Claude synthesizes it into strategy.

    I’ll ask: “Given the keyword data for ‘water damage restoration in Houston,’ show me the 5 best opportunities to rank where we can compete immediately.”

    Claude looks at:
    – Search volume
    – Current top 10 (from DataForSEO)
    – Our existing content
    – Difficulty-to-opportunity ratio
    – PAA questions and featured snippet targets
    – Local intent signals

    It returns prioritized keyword clusters with actionable insights: “These 3 keywords have 100-500 monthly searches, lower competition in local SERPs, and People Also Ask questions you can answer in depth.”

    Competitive Analysis Without the Black Box
    Instead of trusting a platform’s opaque “difficulty score,” we use Claude to analyze actual SERP data:

    – What’s the common word count in top results?
    – How many have video content? Backlinks?
    – What schema markup are they using?
    – Are they targeting the same user intent or different angles?
    – What questions do they answer that we don’t?

    This gives us real competitive insight, not a number from 1-100.

    The Workflow
    1. Give Claude a target keyword and our target site
    2. Claude queries DataForSEO API for volume, difficulty, SERP data
    3. Claude pulls our existing content on related topics
    4. Claude analyzes the competitive landscape
    5. Claude recommends specific keywords with strategy recommendations
    6. I approve the targets, Claude drafts the content brief
    7. The brief goes to our content pipeline

    This entire workflow happens in 10 minutes. With the old tools, it took 2 hours of hopping between platforms.

    Cost and Scale
    DataForSEO is billed per API call, not per “seat” or “account.” We do ~500 keyword researches per month across all 19 sites. Cost: ~$30-40. Traditional tools would cost the same regardless of usage.

    As we scale content, our tool cost stays flat. With SEMrush, we’d hit overages or need higher plans.

    The Limitations (and Why We Accept Them)
    DataForSEO doesn’t have the 5-year historical trend data that Ahrefs does. We don’t get detailed backlink analysis. We don’t have a competitor tracking dashboard.

    But here’s the truth: we never used those features. We needed keyword opportunity identification and competitive insight. DataForSEO + Claude does that better than expensive platforms because Claude can reason about the data instead of just displaying it.

    What This Enables
    – Continuous keyword research (no tool budget constraints)
    – Smarter targeting (Claude reasons about intent)
    – Faster decisions (10 minutes instead of 2 hours)
    – Transparent methodology (we see exactly how decisions are made)
    – Scalable to all 19 sites simultaneously

    If you’re paying for three SEO platforms, you’re probably paying for one platform and wasting the other two. Try DataForSEO + Claude for your next keyword research cycle. You’ll get more actionable intelligence and spend less than a single month of your current setup.

    {
    “@context”: “https://schema.org”,
    “@type”: “Article”,
    “headline”: “DataForSEO + Claude: The Keyword Research Stack That Replaced 3 Tools”,
    “description”: “DataForSEO API + Claude replaces $600/month in SEO tools with $30/month API costs and better analysis. Here’s the keyword research workflow we built.”,
    “datePublished”: “2026-03-30”,
    “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/dataforseo-claude-the-keyword-research-stack-that-replaced-3-tools/”
    }
    }

  • I Built a Purchasing Agent That Checks My Budget Before It Buys

    I Built a Purchasing Agent That Checks My Budget Before It Buys

    The Machine Room · Under the Hood

    We built a Claude MCP server (BuyBot) that can execute purchases across all our business accounts, but it requires approval from a centralized budget authority before spending a single dollar. It’s changed how we handle expenses, inventory replenishment, and vendor management.

    The Problem
    We manage 19 WordPress sites, each with different budgets. Some are client accounts, some are owned outright, some are experiments. When we need to buy something—cloud credits, plugins, stock images, tools—we were doing it manually, which meant:

    – Forgetting which budget to charge it to
    – Overspending on accounts with limits
    – Having no audit trail of purchases
    – Spending time on transaction logistics instead of work

    We needed an agent that understood budget rules and could route purchases intelligently.

    The BuyBot Architecture
    BuyBot is an MCP server that Claude can call. It has access to:
    Account registry: All business accounts and their assigned budgets
    Spending rules: Per-account limits, category constraints, approval thresholds
    Payment methods: Which credit card goes with which business unit
    Vendor integrations: APIs for Stripe, Shopify, AWS, Google Cloud, etc.

    When I tell Claude “we need to renew our Shopify plan for the retail client,” it:

    1. Looks up the retail client account and its monthly budget
    2. Checks remaining budget for this cycle
    3. Queries current Shopify pricing
    4. Runs the purchase cost against spending rules
    5. If under the limit, executes the transaction immediately
    6. If over the limit or above an approval threshold, requests human approval
    7. Logs everything to a central ledger

    The Approval Engine
    Not every purchase needs me. Small routine expenses (under $50, category-approved, within budget) execute automatically. Anything bigger hits a Slack notification with full context:

    “Purchasing Agent is requesting approval:
    – Item: AWS credits
    – Amount: $2,000
    – Account: Restoration Client A
    – Current Budget Remaining: $1,200
    – Request exceeds account budget by $800
    – Suggested: Approve from shared operations budget”

    I approve in Slack, BuyBot checks my permissions, and the purchase executes. Full audit trail.

    Multi-Business Budget Pooling
    We manage 7 different business units with different profitability levels. Some months Unit A has excess budget, Unit C is tight. BuyBot has a “borrow against future month” option and a “pool shared operations budget” option.

    If the restoration client needs $500 in cloud credits and their account is at 90% utilization, BuyBot can automatically route the charge to our shared operations account (with logging) and rebalance next month. It’s smart enough to not create budget crises.

    The Vendor Integration Layer
    BuyBot doesn’t just handle internal budget logic—it understands vendor APIs. When we need stock images, it:
    – Checks which vendor is in our approved list
    – Gets current pricing from their API
    – Loads image requirements from the request
    – Queries their library
    – Purchases the right licenses
    – Downloads and stores the files
    – Updates our inventory system

    All in one agent call. No manual vendor portal logins, no copy-pasting order numbers.

    The Results
    – Spending transparency: I see all purchases in one ledger
    – Budget discipline: You can’t spend money that isn’t allocated
    – Automation: Routine expenses happen without my involvement
    – Audit trail: Every transaction has context, approval, and timestamp
    – Intelligent routing: Purchases go to the right account automatically

    What This Enables
    This is the foundation for fully autonomous expense management. In the next phase, BuyBot will:
    – Predict inventory needs and auto-replenish
    – Optimize vendor selection based on cost and delivery
    – Consolidate purchases across accounts for bulk discounts
    – Alert me to unusual spending patterns

    The key insight: AI agents don’t need unrestricted access. Give them clear budget rules, approval thresholds, and audit requirements, and they can handle purchasing autonomously while maintaining complete financial control.

    {
    “@context”: “https://schema.org”,
    “@type”: “Article”,
    “headline”: “I Built a Purchasing Agent That Checks My Budget Before It Buys”,
    “description”: “BuyBot is an MCP server that executes purchases autonomously while enforcing budget rules, approval gates, and multi-business account logic. Here’s how it”,
    “datePublished”: “2026-03-30”,
    “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/i-built-a-purchasing-agent-that-checks-my-budget-before-it-buys/”
    }
    }

  • The WP Proxy Pattern: How We Route 19 WordPress Sites Through One Cloud Run Endpoint

    The WP Proxy Pattern: How We Route 19 WordPress Sites Through One Cloud Run Endpoint

    The Machine Room · Under the Hood

    Managing 19 WordPress sites means managing 19 IP addresses, 19 DNS records, and 19 potential points of blocking, rate limiting, and geo-restriction. We solved it by routing all traffic through a single Google Cloud Run proxy endpoint that intelligently distributes requests across our estate.

    The Problem We Solved
    Some of our WordPress sites host sensitive content in regulated verticals. Others are hitting API rate limits from data providers. A few are in restrictive geographic regions. Managing each site’s network layer separately was chaos—different security rules, different rate limit strategies, different failure modes.

    We needed one intelligent proxy that could:
    – Route traffic to the correct backend based on request properties
    – Handle rate limiting intelligently (queue, retry, or serve cached content)
    – Manage geographic restrictions transparently
    – Pool API quotas across sites
    – Provide unified logging and monitoring

    Architecture: The Single Endpoint Pattern
    We run a Node.js Cloud Run service on a single stable IP. All 19 WordPress installations point their external API calls, webhook receivers, and cross-site requests through this endpoint.

    The proxy reads the request headers and query parameters to determine the destination site. Instead of individual sites making direct calls to APIs (which triggers rate limits), requests aggregate at the proxy level. We batch and deduplicate before sending to the actual API.

    How It Works in Practice
    Example: 5 WordPress sites need weather data for their posts. Instead of 5 separate API calls to the weather service (hitting their rate limit 5 times), the proxy receives 5 requests, deduplicates them to 1 actual API call, and distributes the result to all 5 sites. We’re using 1/5th of our quota.

    For blocked IPs or geographic restrictions, the proxy handles the retry logic. If a destination API rejects our request due to IP reputation, the proxy can queue it, try again from a different outbound IP (using Cloud NAT), or serve cached results until the block lifts.

    Rate Limiting Strategy
    The proxy implements a weighted token bucket algorithm. High-priority sites (revenue-generating clients) get higher quotas. Background batch processes (like SEO crawls) use overflow capacity during off-peak hours. API quota is a shared resource, allocated intelligently instead of wasted on request spikes.

    Logging and Observability
    Every request hits Cloud Logging. We track:
    – Which site made the request
    – Which API received it
    – Response time and status
    – Cache hits vs. misses
    – Rate limit decisions

    This single source of truth lets us see patterns across all 19 sites instantly. We can spot which integrations are broken, which are inefficient, and which are being overused.

    The Implementation Cost
    Cloud Run runs on a per-request billing model. Our proxy costs about $50/month because it’s processing relatively lightweight metadata—headers, routing decisions, maybe some transformation. The infrastructure is invisible to the cost model.

    Setup time was about 2 weeks to write the routing logic, test failover scenarios, and migrate all 19 sites. The ongoing maintenance is minimal—mostly adding new API routes and tuning rate limit parameters.

    Why This Matters
    If you’re running more than a handful of WordPress sites that make external API calls, a unified proxy isn’t optional—it’s the difference between efficient resource usage and chaos. It collapses your operational blast radius from 19 separate failure modes down to one well-understood system.

    Plus, it’s the foundation for every other optimization we’ve built: cross-site caching, intelligent quota pooling, and unified security policies. One endpoint, one place to think about performance and reliability.

    {
    “@context”: “https://schema.org”,
    “@type”: “Article”,
    “headline”: “The WP Proxy Pattern: How We Route 19 WordPress Sites Through One Cloud Run Endpoint”,
    “description”: “How we route all API traffic from 19 WordPress sites through a single Cloud Run proxy—collapsing complexity and eliminating rate limit chaos.”,
    “datePublished”: “2026-03-30”,
    “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-wp-proxy-pattern-how-we-route-19-wordpress-sites-through-one-cloud-run-endpoint/”
    }
    }

  • The Context Bleed Problem: What Happens When AI Agents Inherit Each Other’s Memory

    The Context Bleed Problem: What Happens When AI Agents Inherit Each Other’s Memory

    The Machine Room · Under the Hood

    {
    “@context”: “https://schema.org”,
    “@type”: “Article”,
    “headline”: “The Context Bleed Problem: What Happens When AI Agents Inherit Each Others Memory”,
    “description”: “When multi-agent pipelines pass full conversation history across handoffs, downstream agents inherit context they were never meant to have. Here is why that is “,
    “datePublished”: “2026-03-23”,
    “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-context-bleed-problem-what-happens-when-ai-agents-inherit-each-others-memory/”
    }
    }

  • Why We Stopped Calling Ourselves a Restoration Marketing Agency

    Why We Stopped Calling Ourselves a Restoration Marketing Agency

    The Machine Room · Under the Hood

    We built our name in restoration marketing. We were the agency that understood adjusters, knew the difference between mitigation and remediation, and could turn a 12-keyword site into a 340-keyword authority in six months.

    Then something happened. A cold storage company in California’s Central Valley asked if we could do the same thing for them. Then a luxury lending firm in Beverly Hills. Then a comedy club in Manhattan. Then an automotive sales training company in Ohio.

    Every time, we brought the same playbook: deep vertical research, persona-driven content architecture, SEO/AEO/GEO optimization, and relentless measurement. Every time, it worked. Not because we understood cold storage logistics or luxury asset lending – we didn’t, at first – but because the underlying system was industry-agnostic.

    The Framework Is the Product

    Here’s what most agencies won’t tell you: the tactics that work in restoration marketing aren’t restoration-specific. Schema markup doesn’t care about your industry. Entity authority doesn’t care whether you’re optimizing for “water damage restoration” or “temperature-controlled warehousing.” The Google algorithm doesn’t have a vertical preference.

    What matters is the system. Our content intelligence pipeline – the one that identifies gaps, generates persona variants, injects schema, builds internal link architecture, and optimizes for AI citation – works the same way whether we’re deploying it on a roofing contractor’s site or a FinTech lender’s blog.

    The 23-Site Laboratory

    Right now, we manage 23 WordPress sites across restoration, insurance, lending, entertainment, food logistics, healthcare facilities, ESG compliance, and more. Each site is a live experiment. What we learn on one site feeds every other site in the network.

    When Google’s March 2026 core update shifted E-E-A-T signals, we saw it across 23 different verticals simultaneously. We didn’t need to wait for an industry case study – we were the case study, in real time, across every vertical.

    That cross-pollination effect is something a single-vertical agency can never replicate. Our cold storage SEO strategy a luxury asset lenderws from our restoration content architecture. Our comedy club’s AEO optimization uses the same FAQ schema pattern that wins featured snippets for Beverly Hills luxury loans.

    Restoration Is Still Home Base

    We haven’t abandoned restoration. It’s still our deepest vertical, the one where we’ve generated the most data, run the most experiments, and delivered the most measurable results. But it’s no longer the ceiling. It’s the foundation.

    If your industry has a search bar and your competitors have websites, we already know how to outrank them. The vertical doesn’t matter. The system does.

    {
    “@context”: “https://schema.org”,
    “@type”: “Article”,
    “headline”: “Why We Stopped Calling Ourselves a Restoration Marketing Agency”,
    “description”: “We built our reputation in restoration. Then we realized the frameworks that tripled restoration revenue work in every industry. Here’s why we stopped nic”,
    “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/why-we-stopped-calling-ourselves-restoration-marketing-agency/”
    }
    }

  • How to Run 7 Businesses From One Notion Dashboard

    How to Run 7 Businesses From One Notion Dashboard

    The Machine Room · Under the Hood

    The Problem With Running Multiple Businesses

    When you operate seven companies across different industries – restoration, luxury lending, comedy streaming, cold storage, automotive training, and digital marketing – the natural instinct is to build seven separate operating systems. That instinct will destroy you.

    Separate project management tools, separate CRMs, separate content calendars. Before you know it, you’re spending more time switching contexts than actually building. We learned this the hard way across a restoration company, a luxury lending firm Company, a live comedy platform, a cold storage facility, an automotive training firm, and Tygart Media.

    The fix wasn’t hiring more people. It was architecture. One Notion workspace, six databases, and a triage system that routes every task, every client communication, and every content piece to the right place without human sorting.

    The 6-Database Architecture That Powers Everything

    Our Notion Command Center runs on exactly six databases that talk to each other. Not sixty. Not six per company. Six total.

    The Master Task Database handles every action item across all seven businesses. Each task gets a Company property, a Priority score, and an Owner. When a new task comes in – whether it’s a client request from a luxury asset lender or a content deadline for a storm protection company – it enters the same pipeline.

    The Client Portal Database creates air-gapped views so each client sees only their work. A restoration company in Houston never sees data from a luxury lender in Beverly Hills. Same database, completely isolated views.

    The Content Calendar Database manages editorial across 23 WordPress sites. Every article brief, every publish date, every SEO target lives here. When we run our AI content pipeline, it checks this database to avoid duplicate topics.

    The Agent Registry, Revenue Tracker, and Meeting Notes databases round out the system. Together, they give us a single pane of glass across a portfolio that would otherwise require a dozen tools and a full-time operations manager.

    Why Single-Workspace Architecture Beats Multi-Tool Stacks

    The average small business uses 17 different SaaS tools. When you run seven businesses, that number can balloon to 50+ subscriptions. Beyond the cost, the real killer is context fragmentation – critical information lives in five different places, and no one knows which version is current.

    A single Notion workspace eliminates this entirely. Every team member, contractor, and AI agent pulls from the same source of truth. When our Claude agents generate content briefs, they query the same database that tracks client deliverables. When we review monthly revenue, it’s the same workspace where we plan next month’s campaigns.

    This isn’t about Notion specifically – it’s about the principle that operational architecture should consolidate, not fragment. We chose Notion because its database-relation model maps naturally to multi-entity operations.

    The Custom Agent Layer

    The real leverage comes from building AI agents that operate inside this architecture. We run Claude-powered agents that can read our Notion databases, check WordPress site status, generate content briefs, and triage incoming tasks – all without human intervention for routine operations.

    Each agent has a specific scope: one handles content pipeline operations, another monitors SEO performance across all 23 sites, and a third manages social media scheduling through Metricool. They don’t replace human judgment for strategic decisions, but they eliminate 80% of the repetitive coordination work that used to eat 15+ hours per week.

    The key insight: agents are only as good as the data architecture they sit on top of. Build the databases right, and the automation layer practically writes itself.

    Frequently Asked Questions

    Can Notion really handle enterprise-level multi-business operations?

    Yes, with proper architecture. The limiting factor isn’t Notion’s capability – it’s how you structure your databases. Flat databases with 50 properties break down fast. Relational databases with clean property schemas scale to thousands of entries across multiple companies without performance issues.

    How do you keep client data separate across businesses?

    We use Notion’s filtered views and relation properties to create air-gapped client portals. Each client view is filtered by Company and Client properties, so a restoration client never sees lending data. It’s the same database, but the views are completely isolated.

    What happens when one business needs a different workflow?

    Every business has unique needs, but the underlying data model stays consistent. We handle workflow variations through database views and templates, not separate databases. A restoration project and a luxury lending deal both flow through the same task pipeline with different templates and automations attached.

    How many people can use this system before it breaks?

    We currently have 12+ users across all businesses plus AI agents accessing the workspace simultaneously. Notion handles this well. The bottleneck isn’t users – it’s database design. Keep your relations clean and your property counts reasonable, and the system scales.

    The Bottom Line

    Running multiple businesses doesn’t require multiple operating systems. It requires one well-architected system that treats each business as a filtered view of a unified dataset. Build the architecture once, and every new business you add becomes a configuration change – not a rebuild. If you’re drowning in tools and context-switching, the fix isn’t better tools. It’s better architecture.

    {
    “@context”: “https://schema.org”,
    “@type”: “Article”,
    “headline”: “How to Run 7 Businesses From One Notion Dashboard”,
    “description”: “How one Notion workspace with six databases runs seven businesses across restoration, lending, comedy, and marketing.”,
    “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/how-to-run-7-businesses-from-one-notion-dashboard/”
    }
    }