Personalized AI Chat Agents Tutorial

Personalising a chat agent is one field: the system prompt.

Not a training run, not an uploaded knowledge base, not a vector store you manage. You write instructions describing how the assistant should behave, they sit above every message in the conversation, and that is the mechanism.

Which sounds thin until you realise it is also how most production assistants are built. The difference between a useful assistant and a generic one is almost entirely the quality of that text.

What you are actually working with

Chat gives you a conversation, a model selector and a system prompt. Conversations persist, so an agent you set up is still there tomorrow.

Fifteen models sit behind the selector, across every major family: GPT-5.4 and GPT-5.2, Claude Opus 4.7 and Sonnet 4.6, Gemini 2.5 Pro and Flash, o3 and o4-mini, DeepSeek V3 and R1, Grok 4.20, plus the smaller and faster variants of several.

Being able to switch model without changing anything else is the underrated part. The same system prompt on a different model is a genuinely different assistant, and it costs you one dropdown to find out which one suits the job.

Writing a system prompt that works

Most weak assistants come from prompts that describe a personality instead of a job.

Say what it does, not what it is. "You are a helpful assistant" tells the model nothing it did not already assume. "You answer questions about our returns policy using only the policy text the user provides, and say when something is not covered" is an actual specification.

Define the boundary explicitly. What it should refuse, defer, or escalate. An assistant with no stated edge will confidently answer things it should not, and that is where most embarrassing outputs come from.

Fix the format. If you want short answers, say how short. If you want a specific structure, show it. Models comply with format instructions far more reliably than with tone instructions.

Give it the failure line. Tell it what to say when it does not know. Without that, it will invent something, because a confident answer is more probable than an admission.

Keep it as short as it can be. Long system prompts dilute. Every sentence competes for attention with every other sentence, so a focused half-page usually beats two pages.

Choosing a model for the job

Real differences worth knowing, without inventing benchmark numbers:

Reasoning-heavy work — multi-step logic, careful analysis. The o-series and DeepSeek R1 are built for it and take longer per reply.

Long context — feeding in large documents. Gemini models are the usual choice.

Fast, high-volume replies — support triage, classification, anything where latency matters more than depth. Haiku, Flash and the Mini variants.

General quality — where you want the best answer and are less worried about speed. Opus and the full GPT-5 line.

Test one prompt across two models before committing. It costs a minute and tells you more than any comparison article.

What does not exist

Because guides on this topic invent a lot of product.

There is no agent builder with a visual flow editor, no drag-and-drop node canvas.

There is no training or fine-tuning. You are not teaching a model your data. You are giving instructions to a general model in a system prompt.

There is no uploaded knowledge base or vector database. Nothing is indexed and retrieved on your behalf. If the assistant needs to know something, it goes in the prompt or in the conversation.

There is no persistent memory across separate conversations. A conversation keeps its own history; it does not carry facts into a new one.

If you need retrieval over your own documents, that is a thing you build with the API, not something the chat page does for you.

Building something real with the API

Once an assistant is worth deploying, it moves out of the chat page.

/api/v1/chat/completions is OpenAI-compatible, so an existing OpenAI client needs only a new base URL and key. That is usually the entire integration.

Create a key under API keys, and give it a scope and a monthly spending cap. That cap is what stops a retry loop at 3am from becoming a large bill, and it is worth setting before the first request rather than after the first incident.

Full documentation is at Developers, the reference at API docs, and language setup at SDKs. If you want an agent to call generation as a tool, there is an MCP server.

There is a fuller walkthrough in building custom chatbots on the Flixly API.

An honest workflow

1. Write the system prompt as a job description, with an explicit boundary and a failure line.
2. Test it in Chat against the awkward cases, not the easy ones.
3. Switch model, run the same cases again. Keep whichever handles them better.
4. Tighten the prompt where it failed. This is most of the work.
5. Move to the API when it is good enough to deploy, with a capped key.

Step 4 is where the quality comes from. There is no configuration screen that substitutes for it, which is why the posts promising one are selling something that would not help anyway.

Costs depend on model and message length, and are quoted before generation. Pack prices are on the pricing page.