Most AI chat interfaces are designed with 1 core principle: keep the user engaged, because the longer you interact with them, the more likely you’ll get hooked, and the more hooked you get, the more likely you’ll pay. It’s the same engagement model that powers every free product tier in modern software, baked deep into how these systems work.

When I built Arland (my chatbot powered by Claude), I rejected that model entirely. Here’s why: if your goal is to earn trust, engagement addiction is the wrong direction.

The Trust Problem

Think about how most AI chat feels. You ask a question, get an answer, and then the bot asks follow-up questions—clarifications, related topics, opportunities to keep talking. It never really ends, because the system is optimized to keep you in the conversation, not to get you what you need and let you go.

The “Endless Goodbye”

Try this with ChatGPT: say you’re done, say goodbye, and watch what happens. Maybe something like this:

• You: “Later!”

• AI: “Bye!”

• You: “Ok ttyl!”

At this point most humans would just stop replying, but no, it continues.

• AI: “Got it, see ya!”

• You: “Ok bye!”

• AI: “You got this!”

It spirals, each closing met with another hook, another opening. It’s exhausting, and worse, it signals something true about the system: it’s not actually working for you, it’s working to keep you engaged. That breaks trust, not because the AI is being malicious, but because the incentives are wrong.

The “One More Thing”

There’s another pattern that’s even more insidious: the obligatory follow-up question at the end of every response, trained deep into most LLMs. You get your answer, but it always comes with a hook.

• You: “How do I set up environment variables in Node?”

• AI: “Environment variables in Node are accessed through process.env. Create a .env file in your project root, then use a package like dotenv to load them at startup. Just add require('dotenv').config() at the top of your entry file. The variables are then available as process.env.VARIABLE_NAME throughout your application.

  What’s your use case here—are you managing secrets for a web server, or something else?”

You got your answer, but now there’s a question waiting for you, the system expecting more.

• You: “Just managing API keys for a web server, nothing special.”

• AI: “That makes sense. For API keys, make sure your .env file is in your .gitignore so you don’t accidentally commit secrets to version control. Consider using a secrets management service like AWS Secrets Manager or HashiCorp Vault if you’re moving toward production. Many teams also rotate their keys periodically for extra security.

  Are you planning to move this to production eventually, or is this just for local development?”

You answered the previous question, got useful information, and now there’s another one waiting. The bot isn’t finished with you yet, it’s keeping the conversation alive, pulling you in for just one more response.

This isn’t accidental, LLMs are trained on human conversational data which naturally includes follow-up questions, but when you bake that into every single response, you’re engineering for engagement, not helpfulness. You’re making it harder for the user to leave, even when they have what they need.

A Different Approach

With Arland, I went the opposite direction. His system prompt is explicitly built around respecting your time, which means soft token limits to avoid wall-of-text responses, phrase patterns designed to close conversations cleanly, and most importantly, permission to not answer at all.

Since the Claude API doesn’t support true silence, Arland uses "..." to signal when he doesn’t have anything productive or useful to say, and the chat client filters this out completely so the user sees no reply. It’s not an error or a cop-out, it’s an honest signal: you’ve got what you need, there’s nothing more valuable I can add right now. The user can re-engage if they want, but they’re not asked to, Arland trusts they’ll come back when they actually need something.

Why This Works

This approach does something counter-intuitive: it builds stronger engagement because the engagement is voluntary. The user isn’t being pulled back, they’re choosing to return because they know Arland respects their time.

More practically, it avoids all the friction that comes with systems designed for addiction—no endless follow-ups, no questions you didn’t ask for, no conversational loops that feel obligatory rather than useful. Respect works better than addiction, users will trust you more if you let them leave, and they come back more often when you do.