VLIRTZ

How we work

What we commit to, and what we do not claim

Most agency pages this deep into a site are a list of adjectives. This one is a list of things that would be obvious if we failed them, plus a plain statement of where we are a younger firm than the alternatives.

Talk about a workflowSee pricing

Commitments

Six things we will be held to

Each of these is written so that failing it would be visible to you, which is the only kind of commitment worth publishing.

We measure before we build
Every build starts by measuring the existing workflow: case volume, handling time, where it stalls, which exceptions recur. You get that baseline in writing. Without it, neither of us can tell afterwards whether the system helped, and 'it feels faster' is not a result.
You get an evaluation set built from your own failures
We assemble a test set from your real historical cases, deliberately including the ones the agent gets wrong, and we report accuracy against known-correct outcomes. This is the artefact that lets someone safely change a prompt or swap a model a year after we leave.
The code lives in your repository
Code and configuration go into a repository you own, running on infrastructure you control. There is no VLIRTZ platform, no licence, and nothing you must keep paying us for in order to keep your own workflow running.
Handover is complete, not deliberately partial
A runbook, a training session with the people who will operate it, and a documented path for what to do when it breaks. We do not withhold operational knowledge to manufacture a retainer. If you take a sustain contract afterwards it should be because you want one.
We will tell you not to build it
If discovery shows your source data cannot support the workflow, or that the genuinely useful deliverable is a documented process rather than software, that is the recommendation you get. It is worse for our invoice and better for your budget, and it has happened.
Data stays in the EU by default
Before customer data moves we document the legal basis, the processor chain, where each processor stores data, and the retention period. Where a capability is only available outside the EU, that becomes an explicit decision you make with the trade-off visible, not a default you discover in an audit.

How we build

How a scoped agent build runs

Two to four weeks from kickoff to handover. The order matters more than the tooling: measure first, prototype on real data second, close the loop third.

  1. 01

    Watch the workflow being done

    2 to 4 days

    We sit with the people who run the process today, and we measure it: how many cases, how long each takes, where they stall, and which exceptions actually recur. Most projects that fail do so because this step was skipped and the brief described the process as management believes it works rather than as it runs.

    You end up with: A measured baseline you can hold the finished system against, and a written list of the exceptions nobody had documented.

  2. 02

    Build the thin version on your real data

    3 to 5 days

    Not a demo on a curated sample. Your records, including the ones with missing fields and inconsistent formatting. This is where you discover that a third of the source rows lack something the workflow depends on, and it is much better to discover that in week one than in month three.

    You end up with: A narrow tool running on production-shaped data, and an honest assessment of whether the rest is worth building.

  3. 03

    Close the agent loop

    1 to 2 weeks

    Now the agent plans across steps, calls the tools it needs, and handles the cases the thin version could not. Human review gates go on every action that is expensive to undo. We build the evaluation set from your real cases at the same time, including the failures, because an agent with no evaluation set is an agent nobody can safely change later.

    You end up with: A working agent, an evaluation suite built from your own cases, and audit logging on every tool call.

  4. 04

    Hand it over properly

    2 to 4 days

    A runbook, a training session with the people who will operate it, and a documented path for what to do when it breaks. We do not make handover deliberately incomplete to keep you dependent on us. If you want us to keep operating it, that is a separate retainer you choose, not a trap you fall into.

    You end up with: Runbook, handover session, and the code and configuration in your own repository.

Guardrails

What we apply to every agent that can act

An agent that can take actions can take wrong ones. These are the six controls that go on by default, before anyone asks.

Read-only first
An agent begins with read access only. Write access to any system of record is added deliberately, per action, after the read-only version has demonstrated it interprets the cases correctly.
Approval gates on irreversible actions
Anything expensive or awkward to undo requires human approval. Moving money, contacting a customer, changing a filed figure, or affecting someone's access to a service all sit behind a gate by default, permanently where that is the right answer.
Confidence-based escalation
Where the agent cannot resolve a case within its defined bounds, it escalates to a person with the context already assembled, rather than guessing. A useful escalation is a success, not a failure.
Full tool-call audit log
Every action, its inputs, and the decision behind it are recorded. This is what makes an incident investigable, and under FINMA, NIS2 or medical-device rules it is a requirement rather than a nicety.
Defined rollback
Any action touching a system of record has a documented way to reverse it. If an action genuinely cannot be reversed, it does not get automated without an approval gate in front of it.
Role-scoped access
The agent's permissions are scoped to the workflow it runs, not to everything its service account could technically reach. Broad credentials are the most common security shortcut in agent projects and we do not take it.

Straight answers

What we do not claim

The agencies competing with us for your search publish numbers we cannot match yet. Rather than leave you to guess where the gaps are, here they are.

We do not publish an implementation count
VLIRTZ was founded in late 2025. Agencies ranking alongside us cite figures like a hundred or more implementations, and we are not going to invent a number to sit next to theirs. When we have client outcomes we are permitted to publish, they will appear here with names or clear anonymisation, and not before.
We do not hold ISO 27001 or ISO 42001
Some competitors do, and if certification is a procurement requirement for you then that is a genuine reason to choose one of them. What we can do is work inside your existing processor agreements and security requirements, and document our processing to the standard your auditor asks for.
We are not a team of fifty
We are founder-led and deliberately small. That is the right shape for one scoped workflow and the wrong shape for staff augmentation or a programme needing ten people on site. We will say which one you need on the first call.
We do not claim model-agnostic superiority
Every agency says it picks the best tool for the job. In practice most builds land on a small set of sensible defaults, and the choice is driven by your data residency, latency and cost constraints rather than by any special insight on our side.

FAQ

Questions about how we work

Why do you publish commitments instead of case studies?
Because we were founded in late 2025 and do not yet have client outcomes we are permitted to publish. Rather than invent a number or stay silent, we publish exactly how we work and what we will be held to. When real case studies exist they will appear with names or clear anonymisation.
How do we verify any of this before hiring you?
Ask us to walk through the guardrails against your specific workflow on the first call, and ask what we would refuse to automate in it. A vendor who cannot name anything they would keep behind a human gate has not thought about your risk.
What happens if the project does not work?
The baseline measurement is what makes that answerable rather than a matter of opinion. If the agent does not beat the process it replaced on your own historical cases, we say so. Because the first engagement is deliberately one scoped workflow, that outcome costs you a scoped build rather than a transformation budget.
Do you sign NDAs and work under our processor agreements?
Yes to both. NDAs are standard. We would rather work inside your existing data processing agreements than insist on our own paperwork, which is usually faster through procurement anyway.
Who actually does the work?
VLIRTZ is founder-led and deliberately small, so the person you speak to on the first call is the person building the system. There are no account managers between you and the engineering, and no offshore delivery team you were not told about.

This page was last reviewed on .