Agentic software delivery creates a control problem that conventional SDLC documentation was not designed to solve. When multiple AI agents participate across requirements, architecture, development, testing and release, the bank needs more than a record of what each agent produced. It needs a defensible record of what the agent knew, which sources it relied on, what it was permitted to do and what remained unresolved when work moved to the next stage.
The whitepaper proposes a practical mechanism for that problem: the context contract. It turns an SDLC hand-off from a transfer of artefacts into a verifiable transfer of meaning.
Why Conventional Hand-Offs Become Fragile With AI
Human delivery teams routinely compensate for incomplete hand-offs. An architect asks the product owner what a requirement really means. A developer checks an undocumented convention with a senior engineer. A tester remembers an exception from an earlier release. These informal corrections are part of how institutions have historically carried tacit knowledge.
AI agents do not reliably recreate that behavior. If a design agent receives a requirement without its regulatory constraints, it can produce an elegant but inadmissible pattern. If a coding agent receives the design without the authoritative API version or domain rule, it can implement the wrong behavior. If a test agent receives the same incomplete context, it can create evidence that certifies the wrong system.
A Context Contract Makes the Hand-Off Defensible
A context contract is machine-readable and human-reviewable. At each stage, it records the required inputs and authoritative sources, generated outputs, decisions and assumptions, constraints and control evidence, owner and approver, confidence, unresolved questions, permitted actions, escalation conditions, version, lineage and expiry criteria.
The value is not additional documentation for its own sake. The contract allows the next agent and the human reviewer to see why an output exists and what boundaries apply to it. A design agent can show which requirements and standards shaped an architecture. A coding agent can show which design decision and API version it used. A quality agent can connect critical scenarios to acceptance criteria and controls. Traceability becomes part of execution instead of evidence assembled after the event.
Dual Control Still Matters in an Agentic SDLC
Agentic delivery does not remove accountability. Dual control still applies to high-impact change, but the checker needs more than the generated artefact. The reviewer needs provenance, confidence, residual risk and the assumptions behind ambiguous judgments.
This creates a more useful form of human oversight. Instead of placing approval everywhere, the bank can apply stronger evidence and review where consequence is higher and allow lower-risk work to move with less friction. Progressive autonomy then becomes possible: agents can begin with read-and-recommend permissions and expand toward create, test or act only when evidence meets defined thresholds.
What a Banking Context Contract Looks Like
The whitepaper illustrates the mechanism through a credit-limit increase spanning UK and UAE books. The contract carries the business intent, authoritative credit and product policies, adverse-action standards, customer-consent information and required context types. It also makes constraints explicit: fraud-score changes require Financial Crime sign-off, PII must be masked in lower environments and UAE data residency must be retained.
Crucially, the contract also records uncertainty. A partner-hosted core eligibility flag is identified as a third-party context gap, confidence is marked medium, and the design agent is permitted to propose patterns but not generate customer copy or decisioning code. If eligibility, affordability or adverse-action logic changes, the work returns to Risk before proceeding. That is materially different from a backlog story. It is a hand-off the bank can examine and defend.
Governance Becomes Part of Flow, Not a Gate at the End
This matters because the objective of AI governance in software delivery should not be to slow every agent equally. It should be to preserve authority, evidence and accountability while allowing work to flow according to risk.
Context contracts make that possible by carrying the bank’s control environment with the work. They also create the lineage needed for audit, incident analysis and continuous improvement. When production outcomes feed back into requirements and tests, the contract can evolve with the system rather than becoming a static compliance artefact.
Go Deeper: Build Verifiable AI Hand-Offs
Maveric’s whitepaper, The Context Continuum: Engineering Trust Across the AI-Powered SDLC, develops the context-contract model in detail and places it within a broader banking context operating system. It covers stage-specific context, provenance, risk-based quality gates, progressive autonomy and the operating capabilities required to govern AI agents from demand through production. Explore how context contracts can make agentic banking delivery faster without separating autonomy from accountability.
FAQ
1. What is a context contract?
A context contract is a machine-readable, human-reviewable record that carries authoritative inputs, outputs, decisions, assumptions, controls, ownership, confidence, permitted actions, lineage and expiry across an SDLC hand-off.
2. How do context contracts support AI governance?
They make the evidence and boundaries behind an AI-generated artefact visible, allowing reviewers to assess provenance, confidence, residual risk and authority rather than reviewing only the final output.
3. Do context contracts replace human approval?
No. They support risk-based human oversight by giving approvers better evidence and allowing stronger controls to be applied to higher-impact changes.
