Give the agent a role. Not unlimited authority.

A model can interpret a request, but the application still needs to establish whose business the request concerns and what that party has authorised. The agent’s conversational context should not become the source of financial permission.

SUPA’s integration direction separates the principal, the agent and the enabled service scope. This gives your application a practical foundation for deciding which information can be retrieved, which preparation tasks can proceed and which consequential actions require an explicit review. A more capable model should not silently receive broader authority.

A workflow needs a clear answer when an action falls outside the agent’s scope. That may be a request for approval, a missing-information state or a prepared task handed back to a responsible person. The interface should explain what happened and what is required next.

The same principle applies after a service call. A submitted request is not automatically a completed operation, and a timeout is not evidence that nothing happened. Your application needs to present the provider’s actual state and follow the agreed recovery process before attempting a consequential action again.

An agent may stop serving a business, a team member may leave or a use case may require narrower permissions. Access needs a lifecycle that can be reviewed and withdrawn. The integration should also preserve the relevant record of actions taken under earlier authority.

We work through these requirements alongside the first supported workflow. Start with a concrete task and a clear permission boundary, test the review and exception paths, then consider additional capabilities when the corresponding service requirements are met. Financial execution should never be inferred from access to onboarding or business information.