How SupportMe Sorts Your Edits Into Style and Knowledge

When you edit a draft in SupportMe, the change is used for learning. SupportMe compares its draft with the reply you actually send. It then uses that difference, called the diff, to update two things: your writing style profile, which covers how you say things, and your knowledge base, which covers what you say. Nothing is sent until you approve it.

This post covers what SupportMe has confirmed about this process and what it hasn't yet explained. It then shows how to think about your own edits so that each one teaches the tool something useful.

What SupportMe has confirmed

SupportMe is still in its pre-launch waitlist phase. The SupportMe website and the product materials describe a four-step workflow:

1. Connect your channels. This means your email inbox or your app store review accounts (iOS and Android).
2. The AI drafts a reply. It writes in your style and draws on your knowledge base.
3. You review and send. You can edit the draft, send it as it is, or reject it. Nothing goes out automatically.
4. SupportMe learns the diff. It compares its draft with your final version, then updates your writing style profile and knowledge base automatically.

Two claims from the product description matter most here:

• Style learning happens through diff analysis. The AI compares its draft with your edits and adjusts to your way of writing over time.
• The knowledge base builds itself. You don't have to write documentation by hand. It grows from real conversations.

What hasn't been published: SupportMe hasn't shared the technical details of how it decides whether an edit is about style or about knowledge. It also hasn't said what happens when one edit is both, or how it weighs a single edit against a long-running pattern. The rest of this post explains the general idea and uses hypothetical examples. It doesn't describe SupportMe's internal logic.

Style vs. knowledge: what's the difference?

It helps to ask one question about every edit: would this change still make sense if the customer had asked something completely different?

Style edits: how you say it

A style edit changes your voice, not the facts. Some common examples:

• Changing "Dear customer" to "Hey Sam"
• Cutting a three-sentence apology down to "Sorry about that!"
• Removing corporate filler like "We value your feedback"
• Replacing a long paragraph with a short bulleted list
• Adding your usual sign-off, such as "– Alex, maker of [app]"

These edits apply to almost any reply you write. They belong in a writing style profile, which is a description of your habits that should shape every future draft.

Knowledge edits: what you say

A knowledge edit changes the facts, the steps, or the answer itself. Some common examples:

• Correcting a wrong menu path ("Settings → Account" becomes "Preferences → Sync")
• Adding a workaround for a known bug
• Updating a policy detail, such as your refund window or which plans include a feature
• Adding a link to the correct documentation page

These edits matter when a similar question comes up again. They belong in a knowledge base, which is a store of facts the drafts can use when they're relevant.

Mixed edits

Many real edits do both. For example, you might rewrite a stiff paragraph and fix a version number in the same pass. The diff holds both signals. The product description says one diff can update both the style profile and the knowledge base. It doesn't say how the two signals are pulled apart.

A hypothetical example

This exchange is made up for illustration. It doesn't come from a real SupportMe user.

Customer: "My exports keep failing on the free plan. Is that a bug?"

AI draft:

Dear valued customer, thank you for reaching out. We apologize for any inconvenience. Exports may fail for various reasons. Please try again later or contact us if the issue persists.

Your final reply:

Hi Jordan! Not a bug. The free plan caps exports at 50 rows, which is why it's stopping. You can split the export into smaller chunks, or the Pro plan removes the limit. Happy to help if you get stuck.

Here is one reasonable way to sort that diff:

| Change | Type | Why | |---|---|---| | "Dear valued customer" → "Hi Jordan!" | Style | Applies to almost any reply | | Removed the generic apology | Style | Shows you prefer to get straight to the point | | Added the 50-row export cap on the free plan | Knowledge | A fact that only matters for export questions | | Added the split-the-export workaround | Knowledge | A reusable fix for the same problem | | "Happy to help if you get stuck" | Style | A closing habit you use often |

If the learning works as described, the next draft to any customer should sound more like the "Hi Jordan!" version. The next export question should also mention the row limit, without you having to type it again.

How other systems approach this

Learning from edits is an active research area, and it helps to know how others have handled it. In a NeurIPS 2024 paper, Gao et al. present PRELUDE, a framework in which an LLM agent looks at a user's past edits and infers a written description of what that user prefers. That description is then used to guide future responses. Their algorithm, CIPHER, looks up the preferences it inferred from similar past situations and combines them. In simulated summarization and email-writing tasks, it reduced how much users needed to edit compared with the baselines.

The paper makes a few points that apply here:

• Written preferences are easier to inspect. The authors note that expressing learned preferences in plain language lets users view and modify them. You can't do that when the learning is hidden inside model weights.
• Context matters. CIPHER learns preferences tied to the situation, because what someone wants can depend on the task.
• Human testing was future work. The evaluation used a simulated GPT-4 user, and the authors list testing with real humans as a next step.

This research doesn't describe how SupportMe is built. It does show that splitting edits into reusable preferences and situation-specific information is a recognized approach, not just a marketing idea.

The "diff" itself is a standard technique. Tools like Python's difflib compare two versions of a text and mark what was added, removed, or changed. Deciding what a change means, whether it's tone or fact, is the harder part that sits on top of that.

How to make your edits easier to learn from

These are practical suggestions based on the style-versus-knowledge split. They aren't official SupportMe guidance.

• Fix facts precisely. If a draft gets a policy wrong, correct it with the exact detail ("14-day refund window," not "a couple of weeks"). A vague fix gives the knowledge base less to store.
• Keep your style edits consistent. If you always cut the opening apology, keep cutting it. A repeated pattern is a clearer signal than a one-off.
• Don't add one-off details that don't belong in the reply. A personal remark to a single customer ("Say hi to the team in Berlin!") is fine to send. Just remember that every edit is treated as a learning signal.
• Reject a draft that's completely wrong. You can reject any draft. When a draft is off in every way, writing your own reply from scratch may be clearer than making dozens of small edits.
• Check that your knowledge is still current. A self-building knowledge base learns from what you send. If your pricing or features change, your next edits are what update it.

Conclusion

SupportMe's documented behavior is simple. It compares each draft with the reply you actually send, and it uses the difference to update both your writing style profile and your knowledge base. It's easiest to think of edits in two groups: style edits are about how you say things and apply everywhere, while knowledge edits are about what's true and apply when the topic comes up again. SupportMe hasn't yet published how it tells the two apart, so treat the examples here as a guide to thinking about your edits, not a description of its internals. Edits that are clear and consistent are the easiest for any system that learns from edits to use.

References

• SupportMe: support-me.dev
• Gao, G., Taymanov, A., Salinas, E., Mineiro, P., & Misra, D. (2024). Aligning LLM Agents by Learning Latent Preference from User Edits. NeurIPS 2024. Code: github.com/gao-g/prelude
• Python Software Foundation: difflib — Helpers for computing deltas