Design Guide

Creating one project means settling on one way of carrying out a piece of work. This guide covers the choices and the criteria for deciding what to settle for the work, how to divide it into steps, and what to put on each of them.

What steps and agents are is covered in Projects and steps. Reading that first will make the decisions here quicker.

Where a section has a place on screen, you will find where to set or check what it asks you to decide at the end of it. Steps and agents are configured on the screen you reach through Edit at the top of the project screen (shown to owners only). That screen has “Editing tools” (for adding steps and agents) and a list (Agents / Steps) on the left, a diagram of the whole thing in the middle (“Editing canvas”), and the settings for whatever you selected on the right (“Properties”). Where the "Where on screen" lines below say "Edit ＞ …", that screen is what they mean. The diagram in the middle can be shrunk with “Display size”, and pressing and dragging an empty spot with the mouse moves the view.

What to settle for the work

Before deciding the type, the steps and the agents, settle four things about the work.

• How much to hand over. There are three clues. Can a mistake be undone? Before an operation that cannot be undone, such as writing to an outside system, put a review step or block it with the execution rules (Review Guide). Can the criteria for the judgement be written down? The criteria an agent judges by go into its goal or a skill; a judgement that cannot be put into words stays with a person. Can the information it needs be reached? List the information needed and what to connect to, and check that it can be used before you start building (Connection Guide)
• What has to be true for it to be done. Settle first when the work is done, then break it down into each agent's goal (later section) and the criteria a reviewer uses to decide whether to advance. How to read a run's result is in Records and metrics
• Where to divide projects. Work that differs in who may see it, which authentication it uses, which operations it allows, or which project memory must not be mixed goes into separate projects. What is decided per project is in Projects and steps
• Where the results go. If a person receives them, put a review step at the end of the workflow (Review Guide). To get them back into a business system, add the destination as a connector and write into the agent's goal what to write, where, and how. The same goes for a run started from the external API (Trigger Guide)

For applications, “Check the contents” is handed over and a person approves before “Register it and reply”. Done means “the entries and attachments are complete, it has been checked against its requirements, it is registered, and the applicant has had the result”. If the system that receives applications differs by department, the projects are divided.

Choosing the type

The first thing to settle is the type. It cannot be changed afterwards.

	Cycle	Workflow
How it ends	No start and no end; it continues	It runs from a start to an end, step by step
How it runs	Each placement runs on its own schedule	One single run goes through the steps in order
How it starts	The schedule on each placement, a webhook, or email	By hand, at a time, through the API, or by email

The criterion is whether there is an end.

If the work starts and finishes one item at a time, use a workflow. It has a beginning and an end, so you can follow each run. A workflow is also the only type where a review step can hold the run itself, for certain (a cycle holds one subject at a time).

If it has no end and simply keeps going, use a cycle. The placements run on their own schedules, and there is no start or finish to the whole.

For which one suits your work, see also Examples of work each suits on the section entry page.

The type decides which of the sections below apply to you. Settings that assume the work moves through the steps in order — what to do when it does not go to plan — belong to workflows only.

Where on screen When you create a project ＞ Type

Dividing the work into steps

How you divide the work differs by type, right down to the thinking behind it.

	Workflow	Cycle
Work it suits	Taking one item and carrying it through to the end in a set order	Going on looking for subjects and doing whatever they call for
How it proceeds	The arrangement of the steps is the order. A step begins after the previous one finishes	Each placement runs on its own schedule, independently. The arrangement is not the order
How stages join up	The platform hands the work over	The next stage picks up what was left in a shared record
A person's decision	Holds the run itself, for certain, at a review step	Holds one subject. The other rounds carry on

If you create a project without specifying the steps, a workflow gets run → a person reviews → run and a cycle gets run → run, because a cycle cannot have a review step. If you had the AI (alpha) draft it, or copied another project, you get the steps that came with it.

There are no product-imposed rules about the names of steps. Name them to suit the work. Nothing progresses differently because of a name, but the step's name is passed to the agent as context and appears in the records. There is an upper limit on the number of steps (Settings reference).

There is no rule that sets the number of steps from the amount of work, and this holds whichever type you chose. When a single run does not finish reliably, narrow what one run takes on in the goal, or split the agents and placements. Adding steps is not necessarily the answer.

Dividing in a workflow

A workflow is the type for taking one item and carrying it through. The arrangement of the steps is the order the work is done in, and a step begins after the previous one finishes.

Take, for instance, a workflow that handles applications as they come in, one at a time.

1. Check the contents — see whether the application and its attachments are complete
2. A person approves — the reviewer looks at it and decides whether to advance or send it back
3. Register it and reply — register what was approved and send the result to the applicant

One item goes 1 → 2 → 3, and it is finished. If it is sent back at 2, it returns to 1 and is redone.

Divide where you want to mark off the progression. In this example the seams fall either side of "a person approves". A seam you create there can carry any of the following.

• A person deciding in between → put a review step there. The run stops there, and from then on it proceeds either on the reviewer's decision or on the setting for what happens once the deadline passes (Review Guide)
• Somewhere for a send-back to land → where a redo starts from is given per step (Review Guide)
• Letting a person choose where to go → put “Destination options” on a review step, and the reviewer chooses a later step to proceed to (Review Guide)
• Waiting for a time → a step can hold a time of its own; leave it unset and the step runs as soon as the previous one finishes (Trigger Guide)
• Changing what happens when it does not go to plan → chosen per step (see below)
• Taking part of it out of the run for a while → steps can be enabled and disabled one at a time. A disabled step is not held at; it is skipped and the run moves on

When you split the work between agents, decide by whether one result must feed the next. Several agents can share one step, but agents on the same step do not pass their output to each other. If an agent is to carry on from another agent's result, divide the steps. Work that does not use each other's results can share one step. The behaviour on failure changes too — retries are counted for each agent placed on the step. How many to place on a step is covered later.

One run's flow can also be split partway. Choose “Split into lanes here” after a step, and from there the run divides into 2 to 11 lanes that go forward at the same time, joining again once every lane has finished. In the application example, after “Check the contents” you could check the entries and the attachments in separate lanes, and go on to “A person approves” once both are done.

• There is only one split. A lane cannot split again
• Within a lane, steps run from top to bottom. Lanes do not wait for each other. When a lane waits for a review, only that lane stops; the other lanes go on and wait at the join
• The step the lanes split from cannot be set to “Run at the same time”
• Steps to send back to, and the destinations in the sections below, are chosen from the same lane. Outside the lanes, they are chosen from the same side of the split — before it, or after the join

Dividing in a cycle

A cycle is the type for going on looking for subjects. Each agent starts on its own trigger, independently, and does not wait for the other steps to finish. So if one stalls, the rest keep running. Where there is nothing to act on, it ends that round without doing anything and looks again on its next round.

A single stage is fine. Looking at something at a set interval and acting if needed — for that alone, you do not need to divide the stages. Created without specifying the steps, you get two, and you cannot delete your way below two, so you can leave the ones you do not use disabled.

A cycle's steps are categories of responsibility. They sit around a circle in the diagram, but they carry no numbers or arrows, and there is no reordering. If you want them to proceed in order, that is what a workflow is for.

Take, for instance, a cycle that gives a first response to incoming enquiries.

• Find them — look for enquiries that have newly arrived
• Sort them — read them and separate the ones a standard reply covers from the ones a person should see
• Draft a reply — prepare a draft for the standard ones
• Check it — before it goes out, see whether the draft fits the enquiry

Enquiries keep arriving, so there is no end to it. Each stage goes round at its own interval.

Divide where the handling of the subject changes. In this example each stage picks up something different. "Find them" takes what has not been dealt with; "sort them" takes what has been found; "draft a reply" takes what was judged standard — what the previous stage left behind decides what the next one takes. That is where the boundary falls.

Once you have the stages, stagger the times they start. Set them all to the same time and a stage can run before the previous one has left anything, and come up empty. Staggering the times puts the opportunities to run in an order (Trigger Guide). It is no guarantee, though, that the previous stage has finished. What each one picks up is settled not by the time but by the marks on the record (see the next section). The schedule belongs not to the step but to each placement on it.

Agents handling the same stage can share a step even when their schedules differ. How many to place, and how the same agent is treated, are covered later.

Joining the stages of a cycle

The stages of a cycle do not wait for one another, so the hand-over is expressed through a shared record. Combine these two.

• A shared record — mark a connector “Use as ledger” (Connection Guide)
• Rules for reading and writing — set out how each agent picks its subject and updates it, in its goal or a skill

Marking a connector “Use as ledger” does not by itself make anything read or written. What you do is have each stage change a mark on the record you settled on above. For the enquiry example from the previous section, that looks like this.

• The find them agent — marks each enquiry it picks up as being checked
• The sort them agent — looks only at what is marked as being checked, and changes the mark to standard or for a person
• The draft a reply agent — takes only what is marked standard, and changes the mark to drafted when it is done
• The check it agent — looks only at what is marked drafted, and changes the mark to checked where there is nothing wrong

Each agent's goal says what it takes and how it changes the mark when it is done. Use whatever form the record supports for the marks — a column, a label, either is fine. The record then serves as the hand-over between the stages.

When the same agent runs over and over, that is expressed the same way too. The platform keeps no list of what has already been dealt with. So a goal that picks its subject by the difference from last time — “what I have not checked yet”, “what I have not looked at for a while” — can end up picking the same subject every time. Leave a mark on what is done, and have the next round leave anything carrying that mark alone — express the difference from last time in the record as well.

A person's decision is expressed the same way. Give the agent's goal an option of handing something to a person, and have it leave a different mark when it does. Tell the other agents, in their goals, to leave anything carrying that mark alone, and that one subject waits on a person while the rounds over everything else carry on. Once a person has decided, outside the product, and changed the mark, it starts moving again.

Here is where the two types differ. A workflow holds the run itself, for certain; a cycle holds one subject at a time. If what you need held is the whole run, choose a workflow. A hold built out of instructions is not something the platform guarantees, so where it absolutely must not be bypassed, use a mechanism on the connector or API side.

A cycle cannot have a review step

You cannot add a review step to a cycle. A person's decision goes in through the marks described above.

Where on screen Edit ＞ “Editing tools” on the left ＞ “Add step” (in a workflow, then choose “Regular step”). In a workflow you can also use “+” between steps in the diagram in the middle ＞ “Run by Agent”. Select a step in the diagram in the middle and the settings for it appear on the right. In a workflow you can reorder them in that diagram (a cycle has no reordering). For the shared record, the Settings tab ＞ “Connectors” ＞ the connector ＞ the “Ledger” switch. To split, right-click a step in the diagram in the middle ＞ “Split into lanes here”. Adding a lane and stopping the split are in the split's box in the diagram. To move a step to another lane, “Step settings” (“Check settings” for a review step) on the right ＞ “Trigger” ＞ “Lane”

What to give an agent

Only two things are required: a name and a goal (instructions). Guardrails, a playbook and skills are added only where you need them.

Start by settling the goal

The goal says what the subject is, what to do with it, and what state it should be left in. This is the heart of the agent.

Writing a goal does not, on its own, put anything external within reach, though. In a cycle especially, write where the work is to be found into the goal, and add the services it needs to the project's connectors (Connection Guide). For the enquiry example from the previous section, the goal goes as far as "look for unhandled enquiries in the connector".

For an agent that writes outside, also write that it should check whether it has already written before writing. The same agent may run again (for a workflow see the later section, for a cycle the previous section). For “Register it and reply” in applications, write “if the same application is already registered, do not register it again”.

Where “Personal information masking” is enabled under “Guardrails Settings” in the admin console, a step's instructions, like a conversation, have personal information masked before they reach the agent. That covers the goal, the output of the previous step, reviewers' comments and reasons for sending back, and the subject and body of an email or the body of a webhook received.

Add only what you need

• If there is behaviour you want it to steer clear of, guardrails. For the enquiry example: "do not send the reply yourself", "do not touch amounts or contract terms". Mixing "do not do this" into the goal makes the account of what to do harder to read. Be aware, though, that guardrails are instructions to the agent. Writing something there does not reliably stop an operation. Operations you need stopped for certain are settled in the execution rules (Execution Rules Guide)
• If there is a set procedure you use again and again, a playbook. For when you want the draft a reply agent to go through the same run of steps every time — "find similar past enquiries → choose the form of the answer → write the draft → attach the articles it drew on". Set out each step with its purpose, guidance and success criteria and the agent works through them. The steps you write are not simply repeated, though. The agent adjusts them to suit the request. To hold an order in a workflow, do not reach for a playbook — divide the work into steps instead
• If you want it to hold the method for one particular piece of work, a skill. Make "how you classify enquiries" a skill, for instance: the table mapping your product names to categories, the order of precedence when a judgement is close, examples you have got wrong in the past — a method your organisation has settled on, written down for the sort them agent to follow. Setting it out separately rather than repeating it in every goal lets several agents work to the same standard. "The form a reply should take" and "when to escalate" suit a skill as well. A skill does not grant any permission on an external service (what it can reach is settled by the connectors). In a cycle, what the agent finds to work on is settled by its goal, its skills and its connectors

You can also add a description and input files. The list of items is in the Settings reference.

Agents are shared across projects

A change to an agent's settings reaches every project that uses it. A small change meant for one project changes how the others behave too. If you want different behaviour per project, use separate agents.

When handing over, have the successor prepare agents they own and put those in place (how an agent's owner differs from the project's owner is in Who decides what).

Where on screen Edit ＞ select the agent placed on the step in question, in the diagram in the middle, then “Agent on this step” on the right ＞ “Basic settings” ＞ “Edit Agent” ＞ “Goal (instructions)”. “Edit Agent” appears only to the agent's owner

Placing agents on steps

Each single agent placed on a step is a placement. Runs happen at the level of the placement.

How many to place on one step

Where one agent can carry the whole step, leave it at one. Placing several lets you do the following, according to the type.

Placing several in a workflow lets you give separate jobs within the one step. By default they run one at a time, in placement order. Set the step to “Run at the same time” and they run together. This suits work that does not wait on each other. Either way, agents on the same step do not pass their output to each other. Each works from the output of the previous step. On "Check the contents" in the application example, you can place an agent that looks for anything missing alongside an agent that checks the application against its requirements. Once every agent placed there has finished, the run moves to the next step, and the next step receives all of their output. If one agent is to carry on from another agent's result, divide the steps (see the next section).

On a step set to “Run at the same time”, each agent whose result is “Not allowed by rules” or “Failed (reported by agent)” follows “Handling of results” on its own (see below). Where that means asking for a review, a review request is raised for that agent, and the other agents carry on. The run does not move to the next step until all of their results are in. Where the agents point to different next steps, a review request is raised to choose where to continue. Send back a review request on this step, and the run redoes the work from the step it goes back to without waiting for the other agents. The results of agents that were still working, and decisions on the other review requests of that round, stay in the record but are not used to move on.

Placing several in a cycle lets you divide one stage into rounds that differ in what they look for, or in how. Each placement runs without waiting for the others. On "Find them" in the enquiry example, you can place an agent that looks through the mail for anything unanswered alongside an agent that looks through the form for the same. Placing several, however, settles neither how the subjects are divided between them nor how duplication is avoided. Which of them takes which is settled by the shared record and each agent's goal (see above).

What is handed over in a workflow

What a workflow hands over automatically is the output of every agent on the previous step, and the files each of them produced. Files saved in the Library reach the agents on the next step as input files. Where the previous step has several agents, their outputs arrive one after another, agent by agent.

There are three things to watch for.

• Nothing is handed over between agents on the same step. Line two up on one step and the second does not receive the first one's output or new files; both receive what came from the previous step. When they run in placement order, though, if the first rewrites a file that came from the previous step, it is the same file, so the second reads the rewritten version. Agents on a step set to “Run at the same time”, and the lanes, are also handed the same files, so do not have them rewrite the same file at the same time
• Only the last step where agents ran is handed over. A review step is skipped, and what arrives is from the step before it. What came from two or more steps back is not handed over automatically. With lanes, the first step of each lane receives what came from the last step before the split where agents ran. The first agent step after the join receives the last of each lane (outputs and files). When more than one output arrives, each is labelled with its lane name and step name (a single output is not, and files are not)
• The exchange along the way is not handed over. What an agent found while looking does not carry across

So where an agent on a later step needs to see what was produced two or more steps back, have it saved to a shared record (Connection Guide). Where the previous step's output and files are enough to carry on from, lining them up is fine.

A cycle has no such automatic hand-over. How its stages join up is expressed through a shared record, as above.

Placing one agent on several steps

The same agent can be placed on several steps. An agent is a setting you reuse, so you get one placement for each step you put it on.

• In a workflow, placing the same agent on consecutive steps still runs it on each step. On the later step, as on any other step, it receives the output of the previous step together with the files produced and saved in the Library (Projects and steps)
• To run the same agent on two schedules in a cycle, divide the steps. The same agent cannot be placed on one step twice

In a cycle, the schedule belongs to the placement rather than the agent. Setting it is covered in the Trigger Guide.

Where on screen Edit ＞ place from “Agents” in the list on the left into the diagram in the middle. Or select the step in the diagram, then “Step settings” on the right ＞ “Add Agent” (in a workflow, on the “Basic settings” tab). To take one off, press × (“Remove from step”) in the same list, or “Remove from step” at the bottom of the right-hand panel when the placed agent is selected. To run them together, select the step in the diagram in the middle, then “Step settings” on the right ＞ “Trigger” ＞ “Run at the same time” (it can be switched once two or more agents are placed). The company memory to read is under “Agent on this step” on the right ＞ “Basic settings” ＞ “Company memory” when the placed agent is selected. “Save memory settings” saves it on the spot, apart from the draft, and it applies from the next run (discarding the draft does not undo it)

What to do when it does not go to plan (workflows)

A step can be told what to do in two situations where it did not end as intended. Both are chosen per step. Both of them apply to workflows. A cycle does not move through the steps in order, so it does not use them.

“When not allowed by rules” lets you choose from “Ask for review (awaiting review)”, “Close as failed” and “Go to a specific step”. This is when the platform forbade the run itself.

• Ask for review (awaiting review) — the work stops where it is and a review request is raised for the owners (such a step has no field for naming reviewers, so every owner at that moment becomes a reviewer. However, on a step switched from a review step to “Run by Agent”, the reviewers named while it was a review step become the reviewers, if they are still members). The run goes to awaiting review, and proceeds from there either on the reviewer's decision or on the setting for what happens once the deadline passes (Review Guide)
• Close as failed — the run itself ends. No review request is raised, and no later agent or step runs
• Go to a specific step — no review request is raised, and the run goes to the later step chosen as the “Destination step”. The steps in between are not run (the run record shows them as “Not selected in the branch”). On a step that runs in placement order, agents on the same step that have not run yet do not run. On a step set to “Run at the same time”, the other agents are already running, so they are not stopped, and the destination is settled once their results are in. The output and files of the agent whose result led to the destination are not handed over to the destination step. Where the destination step was disabled before the run started, it behaves as “Ask for review”

Asking for a review is the default. As a rule of thumb: ask for a review if revisiting the settings might let it through, and close it if not. The execution rules themselves are covered in the Execution Rules Guide.

“When the agent reports it could not finish” lets you choose from “Ask for review”, “Proceed anyway” and “Go to a specific step”. This is when the agent has itself reported that it could not complete the work, or said so in its final result.

• Ask for review — as above, a review request is raised for the owners. The run goes to awaiting review
• Proceed anyway — no review request is raised, and the run moves on to the next agent on the same step if there is one, and to the next step if there is not (on a step set to “Run at the same time”, it moves to the next step once the other agents' results are in)
• Go to a specific step — as above

Here too, asking for a review is the default.

Choose “Proceed anyway” when the agents on later steps do not use this agent's output. If they take that output and carry on from it, stopping for a review is the safer choice. Note that when there was nothing to act on and the run never started, it moves on regardless of this setting.

In neither case is anything retried automatically. Running it again risks writing to the outside world twice. Whether to run it again is for a person to decide, once they have looked at the situation.

A failure on the platform's side — an abnormality in the runtime, or a timeout — is retried automatically. The limit on the number of retries is set for the project as a whole and counted for each agent placed on the step, each time the run enters that step (when a send-back brings the run back to that step, the count starts over). Once it is exceeded, that run ends as a failure (for the permitted range, see the Settings reference). When something has been retried, the run record says “Attempt 2”. A retry does not carry on from where it stopped; the agent on that step runs again from the beginning.

When setting things right, decide whether to start a new run or, if it is waiting for review, send it back to redo from a step partway through. What to check first is in the Record Guide, and how operations already carried out are treated is in the Review Guide.

Where on screen Edit ＞ select the step in question in the diagram in the middle, then “Step settings” on the right ＞ “Trigger” ＞ “Handling of results”. The number of retries is under the Settings tab ＞ “Execution rules” ＞ “Execution” ＞ “Retries per step (failed / timed out)”

Publishing and reuse

Playbooks, skills, agents and projects can each be published. How you reuse them differs.

	How you use a published one	When the author changes it later
Skill	Can be used as it is	It reaches you if you “Follow the latest version”; not if you pinned a version
Playbook	Copy it to your own library first	Copies are unaffected
Agent	Placing it on a step copies it to your own library	Copies are unaffected

A published agent is copied to your own library the moment you place it on a step. From then on it is yours, so you can edit it — but anything the author changes afterwards does not come through. To take a later version, place it again.

For playbooks, only your own appear in the choices for an agent. To use a published one, copy it to your own library first.

Skills are the one case where you use the published item itself and the author's updates do come through. They behave differently from the other two, so keep it in mind. When the author changes it, a new version is made, and an agent set to “Follow the latest version” uses the new version from its next run. If you do not want changes to come through, pin the version the agent uses.

When you publish a project, other users can copy its steps and agents and use them. Its run records and ledgers are not published.

On a project you copied, check the following.

• Connectors — the list carries over (and so do the “Ledger” marks). The connection (authentication) does not, so connect them again in the copied project
• Playbooks, skills and input files — the playbooks and skills used by other people's agents are duplicated into your library and attached (your own skills, and skills that are public and active, are used as they are). Of the input files, only those not in your library are removed
• The review settings, a step's time, and the failure settings — they are not copied. The steps themselves and the send-back targets do carry over (and so do “Run at the same time” and the lanes)
• The trigger settings — a time trigger is copied but arrives switched off. A cycle's rounds do not carry their schedules over. The “Start by email” settings (the address, the allowed email addresses and, for a cycle, the placement to start) are not copied either; turning it on in the copied project creates that project's own address
• The organization and the company memory choices — they are not copied. Set the organization on the copy if needed, and choose the company memory again for each agent

Duplicating your own project does not divide the agents. Your own agents are placed, as the same agents, in the duplicated project. Edit an agent in the duplicate and the original project changes as well.

Checking a draft and applying it

Changes to steps and placements, except the “Company memory” settings, build up as a draft. Until you apply it, the project does not change. What you apply takes effect from the next run; it does not affect a run already under way.

A draft stays in that browser. You can pick up where you left off next time you open the editor, but it does not follow you to another browser or device.

Before applying, you can validate the settings. Validation covers the draft as well, and it neither saves anything nor runs anything against an external service. Coming through validation cleanly does not mean the run will succeed: authentication on a connector, and the permissions it has at the time, are checked when the run happens.

What validation reports is the same judgement as the “to fix” count shown in the editor. It goes through the enabled steps by kind. On a step that takes an agent, it looks at whether an agent is placed and whether that agent has a goal. On a review step, at whether it has reviewers (in a workflow). In a cycle it also looks at whether the placement has a schedule. A schedule you have deliberately stopped does not count as a point to fix.

Changes are applied one by one. If some of them could not be applied, those stay in the draft, and the reason for the first failure is shown. Fix them and apply again. Where adding, deleting or reordering a step, or adding, placing or removing an agent, failed and held up the later changes of that kind, “Discard this change” removes just that one from the draft (this cannot be undone).

One thing to watch. An agent's settings are not part of the draft. When you edit an agent and save it, it is saved there and then. Discarding the draft does not undo the change to the agent. Do not think that discarding a reordering of steps will also roll back what you changed in an agent.

To try out a change to an agent, try it on a new agent. There is no way to duplicate your own agent, so create a new agent, carry over the goal and skills, place it in a project you test with (duplicating makes one), check the results, then apply the change to the original agent. Keep your own note of what you changed and when. Which changes Records (audit trail) keeps is in the Records Reference.

The Settings tab ＞ “Basic information” does not use the draft; it changes when you save. If the project was updated by another change after you started editing, a notice appears when you save, and you choose “Load latest” or “Keep my edits”. Keeping your edits takes the latest values for the fields you did not change and lets you carry on; press “Save” again to save.

Where on screen The top of Edit ＞ “Check settings” and “Apply changes”

Letting the AI draft it for you

The features for creating and consulting with the AI are alpha. Their entry points on screen are marked “(alpha)”. How they behave and look may change. Do not use what the AI made as it is; always check it.

There are two ways to have the AI draft something. When you create a project, choose “Create through consultation” or “Guided setup” under “How do you want to create it?” (both are marked “alpha”).

Talking it through to make one

Write what you want to do and the AI will settle on a type, steps and agents, and produce a draft. It may come back with questions along the way. Playbooks and skills you have already registered are picked out of the candidates by the AI and attached. Anything it only knows by name is shown as “Not registered: …”, for you to attach. The proposal shows the names of the skills and the playbook it attaches to each agent, as “Skill: …” and “Playbook: …”.

Look the draft over and create it, and it is saved at that point.

Answering questions to make one

Choose “Guided setup” and you answer fixed questions one at a time, starting from an official template. While you answer, the AI does not run and no project is created. A question that offers “I don't know, next” can be passed with that button, a question that lets you press “Next” without choosing anything can be passed without a choice, and you can go back to an earlier question to change the answer.

Once you have answered, a “Suggested structure” appears. It lists the type, steps, assigned agents, start and connected services, and nothing is saved yet. Press “Refine with AI” to finish it with the AI, starting from this structure. Look the draft over and create it, and it is saved at that point.

The skills and playbooks the template calls for are not attached by name. They are shown under “Needs to be prepared”; what gets attached is picked as when talking it through, or attached by you. The connected services are not connected yet (they show “Not set up”). Connect them in the project's connected services after it is created.

For a workflow template with a fixed step structure, the number of steps and the sequence of agent steps and review steps stay as in the template, as long as it is created as a workflow. A draft in which the conversation with the AI changed that number or sequence is put back to the template's steps (the screen says so). To change them, use the editor after the project is created. If you decide during the conversation to make it a cycle, the template's structure — lanes, destinations and the like — is dropped (the screen says so).

Where the official questions and templates cannot be used, the screen says that guided setup is not available right now.

What to check either way

Where a time trigger was proposed, it is registered switched off. Where a schedule was proposed for a cycle, the project is created paused, and each placement's sweep is registered with that schedule; sweeping starts once you resume the project. This is the same on both paths. Check the contents before you switch anything on or resume (Trigger Guide).

Look at the placements you ended up with and check how many agents were placed on each step. Where the number or the arrangement is not what you need, adjust it after it is created. A “Run by Agent” step with no agent assigned is marked “No Agent”. Place an agent on it after it is created. Where the proposal has fewer than two steps (for a cycle, review steps are not counted), empty “Run by Agent” steps are added to make two, and a warning tells you so. After creation, set the content and agent of the added steps, or replace them.

Consulting the AI after it is created

After a project is created, you can still consult the AI in the editor. You can consult it on reviewing the project setup and on creating an agent. For eligible workflow step runs that did not go well, you can ask for improvement ideas in the run record (Record Guide).

For a private agent owned by someone else, what the AI receives stops at the goal (instructions). Its guardrail and the skills and playbook attached to it are not visible to the AI, so the proposals may not take them into account. Check with the owner where needed.

When you take in a proposal, changes to steps, placements and sweep schedules go into the draft. They do not reach the project until you apply them. A proposal to create or change an agent opens the agent's screen, and is saved when you save it there. If a new agent has a step to be placed on, that placement goes into the draft too.

Where on screen When you create a project ＞ “How do you want to create it?” ＞ “Create through consultation” or “Guided setup”. After creating, Edit ＞ “Editing tools” on the left ＞ “Ask the AI (alpha)” ＞ “Discuss the project setup” or “Discuss creating an Agent”

Distinctions worth keeping straight

These are the distinctions that cut across the sections above.

• Thinking a guardrail stops an operation. Writing “do not send the reply yourself” into a guardrail is an instruction to the agent; it is no guarantee that the operation is stopped. An operation you need stopped for certain is forbidden in the execution rules (Execution Rules Guide)
• Editing one agent and breaking several pieces of work at once. Changing an agent's settings reaches every project that uses it. And an agent's changes are saved separately from the draft of the steps and schedules — discarding the draft does not undo them. If you want different behaviour per project, split the agents
• Thinking that duplicating a project divides the agents. Your own agents are placed in the duplicated project as the same agents. To try something, create a new agent
• Taking the arrangement of a cycle's steps for an order. However the steps are arranged in the diagram, in a cycle that arrangement is not the order things run in, and no step waits for the one before it to finish. To join the stages up, express it in the marks on the record. To make the work itself proceed in order, choose a workflow
• Not checking the trigger settings once it is created. A time trigger the AI (alpha) proposes is registered switched off, and a cycle it proposes a schedule for is created paused. On a copy, the time trigger is switched off and a cycle's rounds do not carry their schedules over. Once it is created, check that what you want running runs, and what you do not want running does not (Trigger Guide)

What to read next

• Review Guide — where to put review steps, and who to let decide
• Trigger Guide — when, and on what, to set it running
• Connection Guide — what to connect to, and where to send word
• Execution Rules Guide — how far an agent may go
• Settings reference — the limits and defaults for steps, skills, retry counts and the rest