What we build

01.1

Six layers, one team

The layers are not meant to be bought separately. The value is that nobody has to mediate between them.

Architecture

How systems are cut, how data flows, which integrations to make.

Backend

Domain logic, interfaces, connections to existing systems, including those without a usable API.

Frontend

Interfaces that fit the process rather than the framework.

Data

Relational, vector, documents, chosen by access pattern.

Infrastructure

Containers, CI and CD, GPU operation, monitoring.

Operations

Updates, regression tests, cost control, on call.

01.2

Stage 01: single model

A small, tightly scoped model for exactly one task inside an existing process. Quick to start, low risk, often possible to run locally.

Typical cases

Classifying documents, extracting fields from invoices, preparing free text for an existing system, pre sorting tickets.

What you get

A usable module with a defined interface, a test set and a measured hit rate. Not a demo.

Prerequisite

Sample data from the real process and a person who can judge what a correct result looks like.

01.3

Stage 02: agent on the web

An agent with tool access in a web interface, for a defined user group. Connected to internal systems, with access control and traceable results.

Typical cases

An internal knowledge assistant over your own documents, research across existing data, service support with a view into the business systems.

What you get

A working application with a role model, a log of every tool call and an evaluation path that makes quality loss visible.

Prerequisite

Access to the systems to connect and a settled role and permission model.

01.4

Stage 03: agent in the process

An agent that carries out work steps independently and sits inside existing business processes, with approval points, error handling and logging.

Typical cases

Taking in requests, looking things up, creating records, preparing replies and passing them for approval.

What you get

A flow integrated into the business process with defined approval points, restart points after failures and a log that holds up as evidence.

Prerequisite

A documented process and a decision on where a human has to sign off.

01.5

Stage 04: autonomous agents in a product

Agent systems available at scale as part of a product: multi tenant, with load behaviour, cost control per request, resilience and versioning of prompts, tools and models.

Typical cases

Agent features as part of a SaaS product, automated processing at high throughput, customer specific agents on a shared platform.

What you get

An operating concept with metrics: cost per request, latency budget, error budget, a defined process for model changes including regression tests.

Prerequisite

A load profile, a tenant model and the willingness to treat operations as a standing task.

01.6

Cross cutting: self improving agents

Not a stage of its own but a property that belongs to every stage once the agent is in production. This is what we build for it.

Feedback loop

Capture of approvals, rejections and corrections where they happen, with previous state, reason and outcome.

A test set that grows

Corrections turned into test cases with an expected output, split into regression cases and new capabilities.

Automated scoring

Recurring runs across the whole set, metrics per case group, cost and latency included.

Candidate procedure

Changes to instructions, tools, rules or the model as a versioned candidate, compared against the running version, promoted only on an improvement with no regression elsewhere.

Fallback

The previous version stays runnable, with automatic rollback as soon as production metrics diverge.

Prerequisite

People who actually approve or reject what the agent proposes. Without that feedback there is nothing to learn from.

What that looks like step by step →