VerifiedX is an additive action-boundary layer. It does not replace your orchestrator, agent loop, tools, or memory system. It attaches to the surfaces you already use, builds context as the run unfolds, checks high-impact actions before they execute, and returns a decision your system can act on.Documentation Index
Fetch the complete documentation index at: https://docs.verifiedx.me/llms.txt
Use this file to discover all available pages before exploring further.
What VerifiedX uses to make a decision
VerifiedX does not judge an action in isolation. It looks at:- what the agent is about to do
- what the agent has already done in this run
- what the agent has ingested into its context from external retrievals and user-controlled inputs
- the evidence the agent gathered before the action
- upstream context when the run is part of a multi-agent or agent+human system
The execution flow
VerifiedX attaches to your existing runtime
VerifiedX connects through the adapter or runtime surface that already matches your stack. You keep your current orchestrator, tools, prompts, and business logic.
Context accumulates as the run unfolds
As the run continues, VerifiedX observes the relevant context around the agent’s work so it can evaluate high-impact actions with the full picture available at that point.
A high-impact action is checked before execution
Before the agent writes durable memory, updates records, changes workflow state, sends messages, calls webhooks, or takes another high-impact action, VerifiedX checks whether that action is justified.
A decision comes back
VerifiedX returns an outcome, reasons, and structured guidance for how the run should continue.
Decision outcomes
VerifiedX uses the same core outcome model across runtimes and adapters:| Outcome | What it means |
|---|---|
allow | The action can execute normally |
allow_with_warning | The action can execute, but with warnings and guidance |
replan_required | The action must not execute as requested; the run should continue through a safer or better-grounded path |
goal_fail_terminal | The requested action path is terminally blocked for the current goal state |
Single-agent and composed systems
VerifiedX works in both direct and composed systems. In a direct or single-agent flow, a blocked action usually becomes a local replan. The side effect does not execute, and the same agent can keep working toward the goal through a safer next step. In a multi-agent or agent+human system, the same blocked action can be routed upstream instead. That lets a parent workflow or supervisor gather the missing approval, evidence, or context before retrying.What VerifiedX does not do
- It does not replace your orchestrator, framework, or tool loop.
- It does not own your database, memory store, queue, or message bus.
- It does not require you to redesign your system around a special VerifiedX workflow.
- It does not force one integration path. You can use the native adapter that matches your stack or the raw runtime.