Workspace

Playground

Playground is the main validation surface in Calypso RAG. Use it to test the saved agent policy with a real project API key and inspect grounding quality before you deploy anything.

What Playground is for

Playground is the effective home page of the RAG experience. It is where you test the current agent against real workspace knowledge, not where you define the entire product from scratch.

Use Playground to answer one question:

Is the current grounded agent behavior production-ready for the next integration step?

What you can do

  • start a fresh chat
  • select the active agent profile
  • select the active project API key
  • send free-form prompts
  • inspect streaming answers
  • inspect grounded source output
  • jump directly to source management or run-settings follow-up pages

What should be ready first

Playground is much more useful when these are already in place:

  • at least one indexed source in Knowledge
  • a reviewed default or named agent policy
  • a real active project API key

Without those pieces, the UI still works, but the result is not a strong signal about grounded retrieval quality.

Settings rail behavior

The settings rail gives you fast access to three important controls for the currently selected agent:

  • whether grounded source titles are included
  • whether small talk is allowed
  • the current role briefing

For supported agents, these controls can persist changes back to the saved agent policy rather than acting as temporary page-local switches.

Grounding states

The most important interpretation work in Playground is not whether the assistant replied. It is how grounding surfaced.

Available

Grounded sources were returned and can be inspected directly.

Hidden

Grounding likely happened, but source titles are intentionally hidden by policy.

Missing

The run appears to expect grounding output, but source information did not surface cleanly.

None

No grounded sources were returned.

How to use Playground well

Use this rhythm:

  1. test one prompt that should succeed cleanly
  2. test one prompt that should fail safely
  3. test one prompt that exposes missing source coverage
  4. move to an integration surface only after the behavior is understandable

Where to go next