Building the automation with AgentMaker
AgentMaker in the editor turns a plain-language description into a proposed flow. It receives the graph on the canvas at the start of each message, the automation’s name and state, the organization’s time zone, the step catalog, and organization references. Nothing is applied until you select Apply to the flow.
Use it to build or change the graph. Saving — which creates a version and, if the automation is already on, makes that version live — remains your decision.
Where to open it and who can use it
Section titled “Where to open it and who can use it”Open an automation and stay in Editor. Select AgentMaker in the top bar; the panel appears between the side navigation and the canvas. It does not appear under Settings or Activity.
The button and backend require automations.write. A person with read-only access does not see it. That permission does not automatically grant permission to create tags or lists, however; see When a tag or list is missing.
Write a verifiable request
Section titled “Write a verifiable request”State the event, filters, timing, effect, and resources to use. For example:
When a conversation enters the Support inbox, wait 1 hour. If nobody has replied, transfer it to the Triage agent.
If a decision that changes the outcome is missing — the inbox, delay, message, or branch criterion — AgentMaker should ask for one thing at a time instead of inventing it. To reduce ambiguity, use the names shown in SquadOS and explicitly say when part of the current flow must be preserved.
From the conversation to the canvas
Section titled “From the conversation to the canvas”- When you send a message, AgentMaker freezes the graph currently on the canvas as that turn’s base.
- It returns the whole graph, preserving the steps you did not ask to change and using only known organization references.
- Before displaying the proposal, the backend calls the same graph validator used when saving. AgentMaker can correct an invalid answer and try again, up to three validation attempts in the same turn.
- The card summarizes added and removed steps, type changes, changed fields, and the number of connections added or removed. For fields that point to resources — such as a tag, inbox, agent, model, or template — the card shows the field name but not the selected value. Confirm that value in the step panel after applying.
- If you agree, select Apply to the flow. The graph moves to the canvas as an unsaved change and enters the editor’s local history;
Ctrl+Zundoes it. - Review the canvas and every field marked required or invalid. Proposal validation does not replace this inspection: there are known contracts that the editor flags but saving can still accept.
- Use Save only when the draft is correct. AgentMaker does not save or turn the automation on or off.
If all three attempts fail or the validator is unavailable, it should explain that it could not build the flow. Restate the request as a smaller change or configure it manually; do not treat the missing card as an applied change.
Do not mix manual editing with a pending proposal
Section titled “Do not mix manual editing with a pending proposal”Once the card appears, do not edit any step or any connection before applying. The current protection detects changes to steps and configurations, but does not compare connections. A connection changed manually can be replaced without warning by the proposal’s whole graph.
If you changed the canvas, do not use the old card. Send a new message asking AgentMaker to rebuild the proposal from the current flow. When the detected change is in a step, the card shows a stale-proposal warning and blocks application; that does not make a connection-only edit safe.
Do not apply an old proposal after closing the panel or reloading the page either. The text history may return, but the card’s base graph is not restored. Ask for a new proposal.
When a tag or list is missing
Section titled “When a tag or list is missing”AgentMaker can propose creating contact tags and contact lists. The card states each name and reason; Create writes the resources and Continue starts another turn so it can build the flow with the real IDs.
Before creating:
- check the catalogs for the same name;
- for a tag, confirm that you can edit contacts (
contacts.writein organizations using granular permissions; in legacy mode, the catalog requires Collaborator level or higher); - for a list, confirm that you are an Administrator or superadmin, as required by the current e-mail catalog policy;
- if the card contains several items and an error occurs, check which ones were already created before trying again. Inserts are sequential and have no rollback; restarting from the first name can stop on the unique-name constraint and leave the remaining items uncreated.
After a successful creation, Continue may send an incorrect internal instruction inherited from the prompt editor. If AgentMaker talks about a prompt, active tools, or fails to resume the graph, write a new explicit message, for example: “Continue building this automation using the Customer at risk tag.”
AgentMaker reads at most 300 tags, 300 lists, 300 inboxes, 300 agents, and 300 people per turn, with no name search. If it cannot see an existing resource, do not create a duplicate. Open the corresponding catalog to confirm the name and set that reference manually in the step.
It does not create inboxes, channels, or agents. For those resources it can only recommend the corresponding page; finish creating the resource outside the panel and then make a new request.
What remains out of scope
Section titled “What remains out of scope”AgentMaker for Automations cannot:
- save or turn the automation on or off;
- run or test the flow;
- change the automation’s Settings;
- create an inbox, channel, or agent;
- guarantee that a real delivery will occur: channel windows, consent, frequency, opt-out, permissions, and data present at runtime still apply.
When a request depends on one of these actions, it should present a recommendation instead of claiming it performed the change.
Conversation, closing, and reset
Section titled “Conversation, closing, and reset”Each user, automation, and mode combination keeps a copy of the conversation UI in this browser’s localStorage. The backend also retains the history associated with the conversation identifier. Local storage is best effort: a full quota, corrupted data, another browser, or another device can prevent restoration.
- The X closes the panel without deleting the conversation, but it is not the stop command. If an answer is still being generated, use Stop before closing; closing alone does not abort the request.
- Reset chat asks for confirmation, clears the local copy, and starts a new context with the next message. It does not undo an applied graph or remove tags or lists that were already created.
- After a reload or reopen, treat earlier application cards as history and request a fresh proposal.
Review and test
Section titled “Review and test”Before saving, trace the flow from each trigger to every exit, open the steps, and confirm references, text, timing, variables, and connections. Then use Test. The test executes the current draft: deliveries are simulated, but AI, HTTP, contact creation or updates, and other effects may be real. Read Runs and tests before running it.