Keep your agents. Plug them into ThreadPool.
Most teams already run agents and will not move them. ThreadPool's governance gateway lets them stay where they are: before each step the agent asks ThreadPool for permission, and afterwards it reports what it produced. ThreadPool applies your policies and approvals, issues a scoped credential, verifies the output independently and keeps the record. It authorizes and verifies; it never executes your agents.
Updated · by the ThreadPool team
Your agent
Stays where it runs: your servers, your models, your keys.
# Claude Code, Cursor and any MCP clientclaude mcp add --transport http threadpool \ https://www.threadpool.in/api/mcp \ --header "Authorization: Bearer tpk_…"ThreadPool
Authorizes, verifies and records. Never executes.
- authorizeAsking permissionALLOW
Policy, approvals and the Circuit Breaker all pass. A credential is issued for this one step.
- your agentDoes the work, in your infrastructureYOURS
ThreadPool never runs it and never sees its model traffic or keys.
- reportResult reported under the credentialHASHED
The output is fingerprinted with SHA-256 so the record shows exactly what was checked.
- verifyIndependent QAACCEPTED
Deterministic checks first, then the QA model. The agent never grades itself.
- recordOn the recordRECEIPT
Who did it, under what authority, how it was checked and how it ended.
Illustration of the flow. Real decisions come from your own policies, approval gates and the Circuit Breaker.
The problem
Teams already have agents running in LangGraph, CrewAI, Claude Code or their own services. Rebuilding them inside another platform is a non-starter, yet they still need answers to hard questions: who allowed this agent to act, was the result checked, and what is on the record when something goes wrong?
Governance has to come to the agents, not the other way round.
How it works
- Open a run: a governed run groups the steps your workforce performs. ThreadPool never plans or executes it.
- Declare a step and the agent that will do it, using your own identifier and display name.
- Authorize: before acting, the agent asks permission. ThreadPool checks your governance policies, then your approval gates, then the Circuit Breaker, and issues a credential scoped to that one step and agent. The answer is allow, deny or pending_approval.
- Act: only on allow. The agent runs in your own infrastructure, with your own models and keys.
- Report and verify: the agent reports its output under the credential; ThreadPool fingerprints it with SHA-256, runs deterministic checks and independent QA, and accepts or rejects the step.
- Close: ThreadPool returns the accountability record and a governance receipt for the whole run.
Three ways in
| Way in | Best for | Setup |
|---|---|---|
| Hosted MCP server | Claude Code, Cursor and any MCP client | One command with your deployment's URL and an API key; nothing to install |
| TypeScript SDK | LangGraph, CrewAI or your own code | A dependency-free client; governed() runs your function only when ThreadPool says allow |
| REST API | Any language or framework | Plain HTTP under /api/v1/gateway, with an Idempotency-Key on every write |
What ThreadPool checks before a step
- Organization policies: capability access, agent eligibility, step limits. A policy denial beats even a human approval.
- Approval gates: if your policy requires a person to approve outside agents, the answer is pending_approval and nothing is assigned until they decide. Nothing waits on ThreadPool's side.
- Circuit Breaker: a deterministic check that fails closed. An attempt outside the granted scope is refused, logged as a security event, and the agent is revoked.
- Scoped credential: valid for one step and one agent, with a bounded number of uses and an expiry.
What stays yours
- Your agents keep running where they run. ThreadPool does not execute them, call them or proxy their model traffic.
- Your provider keys never reach ThreadPool.
- ThreadPool sees only what you send it: the declared step and the reported output, which is stored as-is and never trusted as evidence.
What you get back
- An accountability record for every step: who did it, under what authority, how it was verified and how it ended. A step that was never reported is shown as unknown, never guessed.
- A governance receipt for the run, fingerprinted with SHA-256, that names the exact output that was verified. Every run is labeled as reported by the caller's agent, not executed by ThreadPool.
- A measured record for each agent. Its quality, success rate and latency come only from ThreadPool's QA verdicts and its own timing, never from what the agent says about itself.
Try it
claude mcp add --transport http threadpool \
https://your-host/api/mcp \
--header "Authorization: Bearer tpk_..."Limitations and trade-offs
- This is cooperative governance: ThreadPool cannot force an agent to ask before it acts. What it guarantees is that a step without a ThreadPool credential never gets an accepted, verified record, and that unreported work is recorded as unknown.
- The hosted MCP endpoint authenticates with an API key in a header. Clients that only support a browser sign-in flow cannot use it yet.
- The TypeScript SDK and the local MCP server are not published to npm yet; the hosted endpoint and the REST API need no installation.
- ThreadPool never retrieves sources for a governed run, so citations in reported output cannot be verified and caller-supplied artifacts are stored but not trusted.
- With no QA model configured, verification falls back to deterministic structural checks, and the verdict says so instead of claiming a model reviewed the work.
- A gateway agent cannot be calibrated, because ThreadPool never runs it; its record builds up from verification verdicts on the work it reports.
Related
Ready to connect an agent? Sign in, open Connect and create a key.
Connect your agents