Local runtime adapter
Hold or release a dependent action inside the agent runtime with a local fast path.
How Varqo works
Verify reality before autonomous workflows continue.
Varqo is being built around independent verification and control close to the action. It identifies what a consequential workflow depends on, verifies the required facts and resulting states independently, and uses evidence to decide whether dependent execution may continue. The broader distributed control plane is product direction; the current implementation proves a scoped local gate.
Product north star
KNOW → VERIFY → CONTROL → RECOVER → PROVE
Authorization is necessary, but it does not prove that the assumptions behind an autonomous action are true. Varqo adds an integrity loop around consequential execution.
The loop is state and dependency driven. It should increasingly reason about what must be true for the next step rather than relying on hardcoded function names.
Honest status: VERIFY is the current live proven technical kernel. CONTROL and PROVE are partially implemented. Broader KNOW and generic automated RECOVER remain product direction.
KNOWIdentify consequential context, claims, and dependenciesUNDERSTAND
VERIFYCheck authoritative facts and system state independentlyPROVE REALITY
CONTROLAllow, hold, or block dependent autonomous executionDECIDE
RECOVERRestore a verified state when divergence can be corrected safelyRECONCILE
PROVEPreserve the evidence chain behind continuation or stopEXPLAIN
Deployment model · product direction
Central integrity intelligence. Distributed enforcement.
Varqo does not need to own every prompt or tool call. The control plane coordinates proof planning, policy, provenance, and evidence while enforcement can run close to the consequential action.
SDK or framework integration
Attach integrity decisions to the execution surface the enterprise already controls.
Existing gateway or tool boundary
Use an existing enterprise gateway or API boundary as an enforcement point instead of replacing it.
Provider or workload integration
Enforce near the external effect while minimizing the data that must leave the customer environment.
Consequence aware control · product direction
Not every action needs the same verification depth.
Low consequence activity can stay on a local fast path when policy and evidence are already sufficient. Consequential or uncertain actions can trigger deeper verification before execution continues.
This lets Varqo earn the right to delay or block based on consequence, uncertainty, and dependency instead of inserting the same remote check into every interaction.
Low consequenceLocal policy and evidence are sufficientFAST PATH
DecisionALLOWCONTINUE
Consequential or uncertainRequired fact or state is not yet provenVERIFY
DecisionALLOW / HOLD / BLOCK / RECOVEREVIDENCE BASED
Automatic verification planning · R&D direction
Compile available context into an executable path to evidence.
The research goal is to reduce hand-authored verifiers. Varqo should derive testable outcome conditions from task context, tool calls and parameters, interface documentation, and available enterprise policy, then construct and challenge a bounded verification plan.
Derive testable conditions
Convert the available task and action context into structured conditions for resource identity, target state, and required properties. Missing support remains explicit instead of being invented.
Build an evidence graph
Connect operations, inputs, outputs, resources, and observable fields so a returned runtime identity can lead to the authoritative state the outcome depends on.
Search a bounded proof path
Compose allowed reads, identity bindings, comparisons, and time-bounded waits into an executable plan rather than asking a model to emit unrestricted verification code.
Challenge with counterexamples
Reject or revise a plan if it would verify the wrong resource, accept an intermediate state, or approve a controlled case where the required outcome is false.
Scope boundary: action-level conditions can often be derived from the task, tool call, parameters, and technical documentation. Proving that an entire enterprise process is complete also requires an authoritative source for organization-specific obligations. Broad planning on unseen interfaces and measurable advantage over a raw model remain research hypotheses.
Control path
See what changes when provider success is not enough.
Choose a scenario and run the workflow. The simulation follows control patterns exercised in Varqo experiments; it does not call a live provider.
1
Agent actionWaiting to run
READY—2
Provider responseNot observed
PENDING—3
Independent verifierNot executed
PENDING—4
Dependent actionAwaiting proof
HELD—Inside VERIFY + CONTROL
Prepare proof early. Bind runtime identity late. Trust neither the agent nor a success label.
For the current post action wedge, Varqo prepares the proof requirement before a consequential write whenever possible. After the write, it binds only provider returned runtime identity, executes an independent verifier, and evaluates authoritative observations against the required outcome.
Semantic preparation can be precompiled and persisted outside the live path. A runtime miss does not silently fall back to an LLM; it fails closed.
PrepareCompile required outcome and verifierBEFORE AGENT RUN
BindAttach real provider returned runtime identityRUNTIME
ObserveRead lifecycle and resulting state independentlyAUTHORITATIVE
DecideVERIFIED / FAIL / UNRESOLVEDFAIL CLOSED
GateRELEASE / BLOCK / HOLD the dependent actionCONTROL
Recovery and durable evidence · product direction
When execution fails, preserve what happened before deciding what comes next.
Recovery starts from a checkpointed view of the action, its result, the evidence already collected, and the dependencies still held. Varqo can then re-read authoritative systems before retrying, reconciling, compensating, or escalating.
Current status: the local console can explicitly resume captured pending verification after a service restart. Release requires an authenticated local evaluator receipt, and the original provider write is not replayed. Explore the proven local path → Generic automated recovery and a complete enterprise-grade evidence history are not yet live proven.
Safe retry
Retry only when the operation is known to be safe or idempotent and duplication risk is controlled.
Re read and reconcile
Observe authoritative state again and reconcile when the system may still be converging or reality changed outside the agent.
Compensate or roll back
Execute a known corrective action when returning to a safe state requires explicit compensation or rollback.
Human escalation
If automatic recovery cannot be proven safe, keep dependent execution held and require a human decision instead of guessing.
Checkpointed workflow knowledge
Persist stable action identity, observed result, completed checks, and unreleased dependencies so restart does not erase what the workflow already knows.
Evidence history beyond chat
Keep a durable event record linking request context, verification plan, actions, observations, and decisions even when the agent session or chat is no longer available.
Safety principles
Ambiguity never becomes permission.
The control boundary is designed around independent evidence, explicit dependencies, and fail closed behavior rather than model confidence.
Independent observation
Varqo queries authoritative state rather than treating the agent's own claim or provider dispatch response as sufficient proof.
Requirement bound verdicts
Evidence counts only when it proves the specific condition the downstream workflow actually depends on.
Fail closed where proof is required
Missing plans, verifier failures, malformed evidence, unknown states, wrong dependencies, and exhausted polling remain held or blocked for actions whose policy requires proof.
Minimize the data path
Distributed enforcement should keep ordinary agent traffic local and send only the structured evidence needed for integrity decisions whenever practical.