Bring in business data

Use this guide when a method needs information from another system, such as campaign results from an ad platform or figures from your finance system. It helps you choose how that information reaches the function, and walks through the first way.

Choose how the information reaches the function

	Your agent passes it in	The function calls a tool
How it works	Your agent fetches the information through its own connections and passes it to the function as input.	The function calls tools of a tool server while it runs, and the run records each call.
Where it is set up	In your agent, like any other connection it has.	In Auto Runtime's settings.
Good for	Trying a method, and work where you check the evidence before each run.	Runs that happen without you, such as scheduled workflows.
Guide	The steps below	Give a function tools, or Use Auto with Apollo for a GraphQL business graph

Neither side inherits the other's tools or credentials. Reasoning functions can call tools from MCP servers and HTTP APIs that Auto Runtime is configured with, and nothing else. Connecting a tool to your agent does not give the reasoning function access to it. In the other direction, your agent can try a runtime tool by hand with Auto's execute tool, but it calls it through the runtime, under the runtime's credentials, not through a connection of its own. Reasoning function format describes what a function may call.

Before you start

You need a connected agent, a method whose inputs are clear, and permission to connect the account that holds the information. Your organization may require an administrator to approve the connection.

Ask only for the access the method needs. A campaign review needs results for the right account and date range; it does not need permission to change budgets.

1. Identify the connection

Ask your agent:

For this method, identify the information we need from another system.
Check which connections are available to us. Explain which account
and permissions each requires, and whether it can change anything.
Do not connect an account or change permissions yet.

Check the proposal against what the method needs. Use connections your agent supports and your organization approves, and follow the integration provider's setup instructions.

2. Authorize the account

Where the integration uses OAuth, you approve access on the provider's sign-in screen. Check the account and the permissions it asks for before you approve, and use an account your organization approves.

Keep credentials in the connection's own settings. Never paste them into a prompt or save them in a function. Connecting one system gives no access to any other.

3. Check it with a read-only request

Ask your agent to fetch a small piece of information you can check in the source system. Name the account, the record or the date range, and tell it not to change anything.

Compare the result with the source. For campaign data, check the account and the date range as well as the numbers: a working connection to the wrong account is not a useful test.

If access is denied, check the account and its permissions with whoever owns the connection. If the data looks wrong, check the query and its filters before you change the method.

4. Pass the evidence to the function

Ask your agent to map what it fetched onto the function's inputs, show you the mapping, and run the saved function once you confirm it. The function sees only the values it is given: it does not inherit your agent's connections or the rest of the conversation. Use Auto with Apollo shows this step in full for graph data.

5. Record who owns the connection

Write down who owns the connection and what it is for, wherever your team keeps such notes. Review access when responsibilities change, and revoke the authorization when the connection is no longer needed.

Before colleagues use the method, read Share a playbook. Access to a playbook and access to a connected account are separate decisions.