A node does what
you tell it to.
Most tags are exactly what you'd expect: your own words on a node — the vocabulary you already use, written where both you and Lifebot can see it, so the assistant reasons with your language instead of guessing. And a handful of them do something as well: give a node a status, a color, an assistant, a lock, or turn it into automation that runs itself. Those you can flip as a switch, say out loud to Lifebot, or set from code — same tag underneath, three ways to reach it.
Three tags and a default decide your audience
Three tags and one default cover every case: open to whoever has the link, closed until someone inside lets you in, human-only, or invisible to everyone but its members. The same rules apply to people, to your own scripts and to the AI — there is no back door for any of them. The full model, with what each looks like from the outside, lives on the privacy page.
private
Visible, but closed inside. Ask for access; anyone already inside approves you by mentioning @@you in the node's chat, so everyone inside sees who let whom in, and when.
Anyone who can edit the node can add it. Only the node's creator can remove it.
kyc
Human-only. The node is visible, but to enter you prove there's a person behind the click: a $0 payment via Apple Pay or Google Pay with a real card from your bank. No owner approval — passing the check is enough. Bots and scripts can't get past it.
Anyone who can edit the node can add it. Only the node's creator can remove it.
wallet
Not private — absent. Until you are inside, the node is not in its parent's list of children at all — not for a teammate, not for a script under their account, not for the AI. Once you are in, you and your own code see it like any other node. Nothing is shown by a direct link either. Getting in takes all three: the link from someone inside, the $0 human check, and their approval. Lifebot never sees it from the outside, even when you are a member; ask it from inside the wallet, once you switch the assistant on there, and it works there, knowing it is a wallet.
Only the node's creator can add it or remove it.
Tell a node what to be
A node can be a document you read, a list you work through, or a 3D map you fly around — same node, one setting. It can have an assistant sitting in it that knows the whole branch, or stay quiet. It can be the red one you spot instantly in a long list. You don't type any of this: in the app it's a switch, a dropdown and a color picker. The tag is only how it's stored — which is why a contract, a script or Lifebot can set the very same thing.
assist
Turns Lifebot on inside the node so the AI can answer and act there. On a regular solo node this is on by default; on a wallet it's off by default (you turn it on if you want AI help with financial or secret data).
You can add or remove any time.
#view#
Sets the view a node opens in — item (the list of children), document (Markdown preview) or graph (3D map). A link can ask for a view by itself: /document/<id> or /graph/<id> opens straight in it. With the tag, the ordinary /item/<id> link opens in the chosen view too, for everyone, just as if they had followed that view's link. Next: more views, as mini-apps on top of a node that you build with Lifebot right in the messenger — the data each one runs on lives inside the node.
You can add or remove.
#color#
Paints the node an RGBA color so it stands out in lists and in the graph view — e.g. #color#255,0,0,1 for red.
You can add or remove.
A board, without the board
A sales team moves deals through lead → call → proposal → signed. A building site moves through survey → permit → foundation → handover. Neither fits someone else's fixed columns — so a list of stages here is just an ordinary node whose children are the stages, with your words and your emoji. Point a parent at it and its children get a status picker, and each branch can run on its own list. Lifebot and agents on MCP understand these lists too. Ask Lifebot to make the stages for you: it looks at your project, sees what it needs, and builds a list that fits it exactly — then moves your nodes along it. And a status change is an ordinary edit, so a contract on the branch wakes up on it — a deal reaches “signed”, and the automation behind it runs.
#marker#
Sets the node's current status — one of the markers offered by whichever list its parent points at. The built-in list is simply the one offered first: 🕑 In Work, ❕ Urgent, ❔ Needs Clarification, ☑️ Completed, ❎ Closed, 📁 Folder, ℹ Info.
You can add, change, or remove.
#markerList#
Enables the status dropdown on a parent's children. A marker list is nothing special — it is an ordinary node whose children ARE the markers, each one a node with a title and a description. Point the tag at the built-in list, or at a node of your own: your stages, your words, your emoji.
You add to enable the dropdown; remove to disable it.
A node that works while you sleep
One tag turns a node into a contract: anything that happens inside its branch — a node added, edited, archived or moved, a message posted — wakes it up. A stage changes and the client gets told. A supplier's price lands and the quote recalculates. A teammate drops a file and the summary appears under it. The node holds the config, another node holds the code, and it runs under your account.
#contract
Marks the node as an automation contract. The node's title has a {{webhook:<URL>}} snippet and its description is a JSON config — the system calls the webhook on every event in the node's descendant subtree.
You add to activate. Remove to stop. Temporarily disable with #contract#disabled (with an optional reason).
Or just ask for it.
Because a node’s settings are tags, you don’t have to go looking for them. “Turn on assist here”, “mark these three urgent”, “paint this branch green”, “make this a contract” — Lifebot sets them, and so can your own code through the SDK. One node, three ways in: the switch, the sentence, the API call.
With one line it can’t cross: ask Lifebot to make a node private and it will. Ask it to take that off, or to set kyc or wallet, and it can’t — the server skips those tags, however the request is phrased. Opening what you closed stays a human act.
And one you can nail down. In a graph where agents, contracts and teammates all move things around, non_drop pins a node where it is: it can’t be moved to another parent and it can’t be archived — not by an automation, not by the AI, not by a stray drag. Its contents still edit normally. Hammer it in when a node is load bearing; it’s a nail, not a clip, so it doesn’t come back out.
Your nodes, your rules.
A few tags, and a node knows how to behave.
Start your graph →