> ## Documentation Index
> Fetch the complete documentation index at: https://polyai-mintlify-41fdf97b.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# What Wren can build
> Every part of your PolyAI agent that Wren can create and change, from flows and topics to secrets, real-time config, and custom metrics, with the guardrails.
Wren operates on the same building blocks you'd edit by hand. For any of these it can read your current configuration, propose a change, and write it to a branch once you approve.
## Building blocks
| Building block | What Wren can do | Where it lands in Studio |
| ---------------------- | ---------------------------------------------------------------------------------------------------------------- | ------------------------- |
| **Flows** | Create flows; restructure steps, transitions, and conditions; rewrite step prompts | Flows |
| **Entities** | Define entities and their values; update definitions used by flows | Flows |
| **Topics** | Create knowledge-base topics from a description or a URL; update wording or scope | Knowledge > FAQs |
| **Functions** | Wire flows to existing functions; describe and create new function specs | Tools |
| **Handoffs** | Add transfer-to-human steps with the right conditions and metadata | Voice > Handoffs |
| **Behavior** | Set or update purpose, role, personality, languages, and translations | Behavior |
| **Guardrails** | Adjust safety filters and phrase filtering | Behavior > Guardrails |
| **Voice settings** | Greeting, style prompt, disclaimer, ringing tone | Voice > Settings |
| **Speech recognition** | Keyphrase boosting, transcript corrections, pronunciations, phrase filters | Voice > Advanced settings |
| **Chat settings** | Messaging channel configuration on multichannel projects | Messaging |
| **API integrations** | Configure integrations and connect them to flows | Integrations > APIs |
| **Variants** | Variant attributes and variant definitions | Knowledge > Variants |
| **SMS templates** | Message templates triggered from voice flows | Voice > Message templates |
| **Simulation tests** | Author, run, and maintain [test cases](/testing/simulation-tests) and keep coverage in step as the agent changes | Testing |
| **Custom metrics** | Register new metrics and edit existing ones | Analytics > Metrics |
| **Real-time config** | Read and edit the config schema and its per-environment values | Real-time config |
| **Secrets** | Prompt you to add, update, or remove account secrets | Account > Secrets |
| **Dashboards** | Build, preview, and publish self-serve dashboards | Analytics > Dashboards |
## How edits reach your project
Wren doesn't edit your project as it works. It drafts everything on its own copy first, then saves it to your branch all at once:
1. **It reads your project** at the start of the session, and reads it again whenever you switch branches.
2. **It drafts the change**, across as many parts of the project as the change touches.
3. **It saves the change** to your branch once you approve, then shows you a summary of every resource that changed, each with a link to open it.
Saving everything together is what keeps a half-finished change from ever reaching your branch. If saving fails, Wren retries once and then tells you plainly rather than reporting success.
None of this touches `Main`. See [Branches](/wren/introduction#branches).
## Real-time configuration
Wren can read your [real-time config](/real-time-config/introduction) schema and values, and edit both.
Because real-time config takes effect immediately, **writes to the live environment always ask first**. Wren shows you exactly what it intends to change and waits for your confirmation. Sandbox and pre-release edits follow the normal plan-and-approve flow.
## Secrets
When a change needs a credential, such as an API key for a new integration, Wren opens a secure modal for you to enter it.
**Secret values are never sent to the model.** Wren can see that a secret exists and reference it by name, but it never receives the value itself. The same applies when it uses a secret to authenticate a request: the value is injected server-side and stripped out of anything Wren reads back.
Wren can prompt you to add, edit, or delete secrets. It cannot read one, and it will never echo a secret back into the chat.
Secrets are unavailable in **Auto** mode by design: there's nobody there to type the value. Wren records it as a blocker in its report instead.
## Connecting to your APIs
When you ask Wren to wire up an integration, it doesn't guess at your API's response shape. It makes a **single read-only request** against the endpoint and reads the real response, so the function it writes matches what your API actually returns.
The guardrails on that request:
* **Read-only.** It only ever performs a GET. Wren cannot create, update, or delete anything through your API.
* **Authenticated by reference.** If the endpoint needs a key, you point Wren at an existing secret by name. The value is injected server-side and scrubbed from the response before Wren sees it.
* **Public hosts only.** Requests to private or internal network addresses are refused.
## Custom metrics
Wren can list, create, and edit [custom metrics](/analytics/kpis/introduction) from chat. This is useful when you're building a flow and want the metric that measures it registered at the same time.
**Registering a metric is permanent.** A metric's name and type can't be changed once registered, and registration applies across all your environments at once. Only the description and a string metric's expected values can be edited later.
Wren asks you to confirm before registering, because environments are shared across teams.
A metric your agent writes reports nothing until it's registered here, so if Wren adds a `conv.write_metric` call it will usually offer to register the matching metric too.
## Related pages
How to phrase a build request so you get what you meant.
Author and run test cases for your agent.
Promote branches from `Main` to Live.