> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tryopencomputer.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Agents, drafts, and publishing

> Work with workflow drafts, published versions, and API identifiers.

An agent is represented by a workflow definition: its nodes, connections, instructions, and configuration. The workflow you are editing can be a draft while callers continue to use a published version. Treat publishing as a release step and review the exact definition before you do it.

## Identifiers

The dashboard and API use several identifiers for different jobs. Keep the identifier returned for the resource you are working with.

| Identifier | Use |
| - | - |
| Numeric `workflow_id` | Manage an agent, its definitions, settings, and runs. |
| `workflow_uuid` | Start a call against a workflow through its public call endpoint. |
| Trigger `uuid` | Start a call through one API-trigger entry point. |
| Numeric `run_id` | Inspect one execution after it starts. |

A dashboard URL containing a numeric workflow ID does not provide the UUID required by a public call endpoint. The call response includes a run ID; retain it to reconcile the later result. See [Trigger a phone call](https://docs.tryopencomputer.com/guides/calls.md).

## Draft and published behavior

Saving edits a draft. Published trigger endpoints use the published definition. Draft trigger endpoints select the latest draft and fall back to the published definition when there is no draft. The `/test/` phone endpoints can still place real calls, so use a controlled destination.

Before publishing, resolve workflow validation errors and test important branches, including tool failures and paths that should end or escalate. A successful save or publish does not establish that an external model, tool, or phone route is ready.

**1. Review the current draft**

Open the agent and confirm the draft contains the changes you intend to release. Check dependencies and test with synthetic data.

**2. Publish the reviewed definition**

Use the publish action after validation. Add a version name and change description when prompted if your team needs a release record.

**3. Check version history**

Open version history to inspect a saved version or compare it with the previous version. Use the history view to confirm what changed before coordinating an integration update.

**4. Keep a rollback candidate**

Identify the previously published version that should remain available if the new version needs to be rolled back.

## Version notes and organization

Version names and change descriptions are release metadata. The API accepts these values when publishing. Metadata can be edited for published or archived versions; the metadata endpoint does not accept a draft, so add the release note during publication if you need it on that version.

Folders organize agents inside an organization. Deleting a folder moves its agents to **Uncategorized**; it does not delete the agents. Archive or delete an agent only after checking any trigger and campaign that uses it.

## Choose the correct test route

Use a dashboard workflow test to review the conversation path. Use a draft phone route only with a number you control, because it can place a real call. Use the published route when verifying the release that your integration will call. These checks exercise different definitions and should not be treated as interchangeable.

Use [Workflow builder](https://docs.tryopencomputer.com/guides/workflow-builder.md) for node prompts, transitions, tool/document attachment, and variable extraction. Use [Feature setup guides](https://docs.tryopencomputer.com/guides/setup.md) to check the optional settings before publication.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.