Schedule a change for a launch

The user wants to make changes now that must not affect live traffic until a later go-live moment. Model this as a branch: all work happens on a non-live branch, main keeps serving the current config, and the change goes live only when the user merges (or ramps traffic to) the branch at launch time. There is no timer. Scheduling here means staging on a branch and holding the merge until the user is ready. Be explicit with the user that nothing publishes automatically; they press merge or ramp at go-live.

Host https://api.elevenlabs.io, header xi-api-key: $API_KEY. The engineer supplies $API_KEY and $AGENT_ID. For the exact branch mechanics, error recovery, and traffic-split rules, follow the branches, versions, and merging skill for every branch write.

1. Confirm the shape of the change

Ask or infer two things before touching anything:

• What changes - a prompt/config edit, a new tool, a knowledge-base document add or rescrape, or a fact the agent should know. A KB add or rescrape counts and is a common launch case.
• When it goes live - the launch moment. Confirm the user will trigger the merge or ramp themselves; you are only staging.

If the change would be fine to ship immediately, say so and skip the branch. Scheduling only earns its complexity when the change must stay dark until a specific moment.

2. Read current state first

Before any write, read the branch list (GET /v1/convai/agents/$AGENT_ID/branches) for exact ids, current_live_percentage, protection_status, parent_branch_id, and draft_exists, and get the currently active branch config (GET /v1/convai/agents/$AGENT_ID?branch_id=$BRANCH_ID). You need main's exact id to branch off it and to know whether main is admin_perms_required, which gates the eventual merge.