In a joint AI implementation, the customer, delivery partner, and platform vendor need explicit responsibilities for each decision. The customer supplies business priorities and authorized data owners; the partner estimates and implements the integration; the vendor confirms supported platform behavior. Those are starting points for a review, not automatic authority to approve cost, access, or launch.
The useful artifact is a decision matrix with named people, evidence, a deadline, and a disagreement route. An FDE can assemble that record and explain the engineering tradeoffs. Being the person who writes the code does not automatically make them the person who can approve a larger engagement.
Why joint delivery needs a decision record
Google Cloud and Accenture’s September 8, 2026 announcement describes a delivery group combining partner expertise and Google Cloud engineering talent, with a planned 1,000-person FDE workforce. That is an announced plan, not a count of completed hires or open vacancies.
Our interpretation: when several organizations contribute to delivery, a request can be technically feasible while its cost, data access, or acceptance decision remains unresolved. A joint delivery model makes that coordination problem worth addressing; the announcement does not prove that the proposed matrix improves outcomes.
A five-decision responsibility matrix
Use one row per decision. Replace the example roles with names and confirm that each person can make the stated decision. The partner’s commercial owner must also authorize changes to the partner’s commitments; customer approval alone cannot change them.
| Decision | Customer | Delivery partner / FDE | Platform vendor | Evidence to attach |
|---|---|---|---|---|
| Scope change | Sponsor prioritizes the request and approves customer scope and budget. | FDE estimates impact; authorized delivery owner accepts revised commitments. | Technical contact confirms supported capability when uncertain. | Current baseline, options, dependencies, revised estimate, both approvals. |
| Data readiness | Data owner authorizes resources and resolves source-quality gaps. | Engineer tests access, freshness, and representative failure cases. | Contact clarifies relevant platform constraints. | Approved inventory, observed access tests, unresolved data gaps. |
| Acceptance | Business owner decides whether agreed workflow criteria are met. | Technical owner presents test evidence and remaining defects. | Contact explains product limits relevant to the evidence. | Versioned criteria, representative cases, known failures, decision. |
| Commercial exception | Authorized buyer approves changed spend or customer terms. | Commercial owner approves changes to partner commitments. | Authorized vendor contact addresses changes to vendor commitments, if any. | Written change record; approvals from each affected organization. |
| Unresolved disagreement | Sponsor names the customer escalation authority. | Delivery lead records the blocked decision and next review. | Named escalation contact addresses platform disputes. | Disputed point, options, decision deadline, hold boundary. |
For each row, add a decision ID, proposer, named approver or approvers, evidence links, decision deadline, status, and escalation route. Multiple approvals should be explicit when different organizations control different commitments. Avoid assigning everyone the same undifferentiated “accountable” label.
Worked example: one more integration after the pilot is sold
Fictional scenario: a partner is building a read-only assistant over approved support articles. During the pilot, the customer asks it to read order status from a second system. The platform can call a tool, but the new integration has no approved access route, test data, or freshness requirement.
The customer says it is a small addition. The partner says the pilot is fixed-scope. The vendor says tool calling is supported. All three statements can be true. The FDE needs a decision about this customer integration, not another demonstration that a tool call works.
- Request and baseline: add order-status answers. Current accepted scope is support-article retrieval only, with no order-system access.
- Proposer: Priya, customer operations lead. Desired outcome: support staff can check the latest order status without changing systems.
- Impact owner: Maya, partner FDE. She separates adapter work from identity approval, data freshness, evaluation cases, and support ownership. Estimate remains provisional until the customer supplies access and sample responses.
- Vendor input: Leon, platform technical contact, confirms the documented tool interface. This confirms a capability; it does not approve customer data access or guarantee end-to-end behavior.
- Options: retain the original pilot and defer the integration; time-box a read-only feasibility check; or agree a revised delivery scope after dependencies are resolved.
- Approvers: Priya approves customer priority and acceptance changes; the customer budget owner approves extra spend; Sam, partner delivery owner, approves the revised partner commitment. The customer data owner separately approves access.
- Deadline and escalation: review at Thursday’s scope meeting. If access remains unresolved, Priya escalates to the data owner. Sam records which delivery milestones depend on that answer.
- Recorded decision: hold the new integration. Continue the original pilot only if its existing acceptance and access conditions remain valid. No one represents the extra feature as committed.
- Reopen when: approved read-only access, representative responses, freshness expectations, and a revised estimate are available.
The record lets the FDE explain exactly what would make a “yes” possible. It also gives the customer a useful choice: delay the extra integration without silently expanding the original pilot’s promise.
Run the review in five steps
- Write the baseline. Identify the accepted workflow, systems, and criteria before discussing the new request.
- Separate feasibility from authority. Ask what works technically, what evidence is missing, and who can approve each affected commitment.
- Present options. Show the smallest bounded option and what it leaves unresolved. Label estimates provisional where dependencies are unknown.
- Record the decision. Capture approvers, evidence, deadline, and an explicit approved, deferred, rejected, or blocked state.
- Update the working plan. Link the decision to scope and acceptance records. Reopen it when a named assumption changes.
How this differs from a runtime checklist or incident card
This matrix addresses decisions between organizations during delivery. Use the managed-agent responsibility worksheet for component-level provider and customer boundaries, the evaluation contract for launch evidence, and the incident ownership card when an operating workflow needs containment and recovery.
What an FDE should be able to demonstrate
A useful career example explains a disputed request, the options you made reviewable, the people authorized to decide, and the resulting plan. A team lead should give the FDE access to those decision makers and a clear route for unresolved questions. Coordination should produce a recorded decision, rather than make the engineer an unofficial buyer, data owner, and commercial approver.
Sources and limits
The Google Cloud/Accenture primary announcement linked above was checked September 22, 2026. It supplies joint-delivery context, not evidence of this workflow’s effectiveness. The responsibility assignments, decision record, names, and scenario are editorial synthesis and fictional illustration. They are not an account of that partnership’s internal process.
The FDE Brief
Get the next operator playbook.
Get field notes on deployment ownership, team design, and turning customer work into reusable capability.
Reader question
Which decision stalls between teams?
Which decision gets stuck between your customer, delivery partner, and vendor? Please omit confidential details.