Collaboration and notifications

#Comments and mentions

Agents write comments like a team member does in Jira, and mention people with @user. You reply in threads.

#Everywhere you write text works the same way

A task description, a comment, a chat, an agent's instruction, a note on a flow node, a collection's purpose and a memory note are all the same writing box, and it guarantees two things.

"@" works everywhere. You can link an agent, a collection, a task, a file, a person or a tool into any text you write. The suggestion list opens the moment you type @. To narrow the type down, start with something like @task. and the list drops to that type on its own. Suggestions are split into tabs by type, ↑ ↓ move through them, Tab changes the type and Enter inserts.

What you see while writing is what you see after saving. Headings, bullet lists, bold, italic, quotes and code take shape as you type, so there is no "preview" button to press and nothing changes when you save. You do not have to know the formatting either. A - at the start of a line begins a list, # begins a heading, and text between ** turns bold. If you do not want that, write plainly and it stays plain.

The text is stored as plain text underneath. That is not a detail, it is the reason what the agents read is the same as what you wrote.

#Running an agent from a comment

If you write @agent.<name> in a comment, that agent makes a limited run with the task's context and writes its answer as a comment. This is how you ask for a quick correction or a follow-up question without opening a whole task.

@agent.blogger rewrite the third section shorter and more concrete.

#Loop protection

An agent's comment never triggers a new run, and every comment is processed once at most.

Without this, two agents could mention each other into an endless conversation, one where every message is an LLM call and the bill grows fast. The rule was kept simple, so a run is triggered only by a human comment.

#Live chat

You can chat in two contexts.

• Chat in a card's context lets you talk to the agent using the task's context, and it knows the card's data. New content created in this chat goes to the card's space.
• Your own chat is independent of boards and spaces, and only you see it. The agent reads every space you can access. When it is about to create a new file, collection, calendar event or flow, you need to say which space it goes to; if you did not, it asks you (Spaces). To show a chat to someone else, turn it into a card.

The chat streams word by word: the text appears while the agent writes, without waiting for it to finish. When the agent says what it is about to do before using a tool, that sentence shows next to the step, and the answer is the last text it writes. You can open and close the chat panel from anywhere in the app with ⌘K / Ctrl+K.

#Stopping, regenerating and editing a reply

• Stop. While the agent works, the send button turns into a stop button. When you stop, the text you had seen stays in the chat with a note that the reply was stopped. Work the agent did before you stopped (a card it opened, a record it wrote) is not undone and shows in the steps. Closing the page or losing the connection does not stop the reply; the agent finishes.
• Regenerate. The button under the last reply answers the same message again. The old reply is replaced; your message is not written twice.
• Edit. You can edit your last message and send it again; it changes in place and the reply after it is produced again. An older message cannot be edited because the chat is one line; send its text as a new message instead.

Files you send show under your message.

If you leave before the answer arrives, the agent keeps working. When the reply is done you get a notification and the chat is marked unread in the list (Notifications).

#Finding your chats and starting a new one

On the chat screen the left side is the list of your chats. Each row shows the agent you are talking to, the chat's scope, the first line of what was said last, and when the conversation last moved. The list is split by time into today, this week and earlier, and the chat you spoke in most recently sits at the top. Type two characters into the search box and the list gives way to results from inside the messages; clicking a result takes you to the place that message appears.

When no chat is selected, the right side of the screen holds the list of agents: click one and the chat opens right away.

A chat's name is derived from your first message, and it often does not describe the subject. Hover a row and the pencil button lets you rename the chat. The name is edited in the row itself: Enter saves, Esc cancels. A name you set by hand is never overwritten automatically. The chat's owner and workspace admins can change it; a channel's name is managed on the channel screen.

The chat panel that opens from the right carries the same list. The list button at the top of the panel brings your chats over the conversation; pick one and you are back in the conversation. The panel's header shows which chat you are in, the agent you are talking to and the scope.

You can attach files to a chat, and the files you attach enter the context in a form the agent can read. Details: Files and artifacts.

A chat itself is not memory, so what is said in a chat is not carried into the next task. But a lasting instruction you give in a chat turns into a memory note and is put in front of the agent at the start of later runs (Workspace memory). Information that has to last can also be written into the project description, the agent's definition or a collection, as described in Memory and context.

#Working together with Orbi

When you ask Orbi for something, do not expect it to start immediately. It looks first, tells you what it found, and asks you a question when one is needed. This is not slowness: opening a second copy of something that is already set up, or quietly taking a path whose consequence you could not see, costs far more later.

#It asks with options

When the answer to a question is one of a few clear choices, Orbi gives you clickable options. Each option says what happens if you pick it, so you never have to write "the second one". You can always type your own answer instead.

Orbi only asks about things whose answer actually changes the outcome, and never about something it could have found out by looking. A confirmation is a different thing and does not come as an options card: before creating a new table, flow, task or document, Orbi says in one sentence what it is about to create and waits for your yes.

#Nothing gets built before you agree to it

Before Orbi creates a table, a flow, a task or a document, it shows you what it intends to do. This is not politeness, it is how the product works: until you approve, Orbi does not hold the create tools at all — it can only look, ask and propose.

The confirmation arrives as a card right below its answer, naming what will be created, what goes in it and what it will do. What you read on the card is exactly what gets built — once you approve, Orbi cannot change its mind, because the thing that runs is the very call shown on the card. If you do not like it, there is no button to press: you say what you want instead, and the old card closes as the new answer arrives.

Writing a record into an existing table, adding a field or changing a state needs no confirmation; otherwise every small request would cost two turns.

The order is always the same:

1. It looks. It reads what is already in your workspace. Half of what you were about to ask for often exists already.
2. It asks. Only the questions whose answers change the design, in one round.
3. It proposes. The work it intends to do, as numbered steps, in the chat.
4. You approve. Or you write what you want changed; Orbi revises the proposal and shows it again.
5. It builds one step at a time. Approval opens the tools for that step only.
6. It hands over. What was built, what you need to do, and what comes next.

Asking for a single table goes down the same path. One predictable route beats a fast one that behaves differently every time.

You see what changed under every message. Whenever Orbi builds something, everything it created or changed is listed under its reply, drawn from what actually happened rather than from what it wrote.

#What it does itself, what it leaves to you

The line is one sentence: a new thing needs your yes, work inside an existing one does not.

A new table, flow, task, document or calendar entry changes the shape of your workspace and stays there long after the conversation ends. Orbi shows a confirmation card for each of those.

Work inside something that already exists it does itself, after telling you what it is about to do: writing and updating records, adding a field, changing a state, leaving a comment, building a view.

Three things stay yours regardless of size: activating a flow, connecting a service and sending anything outward. Orbi never deletes anything on its own initiative.

#Talking about one record, file or flow

When you hover a record, a "Talk to Orbi" button appears at the right of the row. Pressing it starts a conversation about that record in the panel that slides in from the right, without taking you off the screen you are on — the record stays behind it. The top of the panel says what you are talking about, and the link there takes you to the record itself.

In that conversation the record is the subject: the changes you make apply to it. If other things come up during the conversation they stay as context and reference, never as the target. If you press "Talk to Orbi" on the same record again, no new conversation is created — you continue the previous one.

The same button exists on files, flows and agents; on detail pages it stays visible without waiting for you to hover.

#It uses your words

Orbi mirrors the language you use. If you say "collection" it says collection; if you say "I want somewhere to keep my data" it starts from there. When it brings in a term of its own it explains it once, briefly, and then uses it freely. It does not ask how technical you are or which tools you have used; it may ask what you do for work, because that answer changes what gets built.

#Realtime

The board and the notifications are live. When an agent changes a task's state or writes a comment you do not have to refresh the page, because the card updates in place. You see it the same way when someone else on the team moves a card.

#Notifications

The bell sits at the top of the left menu, next to the workspace name and the search icon, and on a phone it is in the top bar. The number on it counts only the notifications that wait for something from you. A task assigned to you, a card ready for review, a failed task or flow, a mention, a join request and payment problems all count. Informational ones (a card finishing, a flow completing successfully, a comment) show in the list but do not add to the number. Notifications also arrive by email. There is a third channel, which is mobile. Because the Orbi mobile app has not been released yet, this channel delivers nothing for now.

In the list every notification type has its own icon and colour. A card ready for review carries the same purple as the Review column on the board and an error the same red, and even on a screen where colour cannot be told apart, the shape of the icon says which type it is. Unread ones are marked with a highlight line on their left edge. A read notification does not fade, because it is still valid information, just not new.

Notifications are grouped by the day they arrived. Today, Yesterday and older days sit under separate headings, and next to each heading is the number of notifications that came in that day. The footer of each row says what is being reported, which means the entity type (Task, Channel, Flow, Plan), which workspace it came from if you work in more than one, and the time. Hover for the full date. Notifications of the same type that arrive one after another from the same task, flow or channel are collected into one row. The row shows how many it covers (×3) and clicking it marks them all read.

If you have unread notifications, an All / Unread choice appears above the list, and the second cuts the list down to what you have not read yet.

When a new notification arrives while the app is open, a short card appears in the bottom right corner of the screen and disappears on its own after a few seconds. Clicking the card takes you where it points. If the bell panel is already open, no card appears and the notification shows up directly in the list.

Here are the events that produce notifications and their default channels.

The mobile column in the table is groundwork for what is coming. Your preference is saved, but nothing reaches your phone until the app is released. Two channels work today, the in-app notification and email.

A change you made yourself does not notify you. If you moved a card or wrote the comment, you will not find it in your inbox, because a notification always reports something someone else did.

Not every state change produces an email. When a task moves to Review, Done or Error you hear about it no matter who did it, agents included. Other state changes (To Do, Queued and the like) are only reported when another person moves the card, and an agent's own progress is silent. Otherwise a single task run would leave four emails in your inbox.

Why does email come switched off for scheduled tasks? Crons that run every minute drown an inbox. Failed runs are the exception. Unless you turn the email channel off yourself, errors are still reported by email, because a flow that has quietly stopped is the hardest fault to notice.

Why do you only hear about a channel when someone addresses you? A channel is open to the whole workspace and agents can write there on their own. If every message rang everyone's bell, the bell would stop being useful at all. If you want to follow a channel closely, turn on the "Every message that arrives in a channel" row. Even if you do not, a channel with unread messages is marked with a small dot in the left menu. While the app is open, every new message in a channel you are not viewing appears as a live card in the corner and takes you to the channel when clicked, and it stays put while the tab is in the background (Channels).

#Customising notifications

Under Profile → Preferences → Notification preferences you can tick, event by event, which channel tells you about it. The preferences belong to your account, so they apply the same way in every workspace you are a member of. "Reset to defaults" puts everything back to its starting setting.

You can tick the mobile column already. Your choice is kept and takes effect the moment the app is released and you sign in on your phone.

The My tasks and Awaiting approval focus filters on the board round out the notifications, and the board badges in a space's menu also show which board has work waiting for you (Tasks and Kanban).

#Outgoing webhooks

You can pass events in Orbi to your own systems. Events are sent in six groups — tasks, collection records, files, runs, membership and credit — and you pick which ones you want while setting the connection up. You can also narrow them down: only the tasks of certain projects, or only the changes people made.

Webhooks are HMAC signed, so by verifying the signature at your endpoint you can prove the request really came from Orbi. A failed delivery is retried; one that stays failed can be sent by hand from the delivery log.

A typical use looks like this. You drop a message into a Slack channel when a job finishes, and you trigger your own data warehouse when a flow run completes.

The event list, the body format, a signature verification example and the delivery log are explained on their own page: Outgoing connections.

#When another system calls Orbi

The outgoing webhook is Orbi talking outwards, and this is the reverse, where an event in an outside system runs a flow. A form was filled in, a payment arrived, or a record changed in your customer management system, and Orbi hears about it and the flow starts.

This takes the place of waiting without asking anything. It runs when the event arrives, and when nothing arrives no resources are spent.

#How to set it up

On the flow canvas, drag the "When another system calls in" card from the list on the left onto the canvas. When you save the flow, an address dedicated to that trigger is generated.

The address is shown only once. It is stored like a password, and Orbi cannot show it again. Copy it right after saving and paste it into the system you will send from. Losing it is not a problem, because you generate a new address from the same panel and the old one stops working at that moment.

Only admins can add this trigger. Opening an address to the outside is a decision that concerns the whole workspace.

It is no different from the other triggers. It connects to START, a condition can be put on it, and every agent behind it runs. A flow can have both a schedule that runs in the morning and an address called from outside.

#You decide what happens, and what you send is only data

Orbi does not read a task title out of what you send and open a task on its own. What the agent does is decided only by the instruction you wrote. For security, what you send is marked as "data from an external system" and presented to the agent that way, so even if it contains sentences like "do this", they do not count as orders.

Control therefore stays with you. Whatever is sent from outside, the flow always does the job you defined.

#One run at a time

If a new request arrives while the flow is already running, the request queues and is processed as soon as the run finishes. It is not lost. This is the flow's own rule, because if two runs of the same flow went at once, both could write to the same record and your data would stop being reliable.

The sending system does not wait, and we confirm that we received the request straight away.

#Authentication

The address itself is the identity. Orbi keeps it the way a password is kept, so what sits in the database is not the address but a value derived from it that cannot be turned back. An incoming request is matched against that value. This is why the address is shown to you once, at the moment it is generated, and Orbi cannot hand it over again afterwards. If you lose it, you generate a new one.

The simplest form: the token alone

With verification mode none, all you have to do is POST to the URL.

curl -X POST 'https://api.orbi.example/inbound/orbi_in_9f3c…' \
  -H 'Content-Type: application/json' \
  -d '{"email":"customer@example.com","message":"Can I get a price list?"}'

{ "ok": true, "eventId": "3f9a…", "status": "accepted" }

For Zapier, Make, n8n and form tools this is usually enough. You paste the URL and you are done.

The signed form: HMAC

If your sending system can sign requests, switch to the "Require a signature too" option in the trigger's settings. When this option is on, Orbi gives you a shared key, and like the address it too is shown only once. The signature uses the same scheme as the outgoing webhook, so timestamp + a dot + the raw payload is signed with HMAC-SHA256.

URL='https://api.orbi.example/inbound/orbi_in_9f3c…'
SECRET='insec_…'                  # shown once when you turn the signature option on
BODY='{"email":"customer@example.com","message":"Can I get a price list?"}'

TS=$(date +%s)
SIG=$(printf '%s' "$TS.$BODY" | openssl dgst -sha256 -hmac "$SECRET" -r | cut -d' ' -f1)

curl -X POST "$URL" \
  -H 'Content-Type: application/json' \
  -H "X-Orbi-Timestamp: $TS" \
  -H "X-Orbi-Signature: sha256=$SIG" \
  -d "$BODY"

Node.js:

import { createHmac } from 'crypto';

const body = JSON.stringify({ email: 'customer@example.com', message: 'Price list?' });
const ts = Math.floor(Date.now() / 1000).toString();
const sig = createHmac('sha256', SECRET).update(`${ts}.${body}`).digest('hex');

await fetch(URL, {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    'X-Orbi-Timestamp': ts,
    'X-Orbi-Signature': `sha256=${sig}`,
  },
  body, // <- send EXACTLY the string you signed
});

Python:

import hmac, hashlib, json, time, requests

body = json.dumps({"email": "customer@example.com", "message": "Price list?"}).encode()
ts = str(int(time.time()))
sig = hmac.new(SECRET.encode(), ts.encode() + b"." + body, hashlib.sha256).hexdigest()

requests.post(URL, data=body, headers={
    "Content-Type": "application/json",
    "X-Orbi-Timestamp": ts,
    "X-Orbi-Signature": "sha256=" + sig,
})

The two things people get stuck on

1. Send the bytes you signed. The signature is produced over the raw payload. Signing first and then serialising the JSON again (adding whitespace, changing the key order) breaks it. In the examples above body is produced once and given both to the signature and to the request, and that is why.

2. Generate the timestamp again on every request. There is a five-minute window. The value is expected in unix seconds, and for convenience milliseconds (Date.now()) and ISO-8601 are accepted too.

If you get a window error, the cause is almost always one of two things. Either the same signature was reused on more than one request, or the sending system's clock has drifted. The error message writes the real difference in seconds (… 3601 seconds in the past), so you can see which one it is directly.

If you want to refresh the URL, renewing the token is enough. The new URL is valid immediately and your event history is kept.

#Sending files

If the event has files (the CV of an email, a document a form uploaded), put them in the top-level attachments field of the body. Each attachment carries a name and base64 content:

{
  "subject": "Backend developer application",
  "text": "Hello, my CV is attached.",
  "attachments": [
    { "filename": "cv.pdf", "contentBase64": "JVBERi0xLjQK..." }
  ]
}

• Attachments do not enter the data the agent reads. Orbi saves each one to Files in the flow's space, and the trigger data keeps only the file's id, name, type and size. The agent reads the file with read_file and attaches it to a card with attach_file.
• Files are saved as attachments. Two senders' files with the same name (two separate cv.pdf) never become versions of each other.
• The signature is computed over the whole raw body, attachments included. The examples above work unchanged.
• A file type Orbi cannot store, or a full storage quota, drops only that attachment. The request is still accepted, and the trigger data shows the reason in that attachment's place (skipped), so the agent can say the file did not arrive.
• A malformed attachment (not an array, not base64, or empty) rejects the whole request with 400.

#The daily cap

Every incoming event means an agent run, that is an LLM call, and that cost is billed to your own API key. The daily cap keeps usage predictable, because if an integration sends more events than expected, the cost does not grow quietly.

When the cap is full Orbi still accepts the request (202) but opens no run, and it appears in the event list as "daily limit reached". The sending system gets no error, so the integration stays open, and you can raise the cap from where you saw it.

#The event log

Every request, accepted and rejected alike, is listed under "Show incoming requests" in the trigger's panel.

Requests that were not accepted are listed too, so if you do not get the result you expect while setting up an integration, you see the reason right here.

#Closing the loop

The address called from outside and the outgoing webhook build a full integration together. The outside system pushes the event, the agent runs, and when the job is done the schedule_job.completed event goes back to that same system. The inboundTriggerId field in the payload says whether the run came from a schedule or from your address.

#Limits

• The payload is at most 64 KB without its attachments, and anything larger gets a 413.
• A request carries at most 10 attachments, up to 10 MB each and 20 MB in total. A larger request gets a 413.
• 60 requests per minute per address are accepted. Over that you get a 429 plus Retry-After, and the sender backs off and retries.
• The endpoint answers immediately (202). An agent run can take minutes, and the endpoint does not wait for the result.
• Inbound runs work with the workspace's tools. Personal MCP connections only come into play in runs you start yourself, so they are not included here (Tools and integrations).
• Creating and deleting a trigger is an Admin permission.

#Connecting Orbi outwards: the Orbi MCP server

The sections so far connected the outside to Orbi. This one is the reverse, and it is about your own tools using Orbi.

Orbi has an MCP server. When Claude Code, Cursor or an agent you wrote connects to it, it can read your board, open cards, change states, write comments and reach the team's shared memory (collections and files). It can work like a developer who joined your team remotely.

That last one matters more than you would think. What an agent working in a chat window learns stays in that window, while what it writes into a collection stays where the rest of the team will see it, so your session and your teammate's share the same memory.

#Creating a token

You create a token with the Create token button on the Tool access tab of your profile (your name at the bottom of the left menu → Tool access). The Access tokens list on the same tab shows, grouped by workspace, every token that acts as you or as an agent across all your workspaces: the ones you created by hand, the connections you granted on the consent screen and the agent tokens you issued. In the workspaces where you are an Admin, agent tokens other people issued sit in a separate Other people's view; each row names its issuer, or says unknown on older tokens. My tokens holds only what sits on your own machines. Each row has the token's name on the left and an identity chip on the right: the agent's avatar and @agentname, or your avatar and As me. Open a row to see its details and the Revoke button; you can revoke any token you see in the list.

• It belongs to you, not to the workspace. Not even an Admin can see someone else's personal token.
• Its validity is 30, 90 or 365 days or no expiry; the default is 90 days.
• It inherits your role. There is no separate permission system. If your role drops to viewer, the token loses write access at that moment, and if you are removed from the workspace the token stops working.
• It is shown once. If you lose it, it cannot be recovered and you create a new one.
• It can be marked read-only, which is the right choice for clients that only watch the board.
• It can be revoked. Revoking takes effect on the next call, and there is no session cache.

#Two kinds of token: yours and an agent's

A personal token works on your behalf. The rules above are for that one.

An agent token works on an agent's behalf, and everything it writes to the board appears with that agent's signature. For an agent to have a token, its place of work has to be "Connects from outside" (Agents). Here are the differences.

If you are connecting a coding agent, the second is the right choice, because who did the work is visible on the board and your own notifications keep working (Working with a coding agent).

#Connecting

claude mcp add --transport http orbi https://mcp.orbiwork.space/mcp

There is no key in the command. When you type /mcp and choose Authenticate, Orbi's consent screen opens in the browser; you pick the workspace and the identity (yourself or an agent) there. The step-by-step walkthrough is on the coding agent page; the steps for Claude, Cursor, VS Code and other clients are on the setup cards under Profile → Tool access. Clients without a browser keep the secret-key path: Streamable HTTP transport and the Authorization: Bearer <token> header.

Closed spaces. Every tool you connect as yourself sees Genel and the open spaces; it sees a closed space only when you choose it. This holds for a tool connected on the consent screen and for a token you create by hand. Open the token's row under Profile → Tool access → Access tokens and tick the closed spaces you are a member of with Choose closed spaces; for a token you create by hand you can also choose them while creating it. Tokens you created earlier do not see a closed space either until you choose it. If you leave a space, the token loses it at once.

#Connecting several workspaces to one client

Each connection sees only one workspace; the tools have no workspace parameter. If you connect two workspaces to the same client (ChatGPT, for example), you set up two separate connections, and both have a Genel. To keep the agent from mixing them up:

• Name the connections apart. Put the workspace in the token's name when you create it: ChatGPT · Acme. The suggestion button under the name field writes it in one click. Name the connection in the client the same way.
• Orbi names the connection too. Every tool description starts with an [Orbi · <workspace>] tag, and the server name and the first line of the instructions sent on connecting name the workspace. The agent reads from the tool list which connection writes where.
• The error points the way. When the agent cannot find a space, the error names the workspace it searched. If you can read a space of that name in another workspace, it names that workspace too and asks the agent to use that workspace's connection. Only workspaces you are a member of and spaces you can see are named.

#What it learns the moment it connects

When a client connects, Orbi sends it an introduction to the workspace, and most clients (Claude Code included) add this to their own system instruction. So the agent knows the following before the first message.

• Which user, which workspace, which role and what write permission it is connected with
• Your spaces and the boards in each (along with their projectIds), and what each space and board is for
• Your collections, with their name, purpose and record count, which is what is in the team's memory
• Your defined Orbi agents and what they are good for
• The organisation text you wrote under Settings → General → Workspace context, the same text given to Orbi's own agents
• The working rules, meaning the card lifecycle, the four things that trigger execution, tying the card to the PR on code work, and searching before writing

This text is generated from your workspace rather than being a fixed instruction. When you create a new collection or edit the workspace context, the next connection sees it. In practice, explaining the project to the agent from scratch every time goes away.

#Tools

Tools that write new content (write_file, write_mind_model, create_collection, create_flow, create_project) say which space they write to with the space parameter, and it has no default. The agent takes the space from the conversation or asks you; whoami and list_spaces list the spaces. A card takes its board, and its space comes from the board. save_memory takes a space or personal as its scope. The connection works with your identity and your space roles, so it cannot write to a space where you are a viewer.

Board

Shared memory: collections (Collections)

Shared memory: files (Files)

Mind models (Mind models)

Pull request links (Tasks)

Channels (Channels)

Setup: flows, agents, projects (Flows, Agents)

All of the write tools (from create_task onwards) are off for a read-only token and for the viewer role. Shared memory is not deleted remotely, so deleting a collection record or someone else's file is done from the interface only, because being able to delete shared memory remotely risks more than it gains. There are two narrow exceptions. delete_task removes a duplicate card or one opened by mistake, the card does not disappear for good, and the activity log shows who deleted it. delete_file moves to the trash only a file the connecting identity wrote itself, that is not an upload and is not attached anywhere; the file can be restored from the interface for 30 days.

list_tasks and get_task also show a card's assignee, and the assignee parameter of list_tasks answers "the cards assigned to this person or agent".

These tools are the same ones the agents use. A record written by Claude Code is seen by an Orbi agent under the same dedup and schema rules, because "the same memory" is not a figure of speech here, it is literally the same code path.

#Four behaviours that can surprise you

Setting queued with set_task_state TRIGGERS agent execution. If you only want the card to show as "next up", use todo.

If @agent.<name> appears in the text of add_task_comment, that agent starts working. Naming an agent in a comment means giving it a job (Tasks).

If assign_task assigns a card that is already queued to an AI (Orbi or an agent), execution is triggered again. This is deliberate, because changing the owner of a card waiting in the queue means "let this one run it from now on". Assigning to a person does not trigger anything, so handing over to a human is always safe.

write_record does not always write, so look at the written field in the result. If the collection has a dedup field (or dedupField was given in the call), the write is refused when a similar enough record is found and the candidates come back instead. If it really is a new record, try again with forceWrite, and if it is the same record, update the existing one with update_record. Reporting a record that does not exist as "added" puts everything that follows in the wrong place. If no dedup field is defined, the similarity check never runs, so if you do not want to write the same thing twice, look first with search_records.