It answers anyone. It only acts for you.

It can do things, and the distinction between the kinds of things is the part worth reading. Reading is the easy case: catalogue and stock questions need nothing, and anything attached to a person or an order needs a verified visitor. Preparing is the middle case — a captured lead, a raised ticket, a started return — where something real is created but a person picks it up, and the customer is told that in the reply rather than left to assume it was handled. Acting is the sharp end: cancelling an order, booking or moving an appointment, applying a tag that sets a workflow running. Those change your business the moment they run, so they require either signed-in staff or a visitor who has proved by email that they own that exact record, and they are capped at five per conversation in any ten minutes. One thing is refused outright and has no setting attached to it: an anonymous visitor cannot cause an invoice to be issued, in any flow you can draw.

It does not take their word for it. When a flow reaches anything personal, the chatbot asks for an email address and then mails a six-digit code to it; the code expires in ten minutes, allows five attempts, and only three can be requested in a quarter of an hour. What is stored is a peppered hash, never the code, and it is compared in constant time so the comparison itself gives nothing away. The important part is where the result lives: on the conversation record on our servers, re-read from the database on every single turn. It is never read back from anything the browser sent, which means a visitor cannot arrive with a verified flag set and be believed. Two smaller behaviours sit underneath that. The chatbot only ever matches on the verified email once a conversation is resumed, because the weaker identifier match is disabled the moment its origin is uncertain; and an identifier from one part of Oneop is never accepted as an identifier from another, so a coincidence of numbering can never authorise anybody.

That depends which block you asked, and we would rather draw the line than blur it. The knowledge-answer block is the one built to hold it. It retrieves from your own content, requires the model to declare in a structured field whether the answer was actually supported by what it retrieved, and overrides that declaration to false on our side whenever nothing was retrieved at all — a model cannot claim to be grounded in an empty context. Confidence is whatever the model reported or nothing at all; it is never defaulted to a plausible-looking number. And when the answer comes back ungrounded or below your threshold, the model text is thrown away entirely and the visitor sees the fallback message you wrote. Not a hedged version of the answer. The answer, discarded. The other AI blocks are ordinary generation with your knowledge attached as context, which is useful for tone and small talk and is not the same promise — so use the knowledge-answer block for anything a customer might act on, and route its fallback to a person.

The visitor gets a short, honest message and the conversation carries on down the flow — never silence, and never an invented answer to cover the gap. Underneath that, three failures are deliberately kept apart. A model or provider failure falls back through a chain of Gemini models first and only produces the fallback message if the whole chain fails. A prompt that trips the injection filter is refused before any provider is called and before any credit is reserved, so an attack costs you nothing. And a billing stop is not disguised: if a workspace has hit its AI ceiling, that error is allowed to travel rather than being caught and shown as a chat hiccup, because a spend limit that presents as a technical glitch is how a limit gets debugged for a week instead of noticed in a minute. What none of these do is escalate to a human on their own — if you want a failed answer to reach a person, you draw that path, and we would recommend you do.

The same conversation, not a copy of it and not a ticket about it. The row the visitor has been talking to changes state; it does not close and reopen somewhere else. What comes with it: the full transcript with both sides in it, any identity the visitor proved during the chat, every field the flow collected, the reason it escalated, and the visitor’s own profile details. The agent replies into the same thread and the customer sees it in the same window — there is no “a colleague will email you”. One thing we will not claim, because it is not there: nothing writes an AI summary of the conversation for the agent. The panel shows the escalation reason if the flow set one, and otherwise the tail of what the bot last said. If a written summary of the conversation is what you are picturing, picture the transcript instead, and set a clear escalation reason in your flow so the top of the panel is useful.

Only the blocks that call a model cost anything. A flow made of questions, branches, lookups and record actions can answer all day without touching your credit balance, which is worth knowing before you reach for AI on every step. When you do: an AI reply and a knowledge-grounded answer are one credit each, and the broader retrieval block is two. The free plan’s fifty credits are therefore about fifty AI answers a month — enough to build something real and watch it work, not enough to run a support queue on. Two details about the meter itself: the workspace is resolved before generation, so no chatbot call can ever happen that nobody is charged for, and a call the provider fails to complete is refunded rather than billed.

Direction and audience. The chatbot faces your customers and follows a flow you drew, which is exactly what you want on a public website: the same question walks the same path every time, and you can point at the step that produced any answer. An agent faces your own team, is started by one of your people, and chooses its own path through a set of tools you granted it until it finishes or hits a ceiling. The chatbot is bounded by its diagram; an agent is bounded by published limits precisely because it has no diagram. They also sit at different risk levels for the same reason this page spends so long on identity: anyone on the internet can open the chatbot, and only your staff can start an agent. Most teams run both, and the rules that constrain them — one workspace, redaction before the model, credits reserved before generation, evidence written either way — are the same rules.