Automate Computer Agents from Python.
Metronome is the workflow layer for ACP. Use it when a process should start from an event or prompt, route through conditions, run agents, call resources, update project state, and leave an observable run trace.
Wire events to agents
Start workflows from commands, schedules, email, Telegram, GitHub, resources, databases, auth, and project tickets.
Run ACP services
Use threads, Imagine, functions, databases, tickets, nested workflows, loops, and conditions in one observable graph.
Version safely
Save named workflow versions, publish the production version, and unpublish without losing drafts or history.
Inspect every run
Review traces with node summaries, branch decisions, started thread IDs, resource outputs, and failures.
Model workflows as graphs
A Metronome workflow is a graph of nodes and edges. The visual builder and SDK use the same definition shape, so humans, agents, and backend services can edit the same workflow safely.
| Triggers | Start from thread commands, schedules, email, Telegram, GitHub webhooks, project ticket events, resource events, database entries, or auth events. |
|---|---|
| Logic | Route with conditions, wrap work in loops, add notes, and finish branches with end nodes. |
| Services | Run threads, generate Imagine assets, invoke functions, write databases, update tickets, or call another Metronome. |
| Runs | Every execution produces a trace with node summaries, branch choices, started threads, resource outputs, and errors. |
| Schema registry | The API exposes supported node kinds, trigger types, condition types, loop types, ticket operations, and resource events so visual builders, SDK code, and runtime validation stay aligned. |
Use the right trigger
Choose the trigger that matches where the business event already happens. All triggers can add a prompt extension so downstream agents receive the right operating context.
| Thread command | Run immediately when a user message starts with a command such as @support, @research, or @deploy. |
|---|---|
| Periodic schedule | Run once or on a cron-style recurring schedule. Published periodic Metronomes appear on the Calendar. |
| Email and Telegram | Receive messages through a workflow inbox or bot command, then route by sender, subject, body, or message substring. |
| GitHub and resources | React to repository events, function/web app deployments, database document creation, or auth registrations. |
| Trigger diagnostics | Inspect last received payloads, matched or ignored reasons, unauthorized webhook calls, and the run created by a matching trigger. |
Connect ACP services
Service nodes let the workflow do useful work. A workflow can ask an agent to run a thread, generate assets, invoke a function, write a database record, update a ticket, or call another workflow.
| Thread | Start an agent run on a computer or inside a project. Pass all previous node summaries or only the latest result as input context. |
|---|---|
| Imagine | Start image or video generation with templates, model choices, attachments, and project context. |
| Function and database | Invoke deployed functions, test payloads, insert or update database documents, and pass results downstream. |
| Ticket and Metronome | Move project work forward by changing ticket status, adding comments or subtasks, starting work, or nesting another workflow. |
Version and publish workflows
Edits autosave to the currently selected unpublished version. Create another named version when the graph reaches a new milestone, then publish the version that production triggers should run.
| Create version | Save the current graph with a label and short description. Creating a version does not publish it. |
|---|---|
| Update version | Rename, describe, or autosave graph changes to an unpublished version. Published versions are locked. |
| Publish version | Choose which saved version production triggers should use. Publishing marks the workflow active. |
| Diff versions | Compare two saved versions by added, removed, and changed node and edge IDs before deciding what to publish. |
| Deployments | List publish and unpublish history to understand which version production triggers currently use. |
| Unpublish | Pause production triggers while keeping drafts, saved versions, and run history. |
| Delete version | Archive stale unpublished versions so operators only choose from meaningful release candidates. |
Run and observe
Run workflows manually during development, inspect durable node timelines, and use the visual run sidebar to see the same trigger, audit, and step data a developer sees through the API.
| Manual test runs | Run an inline definition from the editor without publishing it. This is the safest way to test draft graph changes. |
|---|---|
| Production runs | Run the persisted workflow or published version, ideally with an idempotency key when the request comes from an external event. |
| Timeline | Read trigger diagnostics, structured node steps, attempt metadata, branch decisions, linked threads, audit events, summary rollups, errors, and final output. |
| Trigger diagnostics | Inspect last received, matched, ignored, failed, and unauthorized trigger events per workflow or across the account. |
| Audit trail | Review publish, unpublish, run, retry, delete, attach, and trigger test actions across workflows. |