Most agentic pilots fail the same way. They work beautifully in a demo, then meet an environment where every action has an owner, an audit trail and a control that someone signed their name against and there is no obvious place to put them.
The instinct is to treat governance as the thing slowing the agent down. It isn't. Governance is the thing that tells you what the agent is allowed to be confident about. An agent that can raise a change request but not approve it, that can draft a risk assessment but not close it, that can gather evidence but not attest to it - that agent has a defensible place in the operating model.
The useful question is not "what can the agent do?" but "which decisions are we prepared to let it prepare, and which must a human still own?" Answer that first and the architecture follows. Answer it last and you will be retrofitting controls onto something already in production.
In practice this means agents earn their place at the edges of a workflow rather than the centre: assembling context, reconciling records, drafting the first version, flagging what looks wrong. The centre - the decision, the approval, the accountability - stays where the regulator expects to find it.
CSDM gets adopted in one of two ways. Either it is the model everything else is built on, or it is the clean-up project someone proposes in year two. The second is far more common, and far more expensive.
The reason is that CSDM is not really a data model exercise. It is an agreement about what a service is - who owns it, what it depends on, what it costs, what breaks when it fails. Every one of those questions is organisational before it is technical. Deferring the model defers the agreement, and the agreement is the hard part.
Platforms that skip it do not fail immediately. They accumulate a CMDB that is technically populated and practically untrusted, reporting that nobody quite believes, and a growing gap between the service catalogue customers see and the services the business actually runs.
Getting it right early costs weeks of workshops that feel slow at the time. Getting it wrong costs a re-architecture, and the credibility of everyone who said the platform was ready.
Regulated industries are often described as slow. That framing misses what they are actually good at, which is refusing to let a control exist without an owner. In a bank or an insurer, "who is accountable for this" has a real answer, and that answer is written down somewhere a regulator can find it.
Platforms are generally worse at this than the organisations that buy them. They model risks, controls and issues as records, and they model ownership as a reference field. But accountability is not a field. It is a chain - from the control to the person, to the committee, to the report that reaches the board and most implementations only build the first link.
Where it breaks
The failure shows up at attestation time. Evidence exists but cannot be traced to the control it supports. Controls exist but map to a version of the business that reorganised eighteen months ago. Nothing is technically wrong, and nothing can be defended quickly.
The fix is unglamorous: model the chain, not the record. Make ownership survive a reorganisation. Make evidence point back at the thing it proves. Do that and the annual scramble becomes a report you can run.
Every platform decision is a bet on what the organisation will look like later. Most are made as though the answer is "the same, but bigger."
That assumption is what produces the customisation that made perfect sense for one team and now blocks an upgrade, the integration built for a system that has since been replaced, and the process that encodes an approval hierarchy nobody uses any more.
Designing for year three does not mean building for imagined requirements. It means being deliberate about which decisions are cheap to reverse and which are not. Configuration is cheap. A data model is not. A naming convention is cheap. An identity and access design is not. Spend the architectural effort on the expensive ones and stay flexible everywhere else.
The test I find most useful: if this decision turns out to be wrong, who has to be in the room to change it? If the answer is one team, proceed. If the answer is a steering committee, slow down.
Programme leadership is usually described in terms of governance, reporting and stakeholder management. Those matter. But the thing that actually determines whether a technical programme holds together is whether the people building it believe the person leading it understands what they are building.
That belief is not established in a steering committee. It is established the first time a leader asks a question specific enough that it could only come from someone who has read the design and then does something useful with the answer.
The practical consequence is that credibility buys you honest status. Teams that trust their leader technically will tell them a date is unrealistic eight weeks out. Teams that don't will tell them the week before. Everything else about programme control is downstream of which of those two conversations you are having.
It does not require being the best engineer in the room. It requires being able to tell when the room is avoiding a problem.
Enterprise search projects are commissioned as capability problems and fail as permission problems. The retrieval works. The ranking is fine. The issue is that the index now contains documents that some of the people searching it were never meant to see.
Adding a language model on top raises the stakes rather than solving it. A search result at least shows a user a link they may not be able to open. A generated answer quietly summarises the contents of that link into the reply.
The order of operations
Governance has to come first, and it has to come at the document level. Which sources are in scope. What the classification actually is, as opposed to what it is supposed to be. Whose permissions are enforced at query time rather than assumed at index time. What is logged when an answer is generated, and who can review it.
None of this is exciting, and all of it determines whether the thing can be deployed beyond a pilot group. Enterprise search is a governance programme with a search interface attached - organisations that treat it that way ship it, and organisations that treat it as an AI project tend not to.