Insights | Crosstide

Agentic workflows: Understanding why faster code has not made your delivery cycle faster

Written by Steven Thompson | Feb 26, 2026 10:22:07 AM

Many financial services organisations have invested heavily in AI to improve engineering productivity. Developers can refactor faster, generate tests more easily, and complete complex changes inside services far more quickly than before.

Yet overall, the delivery cycle time in complex BFSI estates, from idea to production, has barely moved.

The reason for this is that delivery speed is constrained by coordination, not code generation.

If your objective is to achieve a meaningful reduction in end-to-end delivery time, the solution is not more horsepower inside the Integrated Development Environment (IDE). It’s intelligence applied at the workflow level.

The Civic and the Turbocharger

Consider fitting a high-performance Garrett Turbocharger to a Honda Civic EJ1. On a rolling road, it is undeniably faster.

But put that same car into rush hour traffic with constant braking, frequent lane changes, and blocked junctions, and it will not arrive any earlier. The local improvement (the turbocharger) is nullified by the systematic constraints (the traffic).

That is where many banks and insurers are with AI. They have increased horsepower within engineering teams, but the delivery journey is still governed by systemic constraints.

Local acceleration does not overcome global congestion.

The building stage - focus on the short term, build for the long term

Before scaling code-centric AI, ensure the primary constraint is coding, not coordination.

In most major change programmes, elapsed time is not spent writing code. It is spent on:

  • Cross-system impact analysis
  • Integration clarification between platforms
  • Data ownership and lineage debates
  • Risk and compliance review cycles
  • Regression coordination across multiple services
  • Release alignment across teams.


In one large financial services programme I was involved in, we uncovered that less than thirty per cent of elapsed time sat in build. The majority was spent understanding cross-system impact and aligning stakeholders.

If that sounds familiar, the constraint is orchestration. 

What should technology leaders do differently? 

If coordination drag is the constraint, intelligence must be embedded in the workflow. This means expanding AI beyond development assistance into delivery orchestration.

This requires applying agentic capability not just to code generation, but also to coordinating the entire delivery process. This is a strategic imperative directly linked to commercial success.

For any material production change raised through Jira or a formal change process, agentic capability can be embedded directly into the workflow. Instead of relying on manual coordination, agents analyse impact, surface dependencies, generate artefacts, and orchestrate cross-team visibility before meetings begin.

The barrier is rarely ambition. It is fragmented visibility and coordination embedded in meetings rather than systems. 

Below are the areas where leadership can apply agentic capability for measurable impact.

Friction point Real-world scenario Impact on delivery
Impact analysis: Agents can read a change request and identify affected services and APIs, surface integration contracts early, and highlight historical incidents or regressions linked to those components. A regulatory update requires changes across payments, risk, and reporting systems. Teams spend weeks mapping which services are affected. Early automated impact reporting reduces ambiguity and shortens assessment time from weeks to days.
Cross-system regression: Generate regression coverage across multiple services, not just within one repository, and flag test gaps before release planning. A feature change in one service triggers defects in downstream systems discovered late in testing. Regression modelling across services reduces late cycle defects and rework.
Compliance documentation: Generate traceability documentation alongside change, pre-populate risk assessment templates, and link changes to data lineage automatically. Traceability documents and risk templates are completed after build, delaying approval. Artefacts generated alongside a feature, regulatory update, defect fix, or platform modification that can shift compliance from gate to parallel activity.
Stakeholder coordination: Surface ownership of systems and data automatically, and identify which teams need to be involved before the first meeting. Programme meetings are required just to identify which teams must sign off on change. Automatic visibility of system ownership removes unnecessary meeting cycles.

 

How can a CTO implements delivery orchestration?

Since the constraint is orchestration, and the solution requires applying agentic intelligence to the workflow itself, the challenge for the CTO becomes an implementation problem. These five steps outline the pragmatic path for deploying this strategic capability and ensuring measurable impact on delivery cycle time:

  1. Start with one value stream, not the whole organisation

  2. Instrument delivery data first. No orchestration without visibility

  3. Embed agents at workflow entry points (change request creation, pull request creation, release planning)

  4. Measure coordination latency as a delivery metric

  5. Treat orchestration capability as infrastructure, not tooling.

For any material production change raised through Jira or a formal change process, agentic capability can be embedded directly into the workflow. Instead of relying on manual coordination, agents analyse impact, surface dependencies, generate artefacts, and orchestrate cross-team visibility before meetings begin.

The barrier is rarely ambition. It is fragmented visibility and coordination embedded in meetings rather than systems.

Below are the areas where leadership can apply agentic capability for measurable impact.

What must be true architecturally?

A critical leadership mandate is recognising that Agentic workflows only operate effectively if the estate has structure. Intelligence alone cannot compensate for chaos; you also need:

  • Clear service boundaries
  • Defined data ownership
  • Consistent integration patterns
  • Observable metrics around change, velocity, and failure.

If these foundations are weak, many AI initiatives expose architectural ambiguity rather than compensate for it. That is not an AI failure. It is a signal that the road network needs attention.

Strengthening architecture and deploying workflow level intelligence should go hand in hand.

Closing thoughts

In regulated financial services, delivery speed is directly linked to:

  • Regulatory responsiveness
  • Time to market for new propositions
  • Cost of change
  • Engineering morale and retention.


Reducing coordination drag shortens release cycles, reduces rework, and lowers the operational cost of complex change.

Faster code alone will not change your commercial position. Shorter feedback loops across systems do.

If you want meaningful reductions in delivery cycle time across banking and broader financial services estates, focus less on increasing horsepower inside the IDE and more on clearing systemic coordination constraints.

The turbocharged Civic is not the issue. The traffic is.

Are you looking for more information on AI best practice?

Read our article How do you use AI in a regulated industry?

Follow me on LinkedIn for more insights.