Every question, answered in full.

A chatbot answers. An agent owns a job. The difference is everything after the answer: an identity of its own, capabilities it was granted rather than credentials it holds, limits on what it may decide, a human it asks when it reaches the edge of its authority, a runtime that keeps it working, and a record of everything it did. A chatbot that could email your customers about their invoices would need all of that too — which is roughly the point.

Automation runs the steps you specified. An agent is given a job and decides the steps, which is more useful and considerably more dangerous — so most of this product is the part that bounds it. If your work genuinely fits a fixed sequence of steps, an automation tool is cheaper and more predictable, and you should use one.

No. A business user describes a job in plain words and the studio builds the agent, and every capability, boundary and approval rule is shown in words before it is deployed. Developers get SDKs, an API, a CLI and manifests for agents that need real logic. Both produce the same kind of agent with the same permissions and the same audit trail — there is no weaker path.

Four things, in order. It has no capability it was not granted. Capabilities that move money or change access are refused to every agent on every plan, not offered as settings. Actions beyond its authority — a discount above your limit — become requests to a named person. And its network reach is a list rather than the internet, so it has no route to send your data anywhere nobody approved. None of that depends on instructing the model carefully, because an instruction is a request rather than a limit.

No. Message bodies, attachments, imported pages and anything else arriving from outside are treated as data, never as instruction. That distinction matters more in this product than most, because anybody who can contact your company can introduce content. An instruction inside a customer's email is text the agent read; it is not a rule the agent follows.

Any agent can be paused or stopped immediately, mid-run, and one control halts every agent in the workspace. Any agent owner can stop their own; administrators can stop anything. Stopping does not undo what already happened — an email that has been sent is sent — so the platform records exactly what completed before the stop. That is also why boundaries and budgets exist: the emergency stop is the last control, not the first.

A plan, plus what your agents consume in model usage and runtime. The product estimates an agent's monthly cost before you deploy it — runs, model, runtime and a total — and shows the actual against that estimate afterwards. A light agent such as a morning briefing runs at around €11 a month; a busy finance agent doing over a thousand decisions runs at around €74. If an agent costs materially more than its estimate, that is a bug in the estimate and we would rather you saw it at the review screen.

No. Your agents' work, your customer records and your approved knowledge are not used to train models made available outside your account. That is a contractual commitment rather than a setting, and the same prohibition applies to the model providers we use. Content in categories you mark sensitive is excluded from model requests by default.

Whichever suits the task, and that is configurable per agent: a recommended default, a fast model for classification, a reasoning model for difficult decisions, or your own. Deliberately not built around one provider — an agent platform that pins you to a single model for ever will be the wrong platform within a year. Changing an agent's model creates a version and goes through review, because it can change behaviour as much as a permission change.

No, and this is not a configuration question. There is no keystroke tracking, no time-online, no idle detection and no per-person scoring in the product, so there is nothing to switch on. Using case data or response timings to build a surveillance record of an individual breaches the acceptable use policy. Agents read roles, responsibilities and approval authority — never salary, performance or assessment data.

Every run produces a timeline written as it happens: what triggered it, what it read, what it decided, what it did, what it asked about and what it cost. Any step expands into why it happened, citing the records and quoting the rule with its version. Every consequential action records the agent, its version, the capabilities used, the approvals obtained and the result, append-only.

It says so and escalates. Agents answer from knowledge your company has approved and cite it; asked something outside that, they hand over with what they have already gathered. When two of your own approved sources disagree, the agent stops and asks rather than choosing — an agent that resolves a contradiction has invented a company policy.

Three ways, in increasing order of how much they will convince you. A sandbox with synthetic customers and mock tools, where there is no route to a production system at all. A dry run that tells you what the agent would have done yesterday against your real records. And a simulation across a month of your history — how many customers it would have contacted, escalated or left alone. None of them sends anything or changes a record.

Your agents, manifests, run history and audit trail export on every plan, throughout the term and during any wind-down. Manifests are declarative files you can keep in your own source control from the first day, so the definition of what your agents do is never only in our database.

No. No configuration of any software does that. What this produces is evidence that may be useful to a compliance process — who granted an agent what, when, why, what it did and who approved it — recorded as a by-product of working rather than assembled afterwards. That is a smaller and more honest claim.