The parts of this that get more expensive the longer you wait
Most of what you will need for an agentic organisation can be added the day you need it. Two things cannot, and they are the two everybody defers. Here is why the order matters more than the timing.
Almost nobody plans their way into an agentic organisation. It accretes.
Somebody adopts a coding agent because it is obviously useful. A few months later three teams are using three different ones, and nobody can find the good prompts, so someone builds a shared place to put them. That works until output quality varies wildly between people, so someone builds evaluation and routing around it. That works until the useful thing turns out to live on one engineer’s laptop and dies whenever they take a week off, so it gets hosted properly. Now there are forty hosted things nobody owns, and someone finally asks who has credentials to what.
Every step is a sensible response to real pain caused by the previous step. That is not a failure of planning. It is what capability adoption looks like in any organisation that is also trying to ship product, and anyone telling you their transformation followed a roadmap is describing a slide, not a year.
The useful question is not how to avoid that. It is which parts of it get harder if you leave them until the pain arrives.
Most of it is genuinely fine to defer
I want to be clear about this before making the argument, because the opposite advice is usually a sales pitch.
Shared prompt libraries, evaluation harnesses, routing logic, agent-to-agent handoffs, orchestration: you can build all of it later, at the point where the absence hurts. Building them early is a good way to construct an elaborate answer to a question your organisation has not asked yet. Most of these things are also better designed once you have watched real usage, because the first version of anything built on speculation is wrong in ways nobody could have predicted.
If you have two teams using agents casually and someone is proposing an orchestration platform, they are solving for a company you are not yet.
Safe to defer
- Prompt and context libraries
- Evaluation harnesses
- Routing and model selection
- Agent-to-agent handoffs
- Orchestration
- Cost is roughly flat whenever you build it
Gets worse with every month
- Which agents exist and what they can reach
- Which changes came from which agent
- What each change was supposed to do
- Who authorised it
- Cost rises with the size of the estate
The two that behave differently
Knowing what your agents are and what they can reach. Provisioned deliberately, this costs an afternoon: a scoped identity per agent, a credential that expires, a written note of what it may touch. Retrofitted across an estate of a hundred automations built by people who have since changed teams, it costs a quarter and produces an incomplete answer, because some of those credentials are embedded in things nobody can safely restart.
Knowing which change came from where, and why. Captured at the moment of the change, this is close to free: the ticket, the criteria, the agent identity, the human on whose behalf it acted, recorded when all four are sitting in memory anyway. Reconstructed afterwards, it is frequently impossible. Not hard. Impossible. The information was never written down, the people have moved on, and no amount of budget recovers a fact that was never captured.
That asymmetry is the whole argument. Everything else on the list is a thing you build. These two are things you either capture as you go or lose permanently.
Why they are always the ones deferred
They have a property that makes them uniquely easy to postpone: they produce no benefit until the moment you desperately need them.
An evaluation harness pays off the week you build it. Scoped credentials pay off never, right up until a security review, an incident, or an auditor. Provenance pays off never, right up until somebody asks what changed in the billing path six months ago and why.
So they lose every prioritisation conversation, correctly, on the visible evidence. Nobody is being negligent. They are responding to the incentives in front of them, and the incentive structure genuinely does favour deferring both.
What is likely to happen next
Some predictions, held with different levels of confidence, because forecasting is where writing like this usually stops being honest.
Confident: the trigger will be external. Very few organisations will decide to fix this on the engineering merits. It will be a customer security questionnaire, a procurement clause, an incident, or a regulator. The EU AI Act began enforcement on 2 August 2026, and its Article 12 logging and traceability obligations are the shape of thing that turns a nice-to-have into a deadline.
Confident: attribution for generated code will get standardised, and later than anyone wants. There is an established way to attribute a generated image and no documented equivalent for a generated function, while something like 41 percent of production code is now AI-generated. That gap does not survive indefinitely. When it closes, organisations with a contemporaneous record will comply by exporting; those without will comply by starting from today and having nothing before it.
Less confident: a remediation market appears and mostly underdelivers. Gartner expects specialist tooling and consulting for auditing AI-generated technical debt. My guess is that the auditing part works and the refactoring part largely does not, because you cannot refactor your way out of not having read something. Discount this one; I hold it loosely.
Genuinely uncertain: whether any of this changes buying behaviour before the first well-publicised failure. Organisations are not good at acting on asymmetric risk with a delayed trigger. It usually takes somebody else’s incident.
What that means to do now
Not a platform. Two habits, both small.
Give every agent its own identity, scoped to what it needs, expiring on a schedule. Do it when the agent is provisioned, when it costs an afternoon. The value is not the security posture on day one, which is negligible. It is that the list exists at all, so the question “what do we have” stays a query rather than becoming an investigation.
Record the chain at the moment of the change. What changed, against which stated intent, by which agent, on whose behalf, verified how. Contemporaneously, because that is the only time it is cheap and the only time it is reliable.
Neither requires deciding on an orchestration strategy, and neither commits you to a vendor. They are the two things that are cheap now and either expensive or impossible later, which is the only real reason to do anything early.
I should say plainly that we sell a product in this space, so treat the recommendation with the scepticism that deserves. The habits above are worth adopting with tooling you already own. What you should not do is defer them on the grounds that you will pick a tool first.
Where this breaks down
For a small company, this is premature optimisation and I would ignore me. Five engineers with two agents do not have an inventory problem. They have a shared mental model, which is better than any register, and time spent on credential lifecycle is time not spent finding customers. This argument gets real somewhere around the point where nobody can name every automation from memory.
Contemporaneous capture assumes you know what to capture. Recording the wrong five fields diligently for a year produces a large, useless archive and a false sense of readiness. The fields I named are my best guess at what questions get asked, and they are a guess.
A complete record can make a bad process legible rather than better. If your changes are reaching production unreviewed, comprehensive provenance documents that clearly and fixes none of it. Several organisations will buy the recording layer and mistake it for the control.
And the strongest objection: waiting is sometimes correct. Standards are unsettled, formats will change, and an organisation that builds an elaborate provenance system in 2026 may be migrating off it in 2028. Capturing a simple record in a format you control is defensible. Building a programme around today’s guess about tomorrow’s requirement is not, and the line between those two is genuinely blurry.
The takeaway
Almost everything in an agentic estate can be built the week you need it, and building it earlier is usually waste. Two things do not behave that way: knowing what your agents are and what they can reach, and knowing what each change was for and who authorised it.
Both cost an afternoon at provisioning time and a quarter at investigation time. Both produce nothing until the day they are urgent, which is why they lose every prioritisation argument until an external trigger arrives and removes the choice.
If you take one thing into next week: try to produce a list of every agent with credentials against your repositories, and time yourself. That number is your position on the curve, and it only goes one way.