Everyone is talking about agentic AI. We have laid the foundations.

In May we wrote a sentence that sounded a little defiant: we simply got started. No pilot project, no steering committee, no concept paper. One agent, one task, and the willingness to throw the whole thing out again. Eight articles later is a good moment to look at what has stuck.

What has held up

Knowledge beats wording. We started out believing that an agent mainly needs good instructions. In fact, almost everything depends on what it knows. When a result misses the mark, the cause is nearly always a gap in the knowledge base, not clumsy wording. That turned our way of working on its head: today we write down knowledge where we used to fine-tune instructions.

An agent is not a tool but an asset. It does not get better because you use it more often. It gets better because someone looks after it. That is an unspectacular insight with considerable consequences for planning: the effort does not stop once the agent is built, it just shifts.

Approval stays with people. We have never questioned this and would not today. It looks like a brake and is the opposite: if you know someone will check at the end, you can use the agent earlier and more boldly.

What we underestimated

The speed of the team. We expected the technology to become the bottleneck. It was our capacity to take things in. An agent can produce more in an hour than a person can assess in a day. If you don’t plan for that, you build up pressure nobody asked for.

The quiet crowding-out. Not everyone on a team gets on board at the same pace, and those who hesitate rarely say so out loud. It took us a while to see that holding back is not a lack of interest but, more often than not, an unanswered question.

The baseline. We did not measure how long things took before. That means we still lack a clean comparison for the first phase. It is the one measurement you cannot make up for later. And it is the mistake we pass on most often, so that nobody repeats it.

What we are working on now

The next step is not a better version of the same thing. In AIC Group’s software development, we are currently trialling how several agents can work together. Not three agents tossing tasks to each other, but a system with several layers: agents that translate business requirements into stories, implement them and test them. Above them, an orchestration layer that distributes the work. Alongside them, instances that check independently whether our standards are being met. When several tasks are worked on in parallel, individual roles run more than once, each based on the same role description.

People remain a fixed part of the process at two points: defining the business requirements, and checking before anything moves on.

We deliberately say “we are trialling”. This runs internally; it is not a service we offer and not established practice. What is clear after the first few weeks, though: bug fixes and new features are coming out at a pace we have not reached before. And contrary to what we expected, this is not at the expense of quality. The code has become more consistent, not more rushed.

We don’t have reliable figures on this yet. Which brings us back to the last article.

Where we stand

The headline of this article is deliberately modest. Having laid the foundations does not mean having arrived. It means that we now know which questions have to come first, and in what order. Can the team carry it? Who uses what, for what purpose? Does it work in day-to-day business? A year ago we would not have asked these three questions in this order. We would have started with the third, because it is the most interesting. That would have been a mistake. Thank you for reading this far. If you are at one of these points yourself right now, get in touch. Sharing notes with others who are trying the same thing has been the most useful part of the whole year for us.