> For the complete documentation index, see [llms.txt](https://docs.meetalto.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.meetalto.ai/mcp/recipes/agent.md).

# Prepare and test an agent

Prepare a playbook, test customer conversations and make a deliberate decision about going live.

Use MCP to turn a clear goal into a reviewed playbook and test it with realistic customer questions. Generating a proposal, saving it, testing it and enabling an agent are separate operations.

You need a connected account supported by the agent tools, the workspace's AI entitlement and appropriate permissions: `agents:read` to inspect, `agents:write` to compose or save, `agents:simulate` to test, and `agents:publish` to enable or change live reply access. Check the actual tool's additional requirements before acting.

## 1. Read the account and current agent

> Confirm my workspace and help me identify the account I name. Read its agent, audience, readiness and latest simulation. Explain what is already active and what needs attention. Do not change anything.

Use exact account names and clarify duplicates. The assistant should read `get_agent` and `get_agent_audience`; `get_latest_agent_simulation` shows whether the latest test still matches the saved candidate. If the account has several agents, these tools use the one marked **Main** in the app unless the assistant names another agent.

If an agent is already active, keep the initial work as a proposal. Saving an active agent also requires `agents:publish`; do not assume the edit is an isolated draft. Decide explicitly whether to pause it or proceed with a live edit before saving.

## 2. Prepare a focused proposal

State the goal, audience, verified knowledge to use, facts to collect and the point at which a human should take over. For example:

> Propose a playbook for answering product questions using our existing knowledge. Ask one relevant follow-up at a time. When information is missing, acknowledge the gap and use only supported handoff behavior. Preserve unrelated settings. Show the proposed changes and unresolved requirements before saving.

`compose_agent` proposes a playbook from scratch and `revise_agent` proposes changes to an agent's saved playbook. Neither saves anything. Review changes, unanswered clarifying questions, compile findings and anything the tool could not apply. Do not ask it to invent an integration or action the account cannot use.

The documented release does not include creating additional named agents. If your connection has no creation tool, use **Campaigns → Create automation → AI Agent** in the app. Do not save a new-agent proposal over an existing Main agent. For an existing agent, keep its exact identity and use the revision workflow below.

Generation and tests can use allowances. Set a small test scope rather than asking the assistant to keep generating until it likes the result. See [costs and limits](/mcp/actions.md#understand-costs-and-limits).

## 3. Save and inspect the result

Approve the exact playbook and intended status. The assistant must use the current revision and status when calling `save_agent`. If someone else has edited the agent, reread it and reconcile the change.

**Check:** inspect both `sections` and `sectionErrors`. A response can report that one section saved while another failed. Read the agent again and repair the failed section using current state; do not blindly resubmit the entire old request.

## 4. Test a small set of conversations

> Test the approved candidate with a normal question, missing information, an unclear request and a request for a person. Explain the reply and any simulated action for each. Do not send live messages or enable the agent.

Use `preview_agent` for an interactive example. For a continuing conversation, preserve its returned `simState` and provide the conversation history. Use `start_agent_simulation` for a simulation suite, then read the returned run with `get_agent_simulation` until it reaches a terminal state. A changed candidate needs a new simulation `start_key`.

Inspect the actual findings, skipped or failed work and candidate match. A finished run is not automatically a passing run. Test results are advisory and do not authorize a live action.

## 5. Review audience and decide whether to enable

Ask for a final summary of the saved playbook, current readiness, test findings and who will be eligible for replies. Audience changes require publishing permission as well as writing permission. Use the [audience guide](/using-meet-alto/agents/audience.md) to understand the choices.

If you choose to go live, authorize the exact account and audience. The assistant can use `save_agent_audience` and `set_agent_enabled` with current revisions; server readiness validation still applies. Afterward, read the agent and audience again to confirm their saved state. Enabling an agent allows its normal automation to reply when eligible events occur.

If it cannot be enabled, fix the reported readiness issue and retest relevant behavior. Do not bypass validation or treat an old passing run as proof that a new playbook is ready.

Next: review real results in [agent analytics](/using-meet-alto/analytics.md) and continue a [weekly review](/using-meet-alto/playbooks/weekly-review.md).