VLIRTZ

AI agent development

AI agent development

We build AI agents that run one real workflow end to end, in the tools your team already uses, with a human on every decision that is expensive to undo.

Most agent projects fail on context rather than capability. So we measure your workflow as it actually runs before we build anything, and the first working thing you see runs on your own messiest records.

Talk about a workflowSee pricing

What an AI agent actually is

A chatbot answers questions. An agent does work. It reads the systems that hold the truth about a case, plans across several steps, calls the tools it needs, and either finishes the task or hands a person a decision with the evidence already gathered.

That distinction matters because it moves where the difficulty sits. Nobody struggles to make a model produce fluent text. The hard parts are getting the right context in front of it reliably, giving it tools that fail safely, and knowing when it is wrong. Almost all of the engineering on a real agent build goes into those three things rather than into the model.

It also changes the risk. An agent that can act can act wrongly, which is why every build we do starts read-only and draft-first, and why the boundary between what it may do alone and what needs a human is a design decision made at the start rather than a setting adjusted later.

One workflow, not a platform

The most common request we decline is the company-wide assistant. It sounds like a pilot and behaves like a platform commitment: broad scope, no measurable baseline, and no honest way to tell whether it worked.

A single workflow gives you the opposite. We can measure how long it takes today, how many cases run through it, and where it stalls. Four weeks later we can tell you whether the agent handles those cases more consistently than the process it replaced, using your own historical records as the test. If the answer is no, you have spent one scoped build rather than a transformation budget.

Once one workflow is in production, the second and third cost less, because the orchestration, retrieval and evaluation harness already exist. That is the order that gets companies to three working agents. Starting with three rarely gets them to one.

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.

How we build

Positions we hold on every build

These are decisions we make the same way every time, because each one is a reason agent projects fail when it goes the other way.

Bounded autonomy by default

An agent starts read-only and draft-first. Actions that are expensive or awkward to reverse stay behind a human approval gate, permanently if that is the right answer. Full autonomy is something a system earns by demonstrating accuracy on your evaluation set, not a launch feature.

An evaluation set from your real cases

Built from your actual records, including the ones the agent gets wrong. Without it, nobody can safely change a prompt or swap a model six months later, which is how working systems quietly rot.

Every tool call logged

Each 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.

Retrieval quality over model size

Most disappointing agents are not under-powered, they are under-informed. Getting the right context in front of the model reliably matters more than which model it is, and it is where the engineering effort usually belongs.

Your repository, your infrastructure

Code and configuration live in your repository and run on infrastructure you control. There is no VLIRTZ platform you have to keep paying for to keep your own workflow running.

One workflow before three

We decline company-wide assistant scopes. A single workflow, measured and shipped, tells you more about whether this approach works for you than any roadmap, and it is recoverable if the answer is no.

Straight answers

What an AI agent will not do for you

Every one of these has ended a project somewhere. We would rather raise them before you sign than explain them in month two.

It will not fix a process nobody has agreed on
If two departments genuinely disagree about how a case should be handled, an agent forces that disagreement into the open rather than resolving it. That is useful, but it is a management outcome, not a technical one.
It will not rescue unusable source data
Retrieval over clean, structured records is straightforward. Retrieval over scanned documents, three competing sources of truth, and a field that has been wrong since a migration is where budgets disappear. Sometimes the honest recommendation is a data project first.
It will not be right every time
The question is never whether it makes mistakes, it is whether the mistakes are caught before they cost anything. That is what the review gates and the evaluation set are for, and it is why we measure the baseline first.
It will not maintain itself
Models change and your source systems change. An unmaintained agent degrades quietly rather than failing loudly, which is worse. Budget for maintenance or plan to retire it.

Adjacent services

When an agent is not the right first step

Sometimes the honest answer is that you need a decision made or a pipeline filled before anything gets built.

If the harder question is which use case is worth doing at all, our AI consulting sequence produces the architecture and rollout plan your own engineers implement, without a build attached.

If the problem is a pipeline rather than a workflow, AI lead generation identifies and scores prospects from public and first-party signals so sales time goes to people who are genuinely interested.

Pricing

What AI agent development costs

We quote in EUR for this market. Where you land depends on how many systems the agent touches, how usable your data already is, and how expensive a wrong action would be. Ask and you get a range on the first call, not the third.

Agent feasibility review

On request

We measure the workflow, assess whether your data supports it, and tell you whether an agent is the right answer. Includes a scoped build proposal.

Timeline: 1 to 2 weeks

Scoped agent build

On request

One workflow end to end, integrated with your tools, human review gates, evaluation set, audit logging, runbook and handover.

Timeline: 2 to 4 weeks

Additional workflow

On request

A second or third agent reusing the orchestration, retrieval and evaluation harness from the first.

Timeline: 2 to 3 weeks each

Sustain retainer

On request

Monitoring, drift checks, model and prompt updates, and a defined response time on failures.

Timeline: Rolling

Full pricing breakdownGet a range for your workflow

By market

Where we build agents

Each market page covers the workflows we are actually asked to build there, the regulators that shape the design, and pricing in the local currency.

Sweden

Stockholm

Fintech and payments, Fintech and payments

Denmark

Copenhagen

Life sciences and pharma, Life sciences

Switzerland

Zurich

Private banking and wealth management, Insurance and reinsurance

Netherlands

Amsterdam

Fintech and payments, Fintech and payments

FAQ

Questions we get about AI agent development

What is an AI agent, as opposed to a chatbot?
A chatbot answers. An agent acts. It reads your sources of truth, plans across several steps, calls the tools it needs, and either completes the task or hands a human a decision with the context already assembled. The interesting engineering is in the tool use and the guardrails, not in the conversation.
How long does it take to build an AI agent?
Two to four weeks from kickoff to handover for one scoped workflow, with a one-to-two week feasibility review ahead of it if the use case is not settled. Anything quoted at under a week is a demo rather than a system, and an open-ended timeline should worry you.
How much does AI agent development cost?
A scoped single-workflow build is the usual entry point. What moves the number is how many systems the agent touches, how usable your data already is before anyone cleans it, how expensive a wrong action would be, and whether your team or ours operates it afterwards. Bands and drivers are on the pricing page.
Will the agent act autonomously?
It starts read-only and draft-first, and anything expensive or awkward to undo stays behind a human approval gate. Autonomy is earned by demonstrating accuracy on your own evaluation set over real volume, not enabled at launch because it demos better. For many workflows draft-and-approve is the permanent right answer and still captures most of the value.
Which frameworks and models do you use?
We are deliberately not tied to one. Most builds use an orchestration layer such as LangGraph with a hosted model and a vector store for retrieval, but the choice follows your data residency, latency and cost constraints. Retrieval quality affects the result far more than which model sits behind it.
What do we own at the end?
Code and configuration in your own repository, running on infrastructure you control, plus the evaluation set, the audit logging and a runbook. There is no VLIRTZ platform you have to keep paying for to keep your own workflow running.
Do you build one agent or a whole platform?
One, first, always. We decline company-wide assistant scopes, because a single workflow that is measured and shipped tells you more about whether this approach works for you than any roadmap, and it is recoverable if the answer turns out to be no. Additional workflows reuse the first one's infrastructure and cost less.
How do you prove the agent actually works?
We measure the existing workflow before building anything, so there is a baseline. Then we build an evaluation set from your real historical cases, including the ones the agent gets wrong, and report accuracy against known-correct outcomes. Without that set nobody can safely change a prompt or swap a model later.

Related reading

Talk about a workflowSee pricing

This page was last reviewed on .