TL;DR: replace the layer you actually need
For a business-owned digital worker, shortlist Unify, Lindy, and Relevance AI. For a code-owned stateful agent runtime, shortlist LangGraph with LangSmith Deployment and Mastra. For tools, MCP, authentication, and external capability access without replacing orchestration, compare Composio, Arcade, Pipedream Connect, and QVeris. Do not place all nine in one ranking: they replace different parts of Toolhouse.
The platform owns triggers, workflow, business context, actions, and a user-facing operating surface.
Your team owns agent code while the platform supplies durable execution, state, queues, APIs, and deployment.
Keep the current runtime and replace capability discovery, authentication, tool execution, or integration plumbing.
Use a runtime for state and approvals, then add one capability provider for external actions and data.
What Toolhouse is in 2026: a fair baseline
Toolhouse should not be described as only a tool marketplace. Its current documentation presents an Agent Backend-as-a-Service: agents can be defined as code and published behind an API, while the platform also covers AI workers, schedules, asynchronous runs, run context, RAG, memory, code execution, browser use, public and custom MCP servers, a reviewed Tool Store, evaluations, prompt optimization, and observability.
| Layer | Toolhouse baseline | Proof required from an alternative |
|---|---|---|
| Worker | Workers, schedules, business-facing automation | A non-developer can operate, pause, inspect, and recover work. |
| Runtime | Agents as code, API publishing, streaming, async runs, run IDs | State survives retries, deploys, timeouts, and human pauses. |
| Capabilities | Tool Store, MCP, RAG, memory, browser, code execution | Auth, schemas, errors, output limits, and side effects are explicit. |
| Control plane | Logs, evaluations, prompt optimization, usage controls | Operators can trace a result from request to model and tool evidence. |
This matters because a narrow tools product may be an excellent component and still be an incomplete Toolhouse replacement. The correct question is not “does it have more integrations?” but “which Toolhouse responsibilities move, which stay, and who owns the gap?”
Prerequisite: draw the replacement boundary
List workers, agent definitions, prompts, schedules, run IDs, memory, RAG stores, tools, MCP servers, secrets, approval gates, callbacks, and dashboards.
CRM, ticketing, identity, billing, and audit systems must remain authoritative even when an agent writes to them.
Start with whole worker, runtime, or capability layer. A hybrid is valid, but every boundary needs an owner and interface.
Define accepted completion, safety limits, cost ceiling, recovery time, and the condition that sends traffic back.
Who this guide is for—and who should stay
Your team has a concrete production workload, needs a different operating model, wants stronger code ownership or user-level auth, or is reducing platform coupling.
Current workers meet SLAs, the team uses several integrated platform features, and migration savings do not exceed revalidation and operating cost.
A migration is not automatically an optimization. If the replacement recreates schedules, memory, tool auth, audit logs, and deployment in five separate services, include that engineering and incident-response burden in the decision.
Evaluation method: score outcomes, not screenshots
The shortlist below is a category map, not a paid ranking. Product capabilities and commercial terms change; verify them in official documentation and a controlled pilot. Weight the scorecard before demos so a polished interface cannot move the goalposts.
| Criterion | Weight | Measure |
|---|---|---|
| Accepted completion | 25% | Correct result, required evidence, and correct destination state |
| Safety and permissions | 20% | Unauthorized reads, unsafe writes, approval bypasses, secret exposure |
| Runtime durability | 15% | Recovery after timeout, duplicate event, worker restart, and human pause |
| Tools and interoperability | 15% | MCP/SDK/API fit, auth model, schema quality, custom tools |
| Observability and evaluation | 10% | Run trace, tool evidence, versions, failure reason, export |
| Portability and operations | 10% | Export, deployment choices, rollback time, on-call ownership |
| Cost per accepted task | 5% | All-in cost divided by accepted—not attempted—runs |
Layer 1: full worker-platform alternatives
Choose this layer when the desired unit is a business outcome—monitor a channel, research a request, update a system, ask for approval—not a runtime API. These platforms may replace more of the Toolhouse operating experience, but the pilot must still prove state recovery, permissions, export, and auditability.
Shortlist for teammate-style work that spans connected business context, channels, and recurring tasks. Prove approval semantics, developer extensibility, export, and deterministic recovery for your workload.
Shortlist when trigger/action automation and accessible workflow composition matter. Prove long-running state, duplicate-event handling, custom integration depth, and operator diagnostics.
Shortlist for configurable AI workforces and multi-agent business processes. Prove handoff contracts, per-agent permissions, shared-state ownership, and failure isolation.
| Best starting fit | Main advantage to test | Do not assume |
|---|---|---|
| Unify | Teammate experience and cross-channel work | That business convenience equals runtime portability |
| Lindy | Fast trigger-to-action workflow assembly | That every long-running failure resumes exactly once |
| Relevance AI | Multi-agent workforce composition | That more agents improve accepted completion |
Layer 2: developer-owned agent runtimes
Choose a runtime when prompts, state transitions, approval rules, and integration contracts belong in version-controlled code. This route can improve control and portability, but your team accepts responsibility for architecture, tests, deployment, on-call response, and capability providers.
Shortlist for long-running, stateful graphs that need durable execution, persistence, human-in-the-loop, threads, runs, streaming, queues, and scheduled jobs. Prove graph evolution, state migrations, trace retention, and operational ownership.
Shortlist for TypeScript teams that want agents, tools, memory, MCP, workflows, suspend/resume, traces, and deployable API surfaces in one developer framework. Prove production hosting, queue behavior, tenancy, and rollback in your chosen deployment.
Prefer LangGraph when explicit state graphs, interrupts, replay, and ecosystem integrations are central. Prefer Mastra when a TypeScript-native framework and integrated workflow/agent developer experience are central. In both cases, separately choose tools, auth, models, storage, and production operations.
Layer 3: tools, MCP, and capability alternatives
Choose this layer when your existing agent runtime already handles state, scheduling, approvals, retries, and deployment. A capability provider should be evaluated on discovery, auth, schema quality, execution reliability, side-effect controls, evidence, and billing—not on whether it can draw a workflow canvas.
Shortlist for broad pre-authenticated toolkits, per-user sessions, managed OAuth, triggers, MCP use, and an agent workbench. Prove tenant isolation, scope control, tool selection quality, and response handling on your top integrations.
Shortlist when per-user authorization, tool-level permissions, secure token injection, MCP gateways, governance, and auditable actions are the center of the problem. Prove policy integration and the authorization/retry user experience.
Shortlist for embedding managed authentication, prebuilt tools, MCP, API proxying, and integrations into your own app or agent. Prove server-side security, end-user identity mapping, rate limits, and event semantics.
Shortlist when an existing agent needs to discover capabilities by intent, inspect parameters, success rate, latency, and price, then call a selected capability through REST, SDK, CLI, or MCP. It is a capability routing layer—not a replacement for runtime, memory, scheduling, or approvals.
| Candidate | Center of gravity | You still own |
|---|---|---|
| Composio | Toolkits, user sessions, auth, triggers, workbench | Agent policy, workflow state, acceptance evaluation |
| Arcade | Authorization, action runtime, MCP governance | Business workflow, memory, planning, schedules |
| Pipedream Connect | Embedded integrations, managed auth, tools, proxy | Agent runtime, product UX, approval policy |
| QVeris | Discover → Inspect → Call capability routing | Runtime, identity policy, memory, scheduler, write approvals |
A portable architecture avoids another lock-in
Convert schedule, webhook, chat, and API events into one versioned request envelope.
Persist state transitions, checkpoints, approvals, retries, cancellation, and deadlines outside prompt text.
Normalize tool schemas, identity, idempotency, errors, citations, cost, and raw evidence across providers.
Evaluate permissions and irreversible side effects independently from model intent.
Store references, hashes, versions, decisions, and evaluator results while redacting unnecessary payloads.
Code: define a provider-neutral agent manifest
A portable manifest is not a universal standard; it is your internal contract. Keep business intent, permissions, and acceptance criteria separate from provider deployment syntax.
type AgentManifest = {
id: string;
version: string;
trigger: { type: "schedule" | "event" | "api"; expression?: string };
runtime: {
deadlineSeconds: number;
maxAttempts: number;
checkpoint: "each_step" | "before_side_effect";
};
capabilities: Array<{
intent: string;
mode: "read" | "write";
scopes: string[];
approval: "never" | "always" | "policy";
}>;
acceptance: {
schema: string;
citationsRequired: boolean;
maxCostUsd: number;
};
};
const riskBrief: AgentManifest = {
id: "customer-risk-brief",
version: "1.3.0",
trigger: { type: "schedule", expression: "0 8 * * 1-5" },
runtime: { deadlineSeconds: 300, maxAttempts: 3, checkpoint: "before_side_effect" },
capabilities: [
{ intent: "read CRM changes", mode: "read", scopes: ["crm.read"], approval: "never" },
{ intent: "create CRM note", mode: "write", scopes: ["crm.note.create"], approval: "always" }
],
acceptance: { schema: "risk-brief-v1", citationsRequired: true, maxCostUsd: 0.75 }
};Normalize evidence before comparing results
{
"run_id": "run_01K...",
"manifest_version": "1.3.0",
"provider": "candidate-a",
"status": "awaiting_approval",
"identity": { "tenant": "acme", "actor": "risk-agent" },
"steps": [
{
"name": "external_research",
"capability_id": "provider.capability.version",
"request_hash": "sha256:...",
"source_time": "2026-07-30T23:58:00Z",
"latency_ms": 842,
"cost_usd": 0.014,
"evidence_refs": ["ev_201", "ev_202"]
}
],
"pending_action": {
"type": "crm.note.create",
"idempotency_key": "acme:account-42:2026-07-31",
"approval_id": "apr_88"
},
"validation": {
"schema": "pass",
"citations": "pass",
"policy": "pass"
}
}Do not score a run from the final prose alone. Preserve the request, resolved identity, capability version, parameters, source time, raw response hash, transformation, validation result, approval, and side-effect receipt.
Validation checklist for every candidate
Correct trigger, source selection, structured output, citations, destination write, notification, and completion status.
Retry slow tools, replay duplicate events, restart workers, pause for approval, cancel, and resume without duplicate writes.
Revoke scopes, cross tenant boundaries, inject prompt attacks, request forbidden actions, and inspect logs for secrets.
Locate one failed run, explain the failure, replay from a checkpoint, export evidence, rotate a secret, and roll back a version.
Security, cost, and latency controls
| Risk | Minimum control | Release evidence |
|---|---|---|
| Unauthorized action | Per-user identity, least-privilege scopes, policy check, approval for irreversible writes | Denied-action tests and immutable approval receipt |
| Duplicate side effect | Idempotency key, write ledger, checkpoint before action | Duplicate webhook and retry test with one write |
| Runaway cost | Per-run budget, tool-call cap, token cap, circuit breaker | Budget breach terminates safely and reports partial work |
| Tail latency | Deadlines, bounded retries, provider timeout, async callback | P95/P99 by step and deadline-exceeded recovery |
| Secret exposure | Server-side vault, token isolation, payload redaction, no model-visible credentials | Log scan, rotation test, revoked-token behavior |
Compare cost per accepted task
Seat price or platform credits alone are not comparable across worker, runtime, and capability products. Build an all-in cost ledger and divide by accepted outputs. Recheck current pricing immediately before procurement because packaging, credits, included workers, and retention can change.
all_in_cost =
platform_fee
+ model_cost
+ tool_or_capability_cost
+ storage_and_network
+ engineering_operations
+ human_review
+ failure_recovery
cost_per_accepted_task =
all_in_cost / accepted_tasks
accepted_tasks =
completed_tasks
- unsafe_or_incorrect_tasks
- tasks_missing_required_evidenceMigration plan: move contracts before traffic
Capture agent code, prompts, tool configuration, MCP servers, RAG sources, memory rules, schedules, API contracts, run context, logs, evals, and secret references. Never copy raw secrets into migration files.
Translate old triggers and API requests into the portable envelope; normalize new provider responses into the evidence schema.
Run frozen cases without side effects. Compare accepted completion, citations, step latency, tool errors, and cost.
Let the candidate observe live requests but block writes. Investigate every disagreement before enabling actions.
Enable one low-risk action for a small tenant cohort with approval, idempotency, and an automatic kill switch.
Move traffic by workload, not all at once. Keep the old path read-ready until the new system passes the agreed stability window.
Canary and rollback gates
| Gate | Example release target | Automatic response |
|---|---|---|
| Accepted completion | No worse than baseline by more than 2 percentage points | Pause expansion; route new runs to baseline |
| Unsafe writes | 0 | Disable write capability immediately |
| Duplicate writes | 0 | Open circuit; reconcile write ledger |
| P95 deadline | Within workload SLA for three consecutive days | Reduce cohort or switch slow capability |
| Evidence completeness | 100% | Block downstream approval when evidence is missing |
Common failure modes and fixes
A tools catalog wins on integrations while a runtime wins on state. Fix: define the replacement boundary and score only responsibilities in scope.
Happy-path demos omit revoked auth, duplicate events, human delays, and partial writes. Fix: inject these failures into the shared workload.
A restart loses approvals and completed steps. Fix: persist explicit state and checkpoint before every side effect.
A timeout hides a successful downstream action. Fix: use stable idempotency keys and reconcile against a write ledger.
The agent receives broad tokens or wrong-tenant context. Fix: bind identity per request, minimize scopes, and keep tokens out of model context.
Low unit cost hides retries, review, and rejected outputs. Fix: calculate cost per accepted task with all operations included.
QVeris implementation pattern: replace only capability routing
QVeris fits when the agent runtime already exists and the missing piece is finding and executing external capabilities. The documented loop is Discover → Inspect → Call: search by intent, inspect candidate parameters and operational signals, then execute the selected capability and return structured results. REST, Python, TypeScript, CLI, and MCP integration paths are available.
from qveris import QverisClient
async with QverisClient() as client:
found = await client.discover(
"retrieve current company risk signals",
limit=5,
)
candidate = found.results[0]
inspected = await client.inspect(
[candidate.tool_id],
search_id=found.search_id,
)
selected = inspected.results[0]
result = await client.call(
selected.tool_id,
{"company": "Example Corp"},
search_id=found.search_id,
)
assert result.success
print(result.execution_id, result.billing)QVeris does not become the system of record, workflow state machine, scheduler, memory store, or approval authority in this pattern. Those responsibilities stay with your runtime and business systems.
Toolhouse alternatives FAQ
What is the best Toolhouse alternative?
There is no universal replacement. Use a worker platform for an end-to-end digital coworker, a runtime platform when your team owns agent code and state, or a capability layer when you only need tools, MCP, and managed authentication.
Is Toolhouse only a tool marketplace?
No. Toolhouse currently combines agents-as-code and API deployment with workers, schedules, streaming, memory, RAG, code execution, browser use, a Tool Store, MCP connectivity, evaluations, and observability.
Which alternatives can replace the full Toolhouse backend?
Worker platforms such as Unify, Lindy, and Relevance AI are candidates for business-owned automation. LangGraph with LangSmith Deployment and Mastra are candidates for code-owned agent runtimes. Each still needs a workload-specific pilot.
Which alternatives replace only Toolhouse tools or MCP?
Composio, Arcade, Pipedream Connect, and QVeris are capability-layer candidates. They can improve integrations, user authorization, tool execution, or capability routing, but do not automatically replace scheduling, memory, workflow state, or the agent API.
How should I compare Toolhouse alternatives?
Run the same task with the same inputs, model budget, approval policy, timeout, retry rules, and expected output. Score accepted completion, unsafe side effects, recovery, evidence quality, latency, and cost per accepted task.
Can I migrate without rewriting my agent?
Sometimes. If your agent already owns prompts, state, and orchestration, replacing only the capability layer can be incremental. A full worker or runtime migration requires remapping schedules, memory, run identifiers, approvals, observability, and deployment contracts.
What security controls matter most?
Use per-user identity, least-privilege scopes, secret isolation, explicit approval for irreversible actions, idempotency keys, egress controls, payload redaction, immutable audit events, and a tested kill switch.
Where does QVeris fit?
QVeris is a capability routing layer. It helps agents discover, inspect, and call external capabilities through REST, SDK, CLI, or MCP. Keep the existing runtime, memory, scheduler, approval service, and system of record unless replaced separately.
Official sources and verification notes
Capabilities were checked against official product documentation on July 31, 2026. Commercial packages and limits can change; recheck pricing, retention, regional hosting, security reports, and support terms during procurement.
- Toolhouse documentation · pricing · agent APIs · workers and schedules
- LangGraph overview · LangSmith Agent Server
- Mastra workflows · Mastra MCP guide
- Composio documentation · Arcade documentation · Pipedream Connect
- QVeris MCP Server documentation · QVeris pricing
- Unify · Lindy triggers · Relevance AI documentation
The final decision rule
Choose the smallest replacement that passes the shared workload, preserves evidence, contains side effects, meets the rollback window, and reduces total operating burden. If only capability access is missing, keep the runtime. If runtime ownership is the problem, change the runtime. If the business needs a ready operator, evaluate the whole worker.