Introduction
This is the third article in my mini-series exploring Moveworks' capabilities by teaching it to manage stories in ServiceNow.
Here is the full list of articles in the series:
- Part 1: Create Moveworks Plugins for Story Management
- Part 2: Let Otto write the Story
- Part 3: Combine Moveworks and Build Agent
The first two articles focused on story management. Making stories available in Moveworks or creating new ones. While ServiceNow Otto inside Employee Slate powered by Moveworks is the ideal conversational assistant for managing stories, ServiceNow Otto in the IDE, aka Build Agent, is the perfect tool for implementing them. What would be better than focusing this time on combining these two systems to directly implement stories.
The Idea
The goal is to seamlessly connect these two solutions. Once a story is in the state ready and assigned to a user, the user receives a notification right inside Employee Slate. From there the user can choose to implement the story directly using Build Agent. If the user accepts, he is transferred to the IDE with a Build Agent prompt prefilled with the details from the story. This scenario is a great way to explore Ambient Agents in Moveworks.
The Architecture
This time the conversation is not initiated by the user, instead the system initiates the conversation. For these kinds of scenarios, we can leverage so-called Ambient Agents. “Ambient agents monitor enterprise systems continuously, detecting events or changes to initiate workflows automatically.”
High-level overview
- Business Rule: Send an event to a Moveworks webhook when a story is in state ready and assigned to a user
- Moveworks Webhook: Receives the event
- Compound Action: Resolves the user and sends a notification
- Action Step: Provides a button that redirects to Build Agent with a prefilled prompt
Ambient Agent
Listener
Before building the plugin, we need to create a Listener. A Listener is basically the configuration of a webhook. It provides a URL for the ServiceNow instance to send events to, handles authentication, and parses the payload of the request for the triggered plugins.
Aside from setting a name and description, we simply need to choose a verification option to secure the webhook. For this example, I enabled credential verification and generated an API Key.
The Plugin
The plugin consists of the trigger and a plugin body.
This time we select SYSTEM as the trigger, which allows us to choose Webhook as the trigger type instead of providing example utterances like we did with the conversational plugin. We then select our newly created listener (story_assigned) to trigger this plugin.
Because the listener automatically parses the incoming event, we can access the data via the objects parsed_body, headers, and query_params.
The data and email attributes are mapped to the inputs of the action executed by the webhook.
Compound Action
The main work happens inside a Compound Action.
A compound action groups multiple actions to run in sequence or parallel, effectively building a workflow.
In this example the workflow contains only two steps.
Step 1: Resolve the user
The incoming event includes an email address, which must be matched to a Moveworks user profile to route the notification correctly. Moveworks provides a built-in action for this: MW.GET_USER_BY_EMAIL takes the email as input and outputs the target user.
Step 2: Notify the user
We use the standard Notify action to send a message to the user.
In this example, the message is built by static pattern. It shows the number of the story and the short description together with a static text. The message was already generated in ServiceNow and sent to the webhook.
Story <story number> - <short description> was assigned to you and is ready for implementation. Do you want to hand it over to Build Agent?
Note: If you need a more dynamic message or want to bring in some variation you could also generate the text inside Moveworks. The built-in action mv.generate_text_action lets you query a LLM to generate the text you need, like we did in the last article.
The notify step can contain several actions. These will display as buttons below the message. We need one action to send the user directly to Build Agent.
This action displays a button with the label “Yes” underneath the message and send the user to the link we also generated in ServiceNow.
Business Rule
The process begins in ServiceNow. When a story in state ready is assigned to a user, a Business Rule send a REST message to the Moveworks webhook URL. The body contains the email address, the message and the redirect link:
// Build notification payload
var body = {
email: mail,
data: {
message: msg,
link: link
}
};
The link points to the IDE on the dev instance because we don’t want development directly in prod. We use the preprompt URL parameter to directly set the content of the story as prompt for Build Agent.
var storyText = current.getValue("short_description") + "\n\n" +
current.getValue("description") + "\n\n" +
current.getValue("acceptance_criteria").replace(/(<([^>]+)>)/gi, "");
var urlSafeText = encodeURIComponent(storyText);
// Construct IDE link with pre-populated story text
var devInstance = gs.getProperty("devInstanceUrl");
var link = devInstance + "sn_glider_app/ide.do?preprompt=" + urlSafeText;
The Result
This is the result once a story is assigned to a user.
If the user decides to hand it over to Build Agent, the system redirects the user with the prompt prepopulated.
Conclusion
The main goal of this article was to explore Ambient Agents and provide inspiration for use-cases. I know that passing the story via URL parameters is not the best way and that it will fail if the story is too long.
If you know a better way to launch Build Agent with an injected prompt, I’d love to hear it. Otherwise, this would make an excellent future enhancement for Build Agent.
