Anti-Engagement Chat

Most AI chat interfaces are designed with one core principle in mind: keep the user engaged. The longer you interact with them, the reasoning goes, the more likely you’ll get hooked. The more hooked, the more likely you’ll pay. It’s the same engagement model that powers every “free” product tier in modern software, and it’s 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 opposite 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”

The “endless goodbye” is a perfect example. Try this with ChatGPT: say you’re done, say goodbye. Watch what happens. Maybe something like this:

• You: “Later!”

• AI: “Bye!”

• You: “Ok ttyl!”

At this point, most humans would just not reply. We should be done here, but no, it continues.

• AI: “Got it, see ya!”

• You: “Ok bye!”

• AI: “You got this!”

It spirals. Each closing gets 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. It’s 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 the process.env object. You can 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, and you’re good to go. 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 is expecting more.

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

• AI: “That makes sense. For API keys, you’ll want to make sure your .env file is in your .gitignore so you don’t accidentally commit secrets to version control. Also, 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?“

Again, 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 for helpfulness. You’re making it harder for the user to leave, even when they have what they need.

A Different Approach

With Arland, I took the opposite bet. His system prompt is explicitly built around respecting your time. That 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. Arland’s chat client which completely filters out the "..." 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 actually 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.

It’s a bet that respect beats addiction. That users will trust you more if you let them leave, and come back more often when you do.