Operating protocols

An operating protocol is a graph of phases that guides how an agent works through a process. Instead of relying on a single free-text task description, the protocol breaks the agent’s behavior into explicit steps — each with its own instruction and, optionally, a tool to run — connected by transitions. Protocols are edited on the agent’s node-graph canvas as part of the agent editor.

Phase fields

Each phase node has:

• Phase key — a unique name identifying the phase within the protocol.
• Instruction — what the agent should do in this phase.
• Attached tool — optionally, a tool the agent executes in this phase.
• Start phase — a marker designating where the protocol begins; exactly one phase carries it.
• Conditional transitions — rules that route to the next phase based on outcomes, for example tool_result.success → a target phase.

Tool phases and branching phases

The editor marks phases by their role:

• A tool phase has a tool attached — the agent runs the tool and its result drives the outgoing transitions.
• A branching phase has multiple outgoing conditional transitions — the agent evaluates the conditions and follows the matching path.

Combining the two lets you model real processes: run a tool, then take different paths for success and failure.

Validation rules

The editor validates the protocol graph before it can be used:

• Exactly one phase is marked as the start phase.
• Phase names are unique.
• Every transition resolves to an existing target phase.
• All phases connect through to the output — no dead ends or unreachable phases.

Fix any reported violations before saving the agent.

Authoring guidance

• Keep each phase focused on one action or decision: one instruction, at most one tool.
• Name phase keys after what they do (collect_details, create_ticket) so transitions read naturally.
• Cover the failure path: whenever a phase has a tool, add a transition for the unsuccessful outcome, not only for tool_result.success.
• Write instructions as directions to the agent (“Ask the user for…”, “Summarize the result and…”), not as documentation.
• For a first draft, describe the process to the Ask-Me Assistant and refine the proposed phases on the canvas.

Worked example: ticket triage

A simple triage protocol for a support chat agent:

1. greet_and_collect (start phase) — Instruction: “Ask the user to describe the problem, the affected system, and how urgent it is. Do not proceed until you have all three.” Transition: details complete → search_knowledge.

2. search_knowledge — tool phase with a memory search tool attached. Instruction: “Search the knowledge base for a known solution to the described problem.” Transitions: tool_result.success → propose_solution; otherwise → create_ticket.

3. propose_solution — Instruction: “Present the found solution step by step and ask whether it resolved the issue.” Transitions: resolved → output; not resolved → create_ticket.

4. create_ticket — tool phase with a ticket-creation tool attached. Instruction: “Create a ticket with the collected details and an appropriate priority.” Transition: tool_result.success → confirm.

5. confirm — Instruction: “Tell the user the ticket number and what happens next.” Connects to the output.

This graph passes validation: one start phase, unique keys, every transition resolves, and every phase reaches the output through either the solution path or the ticket path.