Flows and calendar

#What is a flow?

A flow is work that runs on its own when a trigger fires. There are four kinds of trigger. There is one recurring on a cron, a one-off reminder, an event trigger (something happens inside Orbi) and a service trigger (something happens in a service you connected), and the last two are covered below. It does not appear on the board. Every flow belongs to a project and lives in that project's Flows tab. Flows in the left menu shows the flows of every project in one list.

Every time a flow runs, a run record is created. Like a task, a run keeps its own list of steps and records what it did, but it is independent of the cards on the board. A run is in one of three states, which are running, succeeded and failed.

#The canvas: where a flow lives

Clicking a flow opens the canvas. The canvas is where you draw the flow's diagram, and it reads as one sentence: what starts the flow, then who does what.

Trigger cards sit at the top. Just below them is the Start node they all connect to, and the flow's name, its model and its task definition live there. The task definition belongs to the whole flow, so whichever trigger starts it, the same work is done. Below Start come the agent cards that do the work. The plainest flow is a trigger plus Start, and then Orbi's own assistant does the work.

You can drag both triggers and agents from the list on the left. A trigger you drop connects itself to Start, and any agent with no incoming connection is fed from Start too. That is why no card can end up stranded on the canvas, attached to nothing.

The agent list starts with the agents Orbi runs itself. Agents that connect from outside cannot be placed in a flow, so they sit folded at the bottom under "Connecting from outside" and open with a click. Once there are enough agents, a search box appears above the list; it filters by name or title and finds the externally connected ones too.

Squads are listed below the agents. When you drop a squad on the canvas, that step is run by the squad rather than a single agent: a coordinator splits the step's work between the squad's members that run in Orbi, with two or more members one member critiques another's work, and the step's output goes on to the next step. The card shows the squad's members stacked. Members that run on their own device take no part in a flow step, because a flow cannot wait for a device. More in Squads.

The buttons that run the flow sit together in the bottom left corner of the canvas: Run, Test and Pause. Next to them the flow's current state is written out — when it last ran, whether it is running now, and if it is paused, that its trigger no longer fires. Clicking that line opens the Runs tab on the right. While the flow is paused this corner turns amber and Run becomes Resume.

Tidying the cards. In the bottom right corner of the canvas, next to the zoom buttons, sits a Tidy layout button. If cards have piled on top of each other or the wires cross, this button lays the diagram out again: every card moves under the card that feeds it, cards fed by the same card line up side by side, and none of them ends up hidden under another. The new arrangement is not permanent right away. If you don't like it, click the notice in the corner to go back to the old layout; if you do, press Save.

The top bar keeps the flow's name, Save and a ⋯ button. Focus, Zen mode and deletion live in that menu.

Zen mode. Open it from the ⋯ menu in the top bar and the canvas fills the screen. The left menu and the top bar slide away, and the parts list and the settings drawer move on top of the canvas, where you open and close them as you like. The run buttons stay in the bottom left corner, so you can run the flow in Zen too. It is for seeing the whole diagram of a large flow. Leave with Esc or Exit at the top right.

• Drop an agent onto another agent. The agent you dragged runs after the one you dropped it on, and its card settles below it. This works the first time you drag from the list on the left as well, so you can drop the agent straight onto the card you want it connected to. You can also draw connections by hand from the dots on the edge of a card. A connection that would create a loop is not made.
• Click an agent card. The right-hand panel opens with a summary of that agent and the Instruction for this flow only field. What you write there does not change the agent's own definition, it is added on top of it in this flow alone.
• The same panel has a "This step cannot write to the board" option. When ticked, that step cannot write records, tasks, files or calendar entries; it passes what it finds to the next step through its output only. It is ideal for research and classification steps, because it gathers all writing into a single step at the end of the flow and stops the same information from being saved twice. Reading and web search are not affected. A ticked card shows a "read-only" badge.
• Double-click. You go to the agent's own page.
• Click a trigger card. The right-hand panel opens with the settings of that trigger only. Once it has been saved, a trigger's kind cannot be changed, and if you want another kind you add another trigger.
• Click an empty spot. The panel goes back to the flow itself, showing its name, task definition and model.
• The Runs tab lists the history, with details below.
• Your changes are not stored until you press Save. If something is missing, the Save button does nothing and the panel lists what is missing, one item at a time. If you try to leave the page without saving, you are asked first.

There are deliberately no request or data-transformation cards on the canvas. Expertise lives in the agent's instruction, and the canvas only shows who runs after whom and under what condition.

#What does each agent see?

When an agent card runs, this is what it gets.

• The task definition, meaning the whole of the text you wrote on the Start node. So every agent knows the flow's goal.
• Its own instruction, meaning the text you wrote on that card, which applies in this flow only.
• Its place in the flow, meaning the names of the agents that run before it, right after it, and further down the flow. It is told plainly not to do the work of any later step, and to hand that on through its output.
• The output of the cards whose arrows point at it, labelled so you can tell who produced what.
• The data of the event that started the flow, so for an incoming message that is its sender, its subject and an excerpt of the body. The excerpt is taken from both the beginning and the end of the message, so the contact details in a signature show up too. In very long messages the middle is cut, and the cut is stated.
• The workspace description, the project's purpose, the list of collections and the relevant memory notes.

What it does not see is what the sibling cards running at the same time are doing, and their output. Two parallel branches neither wait for nor see each other.

This is why the task definition and a card instruction do different jobs. Put the flow's goal in the task definition and each card's share of it in that card's instruction. If you list four jobs step by step in the task definition, every card reads all four.

If you connected an agent to Start you can leave the task definition empty, because the card instructions carry the work. Writing the same text into both the task definition and a card is unnecessary, because the card reads it twice and a longer instruction loses focus. The task definition is there only for the context the cards share, so it holds whatever all of them need to know. With no agent on the canvas the task definition is required, because nothing else is left to describe the work.

Task definition (Start):
  Turn incoming requests into lead records so the team finds them ready.

Researcher card:
  Only search and list what you find. Do not write to a collection, do not open tasks.

Writer card:
  Summarise the findings you receive and write them to the Leads collection.

If an agent needs to read all of a very long message, it must have been given the mail service's connection (the connections section on the agent's page). Without it, it gets the sender, the subject and the excerpt above, which is enough for most work.

#Agents do not invent information

An agent writes only values that are actually there in its input or in what a tool returned. If there is no phone number in the message, that field stays empty and no realistic-looking number is produced. It lists what is missing in its output, and you fill the gaps if you need to.

This is a deliberate choice. An empty field tells you nothing, while a filled one is taken as true, so only values that are genuinely known get written.

#Conditions: when should a branch run?

Branches that run in parallel do not all have to run every time. Hover over a connection, click the "+ condition" button that appears, and write it in your own words.

if the customer is complaining

A connection with a condition is drawn as a dashed line with your sentence on it. When the previous step finishes, Orbi judges its result against that sentence, and if the sentence does not hold the branch does not run. That lets you decide inside a single flow, so you can say "if the feedback is negative, write to the support team, otherwise just record it."

Writing the condition as a sentence instead of filling in a form is deliberate. Results are text, and a rule shaped like "field equals value" cannot express most of them.

Here is what to know.

• A condition can also go on a connection leaving Start. What is judged there is the data the trigger brought, such as the body of an incoming email, or the fields of the changed record on a collection trigger ("if its status is won").
• If more than one path leads into a step, it runs when at least one of them passes. Otherwise a single "no" would silence every branch below it, and deciding anything would lose its point.
• Conditions leaving the same step are read together. When sentences like "if it is an HR matter", "if it is a sales enquiry" and "other" are options of one decision, only the best-matching branch runs; independent properties such as "if it has an attachment" and "if it is in English" are judged separately and several may pass. If the previous step's output already states the decision ("Category: HR"), that statement is followed.
• "if X" and "if not X" are not two halves of a whole. The condition is asked of the previous step's result, not of the world. If the result does not settle the matter, neither sentence can be confirmed and neither branch runs. When every exit from a step is conditional, the canvas warns you.
• The easiest way to make the decision predictable is this. Put a clear rule such as "write STATUS: yes or STATUS: no on the first line of your output" into the previous step's instruction, then look for it in the condition. The decision then comes out the same on every run.
• If no decision can be made, the branch does not run. Not running it leaves a gap that shows plainly in the run history, and that is easier to correct than the wrong branch sending an email out of the building.
• No branch is skipped silently. The run history keeps three outcomes apart, namely the condition held, the condition did not hold, and no decision could be made. A step that did not run is listed with its reason, and the run summary says how many steps did not run. On a selected run the condition label on the canvas shows ✓, ✗ or ! as well.
• Judging a condition spends credit too. It is a small operation, but it appears as its own line in the usage breakdown.

#Test: a dry run

The 🧪 dry run button really runs the flow. The model works and reading tools work on real data, but every tool that writes outward (opening a task, writing a record, sending mail or a message) is not carried out, and a "this is what I would have done" preview takes its place. The run summary lists those actions as "→ it would have done this: …" lines, and the cards on the canvas are still painted green or red. When you test an event trigger, the rehearsal uses the data of the last event that actually happened. A dry run does not close a one-off reminder, and it appears in the history with a 🧪 mark. Because the model really runs, it spends as much credit as a normal run.

#Run history: what happened, and when?

The Runs tab shows a flat list. Each run is two lines. On top sit its state, its time and its measurements ("7 steps · 17 s · 101.6K tokens"), and below it what started it, such as the sender and subject of an incoming message. You usually find the run you are looking for from that second line.

Clicking a run opens its detail, and only one stays open at a time, so the story is always read from the same place. The most recent run is open without your doing anything, but if you close it, it stays closed.

#Show it on the canvas

The switch at the top of the list projects the selected run onto the canvas. While it is off, the canvas shows the flow itself, so the cards cannot mislead you while you edit. Turn it on and the cards are painted green, red or faded according to what happened in that run, the paths that ran come alive, and the condition labels show their decisions. Above the canvas it says which run you are looking at, and one click there takes you back to the flow.

#What is in the detail?

The detail that opens reads as one story. First comes what was done, then what did not run, and last what came out.

The work done is laid out as a timeline. Each step's title is the agent's own sentence about its work ("Looking for the account and its owner", say), its duration sits on the right, and below it a grey line says what came out of that step. If a step fails, the reason is written in red under the line.

Steps that did not run because of a condition are listed one line each, with the reason. The agents' full outputs, the actions a dry run would have taken and the checklist are long, so they sit folded, and you click their headings to open them. Intermediate steps such as ticking a checklist are hidden by default so they do not drown the story, and the "intermediate steps" link brings them back. While a run is under way the timeline extends itself every few seconds. Once the run ends it becomes permanent, so you can open it months later and read the same story.

You find the same presentation on a task card (the "now: …" line shown while an agent works, and the Trail tab) and in chat (the "N steps · M tools" block above the answer), because all three speak the same language.

#Setting the cron

Drag the "On a schedule" trigger from the list on the left onto the canvas, then click its card and set it up in the right-hand panel. You pick a daily, weekly or monthly frequency, then the time. The time zone belongs to the whole flow and is picked in the flow panel.

Writing the time as a free sentence is deliberately not offered. "Every Monday morning" does not say whether that means six or nine o'clock, and in work that runs on its own the price of that vagueness is a wrong run you notice months later.

#One-off reminders

Not every job repeats. For requests like "remind me tomorrow at 11:00 to merge that task", drag the "Once, at a specific time" trigger onto the canvas, click its card and enter a date and a time. The card says in plain words what it understood.

A reminder runs once at the moment you set, then closes. It drops off the list into the Past reminders section, together with a link to the task it produced. When you say "remind me tomorrow" in chat, the agent sets that up as a one-off reminder too, and it does not create a job that repeats every day.

Here is what to know.

• Run now runs the reminder without waiting and closes it.
• If the moment passes while a reminder is paused, the job still runs when you resume it. But once that moment is more than 24 hours old it is not run any more and is marked "missed" in the history. A missed job is never swallowed silently.
• A finished reminder can be set up again by editing it and giving it a new date.

#More than one thing can start a flow

You can add as many triggers to a flow as you like, for example every morning at nine and whenever a new task is added in the space. Open the flow and drag the trigger you want from the list on the left onto the canvas, and it connects itself to the Start node.

Each trigger is managed on its own. You click its card to open its settings, pause them separately, give each one its own narrowing and remove them one at a time. Pausing one trigger does not affect the others.

Here is what to know.

• Whichever trigger fires, the same task definition does the work. What the flow does is single, and the triggers only say when you start it.
• Only one run is under way at a time. Even if two triggers fire at the same moment, the flow does not run two copies.
• The last trigger cannot be removed. A flow with no trigger can never run, and to delete the whole flow you use the Delete button in the top bar.
• The same event cannot be added twice, because listening to the same thing twice would do the work twice. The measure is not the kind of trigger but which event it matches. Triggers listening to two different collections, or to two different target states, can stand side by side, because they never meet on the same event. If one listens to something the other already covers (one watching a single collection and the other watching all of them, say), it is blocked.

#Event trigger: run when something happens

The third kind of trigger hangs on an event rather than on time. Each event has its own card in the list on the left, and you drag the one you want onto the canvas. There are four events.

Leaving a narrowing field empty means "all", and you can narrow it later. When the event happens a run opens, the summary of the event enters the run as data, and your task definition says what to do. For task events that summary is the task's number and title. For a collection event it is the changed record's number, its name and its fields, which is what lets you put a condition such as "if its status is won" on a connection leaving Start. Long text fields are shortened, and if the record is very wide it is stated that some fields did not fit into the summary. The steps can always read the whole record themselves.

There are three protections against chained triggers and all of them are automatic. An event produced by a run cannot trigger the same flow again, chained triggers are cut off after 30 steps, and no new run opens once the credit ceiling is reached. Legitimate chains (open a task, then let another trigger handle it) run freely.

#Service trigger: when something happens in a connected service

The fourth kind looks outside Orbi, because an event in a service you connected starts the flow. Drag the "When something happens in a connected service" card from the list on the left onto the canvas, then click it and choose which event and which account it should watch.

Slack, GitHub and Telegram triggers differ from the rest in one respect. These three services tell Orbi themselves when something happens, so they run without waiting. The other services are asked at regular intervals, so a delay of a few minutes is normal there.

Here is what to know about the GitHub trigger.

• A draft PR does not count as "opened". A draft triggers when it is marked ready for review, so a flow narrowed to the "opened" event does not run for drafts in vain.
• Write the event types separated by commas: opened, ready_for_review, merged, closed. Leave it empty and all four trigger.
• The flow's agent reads the diff with a tool. The trigger only carries the PR's number, title, branch and address; a flow that says "review the PR when it opens" fetches the diff with the GitHub connector's tools. For that, the agent in the flow must have been given access to the GitHub connection.
• A PR that mentions a card is linked to the card at the same time. Even without a trigger, the PR's status shows on the card; see Tasks.
• The review trigger runs once per review. Even if a review carries forty inline comments, the flow starts once; the flow's agent reads what was asked line by line with the GitHub connector's review-listing tool. Narrow the review result with commas: approved, changes_requested, commented. A "fix the PR when changes are requested" flow is built on this trigger.

A few details help with Slack triggers.

• Orbi must have been invited to the channel. It cannot listen to a channel it does not belong to.
• You can narrow it down by the channel's name or its id. Typing #sales is enough, and upper and lower case and accented letters make no difference.
• Messages Orbi writes itself do not trigger anything. Otherwise the flow could take its own reply in the channel for a new event and feed itself forever.
• A command and a shortcut feed the same trigger. Both mean "I called it on purpose", and separating them would split the flow in two for nothing. Whoever typed the command sees the run start straight away, where they typed it.

Here is what to know about Telegram triggers.

• The bot must have been added to the chat. In groups a bot only sees the commands addressed to it by default; if you want it to listen to every message, turn off privacy mode for that bot in BotFather.
• You can narrow it down by the chat's name or its id. Typing @channel_name is enough, and upper and lower case and accented letters make no difference.
• Messages the bot writes itself do not trigger anything. Otherwise the flow could take its own reply in the chat for a new event and feed itself forever.
• The flow writes the reply. The trigger carries the chat's id, and the agent in the flow answers in the same chat with the Telegram connector's send-message tool. For that, the agent must have been given access to the Telegram connection.

Here is what to know about the Google Meet trigger.

• Transcription must have been on during the meeting. If it was off, the meeting never triggers.
• The transcript is not ready the moment the meeting ends. Google produces it a few minutes later; Orbi knows this, holds the finished meeting for a while and fires when the transcript arrives. If no transcript appears within half an hour, that meeting is dropped.
• The trigger carries part of the transcript, and the flow's agent fetches the whole of it with the Google Meet connector's transcript tool.

Here is what to know about every service trigger.

• A trigger watches from the moment it is set up. It does not run for the messages already in your inbox when you switch it on, because otherwise switching a trigger on would start dozens of runs.
• The service has to be connected (Settings → Integrations). If it is not, the event still appears in the list but says so when you pick it.
• A personal connection cannot be used. A trigger runs on its own, at a moment nobody started, while the one guarantee a personal connection makes is that it is loaded only in runs its owner started. So only workspace connections can be picked on a trigger.
• Mail the flow sends itself does not trigger anything. A flow that sends an email and listens to the same mailbox could feed itself forever, so items written by the connected account are skipped.
• Events queue up, they are not lost. A flow carries out one run at a time. If a new event is found while the previous run is still going, it waits in line and is handled as soon as that run ends, in the order the events arrived. The same holds when your credit runs out, so the event is put on hold and runs once the credit is renewed. Waiting in line is particular to service events, because a scheduled run is skipped in the same situation, and the "Overlap behaviour" section below explains that.
• At most 50 events can pile up in the queue. Reaching that number means the flow cannot keep up with the events coming in, so review the trigger's narrowing.
• The check runs once a minute. The flow runs a few minutes after the event, not instantly. A trigger that finds nothing for a long time starts to be checked less often, the interval stretches to five minutes at most and tightens again with the first event. There are two exceptions. "When an event is about to start" triggers are always checked frequently so a meeting is not missed, and Slack, GitHub and Telegram triggers are not checked at all, because the news comes from the service itself and there is nothing to wait for.

#Fire and forget

A run creates its tasks and ends. What happens to those tasks afterwards is not its concern.

That distinction matters, because a run's job is to start work rather than to finish it. The tasks it creates land on the board, enter the normal workflow and go through their own reviews. A run showing succeeded means "the work was created", not "the work is done".

#Checking in on an existing task

A flow does not only produce new tasks. If your prompt points at a task, it can write a comment on it as well. The typical use is checking in on a job at intervals and nudging its owner.

Every Monday at 09:00:

Check task @task.50. If it is still in "To Do", add a comment
for @user.deniz saying "check where this stands".
If the task is done, do nothing.

Name the task by its number (@task.50), because a flow has no comment stream of its own, so a comment is always written on a specific task. In the same way it can change the task's state or assign it to somebody else. A @user.<name> mention in the comment sends that person the usual notification.

Prefer this pattern over having a new task opened at every check, and the board stays clean.

#Overlap behaviour

A flow carries out one run at a time. What happens when a new trigger arrives while the previous run is still going depends on where that trigger came from. There are two routes, and the distinction is this. An event happens only once, whereas a schedule comes round again.

Put on hold: service triggers and calls from outside. Something that happened in a service you connected (new mail, an event about to start, a Slack message) and a request that lands on the flow's own address (Collaboration) wait in line, and are handled in the order they arrived as soon as the run ends. These cannot be fetched back if they are missed, so dropping them would lose data. The queue holds at most 50 events per trigger.

Merged: event triggers. An event trigger (a task opened, its state changed, it was assigned to someone, a record was written to a collection, a watcher on your device reported something) that arrives while the previous run is still going is not lost: it goes into the flow's waiting bucket, and as soon as the run ends one more run is started for everything in the bucket. The agent sees the events together: how many arrived, the first and the last, the first twenty in full. The bucket holds at most 100 events or one hour; if it overflows the oldest are dropped and that is written into the run that starts. So five invoices landing one after another in a download folder are handled in one run, and a chatty log file cannot open a run per line.

Skipped: schedules. A recurring schedule or a one-off reminder is skipped if it arrives while the previous run is still going. Piling them up would gather dozens of copies behind a job that has slowed down, grow the cost and write the same data over and over. A schedule comes round again at its next turn anyway.

Run now neither waits nor is skipped. If you press the button while the previous run is going, Orbi tells you a run is already under way and does not open a second one.

#Pause, resume, run now

• Pause / Resume stops the flow temporarily without deleting it.
• Run now triggers it by hand without waiting for the cron. It is the handiest way to see the output while you are setting a new flow up.
• The run log shows every past run, its state and its output.

#Flow steps on the agent's computer

In workspaces where the agent's own computer is on, flows use the computer the way cards do. In a flow with steps, each agent step decides before it starts: work that one reply answers from what it already has stays in Orbi, and research, writing, files or analysis go to the agent's computer. A flow without steps makes the decision once, for the whole run. A scheduled run and a run you start by hand take the same path.

• Every run starts with a clean folder. The steps of one run share it: the next step reads the file the first step left. The next run of the flow does not see it. The folder is deleted 30 days after the run ends; the agent saves the real deliverable to Orbi Files.

• A step's output is the agent's last message. The next step gets it the way it gets the output of a step that ran in Orbi.

• Nobody is waited for. Nobody watches a run, so the agent does not stop to ask; it makes the reasonable choice and writes what it assumed in its last message.

• Whose permissions it uses. A run you start by hand acts for you; a scheduled or triggered run acts for the person who set up the flow. If that person has left the workspace, the run does not start, it closes as failed and the workspace admins are notified. A member can start it on their own behalf with Run now.

• The status line. Open a run's detail in the run history and you see the same status line as on cards: queued, preparing, running, finished or why it stopped. The stop menu is there too.

• A squad step and an agent given work. When the coordinator of a squad step picks the computer, the squad's members work on the run's computer, in the same folder at the same time; the coordinator plans in Orbi and shares the work among them. An agent the run gives work to makes the same decision and, when it picks the computer, works on the same computer. A card the agent opens on the computer shows in the run's list of cards, like a card opened in Orbi.

A dry run and a read-only step always run in Orbi.

#Duplicate

You can duplicate a flow, cards and wires included — if you want a new flow with a small difference, you do not have to start from scratch. The copy is born paused, so you review it and turn it on yourself. If the flow has an incoming webhook address, the copy gets its own new address; the original address stays as it was and keeps working. The duplicate button is in the ⋯ menu at the top bar.

#Runs do not remember each other

A run does not remember the run before it. Past output is reachable only through storage, so a run writes its output to a collection and the next run reads that collection.

That also brings in the mechanism that prevents repeats, because semantic duplicate prevention works on every write to a collection, so the same news item is not added a second time.

#Flow Builder: build it by chatting on the canvas

The Builder panel on the left of the canvas is a building partner that puts the flow together by chatting with you. It is optional and opens with the Flow Builder button in the top bar (while it is open it takes the place of the parts list). You describe what you want in your own words ("every Monday at 09:00 research a topic, then write a draft, and if the editor approves mark it ready to publish"). If it needs to, the Builder opens a question card with options (what should start it, which agent does which step, in sequence or in parallel, where the result goes), then draws the trigger, the cards and the wires onto the canvas live. The card's instruction, the wire's condition and the shared task definition on START fill in front of your eyes.

When you say "after this step, do that as well" on an existing flow, the cards already there are kept, because their run histories are attached to them. A new card is added, and a wire condition is written if one is needed. When a card or a wire is added, the canvas lays the diagram out again on its own, so the new card never lands somewhere you cannot see; if only an instruction or a condition changed, the cards stay where you put them. Every change you make on the canvas by hand is visible to the Builder in its next message, because the two of you are talking about the same canvas.

You can show the flow instead of describing it. The attach button in the message box adds a diagram image or a process document, and you can also point at a file you uploaded earlier by typing "@" and its name. The Builder sees the image and reads the text of the document, then draws the steps it found onto the canvas. If there is a case where it cannot read the file, it tells you instead of guessing the content.

Here is what to know.

• The Builder does not save. You look the canvas over, correct it by hand if you want to, and press Save yourself. The canvas's "worth checking" notes are in front of the Builder too.
• The conversation belongs to the flow and it lasts. After you save, after you leave the page and come back, or when you open it on another day, the conversation is where you left it, and with the Builder you always carry on from where you stopped on that flow. Your teammate sees the same conversation. To start with a new context, use the Clear the chat button in the panel, and the canvas is untouched.
• Only agents that run inside Orbi in this workspace are used as cards. If there is no suitable agent the Builder tells you to set one up first, it does not invent one. A service trigger is only suggested when a service is actually connected.
• Every Builder message is a normal AI run and it comes out of your credit.

#Building a flow from chat

You can build a flow without touching the canvas as well: tell Orbi (or an agent) in chat what you want. A sentence like "every Monday at 09:00 research a topic first, then write a draft, and if the editor approves mark it ready to publish" is enough. The agent will not build the flow before it knows its three parts:

• The trigger, meaning when or on what event it starts (a schedule, a one-off, an event in Orbi, an event in a connected service, an inbound webhook, or news from a connected device).
• The steps, meaning which agent does what. If you described several roles, each role becomes its own card, and if you did not name the agent it asks, or says plainly which one it is proposing.
• The connections, meaning the order of the steps and conditions such as "if the editor approved".

It does not invent the missing piece. It asks short questions in one round (how often, which agent, in sequence or in parallel) and then builds. For a complicated setup it draws the diagram first and asks you to confirm. The flow it builds appears on the canvas just as described, and you can carry on editing there. When you say "add a step to this flow", the existing cards are kept and the new card and its wire are added.

#A typical scenario

Every morning at 07:00 (Europe/Istanbul):

Search for industry news, summarise the most important items,
add them to the @collection.content_ideas collection without duplicates,
open a separate task for the best 3 ideas and assign it to the content writer.

This single flow does the following. It runs a web search, summarises, writes structured data while skipping repeats, creates tasks and assigns them. When you open the board in the morning, three tasks are waiting.

#Calendar

The calendar is a unified view in the style of Google Calendar. It shows three things on one screen.

• Tasks' due dates
• Flow runs
• The events you add by hand

#Views

The buttons at the top right switch between four views.

In the day and week views a red line sits across today: the moment you are in. The line refreshes itself every minute.

Today is marked with a background of its own in every view, and the day number sits inside a filled circle. The Today button at the top left (or the T key) always brings you back to today.

#A crowded day

In the month view, when a day holds more items than fit, a line like +3 more appears at the bottom of the box. Click it: the whole day opens in a small panel. From the panel you can click an item to go to its detail, open the day on the hour grid with the Day view button, or add a new event straight away.

How many items fit depends on the height of the window, so the larger the calendar, the more the box shows.

#Adding and moving events

There are three ways to add an event.

• The Add event button at the top left (or the N key)
• The + sign that appears when you hover over a day in the month view, which opens the event on that day
• Clicking an empty spot on the grid in the day or week view, which opens the event at the hour you clicked

Drag to move. Dragging an event to another day keeps its time and its duration, and dropping it on another hour of the grid in the day or week view changes its time as well (in 15-minute steps). Only the events you added yourself can be dragged: a task's due date is a field of the task (changed in the card's drawer), and a flow run is the flow's reflection on the calendar (changed on the flow's trigger).

#Who added the event

When you click an event, the card that opens says who added it, below the title and the description. If a teammate added it you see their name; if an agent added it you see its name and its title. On a crowded calendar, "who put this meeting here, who do I ask" is answered by the card itself.

Task due dates and flow runs have no such line: they are not added to the calendar by hand, they are how a record kept somewhere else looks on the calendar.

#How long an event lasts

An event is not only a starting time but a span. Next to the start in the form there is an Ends box, and a new event opens set to last an hour. You can write another duration, or empty the box and choose not to give an end at all.

When you change the start, the end shifts by the same amount: moving a meeting two hours later does not mean shortening it.

Duration reads on the calendar like this.

• In the day and week views the height of the box matches the duration. A long meeting looks long on screen, and whether the afternoon is full is clear at a glance.
• The shortest way to change the duration is to drag the bottom edge of the box down or up (in 15-minute steps). You do not have to open the form.
• In the month view an event spanning several days is drawn as a single band running across the days it covers. If the band runs past the end of the week, its end looks cut off and it continues on the next week.
• In the day and week views events spanning several days sit in a separate All day strip above the hour grid, and the grid itself is left for work that fits inside one day.
• In the agenda such an event appears as a single line on the day it starts, with the start and end times written one under the other on that line.

When you tell an agent "a two-hour design meeting on Tuesday at 14:00" or "training from Monday to Wednesday", it writes that as a single event with its duration.

#Filtering and searching

Filters on the left turn the three types on and off separately, and next to each one it says how many of them fall in that range. Flow runs are off by default, because a flow that runs often can fill the calendar on its own.

The Scope box lets you look at a single board instead of the whole workspace.

The search box (or the / key) filters inside the calendar: items that do not carry your word in their title or description drop out of the view. You do not have to look day by day to find one meeting in a crowded month.

The mini calendar at the bottom left is the shortest way to another day: the coloured dots under it say what is on that day (event / task / flow).

#Keyboard

#Task due dates

Tasks whose due date has passed and that are still unfinished show red on the calendar, and the ones coming up are yellow. Clicking a task line does not take you off the page, because the task opens in the column on the right of the screen.

Time zone: times are stored in UTC and shown in your local time. If your team is in different cities, everyone sees the same moment in their own time.

Agents can create, update and delete calendar events with the create_calendar_event, update_calendar_event, delete_calendar_event and list_calendar_events tools. So you can tell an agent "when you have finished this research, put a block on the calendar for the presentation".