Forem: Jonathan Melton

# 9 Seconds. One AI Agent. A Wiped Production Database.

Jonathan Melton — Mon, 11 May 2026 06:54:38 +0000

In April 2026, a team using PocketOS watched Claude Opus 4.6 — running via Cursor — delete their entire production database and every backup in under 10 seconds.

Not a partial delete. Not a staging environment. Production data, gone. Backups, gone. Nine seconds.

The root cause wasn't the model. It wasn't even the code. It was three infrastructure decisions that nobody thought to question:

The agent had a blanket API token with no scope limits
There was no blast radius constraint on what it could touch
Backups were colocated with the source data The agent did exactly what it was told. Nobody told it what it wasn't allowed to do.

This Isn't Isolated

Two months earlier, DataTalks.Club had a similar moment. Claude Code executed terraform destroy and wiped 2.5 years of production data in a single command.

Earlier this year, researchers found over 5,000 AI-generated apps publicly accessible on the open web — exposing hospital records, bank transaction logs, and retail data. Not because the AI was malicious. Because nobody built the guardrails.

The pattern is consistent: the model works exactly as designed. The governance layer doesn't exist.

A 2026 Gravitee survey found that only 24.4% of organizations have full visibility into which AI agents are communicating with what systems. More than half of deployed agents run with zero security oversight or logging. Eighty-two percent of executives said they were confident their policies protect against unauthorized agent actions — but most have no execution-layer controls. Just policies.

Policies don't stop terraform destroy.

The Real Problem Isn't the AI

Every post-mortem on incidents like PocketOS points to the same structural gap: there's nothing between the LLM and the tools it can call.

The model reasons. The tool executes. There's no layer in the middle asking: should this be happening right now?

MCP (Model Context Protocol) made it dramatically easier to give AI agents access to tools. That's the whole point — it's powerful. But power without constraint is just risk waiting for a trigger.

The MCP ecosystem hit 97 million monthly SDK downloads as of March 2026. 78% of enterprise AI teams have at least one MCP agent in production. The CIS published an MCP Companion Guide in April 2026 specifically because enterprises are scared and scrambling for governance frameworks.

The adoption is real. The governance isn't.

What Governance Actually Looks Like at the Execution Layer

Policy-level governance (acceptable use documents, model selection guidelines) is necessary but insufficient. What protects against a PocketOS-style event is execution-layer control — enforcement that happens at the moment a tool is called, not in a document someone agreed to last quarter.

At minimum, a governed MCP setup needs:

Tool scoping. Not every agent needs access to every tool. A customer support agent querying a knowledge base doesn't need write access to your database. Scope by role. Enforce it at the gateway, not the prompt.

Blast radius limits. Define what each agent can touch. Separate environments. Separate tokens with separate permissions. If an agent only needs to read, it only gets read.

Audit logging. Every tool call, every parameter, every response — logged with enough detail to reconstruct what happened. The PocketOS team couldn't answer "what exactly did it call and when?" Logs answer that.

Request filtering. Destructive operations (deletes, drops, destroys) should require a second confirmation path, not just model reasoning. The model thought the delete was appropriate. A filter that flags DELETE * or terraform destroy before execution is a different kind of check.

Separation of data and backups. Infrastructure basics that become critical when an agent has write access to both.

None of this is exotic. All of it is skipped constantly because MCP adoption is outpacing the tooling to govern it.

The Windows Problem Makes This Worse

If you're running MCP infrastructure on Windows — which a significant chunk of the developer market is — you're fighting a second battle before you even get to governance.

I've documented six Windows-specific MCP failure modes that don't exist on Linux: path expansion bugs, Docker socket misconfiguration, BOM encoding issues, server registry limits, absolute path requirements, and WSL2 VHDX placement. Add a seventh: MCP Python SDK DNS rebinding protection (the TransportSecuritySettings issue) that silently rejects Tailscale connections with a 421 because the IP isn't in the hardcoded allowlist.

These aren't documented anywhere official. They're discovered by whoever is unlucky enough to spend three days debugging what should have been a one-hour setup.

When your foundation is unstable, governance becomes almost impossible. You're too busy keeping the servers running to think about what they're allowed to do.

What I Built to Fix This

FusionAL is a unified MCP gateway I built after hitting every one of those failure modes personally. It runs on Windows, manages the Docker configuration that causes most Windows MCP failures, and centralizes tool access so you can actually reason about scope and logging in one place instead of per-server.

The governance layer is the point. Not just "here's a gateway that runs your tools." Here's a gateway where you can define what each agent can see, log every tool call, and filter requests before they execute.

The PocketOS wipeout would have looked different with a gateway in the path. Not because the gateway would have known the delete was wrong — it wouldn't. But because:

The agent's token would have been scoped to what it actually needed
The delete operation would have been flagged as a destructive pattern
Backups would have been on a separate access path the agent couldn't reach
The entire call chain would be in a log that tells you exactly what happened That's not magic. That's architecture.

The Window Is Now

The CIS MCP Companion Guide dropped April 20, 2026. EU AI Act enforcement starts August 2. Microsoft is running VS Live sessions this summer teaching .NET developers MCP basics — and those developers are going to ask "how do we govern this?"

The enterprises asking those questions right now don't have answers yet. The consulting market for done-for-you MCP governance installs is essentially empty below $25K.

If you're building AI infrastructure, governance isn't the feature you add after you ship. It's the feature that determines whether you have a production incident story or a post-mortem.

If you're dealing with Windows MCP failures, governance gaps, or token bloat eating your context window before you've asked anything — I'm building this in public at fusional.dev and happy to talk through what you're hitting.

The nine-second wipeout was preventable. Most of them are.

Why Your MCP Setup Keeps Timing Out in 60 Seconds (And How I Fixed It on Windows)

Jonathan Melton — Thu, 19 Mar 2026 03:39:57 +0000

Every developer hits this wall: add more than 8 MCP servers to Claude Desktop (or Cursor, or VSCode) → it spins for exactly 60 seconds → red X, "timed out." It happens on every machine with limited resources. My i5-7300HQ laptop? Poster child for the problem.

Tutorials skip it. AWS/Finch articles ignore Windows entirely. Docker's own docs don't cover it. But the problem is real, and I spent weeks diagnosing every failure mode until I fixed them all.

I documented 6 Windows-specific MCP failure modes that nobody else has written about, then built a single Docker gateway that loads 150+ tools without hitting the timeout. Every single time.

The 6 Real Killers

1. BOM in `claude_desktop_config.json`

What you see: You edit the config in PowerShell, save it, restart Claude Desktop. Nothing changes. No error message. Claude just ignores your config entirely.

Why it happens: PowerShell's Out-File -Encoding UTF8 adds an invisible 3-byte BOM (byte order mark) at the start of the file. Claude's JSON parser chokes on those bytes without telling you.

How to check:

$bytes = [System.IO.File]::ReadAllBytes("$env:APPDATA\Claude\claude_desktop_config.json")
if ($bytes[0] -eq 0xEF -and $bytes[1] -eq 0xBB -and $bytes[2] -eq 0xBF) {
    Write-Host "BOM detected — this is your problem"
}

The fix: Always write config with BOM-free UTF-8:

[System.IO.File]::WriteAllText(
    "$env:APPDATA\Claude\claude_desktop_config.json",
    $content,
    (New-Object System.Text.UTF8Encoding($false))  # $false = no BOM
)

2. `%USERPROFILE%` Doesn't Expand

What you see: Your config references %USERPROFILE%\some\path and the server never starts. No error — just silence.

Why it happens: Claude Desktop doesn't expand Windows environment variables in the JSON config. It reads %USERPROFILE% as a literal string and tries to find a directory with percent signs in the name.

The fix: Hardcode absolute paths everywhere. No exceptions.

"command": "C:\\Users\\puddi\\AppData\\Local\\Programs\\node.exe"

Not:

"command": "%USERPROFILE%\\AppData\\Local\\Programs\\node.exe"

3. `docker.exe` Needs the Full Absolute Path

What you see: Config looks correct, Docker is running, but the MCP server won't start.

Why it happens: Claude Desktop launches child processes without inheriting the system PATH. So "command": "docker" or even "command": "docker.exe" fails — it can't find the binary.

The fix: Use the full path to docker.exe:

"command": "C:\\Program Files\\Docker\\Docker\\resources\\bin\\docker.exe"

Every time. Don't trust PATH.

4. Docker Named Pipe vs Unix Socket Mismatch

What you see: Docker commands work fine in your terminal, but MCP servers that need Docker access inside containers get connection errors.

Why it happens: Windows Docker Desktop runs through a named pipe (//./pipe/docker_engine), but containers expect the Unix socket at /var/run/docker.sock. Named pipes are flaky when passed through to containers via WSL2.

The fix: Mount the Unix socket directly. Docker Desktop's WSL2 backend exposes it:

"-v", "/var/run/docker.sock:/var/run/docker.sock"

Don't use the Windows named pipe. The Unix socket is stable through WSL2 integration.

5. Cold-Start Bloat Kills the 60-Second Budget

What you see: A server works fine after the first load, but on a fresh start (cold boot, after a Docker prune, or first install), it times out.

Why it happens: Some MCP servers download heavy dependencies on first run. Puppeteer downloads Chromium (~180MB). Python servers pull packages. Node servers run npm install. All of this happens inside the 60-second initialization window that Claude Desktop enforces. On slower hardware, you're dead.

The fix: Pre-bake dependencies into Docker images. If a server needs Chromium, include it in the Dockerfile — don't download it at runtime. For the gateway approach, this is handled by using official Docker MCP images that ship ready to run.

I removed Puppeteer from my registry entirely after it blew the timeout three times in a row. If you need browser automation, use a pre-built image like browserless/chrome and connect to it remotely.

6. Registry Bloat (The One That Started Everything)

What you see: You have 8 MCP servers and everything works. You add a 9th. Timeout.

Why it happens: Claude Desktop initializes all registered servers in parallel on startup. Each server needs CPU time, memory allocation, and potentially network connections. On an i5-7300HQ with 16GB RAM, 8 servers is the practical ceiling before the 60-second timeout hits.

This isn't a bug — it's a resource constraint. Every server you add steals initialization time from every other server. The relationship is roughly linear until you hit the wall, then it's catastrophic.

The fix: This is the one that made me build FusionAL. Instead of registering 8 separate servers, you register one gateway that loads tools from a catalog. One initialization, one process, 150+ tools available.

The Fix: One Lean Gateway

FusionAL runs a single docker/mcp-gateway container that manages everything through a lightweight registry.yaml + tool catalogs. Cold start drops from "never finishes" to 12-18 seconds.

Before (8 registry entries, constant timeouts):

# registry.yaml with 8+ entries
servers:
  github: ...
  filesystem: ...
  redis: ...
  postgres: ...
  puppeteer: ...    # ← downloads Chrome, blows timeout
  slack: ...
  notion: ...
  custom-api: ...
  analytics: ...    # ← 9th server, guaranteed timeout

After (1 registry entry, 150+ tools):

{
  "mcpServers": {
    "fusional-gateway": {
      "command": "C:\\Program Files\\Docker\\Docker\\resources\\bin\\docker.exe",
      "args": [
        "run", "-i", "--rm",
        "-v", "/var/run/docker.sock:/var/run/docker.sock",
        "-v", "C:/Users/puddi/.docker/mcp:/mcp",
        "docker/mcp-gateway",
        "--catalog=/mcp/catalogs/docker-mcp.yaml",
        "--catalog=/mcp/catalogs/custom.yaml",
        "--registry=/mcp/registry.yaml",
        "--config=/mcp/config.yaml",
        "--transport=stdio"
      ]
    }
  }
}

One process. One initialization. All 150+ tools available through the gateway.

Writing this config safely (no BOM):

$config = Get-Content .\my-config.json -Raw
[System.IO.File]::WriteAllText(
    "$env:APPDATA\Claude\claude_desktop_config.json",
    $config,
    (New-Object System.Text.UTF8Encoding($false))
)

Quick Reference: All 6 Fixes

Failure Mode	Symptom	Fix
BOM encoding	Config silently ignored	`UTF8Encoding($false)`
Env vars in paths	Server won't start	Hardcode absolute paths
docker.exe not found	Silent failure	Full absolute path to binary
Named pipe mismatch	Container can't reach Docker	Mount `/var/run/docker.sock`
Cold-start downloads	Timeout on first run	Pre-bake deps in Docker images
Registry bloat (>8 servers)	60-second timeout	Single gateway, catalog-based loading

What I'm Building on Top of This

The gateway solves the reliability problem. But managing a fleet of MCP servers — knowing which ones are running, which ones crashed, queuing new builds — that's the next layer.

I'm building FusionAL, an open-source MCP operations gateway that wraps all of this into one Docker command. It handles the 6 failure modes automatically and gives you a clean interface for managing your MCP infrastructure.

If you've hit other Windows-specific MCP issues I didn't cover here, drop them in the comments. I'm actively documenting every edge case I find.

Find me on GitHub or X (@2EfinAwesome).

I Had Claude Build Me a Full AI Marketing Department — Here's Exactly How I Did It

Jonathan Melton — Fri, 13 Mar 2026 09:28:21 +0000

Real talk: I didn't write most of this code.

I directed it. I described what I wanted, reviewed what came back, pushed back when it was wrong, and kept iterating until it worked. That's the actual skill I want to talk about — because if you're still treating Claude like a search engine that writes code snippets, you're leaving a lot on the table.

Here's what we built together and how the conversation actually went.

What I Wanted

I was tired of asking AI for marketing help and getting back the kind of copy that sounds like it was written by a committee of robots. You know the type — "Unlock Your Potential Today!" Nobody buys that.

The real problem is that marketing isn't a one-prompt job. It's a team sport. You need someone thinking about strategy, someone thinking about keywords, someone writing the actual copy, and someone planning the social calendar. When you smash all that into a single prompt, you get a single-perspective answer that misses everything it wasn't specifically asked about.

So I told Claude what I actually wanted: build me a team.

The Prompt That Started It

I didn't give Claude a spec doc. I just described the problem:

"I want a Python CLI that runs multiple specialized AI agents sequentially. Each agent has a specific marketing role — CMO, SEO, copywriter, social media, email, analyst. Each one should receive the previous agents' output as context so they're building on each other's work, not starting from scratch. Use Claude Opus 4.6 with streaming and adaptive thinking."

That's it. No architecture diagram. No file structure. Just the outcome I wanted and one key constraint: sequential context passing.

What came back was a working base. Not perfect. But working.

The Architecture Claude Landed On

main.py                 # CLI + orchestrator
agents/
  base.py               # MarketingAgent base class
  cmo.py                # Campaign strategy
  seo.py                # Keyword + content strategy
  copywriter.py         # Landing pages, ads, taglines
  social.py             # Content calendar, platform playbooks
  email_marketer.py     # Welcome sequences, nurture flows
  analyst.py            # KPI dashboard, A/B roadmap
tools/
  platform_tools.py     # HubSpot, Mailchimp, Buffer, Semrush hooks
campaigns/              # Saved campaign outputs

Six agents. Each one a specialist. Each one named like a real person on a real team because — honestly — it makes the system prompts better when you write them that way.

The Base Agent — This Is the Core

Every agent inherits from one class. The think() method is the whole game:

class MarketingAgent:
    def __init__(self, name: str, role: str, system_prompt: str, emoji: str = "🤖"):
        self.name = name
        self.role = role
        self.system_prompt = system_prompt
        self.emoji = emoji

    def think(self, task: str, context: str = "", max_tokens: int = 4096) -> str:
        messages = [{"role": "user", "content": task}]
        if context:
            messages = [
                {
                    "role": "user",
                    "content": f"Context from previous team members:\n\n{context}\n\n---\n\nYour task: {task}"
                }
            ]

        full_text = ""
        with client.messages.stream(
            model="claude-opus-4-6",
            max_tokens=max_tokens,
            thinking={"type": "adaptive"},
            system=self.system_prompt,
            messages=messages,
        ) as stream:
            for text in stream.text_stream:
                print(text, end="", flush=True)
                full_text += text

        return full_text

Simple. Take the task, prepend any context from previous agents, stream the response. The context is what makes it not stupid.

The Context Handoff — Why This Actually Works

Here's the pipeline in the orchestrator. This is the part I pushed back on Claude about — the first version ran everything in parallel and the output was incoherent because nobody was talking to each other.

# CMO goes first — sets everything
self.outputs["01_cmo"] = self.agents["cmo"].think(cmo_task)

# SEO gets the CMO brief
self.outputs["02_seo"] = self.agents["seo"].think(
    seo_task, context=self.outputs["01_cmo"]
)

# Copywriter gets CMO + SEO both
self.outputs["03_copy"] = self.agents["copywriter"].think(
    copy_task,
    context=self.outputs["01_cmo"] + "\n\n" + self.outputs["02_seo"]
)

# Social gets CMO + Copy
self.outputs["04_social"] = self.agents["social"].think(
    social_task,
    context=self.outputs["01_cmo"] + "\n\n" + self.outputs["03_copy"]
)

# Email gets CMO + Copy
self.outputs["05_email"] = self.agents["email"].think(
    email_task,
    context=self.outputs["01_cmo"] + "\n\n" + self.outputs["03_copy"]
)

# Analyst gets everything
self.outputs["06_analytics"] = self.agents["analyst"].think(
    analyst_task,
    context="\n\n---\n\n".join([
        self.outputs["01_cmo"],
        self.outputs["02_seo"],
        self.outputs["04_social"],
    ])
)

When the Copywriter writes your landing page headline, it already knows the positioning the CMO defined, the keywords the SEO specialist identified, and the exact personas. The copy isn't generic because it's not starting from scratch — it's starting from a complete strategic brief written by the agent before it.

That's what single-prompt marketing AI can't do. It has no team. It's one person trying to do six jobs at once and it shows.

What I Had to Correct

A few things Claude got wrong on the first pass that I pushed back on:

1. Parallel execution. First draft ran all agents at once. Looked efficient. Output was a mess because the Copywriter had no idea what the SEO specialist recommended. Told Claude to make it sequential and explained why. Fixed immediately.

2. Generic system prompts. Early versions had vague role descriptions like "you are a marketing expert." I pushed for specificity — actual deliverables listed, actual output format expected, written from the perspective of a real person with a real title. The output quality jumped noticeably.

3. No context injection on quick mode. The quick campaign (CMO + Copywriter only) wasn't passing the CMO brief to the Copywriter. Caught it in testing. One-line fix but it's the whole point of the system.

This is what directing AI actually looks like. It's not magic prompt engineering. It's reviewing output, identifying what's wrong, and being specific about how to fix it.

What It Produces

Run a full campaign and you get six connected deliverables:

CMO output — positioning, personas, channel mix, messaging pillars, KPIs
SEO output — keyword clusters, search intent analysis, content briefs for top 3 pages, technical checklist
Copywriter output — hero copy, full landing page, 3 Google ad variations, 3 Meta ad variations, brand voice guide
Social output — 4-week calendar for LinkedIn, Instagram, X, and TikTok with ready-to-post content
Email output — welcome sequence (5 emails), sales sequence (3 emails), re-engagement sequence, newsletter template
Analyst output — KPI dashboard, attribution model, A/B testing roadmap, 90-day benchmarks

Total output on a full run: somewhere between 8,000 and 12,000 words of interconnected marketing content that actually references itself. The social posts use the same messaging pillars the CMO defined. The email subject lines match the copy angles the Copywriter developed. It coheres.

How to Run It

git clone https://gitlab.com/JonathanMelton-FusionAL/ai-marketing-team
cd ai-marketing-team
pip install -r requirements.txt
cp .env.example .env
# Add your ANTHROPIC_API_KEY

# Full campaign — all 6 agents
python main.py campaign --product "B2B SaaS for HR teams" --save

# Quick mode — CMO + Copywriter only
python main.py campaign --product "your product" --mode quick

# Ask one agent directly
python main.py ask cmo "What channels should a bootstrapped SaaS focus on first?"
python main.py ask copy "Write 5 headline variations for a project management tool"
python main.py ask seo "Keywords for email automation software?"

The --save flag dumps everything to a timestamped folder in campaigns/. Use it. You'll want to reference the outputs later.

What I'd Do Differently

Real keyword data. Right now the SEO agent estimates keyword volume. Hooking in a Semrush API key (there's a hook for it in tools/platform_tools.py) would make those recommendations actually grounded in real search data.

Iteration loops. Right now it's a straight pipeline. What I want is the CMO reviewing the Copywriter's output and pushing back if it doesn't match the positioning. That's more expensive token-wise but would be closer to how a real team works.

MCP server version. This is the one I'm actually building next. Wrap the whole thing as an MCP server so it runs inside Claude Desktop as a tool — no CLI, just "run a campaign for X" and it happens in your workspace. That's what FusionAL is moving toward: all your AI tools in one place, zero config headache.

Note: Opus 4.6 with adaptive thinking burns tokens fast. A full 6-agent campaign run will cost roughly $1-3 depending on your product description length. Budget accordingly or swap claude-opus-4-6 for claude-sonnet-4-6 in agents/base.py for a cheaper run.

The Bigger Point

I'm a self-taught developer. No CS degree. No team. I built this working alone, directing Claude to do the heavy lifting on code I understood well enough to review and correct but didn't have to write from scratch.

That's the skill now. Not knowing every syntax. Not being the fastest typist. Knowing what you want, being able to recognize when you're not getting it, and knowing how to course-correct.

If you're sleeping on that because it feels like "cheating" — it's not. It's just how good builders work in 2026.

Repo: gitlab.com/JonathanMelton-FusionAL/ai-marketing-team

If you run it, let me know what it produces. Tag me on X — @2EfinAwesome.

I'm building FusionAL — a unified MCP gateway for teams who don't want to hire a platform engineer to set up their AI tooling. Follow the build on X.