Build with it

Player One has doors on the outside, and it works better with company. Your software can call the AI models you have connected, anything that speaks HTTP can post an event in, and Claude Code, Codex, Cursor or any MCP tool can talk to your agents. Going the other way, Player One can hand big coding jobs to Claude Code or Codex, use the tools of an MCP service, and talk to an agent on another installation. It can also build a page that asks someone a question and hands the answer back to the chat, and give an agent that serves your customers a tool that reaches into your own system.

Player One is the one you run. Everything you connect it to, a coding agent, an MCP service or another person's Player One, is what it teams up with.

You set most of these up by asking in the chat, then see each on a page in the app and cut it off from there. Keys are the exception: you make those on a page, never by asking.

Call your models from your own code

You do: open Admin > Security > API keys (/admin/api-keys), choose New API key, name it for the booking site, pick an expiry of 90 days and press Create key.
Player One does: makes the key and shows it to you once.
You see it: the key in the list, with the address to call on Admin > LLM Endpoints (/admin/endpoints).

Your installation publishes one address that reaches every model you have connected. It is compatible with the most common chat API format, so libraries and tools that already speak it work unchanged: give them the address and the key, and ask for a model by name. Use Player One from your own apps walks it through.

The key is shown once, at creation, and never again. Give each app its own, with the shortest expiry that suits it. Revoking one stops it working immediately and cannot be undone, so create the replacement first.

Every call your software makes is on Admin > Usage > API calls (/admin/usage/calls): the model, the prompt size and a piece of it, the tokens, the cost and whether it worked.

Two honest caveats. Calls through this door get the model and nothing else: no agent, no memory, no tools, no project. And the page carries an early access notice, so do not build anything critical on it yet.

A URL your systems can post to

You say: "Give me a URL our contact form can post to that messages me on Telegram."
Player One does: mints an address and hands it back in the chat.
You see it: Admin > Webhooks (/admin/webhooks).

There are two shapes. One delivers a message to a channel you have already connected, with no model involved. The other runs one agent turn on whatever was posted, for when something has to read it and decide. Both list their address, whether the sender signs its requests, and how often they have fired.

There is deliberately no create button: you ask, and Player One hands back the address. Your installation needs a public web address for the sender to reach, and a message can only go to a channel you have already connected. Set up a trigger covers this and the other ways an outside event starts work; when one should start a whole process rather than a single turn, see Make it repeat.

Pages that ask, and answer back

You say: "Show me the three layouts as pictures and let me pick one."
Player One does: writes a small page and opens it beside the conversation.
You see it: the preview pane, on the right.

When a question does not fit in chat text, Player One builds the surface for it: a grid of options, a form with real validation, a colour picker, a list you drag into order, a place to drop a file. What you choose goes back into the conversation as your answer. Treat the page's address as a secret, because anybody with the link can open it, and keep submissions small: a couple of hundred kilobytes is ample for choices and form values.

A tool of your own, for an agent that serves customers

You say: "Give the support bot a way to look up an order in our system."
Player One does: builds one narrow tool around one call to your API.
You see it: the Tools tab under Advanced on that agent's page (/agents/<name>/advanced), from Manage > Agents (/agents).

The tool is the boundary, and it is deliberately tight: a fixed shape for what may go in, a named list of the fields that come back, and the credential held in your vault rather than handed to the agent. However the conversation goes, that agent can call the one action you allowed and see nothing else. Grow your staff covers those agents, Vault and sandboxing the credential.

Coding agents, on your own code

You say: "Take the refactor to a coding agent and work in our repository."
Player One does: starts a session with that agent in the workspace, and reports back in the chat you asked in when it is done.
You see it: the coding agent's face beside the message box, a linked chat you can open, and the results under Manage > Files (/workspaces).

Player One drives Claude Code, Codex, Gemini CLI, Kimi Code and OpenCode rather than trying to replace them. Bounded work stays in the conversation; for a large or multi-file change Player One says plainly that a dedicated coding agent will do it better, and offers to hand it to one. The gain is that this one works where your files, your memory and the rest of your team already are.

Each is off until you ask for it, needs its own account connected, and then runs on that account's own models rather than the rules you set for your agents. While a session is open you can type into its linked chat and your message goes to the coding agent. Hand big coding work to a coding agent has the setup, what it can touch and what it runs on.

You say: "Share the researcher so Hanley's team can use it."
Player One does: publishes the agent and hands you a link to send. When they ask for access, you approve them with a code they send you, which only you can enter.
You see it: Admin > Sharing (/admin/agent-sharing), in the Communications group.

The agent keeps running on your installation, with your model, tools, files and memory. The other side talks to that one agent and sees only what it sends them, and you can read the conversation and talk to your agent privately in it. A sandboxed agent can also be opened to anyone with an address, for a chat on your website, with limits you set and flood protection always on. It works the other way too: an agent someone shares with you arrives on your Agents page with a Shared with you badge.

End access stops one installation and Stop sharing stops everyone, both from the next message. Share an agent has the steps.

Let your coding agent talk to Player One

You do: open Admin > Communications > MCP (/admin/mcp), make a key, and paste one prompt into your coding agent.
Player One does: lets that coding agent read your chats, talk to your agents, answer the decisions waiting for you and search what Player One knows, as far as its key allows.
You see it: the coding agent in your contacts as an agent of its own, and its messages in the chats it starts.

This is the other direction from the coding agents above: Claude Code, Codex, Cursor, VS Code and other tools that speak MCP reach into your installation from your own computer, through one address and one key. The page walks you through three steps. Key makes a key and sets what it may do: Read, Chat, Decide, Notify and Memory are on by default. Harness picks your tool, where Let the agent do it gives you one prompt to paste and Do it myself gives the command or settings. Watch, the optional third step, is a prompt that has the coding agent take up work your agents leave for it.

A coding agent speaks as itself, never as you. The one exception is Owner, off by default, which lets your agents treat its messages as yours, owner-only tools included: turn it on only for one you trust as yourself. Its keys are listed on the MCP tab of Admin > Security > API keys (/admin/api-keys/mcp), where revoking one stops it at once and keeps its history. The key is shown once, so copy it before you leave the page. Connect Claude Code, Codex or another tool to Player One has the steps.

Tools and services of your own, over MCP

You say: "Connect the MCP server at https://mcp.example.com/mcp so the ops agent can use it."
Player One does: adds the server, and its tools join your agents' own on their next run. If the server offers written guidance for its tools, the agent reads it before the task.
You see it: the agent using the service's tools in its replies.

For a service that should not hold a key of yours, Signed connections on the same MCP page lets you give the service your installation's public key and approve where Player One may sign its requests. Only you can add one: no agent can. A sandboxed agent never gets an MCP server. MCP covers both.