Our multi-agent workflow: how it makes us better and faster

^{By Arne Dierickx (software engineer)}

Getting software delivered faster, without quality taking the hit. That's the expectation businesses have today, and it's a completely fair one. AI makes it more possible than ever.

At we are, we build custom software that automates the manual work running behind your business. Not with a team of a hundred, but with a smaller team of software engineers who treat AI as a full part of the engineering process. Why? Because that's the time we live in. You can't help businesses digitize if you're still working with 5-year-old technology yourself. That's why we stay on top of our game.

‍

Take a platform we're building right now: a mobile app, two dashboards, and an API. Three applications, one project, multiple agents working on it simultaneously. Due to a multi-agent workflow, we were able to deliver fast and they got a bunch of extra features.

‍

First, a quick one: what is an AI coding agent?

An AI coding agent is software that can work on code independently, without needing to be guided step by step. You give it clear instructions on what to build and how, and it gets going: it reads the existing codebase, makes changes, tests the result. Think of it as a digital colleague who picks up a task and handles it end to end.

In practice: multiple agents work on your project at the same time, like a team building the software in parallel. Only now, it's just one very skilled software engineer. That may put the most important concern to rest straight away: an engineer reviews every piece of work that comes out of those agents.

The agents handle the volume. Our engineers keep the hard work and the judgment. The long-term sustainability of your software will always be our responsibility.

We often use Claude Code from Anthropic for this, alongside other tools. But the tool isn't the story. The story is how you deploy them so the result gets better, never worse.

‍

‍

The problem: an agent without context is a liability

Hand an agent your codebase without any context, and you've hired someone who shows up on day one with zero onboarding. The result is inconsistent code, wrong calls, and decisions that don't fit what's already there. But that's not how we're doing it over here. With years of experimentation and learning, we can say that the engineers are pretty comfortable defining context.

Not enough or the wrong context is exactly why a lot of people conclude that AI isn't ready for serious work. As we'd say: skill issue.

‍

The solution: a layered knowledge system for agents

Every agent working on the project gets the right context first. And just like you have to invest time in bringing a junior developer up to speed, you have to invest time in bringing your AI agents up to speed.

We build that context in three layers: a central project document, a dedicated guide for each component, and explicit rules of the game. Each one is explained below.

Layer 1: the project document

One central file that describes the entire project. Written for agents, not for humans. The architecture, the technologies in use, the conventions, the ground rules. Think of it as an onboarding document and a technical bible rolled into one.

It's not static either: agents update it themselves when they spot something missing or incorrect. That way it evolves with the project, as it should.

Layer 2: a dedicated guide for each component

If the project document is the map, the skill guides are the detailed instructions. There's one for each part of the software: for the app, for the dashboards, for the technical engine underneath. Plus guides for recurring tasks, like writing tests or processing feedback. Each one is written as if you're onboarding an experienced developer who knows their craft inside out, but has never seen this project before.

Layer 3: the rules of the game

Multiple agents on the same project need boundaries, otherwise things fall apart quickly. Each agent has a clearly defined territory and stays within it. No agent makes important decisions on its own: when in doubt, they stop and ask.

And perhaps the most important rule of all: agents are not yes-machines. We tell them explicitly that they're allowed to push back. If an approach is unnecessarily complex, we want to hear it. If something's missing, they stop and ask rather than inventing an assumption and building on top of it.

‍

‍

What this gets us in practice

We built a system that automatically picks up feedback on code, carries out the changes, checks that nothing broke, and wraps everything up cleanly. Work that used to take a developer around 30 minutes each time now happens in seconds.

• ‍Less overhead: One agent writes tests, a second builds a screen in the app, a third analyses existing software to prepare a migration. All at the same time. That kind of parallel work is much harder and creates more overhead to organise with a team of people.
  ‍‍
• Never general AI-slop: Every agent follows the same patterns, because they all read the same documentation. No debates over style or approach. The agreements are written down and they're followed. That way, we make sure you won't get any general 'AI-slop'.
  ‍‍
• Knowledge that stays: In a team of people, knowledge walks out the door when someone leaves. With us, that knowledge lives in the documentation. A new agent starts with everything the previous one already knew. Someone taking a holiday? Your project won't be on hold for two weeks.
  ‍
• More time for what we're good at: When agents handle the volume, engineers get more time for what actually matters: architecture and technical choices, mapping out user flows, spotting optimizations, and staying closely aligned with the client throughout.
  ‍

‍

Five things we've learned

1. ‍Context is the new code. The project documentation and the skill guides are not a byproduct. They're as much a part of the project as the software itself, and they have to grow with every change. Update something but forget to update the documentation, and the next agent builds it wrong. Outdated context is just as dangerous as broken code. We hold our documentation to exactly the same standard as our software.
   ‍
2. Iterate. No big bang. We started with a single project document and learned, through trial and error, where agents got stuck. Every time one stumbled over missing context, we wrote down what was missing. Small steps with checks in between will always beat one large attempt you have to unwind afterwards.
   ‍
3. Let agents improve their own documentation. The rule is simple: if you find something wrong in the documentation, fix it. Agents use the documentation, find the gaps, and fill them in. What one agent learns is ready for the next. A system that makes itself better.
   ‍
4. Agents build, Engineers own it. Agents run their own tests and checks after every change. But a human always looks along. Not to rewrite every line, but to assess the decisions: does this fit the whole? Are there edge cases we've missed? Is this the simplest solution? AI speeds up the work. It doesn't replace the judgment.
   ‍
5. Quality over quantity: AI agents let you do a lot more, faster. But speed isn't the point, quality is. Code should be sustainable and scalable. Always focus on quality first; extra speed is just a nice byproduct. Not because we skip steps, but because repetitive work (standard components, writing tests, processing feedback) goes to agents, while our engineers focus on what actually needs thinking.

We've learned a lot more about AI and agentic AI than just these five things over the past few years. Happy to talk if you're interested!

‍

‍

This is how we build software in 2026

For us, AI is a permanent part of how we build, on every project. The difference from two years ago isn't only better tools, though those exist too. It's that we've learned how to deploy them structurally. Not as a replacement for our engineers, but as a serious force multiplier.

The companies investing in this now are building an advantage that compounds fast, and AI is reshaping the software market faster than most expect. Wait it out, and next year you'll be catching up on what everyone else figured out a while ago.

For our clients, it comes down to this: your idea in working software, faster, at a cost that makes sense, built by a team that keeps the technical side in hand. Whether you're weighing custom software or an existing platform, a business case that wasn't worth pursuing two years ago very likely is now.

‍

Curious what this could mean for your project? Let's talk.

‍