Skip to main content

​
Governance responsibilities: buyer vs. seller

Campaign Governance uses the same check_governance task from two different positions in the transaction. The buyer-side orchestrator checks intent before it sends an action. The seller checks execution before it commits or changes delivery. Both checks go to the buyer’s configured governance agent, but they carry different evidence.

​
Roles

​
Setup: bind the seller to the governance agent

Before a seller can make seller-side checks, the buyer account must sync governance agent endpoints with the seller via sync_governance. This is account setup, not per-buy negotiation. The seller stores the configured governance agent endpoint and credentials for the account. Later, when a governed request arrives, the seller knows where to call check_governance.

​
Buyer-side intent check

The buyer-side orchestrator calls check_governance before every spend-commit action on a governed plan. The intent check sends: If the governance agent returns approved or conditions, it returns a governance_context token. The orchestrator attaches that token to the request it sends to the seller. If the response is conditions, the orchestrator must apply the conditions and re-check before proceeding.

​
Seller-side execution check

When a seller receives a governed spend-commit request, it performs an independent execution check before confirming the action. The seller-side check sends: The seller must not treat the buyer’s intent check as sufficient by itself. The seller checks what it will actually deliver, which may differ from the buyer’s request because of inventory availability, seller defaults, or implementation constraints. If the governance agent denies the execution check, the seller must not proceed. If the governance agent returns conditions, the seller must adjust planned delivery and re-check before confirming.

​
Outcome reporting

After a seller responds, the buyer-side orchestrator calls report_plan_outcome. This lets the governance agent reconcile the approved action with the seller’s actual response and update budget state from confirmed outcomes. Outcome reporting is what prevents the governance agent from counting attempted actions as committed spend. The governance agent tracks the state that actually happened.

​
Common mistakes

​
Minimal sequence

  1. Buyer configures governance on the account with sync_governance.
  2. Buyer creates or updates a plan with sync_plans.
  3. Buyer calls check_governance with tool and payload.
  4. Buyer sends the seller request with governance_context.
  5. Seller verifies the context and calls check_governance with plan_id, caller, and planned_delivery.
  6. Seller confirms, rejects, or adjusts based on the governance verdict.
  7. Buyer calls report_plan_outcome with the seller result.
See the check_governance task reference for request and response fields, and the Campaign Governance specification for lifecycle and token validation details.