12 requests per minute
cap per visitor on the public widget interface
applies per visitor and assistant; that allows one question every 5 seconds, and the series waits 5.5 seconds to keep clear of our own brake
At XICBOT an individual function is not a special build bolted onto the assistant but a tool of its own, with a key, a schema, a target address, a minimum role and an approval path.
We also build custom functions for your process. Each function is a tool of its own with fixed rules. The assistant proposes to use the tool. Then your system answers. Only what your system returned goes into the chat. It is set beforehand what may run on its own. Everything else only happens after a click.
Request an individual function View tool control
The assistant proposes the call, your system answers, and only what your endpoint returned goes back into the conversation. What may run automatically and what happens only after a click is settled beforehand in the tool's record — not left to the model's judgement.
Visitor:What does a canopy of 6 by 3.5 metres with one side wall cost?
Assistant:I pass the dimensions to the company's own price calculation and tell you what comes back from there. Otherwise I would be estimating.
Visitor:As a quote, please.
Assistant:For that I create a record in the quoting system. I do not run that on my own: you read beforehand what will be handed over and confirm it with a click.
Visitor:Confirmed.
Assistant:The record is in place. A second click on the same confirmation does not create a second one — a lock in the database prevents that, not a check in the interface.
Ask it yourself, Assistant of this website
Automated assistantTwo statements are readily conflated; here they stand apart. Included in what is delivered are seventeen build forms: seven at the core — capture an enquiry, take an appointment request, hand over to a human, search the catalogue, put together a basket in the chat and lead on into the shop, call a stored address, pre-fill a form on your site once the visitor confirms — plus ten adapters for inventory, calendar, catalogue, customer management and ticketing. Definable as your own action is whatever your system offers through an endpoint: you enter key, schema, address and minimum role, and XICBOT makes the call. The calculating happens in your system, not in the assistant. How a single call proceeds is set out under tool control; how the finished assistant reaches your website under integration and embedding.
Outwards the contract is narrow and identical for every build form: XICBOT sends a POST carrying build form, operation, tool key, conversation id and input, and expects an answer with an ok field and the data. A connected system therefore needs no knowledge of XICBOT, only an endpoint that understands this one envelope. If the ok field is missing, the answer counts as a breach of contract, not as a result.
Tiers, customer groups and case distinctions stay in the system that already maintains them. The assistant passes the input across and takes from the answer exactly the fields the tool declared. A field your system sends on top of that never reaches the model.
Every tool that talks to a foreign system goes through the same connector. If each build form built its own call, the question would not be whether a limit is missing, but in which one.
A calculator in the conversation is a tool with a schema for the inputs and an endpoint that knows the price. XICBOT brings no price or stock truth of its own; what appears in the conversation comes from your answer. If your endpoint fails, the assistant names the failure rather than a figure.
timeout; any other error ends as failedA schema of your own holds at most twenty fields. Required fields are the union of what the build form demands and your own list — but only what also appears in the schema. If a required field is missing, the call is not executed at all. Null, empty text and an empty list count as missing; a 0 is a value.
tenant_id, mandant, mandant_id and konto_id are blocked as field namesSeveral calls within one answer are provided for, but limited: an answer does not execute more than five, and the sixth is logged as a capped call. Once the month's allowance is largely used up, the cap drops to one call per answer. A step that fails is not repeated — there is no second attempt and no background run.
chain_capped in the tool rowfailed, an exceeded deadline as timeout — neither is made up laterOn creation and change every non-reading kind is forced to confirmation, whatever the request says. Without confirmation only what reads and is explicitly set to automatic will run. Every call leaves a row that is written before execution and updated afterwards.
What these building blocks share is the point at which they stop: every outbound call runs through the same connector with target check, time limit and size cap. An individual function therefore brings no route of its own onto the network, only a schema of its own.
Which building blocks your case needs is settled by the end of the initial conversation — together with the question of which details your system has to see for it and which it never gets to see.
12 requests per minute
cap per visitor on the public widget interface
applies per visitor and assistant; that allows one question every 5 seconds, and the series waits 5.5 seconds to keep clear of our own brake
The list below names, for each build form, the key under which it sits in an assistant's tool set and the approval it carries. Five of these ten adapters write and are therefore always subject to confirmation; two reading ones require confirmation by default as well because they touch a personal matter. A tool belongs to exactly one assistant, not to the tenant — a second assistant for a different purpose has its own set.
Below them sit the cases of the Custom package: they are not part of the kit but are set up per assistant as an action of their own — with key, schema, target address, minimum role and approval path. Calculating and record-keeping happen in your system; the assistant asks, applies and passes on what came back.
Writes name, email, telephone and request into the company inbox and attaches files the visitor uploaded during the conversation. Writing, and therefore always with confirmation.
proposed and executes nothinglead.createdRequesting, rescheduling and cancelling sit in one build form, together with the free list, which calculates free times from the company's appointment kinds minus the appointments already requested or confirmed at XICBOT. A request is only created if the appointment kind is known to the company, the lead time fits and the moment falls inside a window; availability is checked under a lock, and the request only becomes an appointment once the company confirms it. The preview follows the act — cancel, reschedule and request each read as their own sentence.
kindappointment.requestedSets the conversation to escalated, creates an enquiry and notifies a human. A second handover in the same conversation triggers no second message. The visitor is not told by which route the company is notified.
escalatedduplicate_prevented rather than an errorautomatic, visitor_confirmed or, in test conversations and via the API, operator_confirmedKnows four forms: search, compare, bundle, also bought. It returns at most six hits and answers only from the company catalogue; a stated article key beats the search term. Without a term and without a key there is no result but a note, and a comparison needs two articles.
search, compare, bundle, also_boughtSix kinds of change, at most 99 units per item. The basket sits with XICBOT, but with no price or stock truth of its own: the total uses the live price from the shop, and if the shop does not answer, the price from the last sync together with its date. “Continue” leads to the stored shop address, with a pickup token attached. Through a read-only pickup address at XICBOT the shop can fetch the basket with that token; the shop connects this pickup through an integration of its own.
set, add, update, remove, clear, couponReads the status of an order in your connected inventory system — and by default still requires a confirmation, because it is a personal matter. Reading is no free pass here.
read, approval confirmChanges an order in the connected system. Writing, with confirmation, and with a one-time key in the call's header so that a repeated call does not take effect twice on the other side.
order.changeautomatic — that is already in the adapter contractok counts as a breach of contract, not as a resultReads stock levels and by default runs without asking, because the build form touches nothing personal and writes nothing. Like every reading build form, it can be switched to “with confirmation”.
read, approval automaticReads a price from a foreign catalogue, without a query. The price comes from your system; the assistant passes it on instead of forming it.
read, approval automaticThe assistant reads free slots from the connected calendar without a query; an entry into that calendar writes and only goes out after confirmation.
calendar_availability on automatic, calendar_booking on confirmCreating a record writes, and reading a customer's activities requires a confirmation by default too. The minimum role a tool needs is stored on the tool: public, member, admin, owner.
crm_lead writing, crm_activities reading with confirmationpublic, even if an administration login happens to run alongsideCreates a ticket in your system out of the conversation — writing, with confirmation, carrying the conversation context in the envelope.
write, approval confirmadapter, domain, operation, action, tool, conversation_id and inputRecords a request for a callback. This is the documented form of what elsewhere is readily described as a completed form: a wish is noted, no form is submitted.
write, approval confirmThis is where the individual function comes into being: a tool with your key, your schema and your address. The build form is classified as reading and stands on confirmation. Your endpoint decides what comes back — a calculation, a configuration, information from an internal application.
__set__ when read back and is never returnedThe calculation logic stays where it is maintained: tiers, customer groups and multi-level case distinctions sit in your system; the assistant gathers the inputs in conversation and reports what your endpoint returned.
Each of these queries is a tool with a target address that is checked before and after name resolution. Identification comes before any account information, and reading is no free pass there.
Several steps within one answer are foreseen and capped. Each step leaves its own line in the log, and writing steps wait for confirmation before they go out.
Whatever leaves at the end of a case is an action with approval as well — not a side effect of the answer. The assistant fills in a form only after the visitor has confirmed the details; it is submitted only if you allow submission and the visitor agrees, and the call is logged.
Every individual function begins with the data it is allowed to read. What that can be depends on the build forms above and on your own endpoint — not on a fixed list at our end. What the assistant answers from texts, by contrast, sits in the knowledge base rather than in the tool set.
Reading is followed by the action, and the action by the log. The assistant applies what your system returns and chains steps within one answer — up to the cap. How a single call proceeds technically is set out under tool control.
Which of these cases end up in your assistant is settled case by case: one case, one build form, one schema, one address, one approval path. The cases above are the scope of the Custom package, not a list every assistant carries in full.
Many of these build forms also carry the ready-made assistants: the cart assistant, the booking assistant and the lead assistant are the same tool set, arranged differently. Which sector reaches for what is shown on the references page; the assignment to the packages sits under pricing, the evaluation of conversations under conversation analytics.
Visitor:Where is my order 10482?
Assistant:I will query the status in the inventory system. The call only reads, but it needs your confirmation because it concerns a personal matter.
Visitor:Confirmed.
Assistant:The inventory system did not answer within the deadline. So I have no status and will not state one. I do not retry on my own — shall I pass your request on with the order number?
Visitor:Yes, please.
Assistant:Passed on, together with the conversation so far and the order number. If you click the same handover again in a moment, no second notification arises.
8 of 8
questions without a basis declined instead of guessed
eight questions deliberately outside the material; the wording of every answer is in the measurement file
The tool set hangs on the individual assistant, not on the account: a second assistant for a different purpose gets its own.
A tool's key is lower case, between three and sixty-four characters long, and used only once per assistant.
The allowance in the top right is the same figure the cap on tool calls later hangs on.

The path is the same for every individual function, and it does not end at programming but at approval. Six steps, two of which deal exclusively with what the assistant may not do.
First comes the sentence a visitor will say, and the answer they expect. From it emerges which details the assistant has to gather, which system answers them and at which point a human should agree.
If an existing adapter covers the case — order status from a connected inventory system, calendar, ticket, customer management — it is used. Only when none fits does a tool for a free call against your own address come into being. A new special route is the exception, not the starting point.
The schema names every field the assistant may pass on, and at most twenty of them. Anything not in it is stripped from the request before it goes out. If a required field is missing, no call is made at all; the assistant asks instead.
The target address is registered, the deadline set, and it is settled which response fields may return to the conversation at all. The address is checked before and after name resolution; the call does not follow redirects, and an oversized response is discarded.
For each action it is settled whether it runs automatically or waits for a click, and which role it requires at minimum. Writing tools are hard-set to confirmation anyway. The sentence the visitor reads before clicking is stored alongside and is not regenerated later.
What is tested is not only the successful case but the failure: if the foreign system stays silent, the assistant says so instead of guessing. In operation every call sits in the log with input, result, duration and approval path, and further cases are added as tools of their own.
Between step four and step five lies the point where projects most often get stuck: the target address is in place, but nobody has decided which response fields may return to the conversation at all. Unnamed fields never reach the model — that is the gain, but it costs a decision.
After going live the path stays open: a further case becomes a further tool on the same assistant. The line on your website is not touched for it.
Three things determine the effort: how many cases the assistant is to cover, whether an existing adapter fits or a call of your own is needed, and whether your system already offers an endpoint or has yet to receive one. Which of these applies is clarified before the quotation, not after.
from 4,900 € net setup
Minimum term: none, cancellable monthly
All prices net, plus VAT Source: XICBOT price list, as of 11 September 2026
Individual functions belong to the Individual package: setup from 4,900 € net, with operation based on scope (hosting in Germany, ongoing operation, care, updates, data protection). Included are tailored actions, custom logic, API connections, calculations and configurators; European or self-hosted language models are possible as a separate project by arrangement and are not included in standard operation. Ongoing services are booked individually and can be cancelled monthly; there is no minimum term.
Describe the process the assistant should map. You get a factual assessment of effort, interfaces and permissions before you commit to anything.
Discuss your special case Tools and approvals in the documentation
A builder widget brings a few standard actions but quickly reaches its limits as soon as a case becomes more specific. An individual function starts exactly there: your own data sources, your own logic, real calculations and a deep connection to your systems. The comparison shows where the difference lies in everyday practice.
Individual does not mean uncontrolledA language model can be wrong — which is why the assistant does not calculate itself but asks the system that keeps the figure, and states no value that did not come back. You decide per action what may run automatically and where a human confirms; for creating and changing, that choice falls away — there the confirmation is hard-set.
Individual functions show their value where standard answers are not enough. The following journeys are anonymized and illustrative and show how a specific need becomes a matching function.
ticket_create opens the matter carrying the conversation context — writing, and therefore only after a click by the visitorTalk your case throughDo you have a process in mind that goes beyond standard actions? In the initial conversation we walk through it step by step and name which build form carries it, which details your system needs for it and at which point a human confirms.
„We do not promise a flawless know-it-all. We construct the cases your everyday work needs — bound to your logic, executed with permissions and handed over to a human at any time.“ — Our approach
How an idea becomes an accepted assistant is described in from idea to a live AI chat assistant. Which actions are technically possible and where permissions apply is shown in the AI assistant controls your tools. How a purpose-built assistant differs from a template bot is compared in custom assistant or standard chatbot.
The questions below come from conversations with companies that already had a process in mind. They turn less on what is possible than on who decides in case of doubt and what happens when a connected system does not answer.
Individual functions are your own actions and processes that go beyond the seventeen shapes shipped with the product. The basis is the tool control: a tool is given a schema, a kind — reading, writing or irreversible — and an approval mode. Reading tools may be set to automatic, anything that writes asks first. The way out to your system runs through exactly one connection with target check, time limit and size limit, without redirects and without access to internal addresses. The tool only ever sees its own schema fields; tenant and account identifiers are blocked as field names. This lets us cover cases no construction kit anticipates — a calculation, a configurator or a multi-step process. Overview under custom functions.
Yes, with the calculation happening where the numbers come from: in your system. The assistant guides the steps, collects the details and calls your calculation route. You describe the tool for it yourself — a schema with up to twenty fields, a title up to 120 and a description up to 600 characters; the input is trimmed to that schema before the call, values are capped, and if a required field is missing nothing is executed at all. The call goes to exactly one stored connection, waits at most eight seconds and accepts at most 64 KiB; what comes back are only the result fields you declared. Prices therefore come out of your logic, not out of the language model. More under custom functions.
In the Custom package, through tools you create per assistant: inventory, CRM, calendar, ticketing or an interface of your own. Every tool carries a kind, namely read, write or irreversible, and an approval mode; the preset is to ask back before executing. Kind and schema come from the register and not from the request. Outward, every call takes the same path: the target address is checked before the fetch, and the resolved addresses are checked rather than the name alone, redirects are not followed, a response above 64 KiB is aborted, and a deadline of eight seconds applies. Whatever comes back is filtered down to the declared result fields. More under tool control.
Yes. Every tool carries an approval mode, and the default is confirmation. Without confirmation only something that reads and is explicitly set to automatic will run; every non-reading kind is forced to confirmation when created or changed, no matter what the request says. A call that requires confirmation first ends in the state proposed and executes nothing: the visitor reads the input in plain text, and only their click triggers execution. Every call leaves a log row that is written before execution and updated afterwards, and knows seven states from proposed to deadline exceeded. The model is offered only what you have entered, switched to active and allowed for the role of the conversation.
Yes, in the Custom package. We chain individual actions into a continuous process — for example read out, calculate, create a document, create a ticket and hand over the lead. This creates a path without media breaks in which each step has its own permission: anything that does more than read is first shown to the visitor as a proposal and confirmed by them. The chain is bounded so it cannot run away: per answer the assistant performs at most five tool calls, and only one when the monthly allowance is tight. Every single call is then recorded in the log, with input, result, duration and the path by which it was approved.
Individual functions belong to the Custom package with a setup from 4,900 € net; operation follows the scope and includes hosting in Germany, care, updates and data protection. There is no list price for operation there, because the number and type of connected systems determine the effort. The package holds 50 seats, 25 assistants, 250 knowledge sources and 20,000 documents and allows tool and API control with custom actions and workflows. We name the binding scope after a free initial consultation. All packages are listed under pricing, typical cases under references. All services can be cancelled monthly; there is no minimum term.
If a question about your case remains, it is usually a question for your own system: is there an endpoint there, and which fields does it hand out? We clarify both in the initial conversation, before anything is set up.
Before the setup
It goes fastest if you bring a real case rather than a feature list: the sentence a visitor says, the answer they should get, and the name of the system that knows it. From that it can be said whether an existing adapter suffices or a call of your own is needed. Describe your case
Describe briefly the process the assistant should cover — and, if you know it, which system keeps the data for it. We report back which build form fits, which details your endpoint would have to supply and where a confirmation becomes necessary. You can reach us by phone at +49 5123 9579000.