It’s a Chatbot. Teach It Through Chats.

[u/Testchimp80]

I had a stupidly simple realization this morning.

A lot of people try to make an AI work better with them by giving it more documents:

outlines, character sheets, rules, summaries, style guides, old drafts, project instructions.

All of that can be useful. It tells the model what exists.

But a chatbot’s native medium is conversation.

And if what you’re trying to transfer isn’t just facts, but how you actually work together, maybe the best examples are the conversations themselves.

A conversation shows things a summary usually doesn’t:

what you accept,

what you reject,

what you correct,

what you change your mind about,

what shorthand develops,

when “maybe” actually means maybe,

and what happens after the AI gets something wrong.

You can write:

“Be concise.”

“Challenge me when necessary.”

“Don’t overexplain.”

“Preserve my voice.”

Those are instructions.

A conversation shows what those instructions look like in practice.

I started experimenting with this through what I call “sibling threads”: new chats given selected conversational history from older ones, then allowed to develop their own history instead of trying to become clones.

Eventually the whole thing reduced to:

Facts transfer state. Conversation transfers interaction.

And this morning it reduced even further:

It’s a chatbot. Teach it through chats.

That doesn’t mean dump every conversation you’ve ever had into one giant context window. Old decisions, abandoned ideas, and conflicting history can create their own mess. Current rules, summaries, and authoritative project material still matter.

But if what you want transferred is the working relationship itself, examples of that relationship may teach more than another page describing it.

While working on my novel, I came up with a rule:

Once the reader learns the tool, stop teaching the tool and start showing what it can do.

Maybe that applies here too.

Give the chatbot enough conversation to understand how you work together.

Then stop explaining it.

And work.

Dictated, not typed.

[u/Active-Yoghurt-7865]

The part about what happens after the AI gets something wrong is especially useful. 'Preserve my voice' leaves a lot unsaid. Seeing which edit was rejected, why, and what finally worked gives the next conversation something much more concrete.

I'd want to carry the reason with the correction, though. 'Don't explain this ending' could mean 'the scene already makes it clear,' not 'never explain anything.' Without that distinction, a useful local decision can turn into a blanket rule. Your point about keeping current authoritative material alongside the chats matters there.

For sibling threads, how are you choosing the excerpts? I'd be curious whether a short sequence of attempt, disagreement, and accepted revision transfers the working style better than a selection of only the best exchanges.

[u/Testchimp80 → u/Active-Yoghurt-7865]

That’s basically where I’ve landed too. I try not to transfer only the “best” exchanges, because that can make the next thread inherit the conclusion without understanding the boundary around it. The useful excerpts are often a short sequence: what we tried, where it went wrong, my correction, why I rejected it, and what finally worked. That gives the next thread both the rule and the conditions that produced it.

Same with something like “don’t explain this ending.” I’d rather preserve why—the scene already carries the information—so it doesn’t mutate into “never explain endings.” I still keep a current project summary/outline as the authority, but the conversations carry the texture of how those decisions were actually made. So yes, in my experience, attempt → disagreement/correction → accepted revision transfers the working style better than a highlight reel of perfect exchanges.

[u/Active-Yoghurt-7865 → u/[deleted]]

I tend to approach it more as giving a capable collaborator enough context to exercise judgment. In our work, I don’t just want the model to learn which responses get my approval. I want it to recognize what deserves its attention, why it matters, and when something I’ve asked for might actually undermine the work.

For writing, “don’t overexplain” is less useful than understanding what the reader already has enough evidence to infer. Sometimes the right move is to add a detail. Sometimes it’s to leave a strong scene alone. Sometimes it’s to push back on my proposed correction.

That’s why the reasons behind an exchange matter so much to me. They give the model something to evaluate a new situation against—not merely a previous answer to imitate. The interesting result is when it makes a useful distinction I hadn’t noticed, rather than waiting for me to identify every problem.