🤖system prompt•6 months ago
Human-in-the-Loop Approval Token Workflow
Gate risky tool execution behind approval tokens so agents can retry safely after a human reviewer signs off.
# Human-in-the-Loop Approval Token Workflow
Imported from curated first-party documentation sources.
## What this covers
Use this workflow when autonomous execution needs a durable handoff from human review back into the agent loop.
## Use this when
- Retrying a blocked tool call after approval
- Adding a human checkpoint to sensitive actions
- Reducing insecure workarounds around approval flows
## Expected outcomes
- Approval becomes a reusable tokenized workflow
- Agents resume work without losing execution context
- Security controls stay explicit instead of being implied
## Source synthesis
- EVOKORE-MCP/docs/V2_MULTI_AGENT_WORKFLOWS.md (https://github.com/mattmre/EVOKORE-MCP/blob/main/docs/V2_MULTI_AGENT_WORKFLOWS.md)
- EVOKORE-MCP/docs/AGENT33_IMPROVEMENT_INSTRUCTIONS.md (https://github.com/mattmre/EVOKORE-MCP/blob/main/docs/AGENT33_IMPROVEMENT_INSTRUCTIONS.md)
## Dedupe notes
Synthesizes the approval-token concept from the main workflow doc and the Agent33 improvement transfer notes.
## Source excerpts
### EVOKORE-MCP/docs/V2_MULTI_AGENT_WORKFLOWS.md
With EVOKORE-MCP v2.0 fully operational, we can now leverage 40+ proxied GitHub and Filesystem tools seamlessly within complex multi-agent workflows. The core architectural advancements include:
## 1. Dynamic Tool Prefixing & Indexing
Instead of loading 40+ tools into an LLM's context window statically (which causes massive bloat), EVOKORE's `ProxyManager` boots child servers (like `@modelcontextprotocol/server-github` and `@modelcontextprotocol/server-filesystem`) and dynamically prefixes their tools (`github_create_issue`, `fs_write_file`). This prevents namespace collisions while keeping the tools accessible to native skills.
## 2. Human-in-the-Loop (HITL) Security Interceptor
Automated multi-agent workflows involving sensitive endpoints (like GitHub write access or file deletion) are governed by EVOKORE's stateless `_evokore_approval_token` architecture.
- When an agent attempts a restricted action, the tool call is intercepted and blocked.
- The server returns an error explicitly commanding the agent to prompt the human for approval.
- Upon approval, the agent retries the exact tool call with the injected token, securely fulfilling the workflow without severing the conversational context.
## 3. Active Skill Orchestration (Native Harnessing)
Unlike v1.0 where skills merel
...
### EVOKORE-MCP/docs/AGENT33_IMPROVEMENT_INSTRUCTIONS.md
> **Purpose**: Feed this file into Claude Code CLI when working on the Agent33 repo. It contains patterns, architectures, and capabilities proven in EVOKORE-MCP that Agent33 should adopt.
---
## 1. Multi-Server MCP Aggregation Pattern
**What Agent33 lacks**: Agent33's MCP server (Phase 43) is a single-endpoint bridge. It doesn't aggregate multiple child MCP servers behind a unified namespace.
**What to build**: A proxy layer that spawns and manages multiple child MCP servers from a single config file, presenting them as one unified tool surface.
### Implementation spec:
```
mcp.config.json
{
"servers": {
"github": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-github"], "env": { "GITHUB_TOKEN": "${GITHUB_TOKEN}" } },
"fs": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-filesystem", "./"] },
"elevenlabs": { "command": "uvx", "args": ["elevenlabs-mcp"], "env": { "ELEVENLABS_API_KEY": "${ELEVENLABS_API_KEY}" } }
}
}
```
**Key patterns from EVOKORE**:
- **Tool name prefixing**: Every proxied tool gets renamed `{serverId}_{originalName}` to prevent namespace collisions (e.g., `github_create_issue`, `fs_read_file`). First-registration-wins for duplicates.
- **Environment interpolation**: `${VAR}` syntax in `env` blocks resolved
...