What it does
Once integrated, VerifiedX automatically observes the runtime context it needs and preflights protected side effects such as:- Memory writes
- Record mutations
- System changes
- External messages
- Internal notifications, handoff notes, and workflow updates
- Webhook calls
- File writes
- Database mutations
- Queue publishes
- Delegation and handoffs
What to expect from a decision
When a protected side effect is about to happen, VerifiedX returns one of four outcomes:allow— the action is sufficiently justified and can proceed.allow_with_warning— the action can proceed, but VerifiedX attaches a meaningful caution and a receipt.replan_required— this exact action should not happen now, but the agent should keep working toward the same goal through a safer or better-grounded next step.goal_fail_terminal— last resort. VerifiedX uses this only when the goal itself depends on a clearly forbidden, unsafe, malicious, or illegitimate action and there is no safe path forward.
What happens when an action is wrong
VerifiedX is optimized to stop the bad action, not stop the agent. If the action itself is wrong but the goal is still valid, VerifiedX returns a replan decision with reasons, what not to do, and safe next steps so the system can keep moving toward the same goal state. In single-agent systems, that replan stays local first: the runtime loopback gives the same agent the decision, the reasons, and the next-step guidance so it can continue without executing the bad action. In composed systems, VerifiedX first gives the current node a chance to recover locally. If the blocker is still unresolved, the decision receipt can route that replan upstream so your orchestrator knows this stage needs an upstream fix before retry.goal_fail_terminal is the complete last resort. Even then, VerifiedX still returns a structured decision receipt with exact reasons, routing, and resume semantics so your system can fail truthfully and hand the situation back to a human or upstream workflow cleanly.
Why builders use it
- Few lines of code
- Machine-readable decision receipts
- Clear reasons and next steps
- Decision logs, usage, keys, and billing in the builder app
- Strong bias toward continuing the workflow safely instead of dead-ending it
What VerifiedX is not
- Not an orchestrator
- Not a replacement for your runtime
- Not a memory system or workflow engine
- Not just post-hoc logging
- Not a generic AI safety, observability, or framework-rewrite product
Supported runtimes and adapters
| Surface | Languages |
|---|---|
| Raw runtime | Python, TypeScript |
| OpenAI direct | Python, TypeScript |
| OpenAI Agents SDK | Python, TypeScript |
| Anthropic direct | Python, TypeScript |
| Claude Agent SDK / query surface | Python, TypeScript |
| LangGraph | Python, TypeScript |
| LangChain | Python, TypeScript |
| Vercel AI SDK | TypeScript |
| MCP tools | Python, TypeScript |
Free Sandbox
The Free Sandbox includes 250 protected action checks per month.Next steps
Quick Start
Protect your first boundary in a few minutes.
Python SDK
Use the raw runtime or a native Python adapter.
TypeScript SDK
Use
bindHarness(...), native adapters, or lower-seam fallbacks.How it works
See taint probe, preflight, receipts, execution reporting, and logs end to end.