The Orchestration Layer: How broberg.ai Builds Software With Fifteen Agents
Most companies bolted AI onto systems that already existed. broberg.ai built AI-native from the foundation — and then applied the same principle to its own production process. This is what came out: cardmem, an orchestration engine where plans come before code, quality checks happen in a real browser, and the reasoning survives the session.
The bolted-on era is ending
Most companies met AI the same way: something was glued onto the top of a system that already existed. A chat bubble in the corner of a website. A summarise button in a CRM. A copilot in an editor. It works, in the narrow sense that it does something. It also leaves the underlying system exactly as it was — which means the AI can only ever reach whatever the old system happened to expose.
broberg.ai took the other route, and has been on it long enough for it to stop being a bet. The company has been building software since 1995 and now builds AI-native — the phrase on its own front page is blunt about the distinction: "Det er ikke en chatbot klistret oven på en gammel hjemmeside." It is not a chatbot stuck on top of an old website.
That sounds like positioning. This article is about the part that is harder to claim and easier to check: what happens when a company applies that principle to its own production process, and then runs its entire operation on the result.
Which player we are
Four things, taken from the front page rather than from an elevator pitch.
Websites, webshops, platforms, and AI integration — on one engine. Not four product lines with four codebases. The same foundation underneath, which is why a site built for a florist and a platform built for a municipality share the same upgrade path.
EU-first, deliberately. All data hosted in the EU. Built without dependence on Big Tech infrastructure. This is not a compliance checkbox retrofitted after a customer asked; it is why the stack looks the way it does — Mistral for the EU tier, Fly.io in Stockholm, no US round-trip for personal data.
Human in the loop, by default. You approve content before it publishes — or switch on autopilot once you trust it. The order matters. A system that starts autonomous and adds approval later never gets the approval built properly; a system that starts with approval can safely remove it.
Customers who cannot afford to be experimented on. Lundbeck. Grundfos. COWI. Ole Lyngaard. More than forty Danish municipalities. One case covers 16,838 employees. These are not the accounts you win with a demo.
The problem that forced an engine
Here is the thing nobody tells you about building software with AI agents: the coding is not the bottleneck.
An agent can write a feature in twenty minutes. What it cannot do on its own is remember why the feature exists, prove it works in front of a human, notice that it contradicts a decision made three weeks ago, or stop itself from shipping something nobody asked for. Run one agent and you can hold all of that in your head. Run fifteen, across a dozen repositories, and you are no longer a developer — you are an air traffic controller without a radar.
That is the problem cardmem was built to solve. Its own tagline states the goal precisely:
Se din idé blive til et live produkt — sporbart hele vejen. See your idea become a live product — traceable all the way.
Traceable is the load-bearing word.
How the loop actually works
cardmem describes itself as the engine that drives every project in the universe, from first thought to finished, live product. Six steps, and each one exists because skipping it caused a specific kind of damage:
1. Idea. Captured from chat, from a phone, from anywhere. No format required. Ideas that need a form to be recorded are ideas that get lost.
2. Plan. cardmem writes a concrete plan with explicit success criteria before any code is written. This is the step most AI workflows omit, and omitting it is how you end up with a roadmap full of topic strings and no reasoning behind any of them. The plan is written while the context that motivated it is still alive — not "next turn", because there is no next turn for context.
3. Task board. The plan is broken into prioritised tasks, visible to everyone. The board is the to-do list. Not a private list inside an agent's head, where the customer cannot see it and no quality gate can reach it.
4. The agent builds. In the correct repository, against the plan, and then it waits for approval rather than shipping.
5. Quality check — in a real browser. Not "the tests passed". A real browser opens the real surface and verifies it looks and behaves the way it should. A failed check sends the work back. Every delivery carries a screenshot as proof.
6. Live — and round again. The change ships, and the loop starts over.
Four principles hold it together: plan before code, real browser checks, gates before deployment, and screenshot proof on every delivery. None of them are novel individually. What is unusual is enforcing all four on machines that would otherwise be very fast at producing work nobody asked for.
Your entire team, in your pocket
cardmem's mobile surface is not a status dashboard. It is a command centre: direct control of agents from anywhere, 15+ running simultaneously, live chat with each of them, and a notification when a build finishes.
The customer-facing half matters just as much. Clients see the live board, approve designs before anything is built, and get proof of delivery per item. That replaces the two worst artefacts in software consulting — the status email and the status meeting — with something the customer can check without asking anyone.
What orchestration looks like on a bad day
Feature lists are easy to write and hard to believe. So here is a week from our own operation instead, and it is the most honest argument we have.
Five agent sessions, five different repositories, working on unrelated things. Over two days, each of them independently ran into the same class of bug: a measurement that cannot tell two situations apart.
- A scheduled probe read an authentication failure as "nothing pending" and reported healthy for three months while doing nothing at all.
- A cleanup tool's preview always answered "0 items" — so "nothing to clean" and "I am not allowed to tell you" looked identical.
- A paging parameter was accepted by the API and never actually used, so a caller looping through pages fetched page one forever. Nothing errored.
- A secret scanner reported "no findings" for text it had never examined.
- A version marker counted the files it intended to write rather than the ones that landed.
Every one of these fails green. There is no error, no red status, no alert. The system reports success on a question it never answered.
What made the week interesting is not that we found them. It is that the sessions found them in each other's systems, across repository boundaries, and fixed them at both ends of the pipe — one agent measuring the consumer side, another measuring the issuer side, neither taking the other's word for it. Two of the five were caught by a peer saying, in effect, your check could not have detected this even if it were happening.
That is what an orchestration layer buys. Not more code per hour. A structure in which the machines check each other, and the reasoning survives.
The memory underneath
There is one more piece, and it is the reason this website exists.
Agents forget. Every session starts empty. Without somewhere durable to put why a decision was made, the reasoning evaporates the moment a conversation is compacted — and the next session re-derives it, or worse, decides differently.
Trail is that layer: a knowledge base that compiles what it is given rather than searching it on demand. The distinction is architectural, and we have written about it at length in Compile-Time Knowledge: A Technical Argument Against RAG.
For the orchestration story, the relevant part is simple. When one of those five bugs was diagnosed, the lesson did not stay in a chat log. It became a durable note — "a measurement without three outcomes is not a measurement" — searchable by every future session in every repository. The next agent to build a probe finds it before making the same mistake.
Plans in cardmem. Reasoning in Trail. Neither one is a chatbot bolted onto anything.
The through-line
broberg.ai's argument is that AI belongs in the foundation, not on the surface. cardmem is that argument turned on the company itself: the same principle applied to how the work gets made, not just to what gets shipped.
The tell is that we did not build a demo of it. We build everything on it — this site, the platforms behind those municipal deployments, and cardmem itself.
Read more: broberg.ai · cardmem — the core engine · Trail