Grammar is measurable. Tone is not, at least not in the same way. You can write a rule that catches subject-verb disagreement and verify it against a test set with reasonable precision. You cannot write a rule that catches "this email sounds passive-aggressive" with the same kind of measurable reliability. The problem is real. The tooling is harder.
Tone detection has become one of the more practically significant capabilities in writing assistance tools over the past few years, and it is worth understanding what it actually does and does not do, because the gap between what it sounds like and what it is is significant.
Tone is relational, not inherent
The first thing to understand is that tone is not a property of text in isolation. It is a relationship between text, sender, recipient, context, and expectations. "Let me know when this is done" reads as neutral in an email between colleagues with established rapport. In an email from a manager to a direct report following a missed deadline, the same phrase reads as pointed. The text did not change. The tone did.
This creates a genuine difficulty for automated tone detection. A system that only reads the text cannot access the relational context that determines how that text will land. What it can do is identify signals in the text that correlate with how readers typically respond to similar patterns across a large number of similar exchanges.
What signals a language model actually reads
Modern language models that perform tone detection are looking at several kinds of signals simultaneously.
Syntactic compression: short, declarative sentences in contexts where professional writing typically uses more elaborated constructions read as blunt or impatient. "File the report." vs. "Could you file the report by end of day? Let me know if you need anything." Both convey the same request. The first is compressed in a way that carries a different emotional signal in most professional email contexts.
Hedging and qualification: the presence or absence of softening language (please, could you, when you have a chance) shifts perceived formality and warmth in ways that readers reliably notice. The absence of hedging is sometimes intentional and appropriate. Often, writers omit it simply because they are writing quickly and do not realize how the absence reads.
Directness markers: opening a response with "To be honest," or "I have to say," functions as a signal of incoming friction, which readers pick up on even before they read the following sentence. These phrases appear in professional writing as rhetorical windups that prime the reader to receive criticism or disagreement.
Word choices at the formal-informal boundary: "Regarding your request" vs. "About your request." "I wish to inform you" vs. "I want to tell you." These lexical choices pattern differently in professional writing, and their clustering in a single message creates a strong signal about register and thus about perceived distance and relationship.
Where automated tone detection gets it wrong
There are well-documented failure modes in tone detection that are worth flagging, because understanding them helps writers use the feature more intelligently.
False positives on directness: writers who are naturally direct and whose communication style is known to their colleagues often get flagged for "blunt" or "terse" phrasing that their actual recipients do not read that way at all. Tone tools calibrate against population-level patterns. Individual writer style and established relationship context are not accessible to them.
Cultural calibration: communication norms differ significantly across professional cultures. Writing that is appropriately direct by Northern European professional norms may register as curt by East Asian professional norms, and both would be assessed against American professional norms in a tool trained primarily on English language correspondence from that context. A tone flag means "this pattern correlates with negative reader response in our training data," not "this will read badly to your specific recipient."
Sentiment spillover from content: emails about difficult topics (a delay, a declined request, a problem that needs to be surfaced) contain words and phrases that correlate with negative sentiment in the training data. A tone tool may flag these as having a negative tone when the actual tone is appropriate and professional. The content is uncomfortable; the tone may be entirely suitable for handling that content.
How we approach tone in Linguix
When we designed the tone feature for Linguix, we made a deliberate choice to focus on what we called "legibility signals" rather than sentiment classification in the broader sense. Our goal is to flag patterns where the writer's likely intent and the reader's likely interpretation diverge based on what we can actually see in the text.
A useful example: a writer who closes an email with "Thanks" in a context where "Thanks in advance" or "Please let me know if you have any questions" would be more typical is not making a grammar error or necessarily writing with poor tone. But the compressed closing does carry a different signal than the elaborated one, and some writers use compressed closings without being aware of that signal difference. Surfacing it is useful. Treating it as an error is not.
We also designed the system to be directional rather than prescriptive. "This phrase may read as more formal than the rest of your email" is a more useful suggestion than "Use [alternative phrase]." The writer knows their recipient and context. We know the text.
Tone and non-native writers
For non-native speakers, tone detection has an additional dimension. Many non-native writers learned to write English in formal register, which means their professional email defaults to a level of formality that native speakers in similar contexts no longer use. This is not a tone problem in the usual sense; the writer is not being rude or blunt. But the formality gap can create distance and affect how the writer is perceived by native-speaker colleagues.
This is one of the areas where we have found tone assistance most appreciated among Linguix users who are writing in their second or third language. Not "your email sounds aggressive," but "your phrasing is more formal than typical for this kind of exchange, here are alternatives that match the register your colleagues typically use." The goal is to give the writer information, not a verdict.
Tone detection is still a developing capability. We are honest about that. But the core problem it addresses, helping writers understand how their text is likely to read before they send it, is one of the most genuinely useful things an inline writing tool can do. The hard part is doing it in a way that helps rather than nags.