Marvin best practices

Keep real data on a trusted provider

In production, keep the active provider set to the self-hosted local server. Real client data must never be sent to a third-party API by accident. Marvin enforces this with a guard, but the setting is your first line of defence.

Only lift the third-party restriction where the law allows it

The “Allow third-party AI providers to process real data” switch is off by default and should stay off for any workspace subject to GDPR or EU data-protection law. Turn it on only when your company and your clients are outside the EU/EEA and you have checked your own jurisdiction's rules. Turning it on means OpenAI, DeepSeek, Grok or Claude may receive real workspace data.

Use development mode for experiments

When trying a new prompt or comparing engines, switch the environment to Development and use fake records only. Never point Development mode at real data.

Write a clear persona

Set a system persona that tells Marvin to answer only from the data provided and to never invent figures, dates or names. A good persona dramatically reduces wrong answers from smaller self-hosted models.

Keep answers short

Lower the max-token setting for faster, cheaper, more focused replies. Most data questions need only a sentence or two.

Treat AI-created records as real records

Marvin can create projects, tasks, milestones, clients, leads, team members and financial documents. Two habits keep that safe:

• Get permissions right first. Marvin can only do what the person asking could already do in the UI, so the protection you want is the permission you set on the role — not a setting inside Marvin.
• Read the confirmation. Marvin shows what it is about to create and waits for a yes. That preview is the moment to catch a misheard client name or amount.

Let NIZU do the arithmetic

Marvin narrates figures that NIZU calculated; it does not add numbers up itself. Keep it that way when extending it — a language model that computes totals will eventually compute a wrong one, and financial answers must match the reports module exactly.

Curate the website widget's knowledge

The public widget answers anonymous visitors, so whatever you put in its knowledge base is effectively published. Practical rules:

• Write the knowledge base as answers to real visitor questions — opening hours, pricing model, trial, shipping, how to contact a human.
• Never put client names, figures or internal policy in it. The widget cannot reach private data, and its knowledge should not smuggle any in.
• Restrict the widget to your own domains with the allowed-domains list, so your site key cannot be reused on someone else's site.
• Re-read it after a price or policy change. A confidently wrong answer to a visitor is worse than no answer.

Answer the hand-offs quickly

When the widget cannot help, it marks the conversation waiting and notifies your team by email and optionally Telegram. Set the auto-close window to a period you can realistically respond within, and switch on “open a ticket when a conversation auto-closes” so a sleeping conversation becomes a tracked ticket rather than disappearing.

Review the Closed tab

The Closed filter in the website-chat inbox shows guest conversations that ended without ever becoming a ticket. Reading it periodically is the cheapest product research you will do: it is a list of what visitors asked when nobody followed up, and each message shows the page they were on when they asked.

Review conversations

Check Marvin → Conversations periodically to see how Marvin is answering internally. Because every exchange is stored, you can catch and correct weak phrasing early.

Respect privacy

• Conversations are kept for oversight and inherit your normal data-protection duties.
• A user deletion or erasure request removes that person's threads through the standard soft-delete.
• Website-widget sessions store a visitor's name, email, IP, pages visited and user agent — cover them in your privacy notice, and only ask for name and email if you will use them.
• Only administrators should have access to the conversation overview.

Size the hardware to the model

On the self-hosted server, VRAM is the limit. A 7–8B model at Q4_K_M fits an 8 GB card comfortably; avoid 13B+ models on that hardware. If you also run the self-hosted voice, leave headroom for it.