Why we rebuilt our MAS
Customers’ decisions are more individual than ever: when, what, through which channel. Why the new MAS is our answer to this, and why everything starts with a central data base.
FOLLOW US ...
Everyone is talking about the AI Act. We're talking about governance.
The last article was about the maturity required before signing with your first agent. It ended with a question that sounds more innocent than it actually is: Who actually reviews what the agent produces?
That’s exactly where readiness ends. And that’s where governance begins.
Governance sounds like a set of rules
When people hear that word, most think of guidelines, approval matrices, and a PDF that no one ever opens. In practice, it all comes down to three questions:
Who assigns which agent to which task? Who reviews the results before they leave the office? And where do they go if something goes wrong?
If the team’s answers are the same, governance already exists—even without a single document. If they differ, even the best set of rules won’t change that.
At the AIC Group, we gradually realized this. First, a second subject area was added, then more tasks, more knowledge bases, and more people working with the agent. Each expansion on its own was small.
But with an agent, nothing stands on its own. A new knowledge file doesn’t just answer the new question—it interferes with the old ones. An additional rule can override an existing one without anyone noticing, until the first result turns out to be wrong. And the more people work with it, the less you realize that they understand it differently.
The real work involved in expanding, therefore, isn’t the act of adding. It lies in determining whether the new elements interact with what already exists and whether the guidelines from back then are still sufficient. That was the moment when a way of working had to become a mutual agreement.
Governance takes shape during construction, not afterward
We see two patterns time and time again. Some people want to have everything figured out first and therefore never get started. Others just dive right in—and there are far more of them. They do give some thought to who will be overseeing things and what the agent should avoid doing. But those thoughts stay in their heads. Six months later, no one remembers exactly what was agreed upon.
That's why we write it down during construction and not afterward. We have it recorded in three places.
During cutting. Anyone who clearly describes an agent’s role, task, and context has, in effect, already classified it. After all, it is not the system that determines the risk, but the intended use. The same language model is uncontroversial as an internal research tool but poses a high risk in the job application process. This can only be deduced from the question of what the agent is intended to do. Every sensible agent project begins with that question anyway. The AI Regulation thus formalizes here what governance means anyway.
At the guardrails. The System Prompt is where boundaries actually take effect. What the agent shouldn’t do, where to ask for clarification, when to hand things off: That’s all laid out there, not in an appendix to the project manual.
During optimization. An agent that has been running for a year rarely does the same thing it did on the first day. Tasks expand, new data sources are added, and someone comes up with an idea. The question is not just whether the output improves, but whether the purpose of the agent has shifted.
If there's more than one agent
What we experienced then is something that happens sooner or later in every project. It never gave any warning beforehand, and at some point, it’s no longer enough for just two people to know what was intended.
That's why we're putting three things in writing.
The Agent Map. It shows what’s happening where: which agents are involved, what sources they draw on, which teams they’re assigned to, and in what direction the whole thing is growing. We create it early on and keep updating it. For governance, it’s the most important tool because it helps answer questions that would otherwise remain unresolved. Who else besides this one agent accesses this source? What are the implications of a change that currently seems harmless? And if an agent is to be granted more access or more leeway: Is the purpose still the same as it was at the beginning? You can see this immediately in an overview. Spread across many individual documents, no one notices it.
The agent profile. A readable blueprint for each agent. It records what role the agent has, which tasks it supports, where its limits lie, who checks and approves, and from when you take responsibility for it yourselves. With version and date. It is the only document that even someone who never works with the agent can understand: management, data protection, the works council, a successor on the team. Whatever is only in the system prompt is invisible to these people.
The overarching agent concept. As soon as several agents are meant to work together, the individual profile is no longer enough. Who may do what, where is work handed over, where do people step in? We derive it from the individual profiles. What was written down beforehand pays off here.
As for the third point, we’re still in the early stages ourselves and are currently exploring what that might look like. One thing has been clear to us from the start: When agents work together that aren’t yet functioning properly on their own, their errors multiply. The maturity of the individual agents isn’t a preliminary step that can be skipped; it’s a prerequisite.
The point that stays
There’s one order of priority we don’t negotiate: governance before autonomy. First the guidelines, then the freedoms. If you do it the other way around, it works for a while, but then it doesn’t anymore.
In our day-to-day work, this means: The agent makes a suggestion, we confirm it, and then it’s carried out. This isn’t a rule set in stone, but rather the natural result of the sequence of steps. How much an agent handles on their own depends on their level of experience and the nature of the task. What must not change, however, is the order: First, we discuss and document what they’re allowed to do; then they’re given the leeway to act. Not the other way around, and not as an afterthought.
That sounds like a brake and is the opposite. If you know someone is looking, you can use the agent earlier and more boldly. And once you have set the guard rails deliberately, you can widen them deliberately later. Without them, every extension becomes a nail-biter.
And then what?
Readiness determines whether the team can handle it. Governance determines who is responsible for what. That leaves the third question, and it’s the most uncomfortable one: Does this actually accomplish anything?
That’s what the next episode is about.
Write to us. We’d be happy to share our approach.
More articles…
Everyone is talking about using AI.
An agent does not get better because you use it more often, but because you look after it. On the two habits that turn an AI assistant into a real sparring partner.
Everyone is talking about prompts.
At AIC Group GmbH we build our AI agent ourselves, with our own knowledge base rather than just a good prompt. We show which three knowledge sources make an agent truly reliable.
*Some articles are created using AI.
