What we heard from bp

• bp does not want ERP replacement, platform lock-in, or another disconnected AI estate.
• The runtime must align to existing AWS, Azure, IAM, Entra ID, and cloud guardrail standards.
• Productivity must be realized with operational safety, bounded writes, and named accountability.
• The enterprise is federated: fragmented ownership, mixed system maturity, regional process variants, and uneven data quality are the reality.
• Governance, controllership, evidence, and operational trust matter more than novelty.
• Transformation must be phased, measurable, human-supervised, and politically adoptable.

What this deep dive must establish

Day 2 deep-dive purpose

• Validate integration into bp technology architecture rather than propose a parallel stack.
• Understand dependency on data quality and align the data governance model needed for credible operationalization.
• Evaluate supplier approaches to cyber security and access management, disaster recovery and resilience, and digital workplace change.
• Surface the risks, assumptions, and dependencies that shape pilot scope, control design, and rollout readiness.
• Clarify additional inputs suppliers need from bp and what additional questions bp needs answered before solution refinement.
• Align on the controllership operating model and the human-governance expectations behind future enterprise autonomy.

Expected outputs from this deep dive

• Validated integration approach into bp technology architecture.
• Clarity on data quality dependencies and the aligned data governance model.
• Validated supplier approaches to cyber security and access management, disaster recovery and resilience, and digital workplace transformation.
• A concrete list of risks, assumptions, dependencies, and architecture decisions requiring follow-up.
• Clarity on additional inputs suppliers need to refine their solution and what additional details bp still needs from suppliers.
• A credible path to align the controllership operating model with replay, evidence, policy runtime, and human-supervised execution.

Questions to resolve with bp across data, security, runtime, and operating model

Each later slide expands one of these domains so the deep dive can end with concrete follow-up actions instead of generic agreement.

Credibility test for the page

• Can bp architecture teams see how the runtime integrates without ERP replacement?
• Can data teams see the dependency on governed products, lineage, and quality stewardship?
• Can security teams see IAM, workload identity, cyber telemetry, and controlled write boundaries?
• Can controllership leaders see how replay, evidence, approvals, and policy runtime preserve trust?
• Can both sides leave with explicit decisions, open questions, assumptions, and next-step inputs?

Enterprise estate in scope

The gap

• Approvals, policies, workflows, AI pilots, and analytics remain functionally or technically siloed.
• Operational intelligence is fragmented across dashboards and system-specific views instead of one supervised runtime.
• Logging exists, but enterprise replay, evidence lineage, and governance reconstruction are not yet first-class operating assets.
• Cross-domain orchestration across finance, procurement, treasury, and operations is still limited.

Current state → transitional state → future state

Author plane and Model Gateway

How agents enter the runtime, and how their reasoning is intermediated

Two planes sit either side of the orchestration runtime above and determine whether the agent estate remains governable as it grows. On the inbound side, the Author plane turns business intent into signed, registered agent artefacts. On the outbound side of every reasoning step, the Model Gateway intercepts the call to any LLM for redaction, routing, moderation, and metering. Together they make the difference between a controlled estate and a sprawl of unaccountable agents.

Why this matters for bp

The model behind any agent is interchangeable without re-certifying the agent itself because the boundary is the gateway, not the model. Every new agent enters the estate through a single bp-owned author surface, which means no shadow deployments, no untracked prompts, and no off-fabric model calls.

Model Gateway

LLM intermediation

• PII redaction, prompt-injection and jailbreak scanning, model routing across Azure OpenAI, Bedrock, and private models.
• Output moderation, citation checks, and schema validation before responses re-enter the runtime.

Cost and trace emission

Every reasoning call emits tokens used, latency, model selected, redaction statistics, and a trace span, feeding FinOps, SOC monitoring, and the engineering trace surface introduced on Slide 05.

Author plane

Skill Studio

Declarative agent specs in Markdown or YAML with tool binding, knowledge attachment, prompt template, and an eval set. No-code for domain experts, with pair-authoring alongside engineering for tool makers.

Registry & promotion pipeline

Signed artefacts for skills, tools, MCP servers, models, prompts, and knowledge packs. Promotion runs through sandbox, shadow, canary, bounded, and general, and each gate requires a passing eval and council sign-off.

Local-to-bp production integration mapping

Critical production message

bp Sphere operates inside bp’s governance and cloud boundaries rather than introducing a parallel operating model.

• The demo surfaces prove orchestration behavior; the production mapping above proves how those behaviors swap onto bp-approved systems and controls.
• No shadow IAM, no parallel data regime, and no hidden direct-write path are introduced in order to move from the local proof estate into production.
• Every local proof path must point to a named bp production target, a concrete integration contract, and a clear governance owner before pilot approval.

Engineering trace and evaluation harness

The surfaces beneath replay

Replay is the controller-facing record of what the enterprise did. Beneath it, bp Sphere runs two further surfaces: a per-step engineering trace that explains why an agent reasoned the way it did, and a continuous evaluation harness that proves the agent estate is not getting quietly worse over time. The three views share a single evidence chain: replay for controllers, trace for engineering and risk, eval for early-warning drift.

Why this matters

Replay reconstructs the operational decision for controllers. Trace reconstructs the reasoning path for engineers. Eval continuously verifies that the reasoning path still matches the gold standard, turning drift from a post-incident discovery into a leading indicator.

Trace surface

Per-step LLM and tool observability

• LLM span: prompt, completion, tokens, latency, model, and cost.
• Tool span: input, output, retries, and side-effects.
• Retrieval span: query, chunks fetched, and citation overlap.
• Hallucination markers when output diverges from citations.
• Searchable by agent, user, supplier, and time window.
• Diffable across model versions and prompt versions.

Evaluation harness

Offline and online quality gating

• Golden suite of 100-500 labelled cases per agent, owned by the agent author.
• Regression gate: any change to prompt, model, tool, or knowledge re-runs the evals.
• Online probes: sampled live decisions checked against an oracle.
• Faithfulness scoring: output measured against retrieved citations.
• Drift dashboards covering confidence, override rate, and escalation rate.
• Quarterly adversarial red-team probes for every high-risk agent.

View 1

Business replay

Signal to context to policy to orchestration to decision to execution to evidence to replay to learning. Controller and auditor surface.

View 2

Engineering trace

Per-step LLM and tool spans, retrieval chunks, and faithfulness scores. Engineer and risk surface, linked to the same evidence pack.

View 3

Evaluation harness

Golden-set regression gates and online drift dashboards. Early-warning surface for the governance council.

Live runtime proof

This deep dive must not stop at diagrams. These live surfaces prove the runtime is operating, governed, and replayable inside the current estate.

What each surface proves

• High-risk runtime demo: one operational moment from signal to policy to escalation to evidence to replay.
• Control tower: live agents, engineering trace, eval status, deployment state, policy gates, and evidence integrity.
• Operator console: production swap sequence, solution choreography, and the presenter-facing proof path across runtime, resilience, and assurance.

Runtime visibility expectations

• Active agents and policy evaluations must be visible as operational state, not hidden inside backend logs.
• Evidence completeness, replay backlog, deployment state, and AWS/Azure runtime location must be inspectable during the deep dive.
• The page should leave no doubt that bp Sphere has a control plane, not just a slide narrative.

Critical first-phase rule

• Phase 1 agents observe, classify, correlate, prioritize, escalate, and replay.
• Phase 1 agents do not post journals, execute payments, mutate workflows, or change master data.
• This reduces governance resistance while creating immediate productivity and visibility.

What bp stakeholders should hear

• This is not autonomous AI executing in production without oversight.
• This is a controlled enterprise intelligence and orchestration layer with explicit write boundaries.
• Replay and evidence are non-negotiable control features, not optional diagnostics.

Multi-agent coordination

Conflicts, looping handoffs, and collusion

The three zones above govern a single agent's path to action. As soon as two or more agents share authority over the same supplier, invoice, or treasury decision, a distinct set of failure modes appears: conflicting recommendations, looping handoffs, capability creep, and most dangerously, two weak agents quietly reinforcing each other's bad call. bp Sphere addresses this with an explicit coordination plane that sits on top of the gateways above.

Most dangerous failure mode

The most dangerous failure mode in a multi-agent estate is not a single rogue agent. It is two agents quietly agreeing with each other when they should not. The mediator and devil's-advocate pattern makes that structurally hard, and the evidence pack captures the disagreement so controllers can see exactly how consensus was reached.

Coordination primitives

• Mediator agent required for any cross-domain decision and never optional.
• Typed message contract covering claim, evidence, confidence, and dissent.
• Conflict policy that tie-breaks by risk class and escalates by default.
• Deadlock breaker with bounded hop count and wall-time before automatic human handover.
• Quorum rules so high-risk decisions require independent agents in agreement.

Collusion and sycophancy defences

• Independent reasoning: agents see each other's evidence, never each other's drafts.
• Diverse models: high-risk multi-agent flows route across at least two model families.
• Devil's-advocate agent argues against the emerging consensus and its output is preserved in evidence.
• Anti-sycophancy probes inject false premises to test whether agents push back.
• Collusion detection flags cases where agents agree faster than baseline on a high-risk case.

Step 1

Specialist agents

Invoice Risk, Treasury Exposure, and Supplier Risk each produce an evidence pack independently.

Step 2

Mediator agent

Reconciles claims, surfaces dissent, and applies quorum and risk-class rules.

Step 3

Devil's-advocate

Required for higher-tier decisions, and its argument is captured in evidence regardless of the final call.

Step 4

Policy gateway

Receives a single mediated recommendation together with the full dissenting trace.

Cross-domain decision pattern

The coordination plane turns parallel specialist outputs into one governed recommendation with explicit dissent, bounded escalation, and a preserved audit trail for controllers and risk teams.

Business context

Legal entity, business unit, desk, portfolio, supplier, customer, asset, cost center, and materiality.

Process context

Current workflow stage, prior approvals, open exceptions, unresolved reconciliations, and case age.

Financial context

Exposure, liquidity, margin, budget, actuals, plan, working capital, and close pressure.

Policy context

Authority matrix, SoD, treasury policy, procurement policy, forecast policy, and execution boundaries.

Operational context

Queue state, source freshness, runtime status, upstream failures, and control-plane conditions.

Historical context

Similar cases, accepted overrides, prior outcomes, dispute patterns, supplier behavior, and decision history.

Why bp needs this

• Because the current environment stores facts but does not assemble operating context across systems.
• Because analysts still spend time collecting context before they can apply judgment.
• Because without context, AI becomes generic assistance instead of enterprise decision support.

Questions for bp

• Which context dimensions are already trusted and production-ready?
• Which domains suffer most from missing historical or policy context today?
• Who owns freshness and stewardship for each context class?

Evidence discovery

Find the records, documents, approvals, communications, and prior decisions relevant to the case.

Evidence resolution

Resolve duplicates, conflicting versions, and related entities across systems and repositories.

Evidence extraction

Extract clauses, milestones, invoice fields, approval facts, and policy-relevant attributes.

Evidence lineage

Preserve source references, timestamps, hashes, authorship, and transformation history.

Evidence packaging

Package the decision trail into one controller-facing and auditor-facing proof set.

Evidence viewer

Expose that package inline for analysts, supervisors, controllers, and approvers.

Recommended initial agent set

What they prove

• Enterprise visibility and prioritization without governance fear
• Replay, evidence, and supervisor surfaces as first-class capabilities
• Operational productivity gains before write automation
• Semantic intelligence and cross-system correlation without replatforming

Human + agent operating model for phase 1

How these Phase 1 agents are authored and owned

Each of the ten agents above is a signed artefact in the bp Sphere registry introduced on Slide 04, with a named bp owner. The owner is the author, the on-call, and the person who approves promotion or retirement. That ownership model makes the Phase 1 estate governable from day one, and it opens the path for ops folks across AP, treasury, controllership, and supplier ops to become creators of agentic capability rather than only consumers of it.

Named owner for every agent

Each agent is owned by a senior ops SME in the relevant domain. The owner authors the spec, owns the eval suite, signs off on promotion, and decides when to retire. Accountability is structural, not procedural.

Citizen authoring open from Day 1

Four of these ten agents, Invoice Risk, Reconciliation, Policy Violation, and Data Quality, are explicitly designed to be authored or refined by ops folks through Skill Studio, with platform engineering pairing only on tool-making. This is how bp grows the agent estate without bottlenecking on engineering capacity.

Author = named owner

Operational accountability and runtime accountability live with the same person.

Spec + evals + sign-off

The authored spec, owned eval suite, and promotion decision form the evidence root.

Registry-backed

Every agent is signed, versioned, and promoted through the registry rather than bespoke deployment paths.

4 / 10 citizen-authorable on Day 1

The initial estate is deliberately designed so a meaningful subset can be created and refined by domain operators, not only by engineering teams.

First entries in bp's Skill Studio registry

These ten agents are the first signed entries in bp's Skill Studio registry. Each one carries a named owner, an eval suite, and an explicit retire-or-renew decision path. The estate grows from this registry, not from one-off bespoke deployments.

Completeness

Required fields, relationships, attachments, and event coverage present for the decision type.

Freshness

Current enough for the operating decision and within an agreed SLA by source.

Lineage

Source, transformation, and stewardship path visible to operators and auditors.

Ownership

Named steward and operational team accountable for quality and remediation.

Trust

Quality signals aggregated into one business-facing confidence posture.

Criticality

Material sources receive stronger monitoring and lower tolerance for degradation.

Illustrative readiness index

Why bp needs this

• Because trust concerns are often really data-trust concerns expressed in business language.
• Because the runtime should degrade safely when readiness falls below policy thresholds.
• Because bp leadership needs to see where autonomy is blocked by data quality, not just by policy caution.

Data strategy expectations from bp

• Clarify which finance and operational datasets are already governed and production-ready.
• Map stewardship, ownership, lineage, and metadata standards that the runtime must honor.
• Treat semantic normalization as a progressive program, not a prerequisite big-bang cleanup exercise.
• Use federated data intelligence rather than forced centralization where not politically or technically realistic.

Questions that belong on the slide

• Which datasets are already approved for operational AI observation?
• What lineage and metadata standards are already required?
• Where are the biggest current data quality pain points in finance operations?
• How does bp want long-term semantic federation to evolve across UDP, Databricks, and domain teams?

Knowledge plane and agent memory

Grounding for accurate, citation-backed reasoning

The federation spine above carries bp's structured data estate: UDP, Databricks, SAP, and Ariba. Agents operate on a parallel plane of unstructured knowledge, policy PDFs, supplier MSAs, controllership runbooks, and SOX documentation, and on distinct memory stores that allow them to be useful across runs without writing back into systems of record. The plane below reuses the same stewardship, lineage, and quality standards bp already applies to its data products, extended to documents and agent memory.

Governance continuity

Ingest, classification, freshness SLA, and steward attribution mirror the governance principles bp already applies to UDP and Databricks. No new governance regime is introduced; the existing one is extended to documents and agent memory so the data stewardship community can adopt the knowledge plane without learning a separate model.

Stage 1

Ingest

• Connectors to SharePoint, Confluence, and controllership repositories.
• Document classification and sensitivity tagging.
• Versioning and freshness SLA per source.
• Author and steward attribution captured at ingest.

Stage 2

Process and index

• Semantic chunking that respects clauses and tables.
• Hybrid vector and keyword index.
• Entity linking into the canonical ontology used by structured data.
• Quality scoring per chunk for retrieval ranking.

Stage 3

Serve to agents

• Grounding-only retrieval so no agent answer lands without a cited chunk.
• Citation identifiers flow into the evidence pack alongside structured signals.
• Per-agent knowledge scopes enforce least privilege.
• Stale-content quarantine triggers on freshness-SLA breach.

Memory plane

Three stores agents draw on across runs

• <strong>Episodic memory:</strong> per-run journal reusable as case memory, such as a supplier flagged 11 days ago with a known resolution. Bounded retention and fully replayable.
• <strong>Institutional memory:</strong> approved override patterns, accepted lessons, and near-miss incidents, promoted only by the Governance Council and never auto-learned.
• <strong>Working memory:</strong> short-lived session context and intermediate state carried across a bounded task without becoming a system-of-record write-back path.

Agentic compounding asset

Institutional memory is bp's compounding agentic asset: the durable layer where approved lessons and accepted patterns accumulate under governance instead of being re-learned from scratch every run.

What bp standards require

• Platform-first delivery through bp internal developer pathways such as LaunchPad / Yalla, not vendor-owned infrastructure.
• Centralized discovery, reuse, and registration through Nexus before new agents or MCP servers are created.
• Mandatory use of MCP for tool and data integration and A2A for multi-agent collaboration.
• AI use-case registration, risk triage, and production gating through AI LaunchPad with named human accountability.
• No direct or ad-hoc enterprise data access outside approved MCP, API, or iHub-style pathways.
• Three Lines of Defence, human oversight, and auditable telemetry for every production AI capability.

What bp Sphere must prove

• Agents are discoverable, owned, and registered in a governance model that aligns to Nexus concepts.
• Every capability has an accountable owner, policy bindings, promotion gates, and retirement path.
• Multi-agent behavior is explicit, orchestrated, and replayable rather than hidden in prompt chains.
• The runtime can show AI inventory, risk class, and LaunchPad-style certification posture for each production use case.
• The operating model stays inside bp's cloud, identity, and governance boundaries instead of introducing a parallel estate.

Platform-first

All AI runs on bp-approved cloud and runtime pathways. The narrative should explicitly reject vendor-owned infrastructure and shadow identity models.

Discoverable and reusable

The agent estate should expose registry metadata, reusable MCP servers, and A2A coordination contracts so capabilities built once can be composed many times.

Governed for production

Unregistered agents, unclassified risks, or non-compliant delivery paths should be impossible to present as “production-ready.”

Golden Path delivery

• bp-controlled repositories and Azure DevOps pipelines rather than vendor-hosted source control.
• Pre-approved build, security, performance, and deployment gates in the standard CI/CD path.
• Technical Design Document and Technical Design Review evidence before production certification.
• Runbooks, monitoring, rollback, and transition documentation as part of delivery, not post-go-live cleanup.

Evaluation and assurance

• Ground-truth evaluation metrics for AI quality; UAT alone is not enough.
• Component and end-to-end agent evaluation, including retrieval quality, reasoning relevance, tool behavior, and workflow completion.
• Drift thresholds, regression history, and promotion blocking when quality degrades.
• Adversarial or red-team testing for high-risk AI implementations.

Agentic UX compliance

• Confidence signals, source attribution, and human override controls in every AI-facing mission surface.
• Consistent role-based UX so analysts, supervisors, and leaders do not relearn each agent.
• Accessibility and design-system compliance as part of AI readiness, not visual polish.
• Trust, control, and transparency treated as UX requirements rather than hidden engineering details.

What the live system should show

• Registry metadata that looks like a governed production asset, not a demo list of agents.
• Trace drawers with prompt, model, retrieval, latency, citations, confidence, retries, and policy context.
• Evaluation surfaces with golden datasets, pass/fail trends, drift warnings, and promotion gates.
• Mission surfaces where confidence, evidence, and override remain inline for operators.

Proof language for the page

The strongest claim is not “the AI is smart.” It is “the AI estate is governable, testable, discoverable, and auditable inside bp's existing standards.” This is the gap that many suppliers will not close.

Identity and access architecture

What this validates for bp

• No separate shadow IAM model is introduced; bp identity remains the source of truth.
• Privileged execution can be bounded, audited, and escalated explicitly.
• Named accountability exists for human and agent actions through replay-backed attribution.
• Runtime telemetry can align to enterprise cyber monitoring and compliance expectations.

Questions to resolve with bp security

• What workload identity, JIT access, and PAM patterns are approved for production runtime components?
• What telemetry classes must be forwarded into SOC/SIEM and cyber audit workflows?
• What runtime isolation and cross-cloud segmentation standards must the pilot satisfy?
• What is the required model for break-glass, revocation, and privileged approval logging?

Operational IAM detail

• OIDC-based federation into bp identity with no separate local identity store for the runtime.
• SCIM-aligned lifecycle integration so role and entitlement changes propagate into mission surfaces and approvals.
• Managed workload identities for agents, tools, and connectors, each scoped to least privilege and bounded data domains.
• JIT privileged execution and PAM-compatible break-glass for sensitive actions, with replay-backed privileged traceability.
• Model access routed through the gateway so prompt, tool, and retrieval spans inherit the same identity and policy context.

Security-team message

Security review should be able to map the runtime to existing enterprise controls in operational language: federation, lifecycle, privileged access, segmentation, and traceability. “Supports Entra ID” is not enough; the page needs to show how access is provisioned, approved, elevated, traced, and revoked in practice.

What this answers

• How does bp Sphere fail safely without creating uncontrolled writes or hidden decisions?
• How are incidents replayed and reconstructed for cyber, audit, and operations teams?
• How do human fallback and bounded autonomy work under runtime degradation?
• What is the continuity story when one cloud plane or source system is impaired?

Questions to resolve with bp

• What RTO/RPO and SLA expectations apply to the first pilot domain?
• What DR and failover patterns are already approved across AWS and Azure for this runtime class?
• What crisis-management hooks must integrate with existing resilience workflows?
• What level of degraded operation is acceptable before manual-only fallback becomes mandatory?

Failure scenario that must be demoed

Failure proof surfaces

• The page should show one explicit degraded-mode path instead of implying that resilience exists somewhere in the platform.
• This is where bp sees that replay continuity, human fallback, and policy downgrade are designed into the runtime rather than added after incidents.