How to save, test and publish agent versions in Tigy

Prepare an identifiable change

Saving an agent preserves its draft; publishing makes a validated version available for execution. Before editing the Tigy AI draft, describe the problem and expected change. Check workspace, instructions, tools and sources, save, and test affected cases. After publication, verify a new conversation through the customer channel.

Changes to an external service's information can affect conversations even when the prompt stays the same. Record that dependency when it matters to the test.

Validate and publish

Review editor validation errors and correct the indicated fields. Select Publish, wait for confirmation and check the published version in history.

An incomplete draft may still be saved. Publication requires validation; a successful save does not guarantee successful publication.

Check the channel with a new conversation

Publishing does not attach a phone number to the agent. Configure that association separately in telephony settings. Then start a new conversation through the intended channel and verify behavior.

Record the version number and verification scenarios. They help compare results after a change.

Use history as evidence

Open an older version to inspect its configuration and compare changes where the interface offers this option. Selecting a version for preview does not restore or publish it.

Apply a correction to the current draft, save, test and publish. Check new conversations to verify the correction in operation.

Publish changes with a hypothesis and evidence

Document the observed problem, changed rule and expected improvement. Save, test affected cases and check neighboring conditions.

Fix validation before publishing, inspect history and start a new operational-channel conversation. Earlier sessions do not establish future-call behavior.

Assign post-release review and compare speech, tools and destination effects. Production channels can reveal dependencies absent from editor tests.

Prepare recovery before it is needed

Consult an earlier version as a reference and apply the correction to the current draft. Check permissions, save, test and publish the corrected configuration. Prepare alternative service routing when investigation interrupts operation.

Validate after correction. Changing the prompt does not undo external records or automatically change documents and numbers. Handle improper effects in their responsible systems.

Record causes and add regression scenarios so version history supports understanding as well as recovery.

Define what changes in the version

Every publication should have a concrete reason. Changing an introduction, adding a source and enabling a write operation require different verification. Before editing, record current behavior, desired outcome and the configuration needing change. This prevents publishing a bundle whose effect cannot later be explained.

In Tigy, saving and publishing are different actions. Drafts support preparation, while published versions identify configuration available for execution. Successful saving does not establish publication validation. Check state and confirmation rather than assume the latest saved wording serves new conversations.

Use history to identify reference number, date and configuration. Documentation states that viewing a historical version does not automatically publish it. To correct behavior, consult the earlier version, apply changes to the current draft and follow saving, testing and publication. Preview is not implicit restoration.

Consider a fictional pickup policy changing opening hours. The version needs the correct source while preserving other tasks. Another example adds order cancellation. Tool contract, authorization and effect confirmation require review too. Both may look small in the editor but have different operational consequences.

Separate external dependencies from versioned definitions. Documents, credentials and endpoints can change without equivalent prompt edits. Record those changes alongside relevant publication. Otherwise comparisons can blame the model for failures originating in integration.

Choose a manageable change size. Where possible, publish a correction whose expected effect can be verified with specific cases. Independent changes can then be reviewed separately, making failure investigation and future maintenance easier.

Combine configuration validation with service testing

Editor validation checks necessary publication conditions but does not replace service evaluation. Configuration can pass while answering from the wrong source or claiming unsupported results. Use scenarios with written expectations: valid task, missing input, caller correction, unavailable source and out-of-scope request.

For content changes, test direct questions and questions using old assumptions. The latter reveals whether current sources correct the premise or the agent accepts it as fact. For tool changes, inspect parameters and results alongside speech. For writes, verify persisted state in test systems.

Use text to investigate decisions without audio and voice to examine understanding, pronunciation and turns. Do not claim telephone validation if all trials used the editor. Publication may be correct while a phone number still points to another agent. Verify the intended channel separately.

After fixing failure, repeat a previously successful case. Broad routing instructions can eliminate wrong answers while transferring almost every request. Regression checks show whether useful scope survives. Retain cases representing distinct decisions without duplicating questions solely for wording variation.

If validation rejects publication, inspect indicated fields. Repeating the action without configuration changes will not resolve structural requirements. Documentation states that rejected publication does not replace the published definition with an invalid one. Check history and correct the draft deliberately.

Record what was not tested as well. A review limited to information retrieval cannot establish cancellation behavior. Clear verification boundaries allow the release decision to match the actual evidence.

Verify publication in a new conversation

After publishing, wait for confirmation and inspect the version in history. Then start a new conversation on the intended channel using a case dependent on the change. This verifies available behavior rather than draft text alone. Choose a question distinguishing the new rule from the previous one.

For telephone service, check number-to-agent association. Tigy documentation emphasizes that publication does not create this association automatically. Testing the wrong number can suggest failed publication when channel configuration is responsible. Review destination and context before editing instructions again.

Do not use an older session as the sole proof of change. Publication guidance calls for a new conversation. Record the relevant version and trial details so another person can reproduce verification. “It seemed to work” provides little evidence for future discrepancies.

Check the task you changed and an essential task that already worked. Publication should fix the problem without harming approved behavior. For integrations, confirm which system and environment were used: a test with fictional information does not prove the system used for real customers will work.

If the new conversation lacks the change, investigate publication confirmation, selected agent, channel and dependencies. Locating the stage prevents repeated corrective publications without clear cause. History explains definitions, but not every external content or service change.

Make the observation concrete: which question was asked, which response was expected, which action occurred and which result supported it. Those details turn a release check into evidence the team can actually use.

Prepare a correction that can be verified

Problematic changes need reproducible cases. Record input and deviation from expectations. Consult prior versions to identify useful behavior, while reviewing external changes too. Reapplying old instructions cannot fix APIs returning new states or policies that genuinely changed.

Prepare corrections in the current draft, save, test and publish under the documented process. Do not announce restoration merely by opening historical previews. Repeat verification in a new conversation. The objective is available correct configuration supported by evidence, not simply finding a screen showing old text.

Tell operations which behavior changed and how to identify pending work. If the previous version created incorrect records, correcting the agent does not automatically repair those records. Owners must assess external effects and handle affected requests under company procedure.

Retain the failing case as regression coverage. It should remain understandable after the immediate incident is forgotten, including the condition that made the earlier result incorrect.

Assign ownership to the version cycle

Define who approves content, maintains tools and decides publication. One person may hold several roles in a small pilot, but responsibilities should remain clear. Otherwise external changes may bypass tests and prepared corrections may remain unpublished.

Keep a short note containing purpose, version, verified cases and limitations. This helps staff interpret new calls and plan further changes. Technical history and operational explanation complement each other: one shows what became available, the other explains why and with what evidence.

Use review effort proportional to the change. Wording adjustments need appropriate conversational checks; new write authority needs verification of permission and effects. This keeps the process practical while preserving evidence where customer outcomes can materially change.

Record changes history cannot explain alone

When publication coincides with external updates, keep a note connecting them. Endpoints can change format, credentials can lose access and sources can receive new content. Instruction comparisons help but may not capture these facts. Investigation should consider the complete configuration encountered by the conversation.

Include the selected verification and external-system owner in the note. This supports reproducing conditions without relying on individual memory.

For example, if a tool changes from returning a confirmed reservation to returning a pending request, the agent must explain the new state accurately. Reusing previous wording would be incorrect even if the published prompt itself did not change. The release check should identify this contract change and verify the new supported claim.