Published: | Updated:
TL;DR – The short answer: the artifact chain is the right spine, and the playbook just starts one stage too late and assumes one company owns the whole chain. Two things break when you run an AI-native SDLC in BFSI. Intent doesn’t arrive clean: work enters through eight different doors and one tech lead is already translating it in his head, so that translation has to become a committed artifact before Plan. And no single company owns the chain – it crosses an MSA at every SI boundary, which makes constraint-store access a legal question, not an engineering one. Underneath both sits the part nobody funds: four shared stores that already half-exist in your estate. Build those first. Build implementation last.
Written for CIOs, delivery heads and tech leads at banks, insurers and NBFCs running agentic delivery across a captive team and multiple systems integrators. Use this when you are scoping an agentic SDLC programme, deciding what to build before the pilot, or renegotiating partner contracts to cover agent access. It covers intake and triage design, shared context stores, approval gates in regulated change processes, and vendor and MSA boundaries.
Anthropic put out an AI-native SDLC playbook a few weeks ago. The core idea is the good part: every stage ends by writing an artifact to version control and the next stage begins by reading it, so the chain of commits becomes the audit trail. Who asked for what, what the agent produced and who approved it.
That is a genuinely clean idea. If you work in a bank, you already know why it matters, because you have spent months of your life reconstructing exactly that chain for somebody holding a printout.
So this is not a rebuttal. It is the two things I kept writing in the margin, both of which come from doing this work in Indian BFSI, where the shape of the problem is different.
The first assumption: intent arrives clean
The playbook starts at Plan, where a person has an idea, brainstorms with Claude and produces a proto-spec saved as intent.md, which the product owner reviews and corrects before committing.
Lovely. Now go look at your actual queue.
At a lender we work with, work enters through eight different doors. Change requests from business as a paragraph in an email. Datadog firing on a p99 threshold. Jira tickets that say “not working” with a screenshot attached. ServiceNow escalations that started as a customer complaint and got translated twice on the way up from L1. Product asks sized by somebody who has never opened the repo. A partner ringing to say their integration broke. Sixty items from the last VAPT sorted by CVSS. And a Confluence page from a retro nine months ago that everyone agrees is important.
Eight formats. Eight ideas of what urgent means. Eight different stakeholders and only one of them is a product owner sitting down to write an intent.md.
Somebody is already translating all of that. Usually a tech lead or BA, in his head, between calls. One of them showed me a spreadsheet he’d been keeping privately for eleven months because his memory had stopped coping. Four tabs, one per source, colour coded. He was slightly embarrassed about it. He shouldn’t have been, it was the best documentation in that organisation.
That translation step has to become a stage. Not a person. In our framing it’s stage zero, sitting before Plan and it produces the same kind of committed artifact the playbook describes, just with more fields because the input is messier:
- Origin and the raiser’s exact words
- Classification, including where an item is genuinely two things
- Impact surface: services, modules, owners, downstream consumers
- Precedent from past similar work, with actuals against estimates
- The constraint set that applies to these paths
- Duplication check against the open backlog
- Blast radius and who finds out first
- Open questions, with names against them
The precedent field is the one everybody drops in a working group, because populating it means querying delivery history nobody has cleaned. It’s also the one that fixes your estimates. Fight for it.
The second assumption: one company owns the chain
This is the bigger one for anyone reading this in Mumbai.
The playbook’s chain works beautifully inside a single engineering organisation. A private bank or an insurer does not have one. You have a captive team, two or three SIs sitting on different towers and product vendors for the core systems who will not let you touch anything.
So the commit chain has a seam in it. Several, actually. Three things follow and I have not seen any of them written down anywhere.
The artifact matters most exactly where it crosses the MSA. Handover between your captive team and a partner is where context currently evaporates and gets rebuilt in a KT call that nobody records. If you build your intake layer only inside the captive team, you have fixed the smaller half.
Sharing your constraint store is a legal question, not an engineering one. The convention and constraint store is what stops an agent, yours or a partner’s, from quietly bypassing an audit wrapper. Which means partner access. Which means an amendment, procurement and a conversation with legal that will take five months. I know it will take five months because that is where one of ours currently sits. Start it now, not after the pilot works.
Nobody has decided who owns the productivity gain and your contract is silent. On T&M, agent-assisted delivery cuts billed hours, so your partner has no reason to bring it up. On fixed price it accrues to them unless you reopen the SOW. We have seen this handled sensibly with outcome-linked pricing on new work. We have also seen it stall completely because nobody wanted to be the one to reopen a contract.
Ask your partners what their agents are reading from your repositories today.
The thing underneath all of it
This one is a mistake we made ourselves.
We spent most of last year starting these engagements at the build stage. It’s the interesting part, it demos well and it’s what clients ring you about. It kept falling over in production and it took me embarrassingly long to work out why: the pilots were being fed hand-curated work items by a tech lead who wanted them to succeed.
Then at another client I watched six agents, built by six different squads, all doing decent work. Five of them were separately figuring out which services a change touched. One queried the CMDB, two parsed the repo directly and one just asked a model to guess from the ticket text. None of them wrote the answer anywhere the others could see it.
The agents were fine. There was nothing underneath them.
Four shared stores fix this and every one of them already half-exists in your estate. Making them queryable is most of the actual work.
The constraint store is the one that earns its keep in a regulated shop. Which write paths must be audit-logged. Which fields carry DPDP obligations. Which services sit inside payment data localisation scope. Put it in the repository, versioned with the code. Anything living outside the merge process is stale within two quarters and a stale constraint is worse than an absent one because people trust it.
Where the human signatures go
The playbook is careful about this and I agree with where it lands. Separation of duties holds because the agent that wrote the code has no way to approve it and approval comes from a human through branch protection. Their hooks-as-gates approach is the right mechanism.
My only addition is a subtraction. Most BFSI change processes carry gates that exist because something went wrong in 2019 and nobody since has had the standing to remove them. They cost calendar time and they train everybody to approve without reading, which is the opposite of a control. Four signatures survive real scrutiny. Audit yours against those four and take the rest out.
If you’re the one funding this
The first takes a fortnight to get. Ask your tech leads to log the time they spend working out what a work item actually is before it can be assigned. In teams we’ve measured it runs between a fifth and a third of the week for the two or three people carrying most of it. That is a real cost, paid out of your most expensive engineering time and it appears in no report anywhere. It is also the strongest slide you will have.
The second is audit evidence assembly. Whatever your team currently spends pulling change evidence together for an inspection, that number moves almost immediately once release verification is automated and it is the one your board will feel directly.
What you should refuse to promise is throughput per engineer. It is what you will be asked for. It moves last, it moves least reliably and committing to it in quarter one is how these programmes die in month nine.
What I don’t have a good answer to
Juniors. The work that used to teach somebody how a core system fits together, the small tickets and tracing a bug across four services at eleven at night, is exactly what a clean intake layer removes. Somebody handed a complete work item learns less than somebody who had to go and find out. Every EM I talk to has noticed. The only remedy I can think of is deliberately withholding context from people, which nobody actually does and I don’t know what it does to your bench in three years.
So, honestly
Read the playbook. It’s better than most things published on this and the artifact chain is the right spine. Then before you build any of it, go and count your doors; and go and find out who is doing the translating today. In our experience, that person exists – has a spreadsheet and hasn’t told anyone about it.
Frequently asked questions
What is an AI-native SDLC?
In short, an AI-native SDLC is a software development lifecycle where every stage ends by committing a machine-readable artifact to version control, and the next stage begins by reading it. The chain of commits becomes the audit trail: who asked for what, what the agent produced, and who approved it. It replaces linear hand-offs between roles with a loop.
Why doesn’t the AI-native SDLC playbook work as written in BFSI?
The short answer is that it rests on two assumptions that don’t hold in a bank. The first is that intent arrives clean from a product owner, when in practice work enters through eight or more channels in eight different formats. The second is that one engineering organisation owns the whole commit chain, when a private bank or insurer has a captive team, multiple systems integrators and core product vendors – so the chain has a seam at every contract boundary.
What is stage zero in an AI-native SDLC?
Stage zero is an intake and triage stage that sits before Plan. It turns messy inbound work – emails, monitoring alerts, tickets, escalations, VAPT findings – into one normalised, committed artifact. The step already exists in most estates, but as a person doing it in their head between calls rather than as a file anyone can read. Making it a stage is what makes everything downstream reliable.
What should an intake artifact contain?
Eight fields: the origin and the raiser’s exact words; classification, including where an item is genuinely two things; the impact surface across services, modules, owners and downstream consumers; precedent from past similar work with actuals against estimates; the constraint set applying to those paths; a duplication check against the open backlog; blast radius and who finds out first; and open questions with names against them.
How do you run an AI-native SDLC across multiple vendors?
In short: start with the contract, not the tooling. The artifact matters most where it crosses the MSA, so giving a partner access to your constraint store needs an amendment, procurement and legal – budget months, and start before the pilot succeeds rather than after. Separately, decide who owns the productivity gain: on time and materials it cuts your partner’s billed hours, and on fixed price it accrues to them unless you reopen the SOW.
Which human approvals should survive in an AI-native SDLC?
The short answer is four. What enters the sprint, signed by the delivery or engineering manager; the approach before any code is written, signed by the tech lead; the merge, signed by a peer reviewer; and the production release, signed by the release manager or CAB. Most other gates in a regulated change process exist because something went wrong years ago. They cost calendar time and train people to approve without reading, which is the opposite of a control.
Who should own an AI-native SDLC programme in a bank?
In most estates it sits with the CIO or delivery head, executed by the tech leads who already carry the translation work. Use this guidance when you are scoping an agentic SDLC programme, deciding what to build before a pilot, or renegotiating partner contracts to cover agent access. It applies to banks, insurers and NBFCs running delivery across a captive team and multiple systems integrators, and it covers intake and triage design, shared context stores, approval gates and MSA boundaries.