Before I send Cowork a task that ends in a WordPress post, I do one thing first: I check that the WordPress MCP tool is listed in Cowork’s available tools. Every time. Not because the pipeline is fragile, but because agentic workflows fail silently — and silent failure is the expensive kind.
TL;DR
- MCP connections don’t automatically persist across sessions. A tool that was connected yesterday may not be connected today.
- When an agent loses a tool connection, it often doesn’t error loudly — it just quietly does nothing, or does the wrong thing.
- The fix is a governance habit: make the agent enumerate its available tools before you send it a task that depends on one of them.
- It’s the same instinct as checking a junior team member’s assumptions before they ship — not distrust, just knowing where silent failure lives.
What the pipeline looks like
My content workflow for douli.com runs through three connected systems. I give a brief via Dispatch, a mobile interface I use to kick off tasks from my phone. Cowork picks up the brief and does the execution work — research, writing, structuring. Then the WordPress MCP tool, claudeus-wp-mcp, handles the actual post creation on the site. The chain is: brief on mobile → agent execution → WordPress draft.
When it works, it’s genuinely frictionless. I describe what I want in a few sentences on the way to work, and a structured draft appears in my WordPress dashboard by the time I sit down at my desk. That kind of automation is exactly what I built this workflow for.
But the workflow has a dependency that isn’t always visible: Cowork needs the WordPress MCP tool to be present and connected before any of the final step happens. And that connection is not guaranteed.
Why agentic systems fail silently
Here’s the thing nobody tells you about agentic AI: the failure mode isn’t usually an error. It’s an omission.
When a traditional system breaks, you typically know about it. A 500 error, a failed deploy, a test that doesn’t pass. The signal is loud and specific. When an agentic system loses access to a tool it depends on, it often continues anyway. It processes the input, generates the output, and then either writes it nowhere, or routes to a fallback that isn’t what you wanted, or silently drops the final step entirely. The task finishes. Nothing looks wrong. And you find out later — when you check WordPress and there’s no draft, or when you trace back through session logs at the end of the day.
MCP connections are one specific version of this. They don’t automatically persist across sessions. A connection that held during one Cowork session won’t necessarily reconnect when the next one starts. Not because anything broke dramatically — just because sessions end and reconnect, and not every dependent service follows cleanly.
Agentic AI shifts failure from errors to omissions. A traditional system throws an exception. An agent just doesn’t do the thing — and you might not notice until you check the output and find nothing there.
This is a well-documented characteristic of agentic systems more broadly. The OWASP Top 10 for LLM Applications covers several categories of agentic failure — excessive agency, insecure tool use, and what happens when agents operate outside the boundaries their designers assumed. Silent failure isn’t a bug in any one tool. It’s a structural property of systems where multiple services are chained together with no mandatory handshake between steps.
The check I do every time
Before I send any task to Cowork that depends on the WordPress MCP tool, I verify that the tool appears in Cowork’s available tool list. It’s a one-step check. I’m looking for a specific item — the claudeus-wp-mcp connection — in the tools Cowork can enumerate at the start of the session.
If it’s there, I proceed. If it isn’t, I reconnect before running anything.
That’s the whole discipline. It takes thirty seconds and it costs nothing. What it prevents is a task that runs to completion, consumes time and context, and delivers exactly nothing to WordPress — with no indication of why.
The interesting thing about this check is that it’s not technical in nature. I’m not running a diagnostic or debugging an API. I’m applying a governance habit: verify the conditions before you run the task, not after. The agent doesn’t always know which of its connections are stale. You have to ask it to show you.
The governance parallel — checking assumptions before someone ships
I think about this the same way I think about reviewing a team member’s assumptions before they push something to production. Not because I don’t trust them — I do — but because I know that unchecked assumptions are where quiet failures hide.
A developer told to deploy to staging, whose environment isn’t configured correctly, won’t always stop and flag it. Sometimes they’ll run the deploy, it’ll appear to succeed, and the change will silently go nowhere. You find out during the QA pass — or worse, you don’t find out at all because there was nothing to test. The failure never announces itself. It just leaves a gap where something should have been.
The discipline I’ve built with agents is the same one I’d apply to any workflow with hidden dependencies: make the system show its state before you rely on it. Ask the agent to enumerate its available tools. Ask the junior developer to confirm their environment. Confirm the connection exists before you send the task that needs it.
This isn’t distrust. It’s knowing where the gaps are and designing around them. The agent is capable. The connection is the variable.
What to build into your own agentic workflows
If you’re running any pipeline where an AI agent connects to an external tool or service, build a verification step in before the action runs. The question is simple: does the agent currently have access to what it needs?
For me that’s: does Cowork list the WordPress MCP tool? For you it might be: does the agent report the database connection as active? Does the API key resolve? The specific check doesn’t matter. The habit does.
Don’t assume a connection from a previous session still holds. Make the agent prove it before you send the task. The useful version of agentic AI is the one where you understand its failure modes well enough to design around them, not the version where you trust the pipeline implicitly and find out later that it quietly did nothing.
Show me the tools. Then we’ll proceed.
