Boundaries and rights
What a conversation on your website can and cannot make the agent do, what the owner may open, and what each of those costs. Read this before opening anything.
Whose conversation it is
A visitor on your site has no account here, no team, and no way to get one. But every turn an agent takes runs inside a team's scope — that is how the product decides what may be read and who pays.
So the visitor is never given one. The turn runs as the agent's owner, in the agent's team, reached through the same membership check a signed-in member goes through. The visitor's identity is a label on the conversation and nothing more.
Two consequences worth saying out loud:
- It is the owner's bill. Every answer to a stranger is spent from the owner's usage, not the visitor's.
- The visitor cannot widen anything. No value they send mints a scope. There is no field, header or message that turns a visitor into a member.
The four defaults
Out of the box, and in every installation, a conversation that arrives from a website is narrower than the same agent in the cabinet:
| what it means | |
|---|---|
| Its own thread | The website conversation never mixes with the owner's. Same storage, same context window, different channel. |
| No hands | No worker, no shell, no network access, no agent-type extras. The agent answers; it does not act. |
| Nothing remembered | Nothing from this conversation is written into the agent's long-term memory. |
| Answer only | The visitor sees the reply. Not the reasoning, not the tool steps, not what a tool returned. |
These are defaults, not laws. They are what every binding in every database does and what a channel gets the moment it is published — but the agent's owner can undo them, one at a time, from the «Сайт» screen.
The four rights, and what each one costs
The honest sentence first, because it is the whole reason this page exists:
an unknown person who opened the page can make the agent run commands in a worker, reach the network, write into its long-term memory and re-time what it does on its own — with the owner's rights and on the owner's bill.
And unknown is literal. The ticket sits in the page's HTML, so "open it to visitors of the site" and "open it to everyone who found the page" are the same sentence.
hands — the agent may act
Gives back the worker’s toolset and the worker that runs it. Both halves together, because a toolset with no machine behind it only describes tools that cannot run.
What it costs. A stranger's sentence becomes a command executed in a container, and network calls made from it. The agent's own grant and egress list still bound what it may reach — this right lifts a prohibition that sat on top of them, it does not exceed them.
It also changes the money. A conversation was rate-limited at 12 messages a minute per visitor and 60 per agent; with hands open the limits drop to 4 and 15, in the same buckets, so flipping the switch mid-minute cannot hand anyone two allowances. It is a flow limit, not a spend cap.
memory — the conversation may be remembered
Lets the curator read this conversation and write from it into the agent's long-term memory.
What it costs. What a stranger says starts shaping how the agent answers everyone else, including the owner. Anything a visitor asserts is a candidate for something the agent later believes.
schedule — the agent may re-time itself
Gives back the heartbeat tools, and the ability for the conversation to start work on its own.
What it costs. It is the only right whose damage outlives the visit: a stranger can leave a standing job running after they close the tab. Because of that, raising it asks the owner to type the agent's own id back as confirmation. Lowering it asks nothing.
visibility — the visitor sees the working
Sends the agent's thinking and its tool steps to the browser as separate notes.
What it costs. It discloses how the agent is built, and — in a tool's arguments — fragments of what it read. It is its own decision and not a rider on hands: a tool's output never leaves either way; a note carries the name of the tool and the verdict.
Pictures a visitor attaches
The widget lets a visitor attach an image, and the agent is shown it. This is part of an ordinary conversation rather than a fifth right: a picture is what the person is saying, not something of the agent's being handed over, so there is nothing to switch on and nothing to switch off short of the channel itself.
What is bounded is what it costs you:
| Types | PNG, JPEG, GIF, WEBP — the same four your own chat in the cabinet accepts, and no others |
| Size | 1 MB per picture (your own chat allows three) |
| How many | up to five on one message |
| How often | the ordinary flow limit — twelve messages a minute per person |
Anything outside that is refused with a sentence the visitor reads, naming the limit: «Картинка слишком большая — принимаю до 1 МБ». It is never dropped in silence, and the agent never answers as though a picture the person watched themselves attach were not there.
Your team sees it. The picture lands in that visitor's conversation, beside their words, and your team reads it on the person's card in the cabinet — the same screen and the same read as the text. Nobody else can reach it: the bytes are served only through a signed, expiring link.
Deleting the person keeps it. Erasing a lead erases the person — the record and everything you noted about them — and leaves their conversations, exactly as it always has. A picture belongs to the conversation it was sent in, so it stays with the words it came with. What removes it is removing the conversation, or the agent.
What no combination reaches
The agent's past conversations. Reading the chat history is not one of the four rights and is not folded into any of them. No switch on that screen makes a website visitor able to read what anyone else said to this agent.
And, under every combination: whose turn it is does not change. No right mints a scope out of a visitor's identity, and none of them lets the agent exceed the grant and the egress list it already had.
Being recognised instead of anonymous
If your site already knows who someone is — a signed-in customer, an order in progress — you can have them arrive as that person instead of as another anonymous visitor. It takes a ticket issued server to server, with the identity in it, by your backend rather than by the page: see What you need on the server.
We believe your site about who this is — within its own team, and no further. That is what the key buys and what it is bounded by. Being recognised is not being privileged: a named visitor gets the same four defaults and the same rights as an anonymous one, and the turn still runs as the agent's owner.
And the agent itself is not told the name. The identity is recorded beside the conversation — it is what your team reads in the lead list — not injected into what the agent is thinking with. If you want the agent to greet somebody by name, that is your page's opening message, not this credential.
A visitor who arrives without an identity is still anonymous, and their Lead record appears on their first admitted message — never at the token exchange, because a browser that loads a page and says nothing is not somebody worth a row.