An agent project covering 12 countries with their own language variants went into production after two weeks, validated against full live operation. A second, considerably smaller project took five weeks and delivered less. The order is inverted against project size.
What set the pace was the documentation of the processes the agent was meant to handle.
What made the difference?
In the first project, data had to be transformed weekly according to rules that differed in each of the 12 countries. Those rules had been documented over years and repeatedly extended and reviewed, exceptions included. The agent could be built almost one to one from that documentation. At the end there was an expert session with a few open questions, after which a system ran that identified the applicable rules by itself and produced the expected result. Acceptance was tested against live production, with full agreement.
In the second project the scope was smaller, but the foundation was missing. Much of the process existed only in individual heads. That produced considerably more rounds of clarification, spread across five weeks, each one triggered by a rule nobody had mentioned before. After delivery, an employee reported what he called an error in the application. It was not an error. The system did what had been described to it. The sentence that came up in that conversation describes the problem better than any study does: I don’t need to document that, I know it without documentation.
The gap itself was easy to close. The real difference sat elsewhere: instead of filling in the missing documentation and closing the case, the process was worked through again together with the team, including the parts that were not part of the assignment. That costs time nobody had planned for. It also prevents the next gap from surfacing only when the next agent hits it.
What does a documented process mean in marketing?
The case above is a data process. In marketing the same problem looks different and behaves the same. Documented means here: the logic of a campaign, the rules by which segments are built, the approval paths per market and the tonality guidelines exist in a form someone outside the team can follow.
The standard case is almost always described. What is missing are the deviations: the customer with their own pricing logic, the region with an additional approval step, the campaign that runs differently for historical reasons. Those deviations decide whether an agent produces usable output, because they are the reason the standard case alone is not enough.
Why is this not about the model?
Because the models are good enough by now and the rest is preparation. Two figures place this.
Gartner expects more than 40 percent of agentic AI projects to be cancelled by the end of 2027, citing rising costs, unclear business value or inadequate risk controls. The forecast rests on a poll of roughly 3,400 webinar attendees, so not a representative sample, but usable as a direction. The MIT NANDA study The GenAI Divide finds 95 percent of generative AI pilots without measurable financial return and attributes this explicitly not to model quality or regulation but to the approach taken by the organisation.
For its Agent Readiness Survey, Microsoft surveyed 500 companies, mostly large and internationally active, based on self-reported data. One figure stands out despite that limitation: only 22 percent strongly agree that their key processes and data dependencies are documented.
For Germany, Bitkom shows the question is no longer theoretical. 41 percent of companies with 20 or more employees actively use AI, another 48 percent are planning or discussing it.
We have described a related pattern elsewhere: that the single customer view usually fails on the org chart rather than on integration. That piece is about ownership of data. This one is about the layer below it, the description of the processes themselves.
When can I start if the documentation isn’t finished?
As soon as you know where the gaps are. Not once there are none left.
Even in the fast project the documentation was incomplete, otherwise the expert session with its open questions would not have been necessary. The difference from the second project was not completeness. It was that the open points could be named and answered within days. In the second case they surfaced one at a time across five weeks, each one as a surprise.
That produces a go/no-go criterion which works without a process audit. You can start building when you can name, for the process in question, which parts are described, which exist only in individual heads and who those people are. If nobody can produce that list, the first task is the list, not the agent.
Three rules make the start viable.
Choose the pilot by state of documentation, not by leverage.
The reflex goes to the largest business case. The first agent belongs where the foundation is cleanest, even if the benefit stays smaller. The first pilot sells the method internally. A fast, verifiable result on a mid-sized process is worth more for that than a drawn-out fight on the most important one.
Capture what gets clarified during the build.
An agent project forces questions nobody asks in daily work, because the answer used to be implicit. That is the cheapest occasion for documentation an organisation gets. In the second project those answers were spent verbally in review rounds. That is why after five weeks a system existed, but the foundation for the next initiative was no better than before.
Define a stop criterion.
If new rules keep appearing after several iterations, there is no documentation problem. There is an unresolved process. The right move then is to pause the agent and decide the process. An agent cannot execute a rule the organisation has never made.
Which four questions settle this upfront?
Does anyone outside the team know the exceptions?
A test question for the room: describe the process for the most awkward special case of the last three months. If only one person can answer, that is the point where the agent will later get it wrong.
Is there a result to validate against?
In the first project a running production served as the reference, which is why full acceptance testing was possible. Many marketing processes have no such reference, because the result is a matter of judgement. Then acceptance has to be defined before the start, otherwise the first complaint becomes the benchmark.
Who decides when two rules contradict each other?
An agent needs a hierarchy of rules. Where the organisation never set one, the project team negotiates it on the side, and does so again in every iteration.
Who owns the outcome rather than the rollout?
A project lead is enough for a rollout. For the outcome you need someone with the authority to decide that a process gets changed before it gets automated. According to Microsoft, about one company in three has named such a role, rising to 61 percent among the fastest scaling ones.
The fastest route to these answers is a conversation, not a document. If the sentence comes up that someone knows it anyway without documentation, the preparation is not finished.