Composio End-user Experience
This guide explains who authorizes accounts and who the agent acts as, based on product model.
Use Case Mapping
Use case 1: One business account for many customers
Example: customer-service assistant for a business.
- Who authorizes: business/admin once.
- Typical principal:
service. - Runtime behavior: all conversations execute tools against the same linked business account.
When to use:
- shared inboxes
- shared calendars
- shared social accounts
Use case 2: Each app user has a personal agent
Example: SaaS app where each user gets their own agent.
- Who authorizes: each end user.
- Typical principal:
end_user. - Runtime behavior: each conversation should include that user’s
executionPrincipal.
Use case 3: Internal workforce with personalized agents
Example: law firm, each employee has a personal Gmail/Calendar/Slack account.
- Who authorizes: each employee.
- Typical principal:
end_user. - Runtime behavior: agent acts on behalf of the employee tied to the conversation/request.
Practical Rule
- Pick service when one shared account should be used for everyone.
- Pick end_user when actions must be isolated per individual user identity.
Why this matters to end users
- Correct principal selection determines:
- whose mailbox/messages are read
- whose calendar events are modified
- whose external account receives side effects
If principal mapping is wrong, the agent can operate on the wrong account even if provider linking was successful.
Recommended implementation pattern
- Set an agent default principal:
servicefor business-shared agentsend_userfor personalized agents
- For personalized agents, always send:
executionPrincipal: { "type": "end_user", "endUserId": "<stable-user-id>" }
- Use one stable
endUserIdper app user across all conversations.
Identity boundary reminder
The chat sender and tool execution principal can be different by design.
Rooaak decides tool identity from executionPrincipal (or agent default), not from chat text or session label.