How long does it take to build an AI agent?

Two to four weeks from kickoff to handover for a scoped single-workflow agent, with a one-to-two week feasibility review ahead of it if the use case is not settled. We travel to Copenhagen for kickoff and handover; the build itself runs remotely with a weekly review.

How much does AI agent development cost in Denmark?

A scoped build is the usual entry point. The number moves with how many systems the agent touches, how usable your data already is, how expensive a wrong action would be, and who operates it afterwards. The pricing page publishes the bands and the drivers.

Do you integrate with e-conomic, Billy or WorkZone?

Yes, and we scope those against the actual API rather than the marketing page. Danish business tooling is not exotic, but it is not what a generic AI vendor has built against, and the honest estimate depends on how each specific API handles pagination, rate limits and error states.

Will the agent act on its own?

It starts read-only and draft-first, and anything expensive to undo stays behind human approval. For the document-heavy workflows common in Denmark, draft-and-approve is usually the permanent right answer, and it still captures most of the time saving because the bottleneck is the reading rather than the final decision.

Can the agent work in Danish?

It can process and produce Danish-language content. What we will not claim is that we are the right people to tune Danish customer-facing copy for tone, since our working language is English. For internal document workflows, which is most of what we build in Denmark, this is not a constraint.

How do you prove it actually works?

We measure the workflow before building, then run the finished agent against a set of your historical cases with known-correct outcomes. Copenhagen's document-heavy workflows are well suited to this because the right answer is verifiable, which is exactly why we steer towards them.

What do we own afterwards?

Code and configuration in your own repository, running on infrastructure you control, plus the evaluation set, audit logging and a runbook. No platform dependency on us.

Do you have an office in Copenhagen?

No. We are headquartered in Stockholms lan and work with Danish clients remotely, travelling for kickoff and key milestones. There is no time difference, and Arlanda to Kastrup is a little over an hour in the air.

Built for Denmark, from Stockholm

AI agent development in Copenhagen

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

Danish buyers ask the operational questions early, which we consider a good sign. So this page leads with what the agent will and will not do rather than with what it could theoretically become.

Talk about a workflow See pricing

Documentation-heavy workflows are the good candidates

Copenhagen's sector mix produces an unusually high share of workflows where the bottleneck is reading and cross-checking rather than deciding. Life sciences submissions, supplier qualification, maritime paperwork, adverse event intake. These are strong agent candidates for a specific reason: the source material is written down, and the correct answer is verifiable after the fact.

That verifiability is what makes a real evaluation set possible. We can take two hundred historical cases, run the agent against them, and tell you its accuracy against known-correct outcomes. Workflows where the right answer is a matter of judgement do not give you that, and they are much harder to deploy responsibly.

So when a Danish client brings us a menu of candidate workflows, the ones we push towards are almost always the document-heavy ones, even when they seem less exciting than the customer-facing option.

The Danish integrations that decide the estimate

An agent that cannot reach your systems is not useful, and Danish businesses run on a specific stack. Accounting and invoicing usually means e-conomic, Billy or Dinero. Public sector and public-adjacent work often means case management in WorkZone. Identity and payment flows touch MitID and NemKonto.

None of these are exotic, but they are not what a generic AI vendor has built against before. The difference between a two-day integration and a two-week one is almost always whether someone read the API's pagination, rate-limit and error behaviour before quoting.

We scope against the actual API rather than the marketing page, and we say plainly when a system's interface will not support what the workflow needs. That answer arrives at scoping, not halfway through a build.

NIS2 and why logging is build scope

If you are an in-scope entity in energy, transport or health, NIS2 reaches the agent more than most clients expect. The incident reporting and supply-chain security obligations land on the logging and access control around the system, not merely on the model.

In practice this means every tool call the agent makes is recorded with its inputs and the decision behind it, access is role-scoped, and there is a documented path for what happens during an incident. We treat all of that as engineering work in the build rather than paperwork assembled before signature.

The same logging is what makes the system investigable when something does go wrong, so this is not compliance overhead sitting on top of a working system. It is part of what makes it a working system.

Use cases

What we are asked to build in Copenhagen

Real workflow shapes from this market, with the point where a human stays in the loop stated for each one.

Life sciences and pharma

Regulatory document cross-checking

Submissions and supplier qualification files where the work is reading and cross-referencing rather than deciding. The agent assembles the file, flags inconsistencies against the source documents, and leaves the judgement with a regulatory affairs specialist.

Life sciences

Adverse event intake triage

Incoming reports arriving in inconsistent formats that must be classified and routed within a deadline. The agent extracts the structured fields and proposes a classification; a human confirms it, because the cost of a wrong classification here is not recoverable.

Cleantech and energy

Alarm and alert prioritisation

Operational monitoring that produces far more alerts than anyone can read, where the important one is buried in noise. The agent assembles context around each alert and ranks it. It does not resolve them, because in this setting a false negative is expensive.

Maritime and logistics

Shipping document extraction

Bills of lading, customs paperwork and manifests across formats never designed to be machine-readable. This work lives or dies on retrieval quality rather than reasoning, and we scope it accordingly.

Consumer brands and SMEs

Bookkeeping classification

Transaction classification and payout reconciliation against e-conomic, Billy or Dinero. High volume, rules mostly written down, and an obvious human gate on anything that changes a filed figure.

How we build

A Copenhagen agent build, week by week

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.

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

Pricing

What an AI agent costs in Copenhagen

We quote in DKK 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 Danish systems, 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 breakdown Get a range for your workflow

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.

More about working with us in Copenhagen

This page covers how we build agents. The Copenhagen market page covers the rest: the regulators that shape a project there, the sectors we see most, and when we are the wrong partner.

AI Software Agency in Copenhagen

FAQ