Playground

The playground is a chat interface inside the Workforce dashboard. You pick a Tool Pack, pick a test user, and start typing, and the agent responds with tool calls streaming inline. Every call hits the same MCP endpoint your employees’ AI clients use, so what you see here is what they will see.

Use it before a rollout. Assigning a Tool Pack to a Group is a guess until something has called it: the model has to pick the right tool from its description, the Connectors have to be authenticated, and your guardrail rules have to fire where you expect. The playground answers all three in a few minutes, without waiting for a support ticket.

It runs as a test user, never as a real employee. The session request is rejected outright for anyone who is not a test employee, which is what keeps a rehearsal from touching a real person’s connected accounts. Add test employees on Provisioning under Employees, on the Test tab.

The sidebar entry is not permission gated, but starting a conversation reads your employees, so a role that cannot view employees gets an error instead of a chat. Check your role with an admin if that happens.

Opening the playground

Playground in the sidebar. Two things to set before you can chat:

1. Pick a Tool Pack. The selector shows each pack’s Connectors, so you can tell at a glance what the pack reaches.
2. Pick a test user. The list holds test employees only.

Type a message and the agent runs. If the test user has not authenticated a Connector the agent tries to call, the chat shows that Connector with a Connect button: click it, run through the OAuth flow, and the agent retries on its own.

Both choices are mirrored into the URL, so a setup can be shared as a link. Changing either one starts a new conversation, since a session is bound to the pack and user it was created with.

What you see when the agent runs

Each tool call shows inline in the chat as a card you can expand:

• The Connector and the tool it called, as Slack: post_message
• A status badge: Queued, Executing, Success, Failed, or Blocked by policy
• Parameters, the arguments the model produced, as JSON
• Response, the result, as JSON

A failed call swaps the response for an Error with the message the tool returned. A call a Security Gateway rule refused reads Blocked by policy and shows the reason that came back with the block, which is how you confirm your rules are firing before an employee finds out they are not.

Latency is not reported here. Neither is a redaction, as such: the response shows what came back after a rule ran, and Violations and alerts names the rule that fired.

Common workflows

Confirming a Group’s access is right. Pick the Tool Pack you are about to assign and ask for something on the edge of it. A tool that is missing shows up as the model apologizing rather than calling anything, which is the same experience the employee would have had.

Tuning tool descriptions. Ask the agent to do something a specific tool should handle. If it picks the right tool, the description works. If it picks something else, or asks a clarifying question, the description needs work: open the Tool Description Override editor in another tab, edit, save, and re-run the prompt. The playground resolves the pack’s tools again on every turn, so the next message sees the edit.

Testing input overrides. Force a field to a fixed value, then ask the agent to do something that should call the tool with that field. Check that the call arguments contain the forced value. See Tool Input Overrides.

Testing security rules. Construct a prompt that should trigger a rule, with an email address, a card number, or an internal customer ID in it. Run it, watch for a Blocked by policy card or a field missing from the response, then cross-check on the Alerts dashboard.

Reproducing what an employee reported. Paste their prompt and run it against the Tool Pack their Group holds. You cannot run as them, so this reproduces the pack and the rules rather than their own Connector authentications, which is enough for most reports: a missing tool or a firing rule shows up either way.

Handing the setup to an AI client

Open in takes the current Tool Pack and test user and hands them to a client, so a flow that needs more turns than a chat box is good for can carry on where it started.

Cursor and VS Code install in one click. Claude Code, Windsurf, and Custom open a Connect to MCP server dialog with a copyable MCP config instead, and the one-click clients fall back to that dialog if the handoff cannot be completed. Either way the config points at the same MCP URL the playground was using, which the URL bar also lets you copy on its own.

Limitations

• No conversation export. The handoff carries the configuration, the Tool Pack and the test user, not the chat transcript.
• A default agent loop. The playground runs its own loop, with an optional extra system prompt set in Settings. That prompt is baked into the session on the first message and locks afterward, so set it before you start. It tells you whether the tools resolve and the rules fire, not how a particular AI client will phrase a request.
• Real calls, real usage. The test user’s calls reach the third-party system and count toward your tool call volume.

Next

Assign the pack you tested to the Groups that need it in Groups and access.