---
title: "Share a playbook"
description: "Give a colleague access to a tested method on a team runtime, and check that they can use it with the access you intended."
url: "https://on.auto/docs/cloud/sharing"
last_updated: "2026-10-17T10:18:42Z"
---

# Share a playbook

Use this guide to let a colleague use a method you have tested. At the end, your colleague runs the same saved function from their own agent, with the access you agreed.

## Before you start

Sharing needs a runtime your colleague can reach. The runtime from the [quick start](https://on.auto/docs/get-started/local) accepts connections from your own computer only, so a colleague cannot use it. Do not expose it through a tunnel or public proxy. Instead, run Auto for your team as [Self-hosting](https://on.auto/docs/self-host) describes, with HTTPS and a public address.

Work you do on your own computer stays there: Auto has no export. If a method is meant for the team, build it on the team runtime from the start. If you already built it locally, the next section shows how to recreate it.

You also need:

*   which playbook and function you are sharing;
*   a sample input your colleague is allowed to see, and a result you have already reviewed for it;
*   an agreed owner for the method, who answers questions about its results.

Test the method on representative examples before you share it, including one with missing information, so your colleague can see how it handles that case.

## Move a method from your computer

A playbook and its runs stay in the runtime that recorded them. To move a method you built locally, recreate it on the team runtime:

1.  Connect your agent to both runtimes, as two connections with different names, such as `auto-local` and `auto-team`.
    
2.  Ask your agent what the playbook depends on:
    
    ```text
    List what my "<playbook name>" playbook on auto-local depends on: tool servers
    its functions call, datasets its prediction functions were given, and which
    functions each workflow calls. Do not change anything.
    ```
    
3.  Prepare the team runtime first. Its operator configures the same tool servers. Datasets that prediction functions were given must be uploaded again: Auto cannot download them, so you need the original files, and an agent that can run commands and make web requests to upload them.
    
4.  Ask your agent to copy the definitions:
    
    ```text
    Copy my "<playbook name>" playbook from auto-local to auto-team. Create a playbook
    with the same name and id there if it does not exist. Copy each function and
    workflow with its document unchanged, in the order they depend on each other.
    Leave out each workflow's schedule for now, so nothing starts on its own. If a definition with the same name already exists on auto-team, show me
    both and ask me before changing it. Tell me anything you could not copy.
    ```
    
    Your agent reads each definition with `get_definition` and creates it with `create_definition`, using the same `source`.
    
5.  Rebuild what does not travel. A prediction function needs a new build on the team runtime, since trained versions do not move. A recall function rebuilds its view from the team runtime's own history, which does not include anything recorded on your computer.
    
6.  Run your test examples on the team runtime and compare the results with the local ones.
    
7.  Once the results match, ask your agent to add back the workflows' schedules on the team runtime.
    

The team runtime numbers each definition's versions from 1 again, and the local run history does not move.

## Decide what access they need

There are two ways for a person to call a team runtime:

|  | Signing in | An API key |
| --- | --- | --- |
| Who it suits | A colleague who uses Auto through their own agent | A machine, a pipeline, or a person who needs narrower access |
| What it grants | Through their agent: every playbook in their organization, with the permissions they approve when they sign in. In Auto Studio: every permission in the organization | Only the playbooks and permissions the key lists |
| Who sets it up | Your colleague signs in to Auto, in the same organization as you | The runtime's operator creates the key |

Each operation needs one permission:

*   `playbook:read` lets them read definitions, runs and history.
*   `playbook:write` lets them run functions and workflows, and create or change definitions. Running and changing are not separate permissions, so anyone who may run the method may also change it. A colleague who runs the method usually needs `playbook:read` as well, to read the results.
*   `org:read` and `org:write` let them list models and playbooks, and create or change playbooks.

To bring a colleague into your organization, invite them from the account menu in [Auto Studio](https://studio.on.auto/), under the organization's members. They accept the invitation when they sign in. Anyone you invite this way can run your methods, and so can also change them.

If your colleague should only inspect results, or only use one playbook, ask the operator for an API key limited to that. [Authentication and security](https://on.auto/docs/self-host/security) describes signing in and keys in full.

Access to a playbook does not give access to the accounts your agent connected. If the method uses information from other systems, agree that separately; see [Bring in business data](https://on.auto/docs/cloud/connections).

## Set up their connection

Give your colleague the runtime's MCP address, such as `https://runtime.example.com/mcp`, and tell them how they will authenticate:

*   **Signing in:** they add the address to their agent as the [quick start](https://on.auto/docs/get-started/local#connect-your-agent) shows for `localhost`, and sign in when the agent asks.
*   **An API key:** the operator gives them their own key, and they add it to the agent's connection as a bearer token. [Run with Docker](https://on.auto/docs/self-host/docker) shows the commands for Claude Code and Codex.

Each person uses their own sign-in or key. Never share your own token or key.

## Check it from their account

Ask your colleague to find the function through their agent and read its definition. If they may run it, ask them to run your sample input and compare the result with yours.

Seeing the function does not prove they may run or change it. Check with the operator that their access matches what you agreed.

If a request is refused, check that they are in the right playbook and what their sign-in or key allows. Do not solve an access problem by sending your credentials.

## Agree how changes are handled

Tell colleagues who reviews changes to the method and where to report unexpected results. A report should include the run's id, which their agent can give them; [Inspect a run](https://on.auto/docs/cloud/console) explains what to check.

When the method changes, run your test examples again. Review playbook access, and the permissions of any connected accounts, when someone changes role or leaves the team.

## Sitemap

See the [full documentation and product sitemap](https://on.auto/sitemap.md) for related pages.