Build with it

Player One has doors on the outside. Your software can call the AI models you have connected, anything that speaks HTTP can post an event in, Player One can build a page that asks someone a question and hands the answer back to the chat, an agent serving your customers can be given a tool that reaches into your own system, a coding agent can be pointed at your code, another installation can talk to an agent you share, and the coding agent on your own machine can talk to Player One.

You set each one up by asking in the chat, then see it on a page in the app and cut it off from there.

Call your models from your own code

• You say: "Make a key for our booking site, expiring in 90 days."
• Player One does: creates the key and shows it to you once.
• You see it: Admin > API keys (/admin/api-keys), 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 when it is done.
• You see it: a linked chat beside your own, and the results under Manage > Files (/workspaces).

Player One drives the popular coding agents, Claude Code and Codex among them, rather than trying to replace them. Bounded work stays in the conversation; for a large or multi-file change Player One will say plainly that a dedicated coding agent will do it better, and offer 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 set it up, needs its own account connected, and then runs on that account's own models rather than the rules you set for your agents. The linked chat is a transcript to watch rather than a second place to type, so you steer it from the conversation you asked in.

Share an agent with another installation

• 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 > Agent 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 > 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. 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 > 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.