Whose account the Agent acts as
An Agent's integrations are derived from its Procedure - every # tool reference adds the tool's integration. The Integrations drawer shows the derived set and, for each one, whose credentials its calls run with.
The Integrations configuration panel requires the domain Owner role because it manages shared connection information. Its navigation entry is hidden for Viewers, Operators and Editors. Authoring the agent's Procedure and tool references separately requires Editor or Owner access. See Roles and permissions.
The identities you choose between
For each integration, Runs as selects the identity:
- The domain's own name (Customer Support, Finance - the option reads Domain account where the name is not loaded yet) - calls use the team account connected to the Agent's domain, a service connection managed by that domain's owners. This is the default.
- The person using it - calls use the sign-in of whoever is running the Agent, with the domain connection's settings and enabled tools. Two people chatting with the same Agent send from their own mailboxes. Each member signs in once under My account on the Integrations screen; nothing is needed from a domain owner first, because personal sign-in is on by default (an owner can turn it off per integration under Personal sign-ins). Beside it, choose what happens for someone who hasn't signed in: Fail if they haven't signed in (the default - the tool fails with a sign-in link) or Fall back to the domain, which uses the team account and says so.
- API caller - the credential arrives on each API fire call and is scoped to that one execution, so different customers of your product can each act as themselves (see Caller credentials).
There is no fallback between identities that you did not choose. A missing account stops the call - with a named error where one exists, and otherwise by leaving that integration's tools out of the turn - instead of blending identities.
Platform (managed by Yekar.AI) can also appear on Yekar.AI-managed integrations, but it is assigned by the system rather than chosen here.
On a plan that permits a single domain, Runs as offers no The person using it option and no domain names: there is one team account and nothing to choose between. See Identity.
An Agent bound to The person using it runs unattended as the person who created the trigger, while that identity remains available. If it cannot resolve, the configured policy either falls back to the domain account or skips the fire with a reason in the trigger's run history. See Identity.
Connect what the Agent needs
The drawer tells you, per integration, which account it resolves to and which named credential would be used - "Uses the Customer Support domain's team account - credential Production". If the domain has no connection, the drawer links to where one is connected. Connecting accounts is covered in Connect an integration.
Gate the risky writes
Any tool the Agent holds - read or write - can be made to stop for a human decision before it runs, per tool, in Settings. In an attended conversation using the initiator's own or the domain's credentials, this is a confirmation for that person. Otherwise it is an approval routed by credential authority. An organization Owner or Admin can additionally require approval for a tool across every Agent via Tool approvals; an organization requirement always takes precedence over an agent confirmation and no Agent can remove it.
Tips
If a session fails with SERVICE_CONNECTION_MISSING, the Agent runs as its domain's team account but that domain has no usable connection - connect the integration for that domain. If a banner above the composer says the Agent runs as you and you have not signed in, or that a domain owner has turned off personal sign-in, that is a person binding that cannot resolve - it has no error code, and the banner links the one person who can fix it. See Troubleshooting.