Integration patterns for governed AI agents

An integration is not established by placing a vendor logo on a page. It is established by a supported operation, authenticated identity, accepted data scope, tested failure behavior and owned compatibility boundary.

This hub describes how integrations are scoped. Specific vendor and product availability is confirmed for the applicable release.

What integration families does an agentic platform need?

Family	Purpose	Governance focus
Identity	Authenticate people, services and administrators	Delegation, revocation, strong privileged access
Data source	Retrieve records or documents	Tenant, classification, purpose, freshness and minimization
Model endpoint	Run inference	Approved provider, data terms, location, evaluation and fallback
Tool target	Create an external effect	Typed operation, approval, idempotency and receipt
Event source	Trigger work from changes	Authenticity, replay, ordering and duplicate handling
Evidence sink	Retain audit and receipts	Integrity, access, retention and export
Notification	Reach reviewers and operators	Recipient scope, content sensitivity and delivery receipt
Administration	Configure policies and adapters	Separation of duties and change evidence

One provider may appear in several families. Each operation still needs its own contract.

What belongs in an operation contract?

operation: crm.contact.update
target_type: contact
effect: durable_write
identity: delegated_service_account
required_attributes: tenant, contact_owner, purpose
approval: resource_owner when material fields change
idempotency: request_id
receipt: target record version
timeout_state: unknown until reconciled
audit: request digest, policy, approval, receipt

The contract makes policy possible. A generic integration method such as call_api hides the consequence from the runtime.

How should identity be handled?

Prefer delegated or scoped credentials that identify the represented principal and permitted operations. Avoid one broad service account shared by unrelated workflows.

Document token lifetime, refresh, revocation, secret custody, administrator access, tenant scope and unavailable behavior. For disconnected deployments, identity and revocation sources must operate inside the boundary.

How should data access be handled?

Shape the query around tenant, ownership, classification and purpose before retrieval. Request only the fields needed for the task. Record source, freshness and data lineage.

If the integration returns more data than policy permits, filtering in the model prompt is too late. Enforce the boundary in the adapter or data store.

How should write operations be handled?

Use typed parameters, validation, current-state checks, parameter-bound approval, idempotency where the target supports it, and durable receipts.

For irreversible or externally visible actions, verify the final state from the authoritative target. A successful HTTP response may confirm receipt without confirming the intended business outcome.

What failure states must be defined?

State	Required behavior
Authentication denied	Stop and alert the credential owner
Validation rejected	Return a specific recoverable error
Rate limited	Retry within a bounded policy or hold
Timeout before send	Safe retry may be possible
Timeout after send	Reconcile before retrying
Partial batch	Record per-item state and continue only by policy
Duplicate event	Detect and suppress or handle idempotently
Target version changed	Re-read and require a new decision when material
Evidence write failed	Hold consequential action or enter explicit degraded policy
Unknown response	Preserve ambiguity and assign reconciliation

Calling every non-200 response "failed" can cause a duplicate side effect when the target accepted the request but the response was lost.

How are integrations tested?

Test authentication, least privilege, positive operations, prohibited operations, malformed parameters, cross-tenant access, expired grants, duplicate delivery, rate limits, timeouts, partial success, API-version change, unavailable target and evidence failure.

Run tests against a representative sandbox or faithful contract fixture. Record the adapter and API versions. A prior green test does not establish current compatibility after either side changes.

How should integration availability be published?

Publish specific support only when the release evidence and commercial offer agree. State whether an integration is built-in, configured, custom, preview, read-only or planned. Name the supported operations and product.

This company page deliberately does not infer support from providers mentioned elsewhere in portfolio copy. Contact Trunnion with the target system and operations to receive a current scope.

What should a buyer provide for scoping?

Provide the product and API documentation, authentication method, desired operations, object and field scope, approximate volume, data classification, environment, test account, error and retry expectations, acceptance criteria, and the owner who can approve target-system changes.

Do not send secrets or restricted data through the public site. Establish an authorized channel before exchanging credentials, exports or production examples.