Creating a Digital Worker from the Digital Workers list: describe what the Digital Worker should do, then name it in the Add New Digital Worker dialog. Creating a Skill follows the same pattern.
Either way, the new Digital Worker or Skill opens directly into its Compose tab, where MetaPrompter is the primary way to build it out. The empty state outlines the process: describe what you want to change, MetaPrompter turns that into a Plan of Execution, and you review and approve the plan.
The MetaPrompter starting screen: guidance on how to get the best results, plus example prompts to start from.
### **Creating with a HAR File** Attach a HAR file, a recording of an existing system interaction, using the paperclip icon when the work involves calling a system through its web interface. The captured calls are indexed directly, so the API does not need to be described or coded by hand. When a HAR file is sent alongside a description, the request is worked through visibly: current configuration is read, the HAR file's workflow and API calls are indexed, and the tools the request requires are created.
Building from a HAR file: current instructions are read, the attached HAR file's API calls are indexed, and the tools needed for the workflow are created.
When MetaPrompter cannot reliably determine a detail on its own, it pauses and asks, usually with a recommended option highlighted, before continuing:
A clarifying question during a HAR-based build: which business input a generated tool should require, with a recommended option highlighted.
Next, MetaPrompter presents a Plan of Execution, a numbered list of the proposed changes, each labeled by type, with a Test button on any tool step and a “more” link for full detail. The changes are applied when Approve & Execute is selected.
A Plan of Execution built from a HAR file: three tools, a system tool, two instruction updates, and two new states, all reviewable and testable before approval.
After approval, each change is confirmed as it is executed, and a summary of what the Digital Worker can now do is provided.
Confirmation after approval: the plan is marked Approved, changes are executed, and MetaPrompter summarizes the tools, outputs, and instructions now in place.
### Creating a Digital Worker Without a HAR File: By Prompt Alone A HAR file is never required. Describing what a Digital Worker should do in a single sentence is enough for MetaPrompter to find the right tools and set up the full workflow, as shown here by creating OrderAnalyzer, a Digital Worker that identifies risky purchase orders (POs), with no file attached at all.
Starting from a description only: naming the new Digital Worker, OrderAnalyzer, from the Digital Workers list. No HAR file is involved at any point in this build.
After the goal is entered (“Your goal is to get Released POs and identify risky POs”), MetaPrompter works through the request on its own, searching for and creating the tool to fetch released purchase orders and indexing the fields it needs. When a business detail cannot be reliably determined, it pauses and asks, with a recommended option highlighted:
A clarifying question during a prompt-only build: which amount the new tool should treat as a PO's Total Amount, with “Gross including charges (Recommended)” highlighted as the suggested answer.
After every open question is answered, the same kind of Plan of Execution seen in a HAR-based build is presented: an Add Tool step, an Add System Tool step for the risk-analysis logic, and an Update Instructions step tying the workflow together, all ready to test, review, and approve.
The completed Plan of Execution for OrderAnalyzer, built entirely from a plain-language description: a new tool, a system tool, and updated instructions, each testable before Approve & Execute.
### Creating a Skill Without a HAR File Skills are created the same way, from the same “describe what it should do” starting point, for example “Find out the open purchase orders, flag the Risky POs and analyze and recommend the next steps for them,” with no file attached.
Creating a Skill: the same “describe what it should do” starting point as a Digital Worker, with example prompts and a list of existing Skills already in the workspace.
Building from a prompt alone, with no HAR file attached: the current configuration is read and the tool the request requires is searched for.
The same clarifying-question and Plan of Execution pattern applies, regardless of whether a HAR file was attached:
A clarifying question while building from a prompt alone, here about which date field a filter should use, with a recommended option highlighted.
A Plan of Execution built without a HAR file: two system tools and an instructions update, alongside the retrieval tool, ready for Approve & Execute or Decline.
Then MetaPrompter confirms what was added and how the result behaves, and it can proactively suggest sensible next refinements, such as a human-in-the-loop approval step or a structured output.
Confirmation after approval: what was added, how the Skill works now, and a prompt for further refinements, such as approvals, notifications, or a structured output.
The finished Skill is a standalone object. It is visible in its Graph view alongside the systems and tools it connects to, and it is available to reuse in any Digital Worker that needs it.
The finished Skill in Graph view, shown alongside the IFS connections and the tool MetaPrompter built for it.
## State-Based Outputs A state-based output is a defined, structured shape of data that a Digital Worker or Skill produces at a given point in its process, such as a workflow error or a completed analysis ready for review. States can be added directly from the conversation: describe the situation that needs its own output, and an Add State step is proposed alongside whatever instruction changes are needed to use it.
Adding a new state from a plain-language request (“show the error in a formatted user-friendly message”): an Add State step plus the instruction updates needed to route to it, all in a single Plan of Execution.
Every state that is added is also visible and editable afterward in the Digital Worker's own Intent Based Output Format settings, including its name, its description, and whether it needs user approval before the workflow continues past it:
The Intent Based Output Format list for OrderAnalyzer: the Error and Risky POs Review states MetaPrompter built, each with its description and Needs User Approval setting.
## Human-in-the-Loop Approval Beyond the Needs User Approval setting on a single output, MetaPrompter can configure a full human-in-the-loop notification for a Digital Worker directly from the conversation. Describe when a reviewer should be looped in, for example “when you identify the Risky POs, show the analysis in a structured actionable format for the user, via Teams.” MetaPrompter then proposes a dedicated human-in-the-loop configuration step, with its own settings card for how reviewers should be notified:
Configuring a human-in-the-loop notification from the conversation: choosing Teams as the notification channel, then the specific Teams channel the reviewer should be notified on.
The human-in-the-loop configuration step appears in the Plan of Execution as its own step type, shown alongside any instruction changes needed to use it, so it is clear at a glance that a human-in-the-loop checkpoint is being added:
A Plan of Execution with a dedicated human-in-the-loop configuration step, alongside an Update Instructions step connecting the new Teams notification to the workflow.
When a run reaches that point in the process, it pauses and surfaces a structured, actionable summary for the reviewer and waits for a decision before the workflow concludes:
The resulting human-in-the-loop checkpoint in practice: OrderAnalyzer pauses with a structured risky purchase order analysis marked Action Required, including a summary and table ready for a reviewer's decision on each flagged purchase order.
## Updating an Existing Digital Worker: Instructions, Tools, and More The same conversation-to-plan-to-approval flow used to build a Digital Worker from scratch is how you evolve one that is already live. For example, a request such as “update the Digital Worker to support an additional supplier” produces a plan using the same step types seen throughout this guide, so the kind of change each step makes is clear: * **Add Tool:** gives the Digital Worker a new capability it can call, built from a description or a HAR file. * **Add System Tool:** adds an internal tool, such as an instruction handler, that supports the Digital Worker's own logic rather than an external system. * **Update Instructions:** changes what the Digital Worker does, step by step. Expanding “more” on this step shows the instruction text before it is approved, so the change can be verified before it is applied. * **Add State:** introduces a new state-based output, as covered in the previous section.
Expanding a plan step's “more” detail on an Update Instructions change: the drafted workflow instructions, including how a tool's output is mapped and used.
A HAR file can be attached to this same conversation to add a tool to a Digital Worker that is already live, as it can when creating one from scratch. Here, a HAR recording of adding a note to a purchase order, AddNotesToOrder.har, is attached to OrderAnalyzer alongside a plain-language instruction for when the new tool should be used:
Adding a tool to an existing, already-live Digital Worker by attaching a HAR file: AddNotesToOrder.har, together with an instruction for when the resulting tool should write reviewer decisions back to a purchase order.
As with any other change, the result is a reviewable Plan of Execution: the new tool alongside the instruction updates needed to call it at the right point in the workflow:
The Plan of Execution for a HAR-based tool added to a live Digital Worker: an Add Tool step built from the attached HAR file, plus two Update Instructions steps connecting it to the existing workflow.
Because every change, on a new Digital Worker or one already in production, goes through the same Plan of Execution and Approve & Execute step, each change can be reviewed first. Each proposed change can be tested, expanded for detail, and approved or declined individually.