Build with ORBY
Build and edit a workflow by describing it, in a conversation docked beside the canvas
What ORBY is
ORBY is the AI assistant docked beside the canvas in MagOne Studio. You describe what you want, and it builds and edits the workflow while you watch it happen.
It is a conversation, not a one-shot generator. You can ask it to add a step, change a branch, explain what a node does, run the workflow, read a failed run, or start over.
Open it from the use case canvas. The button is labelled Build with ORBY if you can edit the workflow, and Ask ORBY if you can only view or run it, so the label never promises something your role cannot do. See Limits and safeguards.
What ORBY can do
Add, change and remove nodes, and connect them. Every change appears on the canvas as it happens.
One turn produces one committed workflow and one canvas update, however many changes it made. You never watch a half-built intermediate state flicker past.
Set an agent's persona, instructions, tools, output schema and knowledge bases.
ORBY validates an agent's configuration against the runtime's own schema before anything is written, so an agent it builds is runnable, not merely saveable.
ORBY attaches the project's existing knowledge bases to an agent. It cannot create one.
When no existing base fits, it tells you to create one on the project's Knowledge page and offers to attach it afterwards. See Knowledge bases.
It checks whether a tool is genuinely connected rather than merely registered, and offers a connect form when a credential is missing. It can also tell you a key is already on file rather than asking for it again.
It can start a run, track it, and then read what happened: the status, the error text and the failing step.
It never sees run inputs, and it only sees the runs you are allowed to see. An ordinary member sees their own runs; an admin sees all of them. ORBY is not a second door onto the executions table.
It can run the use case's test cases and read the results. See Testing workflows.
Ask what a node does, what variables are available at a point in the graph, or why it chose a structure. Reading is the floor, so this works even for someone who cannot edit.
How a build goes
You describe what you want
Plain language. "Every morning, summarise my unread email and send the summary out."
ORBY asks, but only when the answer changes the build
That example gets two questions: which address receives the summary, and what time and timezone.
It asks on two triggers only: an irreversible step with an unstated recipient or approver, and two plausible structures with nothing to choose between them. It will not ask for anything it can read from the canvas, the tool catalog, or a run, and it asks at most one question per turn.
A request with nothing to decide gets built straight through, with its assumptions stated. "Search the web and write a summary" needs no questions.
It writes a build plan
The plan lists the steps it intends to build. A plan is written after any questions are answered, not before, so you are not anchored to a guess.
A small plan, up to three new nodes, is built in the same turn. A larger one waits for your approval. See Approval.
It builds, and the canvas updates as it goes
The plan is echoed into every later turn, with a rule not to redesign it. This is what stops the structure flip-flopping halfway through a session.
You save
ORBY does not write agent rows itself. It stages them on the nodes, and your canvas Save writes everything it proposed, all or nothing. See Saving.
Approval for a large build
A build plan is held back for your approval in two cases:
- It creates more than three new nodes.
- ORBY recorded a question it could not decide for you, whatever the size.
The second trigger exists because size alone ran backwards. A vague request produces a small plan, because a model that does not know what to build builds less. The most under-specified request would sail under a node-count threshold while the most carefully specified one got held back.
A held plan is stored as a draft. If you answer the questions, the next turn rewrites the plan from your answers rather than executing the one you did not approve.
Approval is read from what you actually agreed to, not from what the assistant claims. A large first commitment is held even if it presents itself as already building.
Cards and questions
ORBY asks through cards in the panel: a question with options, a connect form, a model setup form, a run form. Answer the card and the conversation continues.
Cards survive a reload. If you close the panel with an unanswered question, it is there when you come back.
ORBY will not offer you a card you could not complete. Before showing a form it checks whether you hold the permission the endpoint behind it requires, and if you do not, it tells you which permission to ask an administrator for rather than letting you fill in a form that would collect a 403.
A connect form is filtered rather than hidden: if you may create a personal and a project credential but not an organization-wide one, the form offers the two you may create.
Saving what ORBY built
The canvas is authoritative for the graph. ORBY proposes agent changes on the nodes, and one Save writes all of them.
| Node state | What Save does |
|---|---|
| A new agent node ORBY added | Creates the agent row |
| An existing agent ORBY edited | Merges the change into the row as it is now |
| An existing agent that a published version runs | Creates a copy, so the published version keeps running the agent it was published with |
Until you save, the panel says the work is not saved yet.
Save is disabled while a turn is streaming, in the UI and on the server, including the keyboard shortcut.
This is not caution. A save during a turn prunes agents the turn has just created but which your canvas does not reference yet, leaving nodes pointing at deleted rows. Wait for the turn to finish, which takes seconds.
If someone else holds a turn on the same use case, your save is refused with a 409 for the same reason.
Two people editing one canvas still last-write-wins on the graph. The guard above closes the destructive case, a prune of live rows, not concurrent editing in general.
Editing the canvas by hand
You can. ORBY reads the canvas at the start of every turn, so a change you made by hand is a change it knows about and will not undo blindly.
The canvas is the authority. If a retry of the same message arrives, ORBY answers from its record rather than re-applying its earlier changes, because you may have edited since.
Starting over
Ask ORBY to clear the canvas. It is one operation, so you do not get a half-cleared graph.
Clearing the conversation is separate and deletes only your conversation with ORBY. It does not touch the workflow.
Super Agent nodes
ORBY can build a Super Agent, and it decides between an agent and a Super Agent on one question: are the steps knowable now?
- Steps you can draw become an agent inside a pipeline.
- One assistant fielding a whole class of requests becomes a Super Agent.
A Super Agent's tools are the project's published workflows, resolved when it runs. So if nothing is published, the tool belt would be empty, and ORBY refuses the node once and asks you first rather than building something that cannot work.
When a published workflow already covers part of what you asked for, ORBY makes the choice yours rather than deciding itself. Rebuilding as an agent what the project already publishes is the waste the node exists to prevent.
What ORBY will not do
A message that is not about the work is refused before it costs a turn. A reply to a question ORBY itself asked is never judged this way.
A turn that reproduces ORBY's persona or its internal rules is replaced with a fixed reply before anything is dispatched, streamed or recorded. See Limits and safeguards.
Attach only. Create them on the project's Knowledge page.
A viewer can open ORBY and ask it to explain the workflow. Edit and run tools are not offered, and are refused if something tries to call them anyway. See Limits and safeguards.
ORBY is limited to node types the canvas can render, which is narrower than what the engine can execute. A plan cannot propose a step it could not build.
Good practice
When ORBY asks who receives something or when it runs, that is the one case where a wrong guess is expensive, because the step is irreversible. Answering gets you a plan built from facts.
Save is blocked during a turn for a good reason, and turns are short.
It can see the status, the error and the failing step. Asking it to diagnose from a screenshot wastes the turn.
A Super Agent's capabilities are the published workflows. Building one against an empty project gives it nothing to call.
It can attach, not create. Having the base ready saves a round trip.
ORBY does one thing at a time and asks at most one question per turn. Three requests in one message get handled in sequence anyway.