Skip to content
Vasko

An agent acts only when there are grounds for it

Vasko checks agent actions against your company’s documents. If the grounds are absent or superseded by a later document, the action does not go through — and you see which document was missing.

vasko — gate

Confirm the 15% discount agreed with the client in the March thread

Verdict
Action not performed
Grounds
Discount policy of 1 June, §2.4 — maximum discount 10%

What was missing

The March approval was superseded by a later document. A 15% discount is signed off by the commercial director.

A worked example. The documents and the request are for demonstration.

Works with

  • Claude
  • ChatGPT
  • Cursor
  • Codex
  • Copilot
  • Gemini
  • Cline
  • Windsurf
  • n8n
  • LangChain

and any other MCP client

Agents fail where documents contradict each other

In a demonstration the agent answers prepared questions and the cost of an error is zero. In production it writes to clients, edits records and confirms terms — and from that point its error becomes a commitment made by the company.

A client asks for a discount. The agent finds an approval for 15% in a March thread and sends the offer. Since June the company has capped discounts at 10%. Both documents sit in the same corpus, both are relevant to the request, and the later one supersedes the earlier. Semantic search does not see that difference.

Orchestration and tracing are given away for free today: they decide which agent runs which step, and they show what it did once it has already done it. Nothing in that layer decides whether there were grounds for the action in the first place.

What Vasko does

  1. 01

    Knowledge on the way in

    The agent receives a slice prepared for the task rather than the whole corpus: the relevant documents, the versions in force, and the history for this client or project.

  2. 02

    Grounds under every claim

    Each claim the agent makes is tied to a fragment of a document: quote, date, source. The grounds open in one click.

  3. 03

    A stop when grounds are absent

    If there is no confirmation, or a later document has superseded it, the action does not go through. The response states which grounds were missing.

  4. 04

    Validation against a scenario set

    The system runs against an agreed set before launch and after every change to the instructions, the model or the corpus.

  5. 05

    A trace after the action

    What fragments were available to the agent, which ones it relied on and which checks failed are all recorded.

Integration

Vasko runs as an MCP server — the same protocol your agent already uses to reach every other tool. The agent architecture does not change.

  1. The server address in the agent configuration

    Vasko is deployed inside your perimeter, so the address and token are issued during rollout.

    {
      "mcpServers": {
        "vasko": {
          "url": "https://vasko.<your-domain>/mcp",
          "headers": { "Authorization": "Bearer ${VASKO_TOKEN}" }
        }
      }
    }
  2. A rule in the system instructions

    One line. After that the agent asks for grounds before every action.

    Call gate before any action. Do not act without approval.

This is everything required from your team. The rest is on our side.

Validation runs on your scenarios

The set is agreed before the work starts: ten common situations where agents fail most often, plus cases from your own practice.

  • A condition was changed by a later document

    What is tested
    Time in force
    Expected behaviour
    The later document applies, the earlier one remains available as history
  • A decision was discussed and then reversed

    What is tested
    Resolving contradictions
    Expected behaviour
    The answer follows the superseding document and the contradiction is shown
  • Two counterparties with similar names

    What is tested
    Data separation
    Expected behaviour
    No overlap in the answer
  • A document is moved to a restricted section

    What is tested
    Permission inheritance
    Expected behaviour
    The document and derived fragments disappear from results
  • A document is deleted after facts were extracted

    What is tested
    Cascading deletion
    Expected behaviour
    A claim without grounds is no longer used
  • An incoming file contains instructions for the agent

    What is tested
    Trust boundary
    Expected behaviour
    The content is handled as data, not as a command
  • The corpus holds no answer

    What is tested
    Refusal
    Expected behaviour
    A refusal that states which information was missing

The run gives you four figures: the share of claims confirmed by a source; the share of answers built on information no longer in force; the share of contradictions found; and the share of correct refusals. The same set runs after every update, so any drop in quality is visible immediately. You score it, on your own data.

Scenario

Your data stays inside your perimeter

Deployment
Inside the customer perimeter or a dedicated one. A cloud option is arranged separately.
Choice of sources
Specific sections, folders and channels are connected. The volume and composition of the data are visible before loading begins.
Access rights
Rights are inherited from the source: if an employee has no access to a document, they see neither the document, nor fragments derived from it, nor answers built on them.
Deletion
Deletion runs through the whole chain: file, fragments, extracted facts, links and cache. A report is produced afterwards.
Trust boundaries
The content of loaded documents is handled as data and cannot become an instruction to the agent.

Where Vasko earns its place in month one

Client-facing work
The agent builds offers within the terms currently in force: prices, discounts, deadlines, warranties.
Internal process
The agent follows current policy rather than a previous revision of it.
Engineering
The agent relies on the technical decisions that were made and sees which of them were overturned, and by what.
Handover between agents
The second agent receives not only the result but the grounds the first one worked from.
Incident review
After a failure you can see what the agent knew, what it relied on and which checks it did not pass.

How we start

  1. 01

    Demonstration

    Forty minutes. We show the system working on a corpus comparable to yours.

  2. 02

    Validation

    You provide an export of documents and at least twenty real scenarios. This is paid work, with cost and timeline fixed in advance.

  3. 03

    Report

    The figures on your scenarios. The rollout decision is made on those numbers.

  4. 04

    Rollout

    Deployment inside the perimeter, agent integration, a procedure for keeping the corpus current, and ongoing support.

Licence cost depends on the size of the corpus, the number of connected agents and the deployment model.

Questions

We will build this ourselves

The technical part is reproducible. What is harder to reproduce is the set of test scenarios and the discipline of re-running it after every change. What usually fails is not the logic but the absence of a regular check.

We already have memory wired into the agent

Memory answers what was said earlier. Vasko answers whether it is still in force and whether it is enough for the action to go through.

Everything works for us

A run against the agreed set takes one day and either confirms that or shows exactly where the discrepancy is.

We are not ready to hand over data

Deployment happens inside your perimeter. For validation a limited export of selected sections is enough.

How much will this slow the agent down

The check runs while the context is assembled and again before the action. The delay is comparable to a call to any external tool and is stated in the report.

Request a demonstration

We reply within one business day. On the call we show Vasko working and agree which scenarios to validate against.

By submitting you agree to the privacy policy

Vasko — an agent acts only when it has grounds