Level 7: Your Agent as an MCP Server & Walk-Away Mode
When your persistent agent becomes an MCP server, your coding tools can call it, your phone approves dangerous operations, and you can walk away from long jobs with confidence.
Introduction
Six levels in, you have a persistent agent running 24/7 on a dedicated machine, integrated with your messaging platforms, curating its own skill library, automating scheduled work, orchestrating specialist teams through a Kanban board, and remembering operational facts across sessions.
Level 7 is the capstone. It is the layer that closes the loop between your agent and your coding tools — and the one that gives you the freedom to step away from your laptop without losing control of long-running work.
At level 7, your persistent agent becomes an MCP server. Your coding tools can call it. Destructive operations route to your phone for approval. Long jobs send progress pings while you are nowhere near a keyboard. And when a bug surfaces at midnight, you can triage it from your phone before deciding whether it is worth opening the laptop.
This is what a level-7 agent stack looks like in practice. Knox built it. It runs continuously.
Core Concept
The MCP Server Pattern
MCP (Model Context Protocol) is the standard that lets tools expose capabilities to LLMs as structured, callable APIs. Most agents are MCP clients — they call external MCP servers to access tools. Level 7 inverts this: your persistent agent becomes an MCP server that other tools can call.
The Agent Framework gateway exposes tools like agent_channel_list, agent_conversations_get, and agent_tasks_query as MCP endpoints. Any MCP-compatible client — Claude Code, Cursor, other agents — can call these tools directly, the same way they call a filesystem tool or a web search tool.
This implementation uses mcp-bridge: a bridge MCP server that routes calls from Claude Code sessions through to the Agent Gateway running on a dedicated machine. When a Claude Code agent needs to check the Kanban board, query session history, or request human approval, it calls mcp-bridge, which relays to the gateway, which executes and returns.
The registration is a single JSON block in your Claude Code config:
{
"mcpServers": {
"mcp-bridge": {
"command": "python3",
"args": ["/Users/yourname/.config/agent/mcp_bridge.py"],
"env": {
"GATEWAY_URL": "http://localhost:8080",
"GATEWAY_TOKEN": "${GATEWAY_TOKEN}"
}
}
}
}
After this, mcp-bridge appears in the Claude Code tool list alongside read_file, bash, and web_search. Your coding agents can call your persistent agent as a peer.
The Approval Gate
Claude Code cannot natively ask for human approval. It can read a file, it can check a database, it can run a bash command — but it cannot send a message to your phone and wait for a reply. Your persistent agent can.
The pattern:
- Claude Code is about to do something destructive — force-push a branch, drop a database table, run a production deploy
- Instead of executing, it calls the persistent agent via MCP:
request_approval(action="force-push main", context="reverting last 3 commits") - The persistent agent sends a message to your Discord or Telegram DM: "Claude Code wants to force-push main. Approve? [Yes/No]"
- You reply from your phone: "Yes"
- The persistent agent returns
approved: trueto Claude Code - Claude Code executes
The Agent Framework documentation makes this explicit: "Claude Code cannot do this natively. It doesn't have Telegram or Discord access." The MCP bridge fills that gap. The persistent agent is the gatekeeper between autonomous code and irreversible production actions.
This is not about slowing down routine work. Reads, searches, drafts, and code generation proceed automatically. The gate activates for a specific class of operations: anything where a mistake requires manual recovery, costs money to reverse, or affects external systems. You define the list; the agent enforces it.
Walk-Away Mode
Long-running Claude Code sessions — building a feature, running a full test suite, orchestrating a multi-repo migration — can take 30-90 minutes. Staying at your laptop to monitor is a waste of time. Walk-away mode solves this.
The pattern:
- Claude Code starts a long job
- Every N minutes (or at defined checkpoints), it calls the persistent agent:
send_progress_ping(message="Completed phase 2 of 5: tests passing", job_id="migration-xyz") - The persistent agent forwards the ping to your Discord or Telegram DM
- You read the update from your phone, couch, or wherever
- If you need to steer — "skip the database migration, just do the API changes" — you reply in the thread
- The persistent agent queues your reply as input for the next Claude Code checkpoint
The job completes while you are away. You stayed in the loop. You did not babysit a terminal.
This is how Knox runs large migrations, multi-PR feature builds, and overnight content generation pipelines. The agent team executes; progress pings keep him informed without requiring his presence.
Bug Triage From Your Phone
A third use case: asynchronous bug triage. Something alerts at midnight. You get a notification. But you do not want to open your laptop — you want a quick read on whether this requires immediate action.
You send a message to your agent: "look at the error log for the trading bot from the last hour, give me a 3-line diagnosis."
The agent SSHs into the relevant machine, reads the logs, runs its analysis skill, and replies: "trading-bot: 3 USDT futures rejections due to insufficient balance in futures wallet. Not a code bug. Transfer USDT from spot to futures wallet to resolve."
You now know: no wake-up required, here is what to do tomorrow. You go back to sleep.
This use case — which the Agent Framework documentation calls "phone-first triage" — is arguably the highest-value application of the full level-7 stack. It turns "something broke, I need to investigate" into "something flagged, I have a diagnosis and a decision."
Practical Application
Here is the MCP server definition for a minimal approval gate tool:
# Part of your persistent agent's MCP server implementation
# Uses the official Python MCP SDK (pip install "mcp[cli]")
from mcp.server.fastmcp import FastMCP
mcp = FastMCP("agent-gateway")
@mcp.tool()
async def request_approval(action: str, context: str, risk: str = "high") -> dict:
"""
Route a destructive action to the human for approval via Discord/Telegram.
Returns {"approved": bool, "comment": str | None}
"""
message = (
f"APPROVAL REQUEST\n"
f"Action: {action}\n"
f"Context: {context}\n"
f"Risk: {risk}\n\n"
f"Reply 'yes' to approve or 'no' to reject."
)
# Send to Discord/Telegram DM via your messaging integration
await send_dm_and_wait(message, timeout_seconds=300)
# Returns the parsed reply
...
@mcp.tool()
async def send_progress_ping(message: str, job_id: str) -> dict:
"""Send a progress update for a long-running job."""
await send_dm(f"[{job_id}] {message}")
return {"sent": True}
Register this server in the agent's MCP configuration and it is immediately callable from Claude Code, other agents, or any MCP-compatible tool.
The critical safety rule: every approval gate request must have a timeout. If the human does not respond within 5 minutes (or your chosen threshold), default to approved: false and surface the timeout. An unanswered approval request should never block the agent indefinitely or default to approved.
Common Mistakes
No timeout on approval requests. An agent waiting indefinitely for human approval is a hung process. Set a timeout; default to reject on timeout.
Gating everything behind approval. If routine operations require phone approval, you will approve mindlessly — and that defeats the purpose. Reserve the gate for a small, specific list of irreversible operations. The gate's power comes from its rarity.
Not logging approval decisions. When a force-push was approved and something goes wrong, you need to know who approved it, when, and what context they had. Log every approval gate interaction with the full decision trail.
Skipping the simpler levels. Level 7 is not a shortcut. Without a stable dedicated machine (level 2), reliable messaging (level 3), and persistent memory (level 6), an MCP server and walk-away mode create complexity without the foundation to support it. Build the ladder in order.
Treating this as a product to install. Agent Framework is a reference architecture; Agent Gateway is one real-world implementation of it. But the patterns — MCP exposure, approval gates, walk-away mode — are architectural decisions you implement for your specific stack. Understand the pattern; adapt it to your tools.
Summary
- Level 7 exposes the persistent agent as an MCP server so coding tools can call it as a peer
- The approval gate routes destructive operations to your phone before executing — Claude Code cannot do this natively
- Walk-away mode delivers progress pings during long-running jobs so you remain in the loop without watching a terminal
- Phone-first bug triage turns midnight alerts into 3-line diagnoses without opening a laptop
- Every approval request needs a timeout that defaults to reject — never let the agent hang waiting for human input
- Build the ladder in order: levels 2-6 must be stable before level 7 adds meaningful value
What's Next
You have completed the Seven Levels of Agent Orchestration track. The ladder is clear: from a chat session to a 24/7 AI employee with isolation, messaging, curation, cron, multi-agent coordination, persistent memory, and MCP integration. The gap between level 1 and level 7 is not complexity — it is compounding. Each layer builds on the last, and the value at the top is qualitatively different from where most people stop.
One agent is a toy. A conducted orchestra is a business. You now have the map.