Chatterfly

Chapter 3 of 11 · ~2 min

Setting up the coding agent

Three things connect a coding agent to a workspace: a personal access token from the dashboard's API tokens page, a few lines of configuration that point the agent at the MCP endpoint with that token, and the brief from chapter 1. The dashboard generates the configuration for the common agents; the shape is shown in the experiment below.

What the agent reads before it writes. A well-behaved agent does not start from memory. It loads the DSL reference by section (authoring first, then core and nodes, then conditions, inputs, human-in-the-loop and parallel as needed), lists the models available to the workspace and what each can do, lists the tools and connections it may use, and lists the surfaces if the workflow goes beyond the web widget. All of that is one tool call each, and the reference text is the same text a person reads in the documentation.

Rules the agent follows. The definition lives in your repository as the source of truth; the platform's draft is not version history. Every definition is validated before it is saved and deployed. Deployments are private unless a workflow is benign and has a single human participant. Node ids are unique among siblings, node types are spelled the way the reference spells them, and the DSL version is never written by hand. Credentials and environment-specific ids never appear in a definition; the workflow names a connection and the deployment binds it.

The prompt. It is the brief, plus what you want first: the skeleton only, rules and messages and the form, no model yet, validated. The agent's first output is a definition you can read in five minutes. The rest of the course adds one decision at a time.

Experiment

Runs in your browser

The configuration for a coding agent, the opening prompt, and the validated skeleton the agent returned, annotated.

Configuration, prompt, and the first skeleton. The MCP configuration for a coding agent, the opening prompt, and the skeleton the agent returned after validating it.

// .mcp.json in the repository (the dashboard generates this for you)
{
  "mcpServers": {
    "chatterfly": {
      "type": "http",
      "url": "https://<your-api-origin>/mcp",
      "headers": { "Authorization": "Bearer ${CHATTERFLY_TOKEN}" }
    }
  }
}
// The opening prompt
"Read the attached brief for Kettle Co.'s enquiry process. Load the DSL
reference (authoring, core, nodes, input-fields, hitl) and list the models,
tools and connections available in this workspace before writing anything.
Write the skeleton only: the intake form, the rules, the messages and the
approval; no model steps yet. Validate it. Keep the definition in
workflows/enquiry-to-quote.json. Do not deploy."
// What the agent returned, trimmed (validated, 0 errors)
{
  "type": "Workflow",
  "id": "enquiry-to-quote",
  "participants": [
    { "name": "prospect", "type": "human", "bind": "unbound", "surface": "widget" },
    { "name": "rep", "type": "human", "bind": "team_member", "team": "sales", "surface": "inbox" }
  ],
  "children": [
    { "type": "Message", "id": "welcome", "participant_role": "prospect", "content": "…" },
    { "type": "Workflow", "id": "enquiry", "surface": "form", "participant_role": "prospect", "children": [ … 9 Input nodes … ] },
    { "type": "Code", "id": "qualify", "input": { … }, "expression": "function ({ … }) { … }" },
    { "type": "Conditional", "id": "gate_qualified", "condition": { "operator": "eq", "field": "qualify.qualified", "value": true }, "false": [ … ], "true": [ … ] }
  ]
}
  1. 1A personal access token from the dashboard. It authenticates as you, in one workspace, and can be revoked from the same page.
  2. 2The agent reads the same reference a person reads, one section per tool call, before it writes a line.
  3. 3Rules, messages and people first. A model step is added when a chapter earns it.
  4. 4Deployment is a separate, deliberate step, and private by default.
  5. 5The rep is a role bound to a team, resolved when a run starts. No names in the definition.
  6. 6The five questions are one form, one pause, one answer object.

Big question

Who in your organisation holds the token, and who reviews what the agent writes with it?