Connect Apps and Tools to Your Agents

Before You Start

Decide which agent needs access, which app it should use, and what job the app supports. Connect the smallest useful set of tools first so the first test is easy to inspect.

Use an account that has permission to authorize the app, read the records the agent needs, and perform any actions you expect the agent to take. For team-owned workflows, connect a shared or admin-approved account instead of a personal account when your security policy requires it.

Have any required API keys, workspace ids, project ids, or admin approvals ready before setup. If the app uses OAuth, be prepared to approve the requested scopes in the provider window.

Connect the App

Open Integrations, find the app, and choose Connect. For OAuth providers, Agentic Workers sends you to the provider so you can approve access without sharing your password with the agent.

For API-key based providers, paste the key or token from the provider account. Use a key with the narrowest permissions that still supports the workflow, and rotate it from the provider if it is exposed or no longer needed.

After the provider confirms authorization, return to Agentic Workers and check that the integration shows as connected. If your workspace has multiple teams or organizations, confirm you connected the app in the workspace where the agent lives.

Attach Tools to an Agent

Open the agent that should use the connected app. In the agent tools or integrations area, enable the connected app actions that match the agent role.

Keep the tool list focused. For example, a support agent may need to search Gmail and draft replies, but it may not need permission to send messages without approval.

Add clear agent instructions for when to use the app, what data to look for, and which actions require confirmation. Sensitive actions such as sending customer messages, changing records, issuing refunds, or posting publicly should require approval unless your workflow explicitly allows autonomous execution.

Verify Access With a Small Prompt

Run a prompt that proves the exact permission you need before relying on the workflow. Start with read-only checks such as "Find the three newest unread support emails and summarize the senders, subjects, and requested next action."

Then test any write action in a low-risk way. Ask the agent to create a draft, prepare an update, or show the exact change it would make before approving execution.

Review the response and the trace, the step-by-step run log. Confirm the agent used the expected app, selected the right account or workspace, and either completed the action or asked for approval at the right point.

Troubleshooting

If the app does not appear for the agent, reconnect it from Integrations and confirm the connection belongs to the same workspace as the agent.

If OAuth fails, check that pop-ups are allowed, you are signed into the correct provider account, and your provider admin permits third-party app access for the requested scopes.

If an API key fails, create a fresh key in the provider, confirm it has the required permissions, and remove any extra spaces before saving it.

If the agent says it cannot use a tool, enable that specific action on the agent and rerun a narrow verification prompt. If the trace shows a permission or scope error, reconnect the app with the required scope or use an account with access to the target resource.

If the agent used the wrong app action or guessed at missing data, update the agent instructions with the correct source, approval rule, or fallback question, then repeat the same test prompt.

Next Steps

After the manual verification works, turn the request into a reusable prompt or scheduled job if the task repeats on a predictable cadence.

Use traces after the first few real runs to check tool calls, approvals, and failures. Small instruction updates usually fix most integration issues.

Review connected apps periodically. Remove tools an agent no longer needs, rotate API keys according to your security policy, and reconnect OAuth apps when provider permissions change.