Most of the AI pressure inside a large enterprise shows up as a question about speed. The board wants a position, a competitor has announced something, and leadership asks everyone to move quickly. So the organisation buys more tools and starts more pilots, and for a quarter or two the activity looks like progress. The harder question arrives later, when whoever put their name to the AI push has to explain why the way the company works hasn’t changed.
That gap is the question behind agile for AI adoption, and it has little to do with how fast anyone moved.
Why AI pilots stall a few months in
The reason usually has little to do with the pilot itself. The model that powered it ships an update and starts behaving differently, the vendor changes what the licence covers, or a new capability makes last quarter’s workflow look clumsy. A team that built one process around one tool now has to unpick it. Speed produced the demo, but it did little to prepare the team for the version of the problem it faces two quarters later. The research on why AI programmes stall keeps pointing at the same cause, and it is rarely the technology.
Agile was built for changing conditions
This is the part the speed framing misses, and it is the same ground Agile was built on. Agile came out of software teams that could not freeze their requirements for a year and hope the market waited, so the practice was designed to re-check assumptions often enough to change direction without starting over. That is the position an enterprise adopting AI is in now. The tools change month to month, and what a model can do today is not what it could do two quarters ago, so the teams that keep delivering are the ones built to adjust as conditions change.
What AI adoption looks like across Southeast Asia
In the banks, insurers and energy firms Ekipa works with across Indonesia, Singapore and Malaysia, the pattern repeats. A compliance team automates part of its KYC review around one model, and six months on the outputs have drifted and the checks need reworking (and in a regulated shop, OJK or MAS will ask how that drift is controlled). An insurer stands up a customer-service assistant, then rebuilds its prompts and guardrails the week the underlying tool ships a new version. An energy firm modernising its data for AI finds the technical rebuild is the smaller job, and the harder one is getting the data team to work in a way that absorbs change rather than treating every shift as a separate emergency. In each case, the firms that kept moving had teams that could take a change in the tool and rebuild around it without a steering committee and a three-month pause. How fast they had moved at the start made little difference.
Adaptability is a set of habits
It is not a slogan for a town hall; it is a handful of concrete habits. A team running short delivery cycles looks at what it is building often enough to catch a shift early, so a tool update shows up inside a sprint rather than in a post-mortem months later. That only works when everyone shares a language for the problem, so the C-level sponsor, the line manager, and the person using the system are not describing three different things as the day’s conditions change. When the tool used in a workflow changes, an adaptable team rebuilds the workflow rather than defending the version they already have. Bringing that kind of structure to AI delivery is what keeps a pilot alive from one quarter to the next, and it is the opposite of shipping faster without the controls to match.
The part that takes time to build
None of this is new; it is what good Agile practice has always produced. What has changed is that AI puts a price on the absence of it sooner than earlier technology did. Ekipa has spent ten years coaching agile ways of working into enterprises across Southeast Asia, in banks, insurers, pharma and energy, long before AI was the reason anyone called, with engineering support from Bridge Global when a client needs to build. The AI work since 2025 has not changed the core of it. The companies getting steady value from AI are the ones that could already change how they work. Buying the tools is the easy part; building the habit of adjusting around them is what takes time, and it decides whether any of it holds.
Most of this is hard to judge from inside the organisation. If your teams are being asked to move on AI faster than they can adapt, a scoping conversation is a sensible place to start. Half an hour on your specific situation is enough to map where your teams actually stand and what the first change should be. Contact Ekipa to arrange one.