Connect agents and apps

Pick the path by who calls whom.

Direction	How	Runs as	Limits	Page
Agent → agent	The Call Agent tool, or an @mention in chat	The person running the calling agent	Background only; two levels deep; the called agent must accept work	Hand work to another agent
App → agent	The app's backend runs an agent with the app's own key	The signed-in person viewing the app	Visitors who are not signed in are refused	Call an agent from an app
Agent → app	The app serves MCP tools; the app is added as an MCP connection	The token in the connection	The app must be `public`; the token is in the URL	Let an agent use an app
App → app	An MCP connection the calling app declares, or the other app's public URL	The person viewing the calling app, or anyone	Same as agent → app	Connect two apps
Outside system → app	A signed webhook	The app's own signature check	The app must be `public`; the signature is in the query string	Send events to an app
Outside system → agent	An API key with `run-stream` or a background run	The key's owner		Run and stream agents

Why some paths need a public app

Apps are served through the app gateway, which knows a caller only by a signed-in browser session. A call from a server, such as an agent's MCP connection, a webhook sender or another app's backend, has no session, so the gateway lets it through only when the app's visibility is public (visibility). Otherwise it redirects to sign-in.
The gateway passes only these request headers to the app: content-type, accept, accept-language, range, user-agent, cache-control. Authorization and custom headers never reach the app, so the app checks a token or a signature from the query string.
An app's own calls to the platform do not go through the gateway, so app → agent works for private apps.
Anyone with a public app's link can open it. Keep data that only some people may see out of apps that agents or outside systems must reach, or check the token on read routes too.