Suppose an invoice-coding agent works well in its builder's demo. Next week, the finance team will depend on it, and the builder won't be on call. Who handles a stuck queue, a wrong suggestion, or an unexpected permission request?
Write those answers into a short operating agreement before the handoff. The next operator should know what the service may do, how to investigate it, and who can approve a change.
Agree on the job before reviewing the controls
Consider a hypothetical invoice assistant. It extracts invoice details and proposes coding for review. It does not approve payments or alter bank details.
That service description is intentionally narrow. A later change to submit payments would reopen the agreement, even if the agent kept the same name and framework.
Use the operational inventory to establish the deployed workload, registered identity, credentials, and owner. The meeting starts from that record rather than recreating it.
Complete the operating agreement
The following is an illustrative completed agreement, not a customer deployment or a claim that the listed tests have run.
| Commitment | Example agreement | Evidence required before production |
|---|---|---|
| Business boundary | Propose invoice coding; a reviewer makes the accounting decision | Allowed-effects description and backend permission review |
| Accountable service owner | Finance applications owns purpose, service recovery, and scope changes | Named team and reachable on-call route in the service catalogue |
| Runtime operations | Platform operations owns deployment, gateway configuration, and agent credentials | Deployment link, agent ID, endpoint configuration, and credential owner |
| Policy changes | Finance approves business scope; security reviews authority expansion | Reviewed rules and positive/negative acceptance cases |
| Budget behavior | Pause new batch work when the approved budget is exhausted | quota configuration and application handling evidence |
| Investigation | Operations retrieves governed records; finance supplies invoice-system state | One reconstructed synthetic operation |
| Containment | On-call may suspend the identity and stop the worker; finance reconciles accepted work | Rehearsed stop and recovery procedure |
| Re-review | New write effects, new destinations, ownership transfer, or changed failure behavior reopen review | Triggers attached to the normal change process |
Fill in actual people and links in the service record. “Platform” is an organizational label, not a reachable escalation route.
Test the configured application
Dome provides concrete parts of this agreement: agent identities and lifecycle controls, runtime rules, and shared audit evidence.
Check those controls in the workload you plan to release. An agent record does not establish that the application points at the intended gateway. An allowed call does not establish that the proposed invoice coding is correct.
For this service, the review should verify that the application can produce a useful proposal without acquiring payment authority. That is the business distinction the controls and tests need to preserve.
Who handles an uncertain result?
Suppose the review discovers that no one can reconcile invoices left in an uncertain state after a timeout. Adding more gateway logs will not assign that responsibility.
Name the finance owner and decide which invoice-system record is authoritative. Then rehearse the handoff from the on-call engineer to that owner.
Similarly, if a provider outage makes the application retry indefinitely, the application team needs a bounded failure path. The platform team can supply routing and controls, but the operating agreement must say when the service stops trying and who communicates the delay.
Approve, narrow the scope, or hold the release
End the meeting with a decision. Approve the defined scope, allow a smaller release with enforceable restrictions, or name the missing evidence that keeps it on hold.
For the invoice assistant, a bounded release might allow proposal generation for a small queue while excluding sensitive invoice categories. That limitation must be enforced by the actual workflow and controls, not merely written in the meeting notes.
Give every open item an owner and a clear completion test. A missing recovery contact can block a safe handoff even when all the code is finished.
Update the agreement when the job changes
Attach the agreement to the service's normal release process. Ownership transfers, tool additions, new model destinations, and changed business effects should trigger review of the affected commitments.
The practical test is a second operator: can they find the identity, explain the allowed work, retrieve one event, and carry out the recovery procedure? Use that exercise to improve the agreement before increasing the workload's authority or scale.