Agents on the canvas
The components of the visual builder, variables, test runs and debugging, templates, scheduled automations and confirming actions in Telegram.
An agent in Gleyk is described as a graph of components connected by directed transitions. You build it on the canvas without code: search, model, conditions, processing, output. This article describes the components, variables, running and debugging, and how an agent becomes an automation.
Creating an agent
In the "Agent" section, click "Create agent". There are two ways: "Create from templates", where ready-made scenarios (for example, a knowledge base report or deep research) are copied into your organization, and "Create your agent from scratch". After you choose, the canvas opens with the "Begin" component; you add the other components with the "+" button on a node.
After copying a template, check it: references to knowledge bases and models must point to your organization's resources, and tools that change data must be turned off or approved.
Components
| Component | What it does | Key settings |
|---|---|---|
| Begin | The only entry point. The "conversational" mode with a greeting or the "task" mode without a dialogue | Global variables: text, paragraph, list, number, flag, file; required and optional |
| Retrieval | Extracts chunks from knowledge bases | Query variable (sys.query by default), bases with a single embedding model, similarity threshold, keyword weight, number of chunks, reranker, text for an empty result |
| Agent | A model with a system prompt, tools and sub-agents | Model and generation parameters, prompt, tools (including "Retrieval" and MCP), number of reasoning rounds, retries on error |
| Categorize | A model assigns the input to one of the categories | Categories with a description and examples; examples matter more than the description |
| Switch | Branching by rules without a model | Cases with conditions: equals, contains, greater than, empty and others; combined with AND or OR |
| Message | Shows the result to the user | Text with variable substitution; if there are several options, one is chosen at random |
| Code | Runs Python or JavaScript | Input variables, the main function, returned variables |
| Iteration | Splits text by a delimiter and runs a nested scenario for each part | Delimiter; the internal IterationItem node as the entry point of the nested scenario |
| Await Response | Stops the scenario and asks the user for data with a form | Form fields, as in "Begin" |
Categorize relies on a model and suits recognizing the user's intent. Switch works by rules and suits deterministic checks: document status, an amount above a threshold, an empty search result.
For actions in external systems there are gateway components: nodes that wait for an event, pause, or wait for human approval. They let a scenario wait for hours and days and survive restarts.
Variables
The arrows on the canvas set only the order of execution, and data is passed through variables. The output of each component gets a name and is available further down the graph. In input fields, click (x) or type / to choose a variable: sys.query (the user's query), variables from "Begin", component outputs. In the prompt of an "Agent", variables specify which data the model must take into account; a preceding node is not an input by itself.
The scenario's global variables include the query, the user, the dialogue turn number and attached files. A file uploaded as a variable is passed to the model as raw text, without processing and without being added to a knowledge base; if the text is longer than the model's context, it is truncated.
Running and debugging
The "Test Run" button runs the scenario on control data. Fill in the "Begin" fields, watch the nodes execute and the error messages, then open the final result and the log. The log shows the execution path, variable values and the trace of tool calls: name, arguments, result, time. For the "Retrieval" component, the found chunks are checked separately.
Debugging rules:
- change one parameter at a time and repeat the full control set: positive, negative and erroneous input;
- when a component fails, set a transition to an alternative branch or a default value;
- for an action that changes data, check the external system separately and do not repeat the run until it is clear whether the first action partially completed.
The canvas stores versions, so a working scenario can be rolled back to a previous state.
Automations
An agent becomes an automation in the "Automations" section. An automation has a trigger, a target and delivery:
- Trigger: a schedule, a webhook, a connector event or polling of an MCP tool that fires only when the response changes.
- Target: an agent, an agentic job with a budget on the number of items and model calls, a canvas scenario or a long scenario with pauses.
- Delivery: a conversation, Telegram (including several chats), Bitrix24 or another connected system.
Example: every day at 18:00, collect new payment documents from 1C and send a summary to Telegram. You can also create an automation from chat: an assistant with the automation copilot enabled creates it on request, but always disabled. Check it in the "Automations" section, enable it, and only then register the webhook address in the external system.
Note
The first scheduled run happens in the next slot after you enable the automation, not immediately.
Confirmations
Any write to an external system requires human confirmation. On the canvas, an approval node parks execution until a decision is made; a long scenario survives a restart and continues from the same node. In chat, the assistant stops the turn and shows a card with the description of the action, the object and the parameters; the card is valid for a limited time, after which the action has to be requested again.
If the agent delivers the result to Telegram, the confirmation arrives there as a message with "Confirm" and "Reject" buttons. The user waiting for the decision sees the status "awaiting confirmation" rather than endless typing. A rejection and a cancellation are recorded, and resubmitting the same action does not cause a double effect.
Before confirming, check the target system, the object, the new value and whether the change can be reversed. After execution, open the external system and make sure of the actual result.
What's next
- MCP servers: where an agent gets its tools.
- API key and SDK: running an agent through
POST /agents/{id}/completionswith input parameters. - Automation scenarios for departments: the Automation page.
Ask Sema