1. The rose that cannot be commanded
A Big Bang is an explosion. It is spectacular, it is swift, and it leaves behind a landscape in which nothing is as it was before — not even what was supposed to work. The history of digitalisation over the last twenty years is a list of Big Bangs: group-wide software roll-outs that went live on the first Monday because the board needed a deadline.
If you want roses, you don’t buy an explosion. The gardener does not force a bloom — he allows it its cycles: overwintering, pruning, waiting, observing. It is not the variety of rose that matters, but whether the soil was prepared before planting. Every gardener knows: if you plant too much at once, you lose everything at once.
In the age of agents, this saying is no longer just a pleasantry, but risk management. For the agent rollout differs from any ERP implementation in one crucial respect: it does not merely plant systems; it plants the capacity to act. A misguided agent is not a crashing programme, but an active agent with access. A ‘Big Bang’ does not scale successes — it scales mistakes. The rollout itself becomes the security architecture.
Key phrase: “Patience brings roses: short cycles, patient scope.”
Stage 2.1 Why agents at all? — the question before the question
There is a question that must come even before the ‘roses’ question, and one that consultants are least likely to ask: Why roses? If you don’t first ask the gardener what he wants to do with the flowers, you’ll end up with a flowerbed, but not a garden.
The agent craze has reversed this order. In many companies, the answer to the question ‘Why do we use agents?’ is, quite frankly, this: Because it’s en vogue. Because everyone else is doing it too. Because at the next trade fair, nobody wants to have to explain why they don’t have one yet. The agent has become a status symbol — and status symbols are acquired before the need for them is assessed. This is the agenda-driven logic of the digitalisation narrative in its purest form: first the tool, then the search for a problem that might justify it.
The test is simple and uncomfortable: an agent must be able to specify what it solves, simplifies or improves for the company — not in the language of trade fairs, but in the language of the business. Does it take on a task that would otherwise have to be done by a human? Does it speed up a process that depends on the customer? Does it relieve a burden that nobody wants to pay for? If none of these questions has an answer, the agent is not a necessity but a mere ornament — and an ornament with access permissions is the most expensive thing a company can acquire.
That is why the same applies to the question ‘Why agents?’ as to every assertion in this book: the answer is an obligation to justify, not an obligation to enthuse. Anyone who cannot name a reason does not need an agent — and anyone who can name a reason has only just reached the start of the second question, which comes in the next section. For the reason for having an agent does not yet justify the number.
2.3 How many agents? — the question before planting the first rose
The gardener from the first section has a question that consultants rarely ask him: How many roses should I actually plant? The gardener’s answer sounds trite, yet it is the whole art of it: as many as necessary, as few as possible. Not because roses are expensive — but because every rose consumes soil, light and attention, and because a bed that is planted too densely will not allow any of its plants to thrive.
For a swarm of agents, this statement is no longer just a piece of gardening wisdom, but an architectural rule with three justifications. Every agent in a swarm is an authorised actor: it has tools, access rights, storage and communication channels. Any agent that cannot justify its existence is like a room in a house that nobody guards — it increases the attack surface without providing any benefit. That is the first reason, and it would be enough on its own. But the age of cost accounting has added a second: any agent that cannot justify its existence consumes tokens without providing any benefit — the cost base grows alongside the attack surface, silently, with every call. An agent’s existence check is therefore both a security audit and a financial audit rolled into a single question: Why are you here?
The third reason is the oldest of all, and it comes from the kitchen: too many cooks spoil the broth. Every additional cook is another set of mouths that can spoil the broth — in an agent swarm, this means: every additional agent is both a coordination surface and a compromise surface. The swarm is not difficult to manage because agents are complicated, but because the number of connections grows with every member that is added without justification.
This gives rise to the procedure outlined in this chapter, and it is the real reason why this is not a ‘Big Bang’ chapter: the question ‘How many agents?’ does not have a number as its answer, but rather a proof. Anyone who knows the answer before the rollout begins has not justified the setup, but merely populated it — twelve agents from the supplier’s package are twelve unanswered questions. The justification does not arise at the table or in the plan, but in the process itself: with every single addition, step by step, agent by agent. The swarm does not grow through installation, but through justification. A rollout without a ‘Big Bang’ is therefore more than just a pacing strategy: it is the only process in which the question ‘Why do you exist?’ can be asked before the agent exists — and that is precisely the difference between a configuration and an architecture.
Stage 2.3 — The vision before the ground-breaking ceremony
Before the first agent is up and running, before the first pilot is selected, before the backlog is created — the announcement must be made to everyone. Not the announcement in the sense of Section 4 (the fait accompli), but the vision announcement: the entire workforce, across departments and teams, learns what lies ahead for the company — why, for what purpose, and in what stages.
This is not a celebratory event nor a memo to senior management. It is the foundation laid with three building blocks:
- Why for everyone. The question that preoccupies every employee from day one — “What does this mean for my job?” — is answered before it turns into anxiety in the coffee kitchen. Job anxiety is not a marginal phenomenon; it is the greatest fuel for resistance. Those who do not take it seriously will reap it as a backlash against the roll-out.
- A single direction, across departments. The vision is communicated to the entire company, not silo by silo in tailored versions. Those who inform departments individually buy themselves short-term peace and long-term contradictions: each department hears its own story, and the stories collide at the latest when agents cross over into other processes — which, by definition, they do.
- Just once, but do it properly. The vision announcement is not a recurring event repeated at every iteration — it is the ceremonial starting signal. After that, the engagement cascade takes over: everyone focuses on the ‘why’, the OKR owners on the ‘what’, and the process owners on the ‘how’. Stage 0 sets the direction for the whole endeavour; the stages that follow set the pace.
The message that must resonate in every line: Every employee is needed — and no one’s job is at risk. This isn’t just reassurance; it’s the truth of the architecture: an agent-based system thrives on the knowledge that only humans possess — the exceptions, the workarounds, the tried-and-tested methods. Without the workforce, there’s nothing to orchestrate. Anyone who frames the transformation as a threat (“Anyone who doesn’t go along with it will be replaced”) is sabotaging their own project: the very knowledge the system needs will then no longer be shared. The message is not a favour — it is the procurement logic for the most valuable raw material.
And it has to overcome a psychological barrier that is older than any technology: resistance is not ignorance, but identity. Anyone who, for twenty years, has been ‘the one who knows how it works’ has more to lose than just a job — and the more competent someone is, the more resistant they become. That is why no message simply stating ‘You are needed’ will work against this — the abstraction ‘You are part of the journey’ reads as: ‘We haven’t yet worked out what that means for you, but please do not resist.’ The difference between instruction and participation is the difference between told you are needed and given the pen: a named role, a concrete task, a tool in the hand. Whoever is given the pen is no longer a recipient — they are an author. The two forms of intervention for this stem from the author’s old workshop: the pen for the role, the cockpit visit for the mystery (described in detail in *OrgDNA: The Human-AI Constitution for the Enterprise*).
The Early Adopters: Transformation on an equal footing
The vision statement reaches everyone — but it does not convince everyone in the same way. That is why, based on experience from transformation courses: In every team and every department, the naturally curious are appointed as early adopters — not by email directive from above, but as a voluntary role. Their task is not training, but translation:
- Equal footing instead of a podium. A colleague says, “I’ve tried it out, and this is what happened to me” — that’s what wins people over where every change presentation slide falls flat. The sceptic in the team trusts their team mate, not the consultant with their slides.
- A safe space to experiment. The early adopters are the low-threshold point of contact: a place where you can ask silly questions without having to ask them in front of the whole department. The first contact with the agent happens in passing, over a coffee — not in a classroom.
- Feedback loop to the top. The early adopters report back on what’s really resonating within the team — what fears, what objections, what use cases. This is flat power distance in role form: the truth travels upwards before it travels to a citizens’ initiative.
- A trial period before promotion. Those who perform well as early adopters become visible on the career ladder: pilot owner, process owner, perhaps governance. The transformation creates its own architects — a career path rather than a lure.
Quote from the book: “It’s not the consultant with their slides who does the persuading. It’s the colleague who’s simply given it a go.”
Anyone who skips Stage 0 will pay for it later — with interest. A rollout without a ‘Big Bang’ is not a small-scale stealth rollout: a pilot that the workforce hears about in the coffee room is a ‘Big Bang’ in slow motion. The surprise isn’t any smaller; it’s just delayed.
3. The phased plan: one system, one node, one person
The path from pilot to full-scale operation is not a straight line, but a staircase. Each step must provide its own proof before the next is taken:
Stage 1 — The pilot. One system. One node. One person. No more. The pilot is not a miniature model of the corporation, but a testing ground: does the hub demonstrate that it maintains authorisation? Does the agent demonstrate that they respect the boundaries? Does the log demonstrate that every step can be traced? The pilot is run with the same rigour as the full-scale operation will be later — just on a fraction of the scale.
Stage 2 — Scaling. Only once the pilot has measured its performance — not just sensed it, but measured it — does the scope expand. One additional department, one use case, one agent. Not everything. Scaling means that every expansion answers the question: What has the pilot proven, and what new risks are now being taken for the first time?
Stage 3 — Continuous improvement. The rollout does not end — it becomes routine. Each iteration re-evaluates the proof of concept because the environment changes: new models, new attacks, new staff. A system that stops learning begins to become obsolete — the rollout without a ‘big bang’ is the only one that can keep pace with the agent-driven era, because it never has to be ‘finished’.
The crucial point: short cycles, patient scope. The cycles are short because the world moves fast. The scope is patient because trust grows slowly. Anyone who confuses the two — short cycles with rapid scope expansion, patient cycles with sluggish scope expansion — gets both wrong.
4. The Backlog Principle: one department, one use case, one guard
The backlog is the translation of the Gardener Principle into project form. Exactly three things per iteration:
- One department. Not ‘everyone’, not ‘the company’ — a department with a named owner who bears responsibility.
- One use case. A real-world scenario with real consequences, not a toy demo or a showcase project that exists solely for presentations.
- A guard. Each iteration expands not only capabilities but also boundaries. An agent without a new guard is an iteration without progress in security awareness.
This is the reversal of procurement logic: not ‘buy first, then set limits’ — but ‘build the boundary alongside every expansion’. The guard is not a drawback; it is proof that the iteration was planned. Anyone who cannot specify a Guard detail has not defined an iteration, but merely a mood.
5. Announcement-based procurement and its four predictable consequences
There is a form of procurement that small and medium-sized enterprises know as well as they know the rain: the announcement. A board member decides, a project team makes the purchase, and the result is presented to the workforce — as a fait accompli, complete with confetti and a sense of obligation. “From Q3 onwards, you’ll be working with agents.”
The four consequences are not risks; they are predictions:
- Resistance instead of participation. Those who weren’t consulted respond with refusal — not out of malice, but out of self-preservation. The workforce becomes a citizens’ initiative against its own tool.
- Knowledge is left out. Those who truly know the process — its exceptions, its detours, its sacred rituals — have no ownership of the system. Their tacit knowledge, the most valuable building block of any agent-based architecture, is not incorporated. The agent learns the process as it appears on paper, not as it is lived.
- Shadow AI as a counter-rollout. What is officially imposed is unofficially circumvented. Staff bring their own tools, their own chat groups, their own accounts — the uncontrolled rollout begins exactly where the controlled one ended. The announcement creates its own risk.
- The reversal of blame at the first incident. When the inevitable error occurs, the incident is not a failure of the rollout — it is proof to the workforce that they were right. Any subsequent training is perceived as a punishment; every new rule as an admission of fault.
The alternative is not a question of pace, but of authorship: Those affected are authors, not recipients. The non-‘Big Bang’ rollout does not begin with the technology, but with the people who will later manage it. The agent is not introduced — it is presented. People are given the ‘why’. Agents are given the ‘what’. Anyone who swaps these around will face resistance from both sides.
6. The bridge to Chapter 8: The rollout as seamless integration
The Two-Circles Model and the phased rollout are the same process described across two chapters: building the boundary (Chapter 8) and bringing the boundary to life (Chapter 9). A guard who exists only on paper is a token security checkpoint — a junction that never sounds its alarm is not proof of security, but of blindness. It is only the rollout that tests the seam in everyday practice: does the authorisation process work with a real customer, under real time pressure, with real exceptions? The rollout’s stages are, at the same time, the litmus test for the boundary. And the MAS finding from Chapter 8 applies here with even greater force: anyone who scales the swarm without checking the topology also scales the attack surface — the rollout is the moment when architecture becomes a responsibility.
7. The chapter’s honest limitations
This chapter promises no security — it promises limitations from the outset:
- Patience costs money. A slow rollout is not the cheapest option. It is the cheaper option in relation to the follow-on costs — the comparison only holds against the ‘Big Bang’ approach, not against a zero-scope project.
- Short cycles demand leadership. An iterative cycle without an owner, without a deadline, without metrics degenerates into a waiting room: participation without pace ends in endless negotiation.
- Not every company can afford to wait. There are circumstances that force a rapid roll-out — competition, the customer, a crisis. Even then, the following applies: the scope can be negotiated, but the sequence cannot. Even in crisis mode, the ‘staircase’ approach applies, only faster.
- The pilot project can be misleading. What works with one person does not automatically work with twenty — scaling is not a continuation, but a new test. This chapter offers a structure to counter this illusion, not a guarantee.
8. The Key Step: What SMEs Will Do Tomorrow
- Inform the entire workforce about the vision — once, across all departments, explaining the ‘why’.
- Choose a department with a designated owner — not the most enthusiastic, but the most forward-looking.
- Choose a use case with real consequences and a ‘guard’ to limit it.
- Set an iteration length — and stick to it, no matter what or who.
- Measure performance before any expansion: has the release been maintained? Has the boundary been respected? Is the log complete?
- Involve those affected in the ‘why’ before you show them the ‘what’.
Then the rose is not commanded. It is nurtured. 🌹
