Build workflows with an AI agent

​

How a build works

​

Ask for a workflow

• “Build a workflow for our Contact Sales form. Match the person to a Salesforce account. If there is a match, send the lead to the account owner. If not, route it through the ‘Inbound AE’ queue and post the result in #inbound-leads. Use the real queue and channel. Show me each change before you save it.”
• “In the ‘Inbound router’ workflow, add a branch for companies with more than 1,000 employees that goes to the ‘Enterprise AE’ queue. Check the draft and fix what it reports, then ask me before you publish.”
• “What does a Round-Robin step need, and what does it give the next step?”
• “Which Salesforce fields could the Update Record step in ‘Inbound router’ write to?”

• Vague values, such as “set a sensible delay” or “notify the right channel”. Name the value, or ask the agent to list the options first.
• “Publish anyway” when the check reports problems. Fix the problems first.
• “Delete the workflow” or “turn it off”. The agent cannot do these. Use the app.

​

Design rules

• Check a step’s exits before you add after it. Match Record has a fixed Match and No Match exit. Display Scheduler has a fixed Booked and Not booked exit. You cannot add a third exit to either. Most steps allow only 1 next step. Add the new step on a specific branch.
• Give every Multi-Branch branch a condition. A new Multi-Branch step starts with only the Else branch. When 2 branches can both match, set their order: the first match wins.
• Give Run Experiment weights that add up to 100. A new Run Experiment step starts with no branches. Add each branch and its weight.
• Use outputs from earlier steps, not typed text. Bind an email, a domain, or an owner to the step that produced it. After 2 paths join, a value is safe to use only if every path into that point produces it.
• Compare values as the type they are. Many providers send yes or no flags as the text "true", not as a true or false value. Check the field before you write the condition.
• Use the CRM field, not its label. For a Salesforce or HubSpot write, use the field the agent found with workflow_find_values. A restricted picklist accepts only its listed values.
• Name the exact owner field. “Owner” can mean the record owner, the account owner, or a custom field. Say which one.
• Name every step. An unnamed step shows its type on the canvas, which makes a large workflow hard to read.

​

Test and go live

1. Open the workflow in the builder and use Test to run it with sample data. See Test a workflow. A test performs real actions.
2. Read the run logs step by step. A run marked as successful does not prove each step did its work. For example, a match step with an empty email takes the No Match path without an error.
3. Ask the agent to publish.

​

What the agent cannot do

• Delete, pause, or turn on a workflow. Use the app.
• Run a draft. Use Test in the builder.
• Work in a different workspace. The workspace comes from your sign-in, not from the prompt.
• Use a CRM field that Default cannot see yet. A new Salesforce or HubSpot field can take up to 15 minutes to appear. A Salesforce field hidden by field-level security never appears, and the error looks the same as a wrong field name.

​

Common errors

​

Rules for your agent

# Building Default workflows over MCP

Order of work:
1. workflow_describe with no type, then once per step or trigger type you will use.
2. workflow_find_values for every field you fill. Copy option values and reference selectors
   exactly. Never use a value marked availability "downstream". A "blocked" field needs a
   sibling field set first.
3. workflow_read_graph with select "summary" first. Use nodeIds or search to read only what you
   need. Keep the revision it returns.
4. workflow_apply_changes without confirm. Show the person the preview and its issues. Only after
   they approve, send the same arguments plus confirm: true and the confirmationToken.
5. Act on every issue and its repair text before you continue.
6. workflow_validate_graph until it reports valid. It takes a few seconds.
7. workflow_publish without confirm, show the preview, then confirm after approval.

Rules:
- Always send expectedRevision from your latest workflow_read_graph. After any saved change, or
  on WRITE_CONFLICT, read again before the next change. Never retry with an old revision.
- Do not send a new step's exits. The server adds them.
- Before adding after a step, read its edges. Match Record and Display Scheduler have fixed exits.
  Most steps allow one next step. Use via_edge to choose a branch.
- Multi-Branch starts with only Else. Give each new branch a condition and an order.
- Run Experiment starts with no branches. Weights must add up to 100.
- Bind values from earlier steps as references, not typed text.
- Use CRM field API names from workflow_find_values, never display labels.
- Name every step.
- Get workflow IDs from list_workflows and run IDs from list_workflow_runs. Never guess an ID.
- After creating a workflow, use the returned workflowId. Do not send the create again.
- Never publish while validation reports problems. Never publish without the person's approval.
- A new workflow goes live on its first publish. Say so before you ask for approval.
- You cannot delete, pause, turn on, or test-run a draft. Tell the person to use the app.