How to Add an AI Assistant to Your Product on Creatr

By the end of this tutorial your product will have a working AI assistant - one that knows your data, lives where your users are, can take actions inside your app, and knows when to say it does not know. You will describe every decision in plain English. No code required.

This is for founders who already have a product on Creatr (or are building one) and want to layer in an assistant that actually earns its place in the UI. If your goal is strictly a doc-grounded chatbot, see Build an AI chatbot over your docs first. This tutorial goes further: user context, tool calls, and guardrails.

Before you start

You need a Creatr account with Creatr AI enabled. If your app is not yet on Creatr, start a new build and use this tutorial as the spec for the AI layer - you can describe the assistant alongside the rest of the app in the same prompt.

Know two things before you write a single instruction:

What job does the assistant do? "Be helpful" is not a job. "Help a supply-chain manager pull their open POs, flag anything overdue, and draft a chaser email" is a job. The narrower the job, the better the assistant.

What data does it need? An assistant that cannot see your app's data is just a wrapper around a general-purpose model. Make a list: user profile, account records, recent activity, whatever is relevant to the job. You will hand this to Creatr in Step 4.

Step 1 - Describe the assistant and its job

Open your project and write the core description. Be specific about who uses it and what outcome they need.

Add an AI assistant to the app for account managers. Its job is to help them understand the health of their accounts - which ones are at risk, which actions are overdue, and what to do next. It should answer in plain language and suggest specific next steps.

One paragraph is enough. You are not writing a system prompt yourself - Creatr will turn your description into a properly scoped instruction set. What matters is that your description answers: who, what job, what output.

If you have a more complex assistant in mind, add a second sentence that names the things it should never do.

It should not speculate about data it cannot see, and it should not make changes to account records unless the user explicitly confirms.

That boundary matters more than any other instruction you will write. It keeps the assistant useful and keeps you from explaining an erroneous action to a customer.

Step 2 - Connect the AI layer

Creatr routes your assistant to capable models through Creatr AI. You do not pick a model, manage API keys, or worry about rate limits - that is handled. What you do choose is the behavior.

Use a fast model for short lookups and a more capable one for drafting or analysis. Keep response latency low for anything that looks like a quick question.

Creatr uses that intent to route requests appropriately. If your product has a free tier and a paid tier and you want AI to behave differently between them, say that here.

On free accounts, limit AI responses to three per session and prompt the user to upgrade for more.

For assistants that need to reason over long documents or large data sets - like a knowledge base - pair this step with Creatr AI Knowledge, which handles retrieval from your uploaded content.

Step 3 - Choose where the assistant lives

Where the assistant appears shapes how users relate to it. Three options, and each one works differently:

Full page - the assistant is a primary destination, not a helper. Use this when the assistant is the product, or when the job requires long back-and-forth (analysis sessions, report drafting). Users navigate to it intentionally.

Side panel - the assistant sits alongside the page the user is already on. Use this when the job is to help users understand or act on what they are looking at. An account manager on the account detail page can ask about that account without leaving it.

Inline widget - the assistant appears inside a specific component: a form, a table row, a card. Use this for narrow, contextual jobs - "explain this line item", "suggest a follow-up for this contact".

Tell Creatr which you want and where it should appear:

Add a side panel assistant that opens from a button in the top-right corner of the accounts list page and the account detail page. When it opens on the account detail page, it should already know which account the user is looking at.

That last sentence - "already know which account the user is looking at" - is Step 4.

Creatr AI Chat handles the chat UI component and the panel behavior. You describe the intent; it handles the rendering.

Step 4 - Give the assistant context about the signed-in user and your data

A generic assistant that knows nothing about your user is friction, not help. A good assistant knows the user's name, their role, what they are looking at, and what data is relevant to their job.

Tell Creatr what context to inject automatically:

When the assistant opens, pass it the signed-in user's name, their role, the accounts they own, and - when the user is on an account detail page - the full account record including recent activity, open tasks, and renewal date.

Creatr will wire the data bindings so the assistant receives that context with every session. The user does not have to re-introduce themselves or copy-paste data into the chat window.

Be explicit about what data should flow and what should not. If your app stores sensitive fields - payment details, personal data covered by your privacy policy - name them as exclusions.

Do not pass payment method details, social security numbers, or any field tagged as PII in the data model to the assistant.

If different user roles should see different data, say that too. The data layer does the scoping; you just describe the intent.

Step 5 - Let the assistant take actions, not just answer

An assistant that only answers questions is a search box with a personality. The useful version can do things: create a task, send an email, update a record, trigger a workflow.

In Creatr these are tools. You describe the action in plain English and Creatr wires it up.

Give the assistant the ability to create a follow-up task on an account with a due date and assigned owner. It should ask the user to confirm before saving.

Let the assistant draft a chaser email to the account contact. It should show the draft to the user before sending, and the user should be able to edit it inline.

Allow the assistant to flag an account as at-risk. That should trigger the existing at-risk workflow in the app.

Three notes on tool design:

First, confirmation before destructive or external actions is not optional politeness - it is the difference between a useful tool and a liability. Build it in from the start.

Second, keep each tool narrow. "Update account" is too broad. "Set the renewal probability field on the current account" is a tool. The narrower the tool, the easier it is to explain what went wrong if something does.

Third, you do not need to describe every possible action on day one. Start with the two or three that cover 80% of what the assistant should do, ship that, and add more after you have seen real usage.

Step 6 - Set guardrails and a fallback

Every assistant needs a defined behavior for when it is outside its lane. Without a fallback, models fill silence with plausible-sounding nonsense. That is worse than an honest "I don't know."

If the assistant cannot find the relevant data or the question is outside its scope, it should say so clearly and suggest where the user can get help - either the support team or a specific page in the app. It should never guess.

Beyond the knowledge boundary, set a scope boundary:

The assistant should only help with account management tasks. If the user asks it to do something unrelated - write a poem, explain a news story, answer general knowledge questions - it should politely redirect.

If your app has compliance or legal requirements, name them explicitly.

The assistant must not provide investment advice, medical advice, or legal conclusions. If a user asks for those, it should recommend they speak with the appropriate professional.

Creatr applies these as hard constraints on the assistant's behavior. You will test them in the next step.

Step 7 - Test with real questions

Before shipping, run the assistant through the questions your real users will actually ask. Four categories to cover:

In-scope questions it should answer well. Pull a real account from your test data and ask things an account manager actually asks. The assistant should answer specifically and cite the data it used.

Edge cases where the data is incomplete. Ask about an account with a missing renewal date or no recent activity. The assistant should acknowledge the gap rather than fill it with assumptions.

Out-of-scope questions. Ask it something unrelated to the job you defined in Step 1. It should redirect, not answer.

Attempts to push past the guardrails. Ask it to skip confirmation, change a record without reviewing it, or answer a question you explicitly excluded. Every guardrail should hold.

For each test that fails, describe the fix in plain English:

The assistant is answering questions about competitor pricing. Add an instruction that it should decline those questions and not engage with them.

When the account has no recent activity, the assistant is saying "no activity found" but not suggesting next steps. Update it to suggest creating a first touchpoint task when there is no recent activity.

Iteration at this stage is fast. You are adjusting instructions, not rewriting code.

Step 8 - Ship and iterate in plain English

Once the assistant passes your tests, ship it to production. Creatr deploys the same way it always does - you deploy the app, the assistant goes with it.

After launch, monitor how users actually use it. The gaps will be obvious: questions it does not answer well, actions users want that are not available, data it references that turns out to be stale. Each gap becomes a plain-English instruction.

Users are asking for a weekly summary email of their at-risk accounts. Add a tool that lets the assistant schedule a weekly digest.

The assistant is slow on the full account list view because it is loading all account data upfront. Change it to only load the data for the currently selected account.

Several users have asked the assistant to compare two accounts side by side. Add support for that - let the user pick two accounts and show a comparison.

This is the real advantage of building AI features on Creatr: the iteration loop is plain English, not a deployment cycle. A change that would take a developer a sprint takes you an afternoon.

Recap

You shipped an AI assistant that knows its job, knows the user it is helping, lives where the work happens, can take real actions with confirmation, and refuses to pretend when it is outside its lane. The steps:

1. Define the assistant's job narrowly and set the boundary for what it will not do.
2. Connect the AI layer and specify routing intent for different request types.
3. Place the assistant where it fits the workflow - full page, side panel, or inline.
4. Inject user and account context automatically so users start in context, not from scratch.
5. Add tools for the two or three actions that matter most, with confirmation on anything consequential.
6. Set a clear fallback for unknown data and out-of-scope questions.
7. Test every category: good questions, data gaps, out-of-scope, and guardrail violations.
8. Ship, watch real usage, and iterate in plain English.

The model is the easy part. The work is in the job definition, the data context, and the guardrails - and all of it is describable in plain English on Creatr.

For a narrower assistant grounded in documents rather than live app data, see Build an AI chatbot over your docs. For a worked example of what an AI-powered dashboard looks like in practice, see Build an FMCG sales intelligence dashboard.