How MetaPrompter generates proposed changes

How MetaPrompter takes a behavioral description & turns it into targeted configuration proposals.

How MetaPrompter Works

Overview

MetaPrompter takes a natural language request and translates it into configuration changes across a Digital Worker's components. The process is designed to be transparent at every step, surfacing a structured summary of what changed so users can review, refine, and confirm before saving.

The Processing Sequence

When a request is submitted, MetaPrompter follows a consistent sequence.

The user enters a request in natural language. MetaPrompter interprets the request and identifies which parts of the Digital Worker's configuration need to change. The graph view updates to reflect the proposed changes, with affected nodes marked. The system surfaces a structured summary of the changes in the chat panel. The user can then review the affected nodes, refine settings manually, test the updated configuration, and save the result as a draft. If the updated draft is ready for release, it can be submitted for promotion to production through the standard release flow.

Test and Production Environments

MetaPrompter works differently depending on the environment.

Test environment. The test environment is editable. All MetaPrompter changes are applied in test first. From the test environment, users can import and edit Digital Workers, test behavior, review configuration changes, and save draft versions.

Production environment. The production environment is read-only. Users can view the live production configuration, compare it against the current draft or test version, and review what is currently deployed. Direct edits through MetaPrompter are not available in production. To update a production worker, users make changes in test and promote the updated version through the release flow.

Versioning

MetaPrompter works in conjunction with the platform's versioning system. When a Digital Worker is updated in the test environment, the system creates or updates a draft version that captures the full configuration state, including instructions, tools, connectors, graph structure, approvals, runtime settings, and related changes.

Common version states include draft, pending review, published, live, archived, and rolled back. Before promoting a version to production, the change summary, affected nodes, updated settings, warnings, approval requirements, and test results should all be reviewed.

Last updated

Was this helpful?