Skip to main content

    Filter by idea status

    Filter by product

    1293 Ideas

    Slot Resolver strategy inference suggestions5. Not Enough Info to Make Decision

    Problems:We do not have much influence over how to get slots to infer (descriptions and the 3 inference options are nice, but are not sufficient in many use cases) Slot Resolver Strategies are very poor with inference when the options to choose are objects with multiple attributes. I can make it work by just outputting the name of the value (list of strings instead of list of objects), but I also have description values for each option object that I want to be considered to assist in choosing the correct option. This approach also means the api calls are made twice for resolver strategies: once in the resolver strategy to get the string list and then again to get the object in the conversational process which is needed for further actions. If a slot is inferred incorrectly, the user can ask for a change, but it doesn’t handle that change very reliably, if at all. Asking for all options of a slot does not always work and if it does, it usually is cut off after around 20.Current Workaround:Use a generate_structured_value_action to take in a description slot (and possibly others like the user) and do the selection This enables me to pass it multiple attributes to use for selection and build out a detailed prompt on how to choose the proper values. I have it also return a confidence score so if it isn’t confident in the choice, I can exit the plugin with information to provide more detail One negative here is that it then lacks the full context of the conversation. I can try and grab the context with a slot, but that does not always work reliably. Use plugin, conversational process, and slot descriptions to try and influence behavior as much as possible for choosing options and displaying options properly, but this does not always work reliably.While this is working well, I want slots themselves to be able to handle this sort of behavior instead of building around the problems.Proposed solutions:For a slot, give us a text box to define the system_prompt and user_input just like the generate_structured_value_action. This should work seamlessly with resolver strategies. The system prompt can define the logic on how to use inputs to choose the proper slot value and when it is necessary to ask the user for an exact value. For slots that are not set to always infer, always output a human readable version of the value selected on the action when it is selected. At any time afterwards, the user may request to change the value. If they do so, the conversational process goes back to the action where the slot is set as required and moves forward from there. Slots set as required in following steps should be reconsidered in this case. If a user asks to see all options of a slot that has a resolver strategy, all options are presented to the user and they are not cut off after ~20. The max I have currently is around 130 options for 1 slot. Most are under 20, but I do have multiple over this. Give the context as another system provided variable that can be leveraged in a conversational process like data and meta_info

    dhorvathCommunity Manager

    Version History6. Delivered

    What’s newAgent Studio now provides Version History and Revert for Agent Studio assets, a new version-control capability that records every publish and makes it simple to inspect or return to a previous known-good state.Release type: New capabilityProduct area: Agent StudioAvailability: All customers, all data centers. No configuration required.🧭 What’s includedVersion History tab on Plugins, Conversational Processes, Data Types, Actions (HTTP and Script), Event and Webhook Listeners, and MCP Servers. Commit messages: the Publish modal accepts an optional message describing the change. Version chips in the editor header and in the tab strip to show which version is open. Open any earlier version directly in the editor to inspect its contents. Publish from an opened earlier version to create a new version based on that content. One-click revert with a confirmation modal that lists related child artifacts the revert will affect.🌟 Why this mattersBefore this release, publishing an update overwrote the prior asset immediately and teams needed external backups to keep a change history or recover from mistakes. With Version History and Revert:Developers get an auditable history of publishes (author, timestamp, optional commit message). Teams can easily inspect previous versions without rebuilding from scratch. Reverting to a previous version is simple and safe, reducing risk and speeding recovery from bad publishes.✋ How revert behavesRevert is additive and non-destructive:Reverting an asset, for example, currently at V4 back to V3 will create a new version V5 containing V3’s contents. V4 remains in the history and is still viewable. Nothing is deleted so a revert itself can be reverted later. The revert confirmation modal lists the child artifacts that will be impacted so you can confirm the downstream scope before proceeding.⚠️ Known limitationsRevert unavailable for some sub-configurations: plugin utterances, certain Data Type sub-configs, plugin triggering configuration, and slot resolution strategies inside Conversational Processes are versioned and viewable, but cannot be reverted today. Agent Studio surfaces inline flags where these limitations apply. Support for revert on these items is planned as a fast follow. Drafts are not versioned: Version History applies only to published assets. Platform updates are recorded: When Moveworks applies schema migrations or other platform changes to an asset, those updates appear as versions attributed to a Moveworks administrator. Version numbers can advance without a developer publish. No side-by-side diff: To compare two versions, open each one. A diff view is planned for a future release. No staged testing of drafts: You cannot test an unpublished Conversational Process in a staging mode that prevents immediate replacement of the live asset in this release. Staged testing is planned for a future update. One-asset revert only: There is no batch revert and no cross-asset activity log in this release.📌 Notes for developers and adminsEvery publish is recorded with an author and timestamp. Consider adding a descriptive commit message when publishing to make history easier to scan. Because reverts create new versions rather than deleting history, you can always traverse and restore any prior state. Review the revert confirmation modal carefully — it shows child artifacts that will be affected so you can understand impact before proceeding.📚 Learn moreDetailed documentation and usage guidance is available in the Agent Studio docs. If you have immediate questions or feedback, please post them in the community forum and our team will respond.Thanks,The Agent Studio Tea