# Version control console for your Hume EVI voice agents > See every voice agent configuration, compare any two versions side by side, and publish prompt changes with a written changelog. - Workflow type: app - Services: Hume, Slack Bot - Categories: Engineering, Product - Published: 2026-08-24 ## What it does - Lists every voice agent configuration with the version it is on, the prompt it uses, its voice, and the tools attached to it - Shows the full history of each configuration, prompt, and tool, with a side by side comparison of any two versions - Lets you edit prompt wording and publish it as a new version, then record what changed and why so the next person can follow the trail - Adds a Draft the next version from real calls button that reads recent conversations, finds the mistakes that keep repeating, and writes a suggested prompt revision for a human to approve - Announces every published change to a Slack channel so the rest of the team knows the voice agent behaves differently now ## What you'll need - A Hume account with at least one voice agent configuration already set up - Recent voice conversations on that account, so the draft assistant has real calls to learn from - A Slack workspace and a channel where change announcements should land - Someone who owns voice agent behavior and can approve what goes live ## Prompt Build me a release console for the Hume EVI voice agents my team runs, so whoever is tuning them can see history and diffs instead of editing prompts blind. This is a management and history surface only. Hume's live voice chat runs over a WebSocket that is outside our documented surface, so the app must never offer a test call, a live chat, or anything that implies you can talk to the agent from inside it. The landing view lists every configuration from Hume List EVI Configs. Each row shows the configuration name, the version it is currently on, the prompt it points at along with that prompt's version, the voice, the language model, and the tools attached to it. Hume list endpoints are zero-indexed and paginated with page_size up to 100, so handlers should page until page_number plus one is greater than or equal to total_pages. Include a name filter and a refresh control, and show when each configuration was last changed. Opening a configuration shows its version history from List Config Versions, using each version's description as the changelog entry. Let the user select any two versions, fetch both with Get Config Version, and render a side by side diff that highlights exactly what changed: the prompt reference, voice, language model, attached tools, and behavior settings. When the two versions point at different prompt versions, diff the prompt text itself rather than just showing two version numbers. A prompts section lists every prompt from List EVI Prompts, and opening one shows its versions from List Prompt Versions with the same two-version comparison built on Get Prompt Version, this time as a text diff of the prompt body. A tools section gives each tool attached to a configuration the same treatment through List Tool Versions, so the user can see when a tool definition changed underneath a config they thought was stable. From the console the user can edit prompt text in an editor and publish it with Create Prompt Version, cut a new configuration version with Create Config Version, write or correct the changelog on any configuration version with Update Config Version Description, and rename things with Update Prompt Name and Update Config Name. Require a short description of what changed before any publish goes through, so the history is never a wall of blank entries. Be honest about rollback. Hume has no operation that sets an active version, so rolling back means reading an older version's payload with Get Config Version or Get Prompt Version and creating a new version from it with Create Config Version or Create Prompt Version. Present the control as "Restore version 4 as a new version 9", say plainly in the UI that this creates a new version rather than rewinding history, and pre-fill the changelog with something like "Restored from version 4". Never label a button Revert and never imply a previous version can be reactivated in place. Each configuration gets a "Draft the next version from real calls" button that starts a background agent inside the app. The agent pulls recent conversations for that configuration with Hume List Chats, filtered to that config id, then walks each conversation's transcript with List Chat Events, which returns user messages, assistant messages, tool calls, and emotion features, paging with page_size up to 100. It looks for failure patterns that repeat across calls rather than one-off oddities: the agent misreading the same kind of request, dead ends where the caller repeats themselves, tools firing at the wrong moment or not firing at all, questions it cannot answer, and moments where the tone lands badly. It then writes a proposed revision of the current prompt text plus a rationale that cites the specific calls and quotes the moments behind each suggested change. Staged drafts persist inside the app with a status of pending review, published, or discarded, along with the proposed prompt text, the rationale, the chat ids it drew from, who requested it, and when it ran. The reviewer sees the draft against the current prompt text in the same diff view used everywhere else, can edit it before accepting, and can discard it with a note. Publishing a draft calls Create Prompt Version, and when the configuration pins a specific prompt version it also cuts a new configuration version with Create Config Version pointing at the new prompt version, then writes the summary of what changed into Update Config Version Description. Publishing announces the change to a Slack channel with Slack Bot Send a Message: which configuration and prompt changed, the old and new version numbers, who published it, the one-line summary of what changed, and a short excerpt of the diff. Make the channel configurable in app settings. Announce on publish only, never when a draft is merely staged. Write the whole console for a product engineer or PM who owns voice agent behavior and does not want to read raw payloads. Render voice, model, and tool changes as readable labels, show timestamps in the viewer's local time, and make every screen answer the question this app exists for: what changed, when, why, and which real calls made us change it. ## How to customize - Choose which Slack channel gets the announcements and how much detail each one carries - Set how far back the draft assistant looks, for example the last 25 calls or the last seven days - Decide what shows on the landing list, such as hiding retired configurations or grouping them by team ## FAQ ### Can I roll a voice agent back to an older version? Yes, but not with a revert button, because Hume has no way to mark an older version as the active one. The console handles rollback by loading the older version's settings and publishing them as a brand new version, so your history stays honest and everyone can see exactly when the rollback happened and who did it. ### Can I make a test call to the voice agent from inside the app? No. Live voice conversations happen over Hume's real-time connection, which sits outside this app. The console covers managing configurations, prompts, and tools, and reviewing the calls that already happened. ### Does the draft assistant publish prompt changes on its own? No. It stages a proposal with its reasoning and the specific calls that motivated each change, and it waits. Nothing reaches your voice agent until a person reads the draft, edits it if needed, and publishes it. ### Will editing a prompt immediately change what callers hear? It depends on how the configuration references the prompt. If it is pinned to a specific prompt version, callers keep hearing the old wording until you cut a new configuration version pointing at the new one. The console always shows which version each configuration points at, so you can tell at a glance. ### Do I need to be technical to use this? No. Prompt editing is plain text, and version differences are shown as readable labels rather than raw data, so a product manager can review and publish a change without help. Use this prompt in General Input: https://www.generalinput.com/prompts/version-control-console-for-your-hume-evi-voice-agents