A customer or partner sets up the Artific platform along four questions: how users interact with it, how customers are separated from each other, what you configure, and whether their own systems should get access to AI through the platform. Use this page to shape the setup.
How do users interact with the system?
How do you roll out customers on the platform?
Which context and capabilities do you want to set up?
Do you want systems to get access to AI through the platform?
This is what the customer already knows and tells you first. A customer often chooses several forms, one per audience: their own employees in the workspace, visitors through a widget, their own system through the API.
Users log in to the Artific portal and work there: they chat with assistants, run toolbox elements and use files, projects and the knowledge base. Admins set everything up in the same environment. Nothing needs to be installed or built on the customer's side.
The customer's own employees work with AI every day and the customer wants administration in the same environment.
The portal carries the organization's branding. With a shared organization (B2), all end customers therefore see the same branding.
The customer places a small snippet of code on their website or in their app, and the Artific chat window appears there in their own colors. The customer doesn't build a chat themselves. The window can work anonymously or recognize the customer's logged-in user, and the website can steer the conversation and pass along information. New chat window capabilities, such as voice or sending files, reach the customer automatically.
The customer wants to help their own visitors or users and is happy with a chat window in their own colors.
The assistant responds in a channel the end user already uses: it answers an email or takes a phone call. The end user doesn't need to install anything or log in anywhere, and doesn't notice there's a platform behind it.
The end users already make contact through that channel and you don't want to change their behavior.
Email and telephony are available today. Channels such as WhatsApp and Teams are in development.
The customer builds the screens themselves, in their own product, and sends questions to the platform. The platform returns the answer and the customer displays it in their own design. The end user only sees the customer's product. How the customer connects is covered in D: their own software, a workflow tool or their own agent.
The customer has their own product that the conversation needs to fit into natively.
There is no user typing anything. A point in time or an event starts the assistant, for example a report every morning at nine, or a confirmation as soon as an order comes in. The result lands in a system, a mailbox or the portal. The one question that matters is where the playbook lives, and that immediately determines the need for "headless integration" (options D).
In the portal you configure an assistant to carry out a task at a set time, or as soon as another system sends a webhook. Task, prompt and destination live in the platform. The customer doesn't program anything and can see whether it succeeded.
Their software, workflow tool or agent calls assistants and elements in the platform and decides the next steps itself. The same considerations as A4.
Scheduling background tasks in the portal is in development. The variant from their own system is already possible today via the API.
Does every customer or end customer get their own organization, or do they share one? This is the question the customer usually doesn't ask, and the one that determines the most about administration, separation, branding and what a customer can add themselves.
Every customer has their own, isolated environment. Only their own admin decides who has access, which assistants exist, which files and connections are in it and what it looks like. None of that is visible to other customers. The trade-off is that each environment is set up and maintained separately.
The customer wants to manage it themselves, wants to add their own connections, files or sources, has data that must stay strictly separated, or wants their own branding.
More setup work per customer.
All end customers work in the same environment and one party manages it. With groups you determine which end customer sees which assistants and sources. It's quick to set up and cheap to manage. But everything you add to the environment applies to everyone: one branding, one set of connections, one set of files and sources. An end customer can't add anything of their own and can't get admin rights, because they would then see the other end customers' data.
One party is the admin, the end customers only use it, and the offering can be the same for all end customers.
The entire configuration from C applies to all end customers at once here: one branding, one set of connections, one knowledge base. End customers can't add anything of their own and can never get admin rights. As soon as that's needed, that end customer has to move to their own organization.
Every end customer keeps their own environment, but the assistants and toolbox elements come from a central catalog. You build them once and install them in every environment. When you update the source, every installation picks up that change. Per environment, the end customer can add their own files, connections and instructions, without other end customers seeing them.
You want to roll out the same offering to many customers without giving up separation. Combines the separation of B1 with the convenience of B2.
The marketplace is in development. Today a partner can copy assistants to an end customer's organization; that copy is detached, so later changes to the source don't carry over.
Four conversations you have in every intake. Each has variants, and they differ mainly in who does the work. Building assistants and toolbox elements isn't a separate item; that's the work that rests on this configuration.
How the organization behaves and what is switched on for it. This is the first conversation with the admin, and it touches everything that gets built afterward.
The customer's admin, or Artific or the partner during the initial setup.
This isn't a complete list. Everything that can be configured per organization falls under this; the portal is leading. For an overview of all features, see product.artific.nl.
Access runs through groups: a group determines which assistants, elements and knowledge someone sees. The question is how the customer gets their people in, and whether they log in with their own account or through their own system.
The documents and sources assistants need to know, organized into collections, with per assistant the question of which collections it may use. The question is where the knowledge lives now and how often it changes: individual documents that rarely change, a living source, or an own system that generates knowledge.
The systems in which assistants need to be able to read and act: calendar, CRM, ticketing system, own applications. The assistants then call those systems. What an assistant may do with a connection is set per assistant in the portal.
An assistant consults the customer's CRM, calendar, an API or an MCP server as a tool. The playbook lives in the platform and the admin configures it through the portal.
For most customers the answer is no: everything runs through the portal, the widget and the channels. For customers with their own software, workflow tools or their own AI agents, the platform is the integration layer through which they reach AI securely, with the knowledge, connections and rules configured in the platform. All through the same API and the same permission model.
The customer's systems don't call the platform. Users work in the portal, the widget or a channel, and the entire configuration is set up by an admin.
The customer has no own software or workflows that need AI.
Not possible in combination with A4, nor with A5 if the playbook lives on their side.
A step in n8n, Make or Zapier sends a question to an assistant or element and uses the answer in the next step. This gives existing automation secure access to AI, with the knowledge, tools and rules configured in the platform. No programmers needed, but someone who knows the tool is.
Their system calls assistants and elements in the platform and decides what happens with the answer. The playbook lives in their system.
The customer already automates with such a tool, usually for A5 with the playbook on their side.
Today via a generic HTTP step against the API. A ready-made Artific step for these tools is in development.
The customer's software, with or without AI in it, calls the platform via the API: have assistants answer, run elements, create widget sessions for logged-in users, supply knowledge. With admin rights it can also create organizations, users and assistants. Technically the same connection as D1, but built by developers using the SDK and documentation.
Their system calls assistants and elements in the platform and decides what happens with the answer. The playbook lives in their system.
The customer has their own product (A4), own systems that drive the platform (A5), or wants to pass the logged-in user to the widget (A2).
Answers come back all at once; word-by-word streaming via the API is in development. Usage is reported per organization, not yet per individual connection.
The customer's own agent, or an assistant such as Claude, ChatGPT or Copilot, uses the platform via MCP: consult assistants, run elements, search the knowledge base, and with admin rights configure the platform. The agent decides itself when to call on the platform. The customer doesn't need to program anything, only activate the connection.
Their system calls assistants and elements in the platform and decides what happens with the answer. The playbook lives in their system.
The customer already runs their own agents and wants to include the platform in them without building anything.
Artific as an MCP server is in development; until then D2 is the alternative. Not to be confused with the own MCP server under C4: there an assistant uses their MCP server, here their agent uses the platform.
The same questions as in the intake, in order: experience, structure, then the options from C and D. Go through it once per audience if a customer needs several experiences.