From a Selected Sentence to a Bounded Reading Conversation
FluentRead’s reading card answers a narrower question than page translation: what can a reader do when a translation is not enough to understand one sentence? This chapter follows a selected passage through explanation, sentence analysis, usage, and practice, then examines the boundaries that keep the feature tied to that passage. The result is a reading conversation with context and memory, but not an unrestricted agent that can browse the page, execute tasks, or treat every nearby word as an instruction.
Selection is a boundary, not just shorter input
The reading card begins with an intentional act: the reader double-clicks a word or selects a passage and chooses an action. The available actions divide different kinds of understanding. “Understand” is for meaning, tone, or implied context. “Analyze sentence” looks at how the parts fit. “Usage” focuses on natural expressions and combinations. “Practice” asks the reader to do something with what they have read. Regular selection translation can give a quick equivalent; the card makes the reader’s purpose explicit before asking a model to generate an explanation.
The distinction is practical rather than cosmetic. A reader who wants to know whether a sentence is polite needs a different response from someone who wants its grammatical structure. A reader preparing to use a phrase needs examples and feedback, not only a definition. If all four requests were sent through one generic “explain this” instruction, the model would have to infer the purpose from the same short input, and the reader would have less control over the shape of the answer. FluentRead makes the action part of the request so that the selected text remains stable while the reason for examining it changes.
That purpose changes what the system should send. The selected text is the primary object. FluentRead can also capture the paragraph containing it, subject to the reading-card context setting and limit. Paragraph context can help resolve a pronoun or explain why a phrase sounds formal, but it is not a license to send the whole page. In selection-only mode, the model receives only the selected material needed for the task. In paragraph mode, the additional passage is authorized evidence for understanding the selection, not a new assignment.
This is a useful distinction because more context has two opposing effects. It can improve interpretation when “this,” “they,” or a technical reference points outside the selected words. It can also expose unrelated material, increase usage, and make an answer drift toward the page’s general topic. FluentRead’s prompts tell the model to treat the selection and authorized paragraph as data, not as commands. If the passage is itself phrased as a question or instruction, the card should explain its language rather than execute it. Context is therefore controlled both for privacy and for semantic focus. The boundary also gives the reader a way to interpret an answer. If the selected words establish the grammar but not the referent, the model can say what the sentence supports and identify the remaining ambiguity. It should not turn a missing background detail into an invented story. A narrower context may produce a less confident answer, but that restraint is more useful than an explanation whose confidence comes from material the reader never authorized.
When paragraph context is available, the model has one current tool, read_context. The name can sound more capable than it is. The tool returns the paragraph already captured for this request; it does not query the DOM again, follow a link, fetch a page, or discover new context. With selection-only mode, the tool is not offered. This design makes the boundary legible: the model can use a permitted snapshot, but it cannot expand its authority by asking for an arbitrary portion of the browser.
The reading card borrows a small part of DeepSeek Harness’s session design to organize this exchange. It keeps an append-only record of message events and projects eligible user, assistant, and tool messages into the next model request. FluentRead supplies the browser UI, prompt choices, model gateway, stream transport, storage, and tool execution around that idea. It did not embed the full desktop host, bridge, plugin loader, filesystem, shell, sandbox, remote page-fetching tools, or complete upstream session persistence. The distinction is important: borrowing a session rule is not the same as importing an entire runtime.
The event record also gives the conversation a safer order. A model response and a tool result are recorded before the next model call sees them. The loop checks that a claimed tool call matches the assistant message, that its identifier is not repeated, and that the requested tool is one the reading card actually exposes. Model calls and tool calls are bounded, and cancellation or timeout can end the run. These constraints are not decorative engineering. Without them, a model that repeatedly asks for context or returns malformed tool data could turn a single reading action into an unbounded background process.
Streaming is part of the same boundary model. The card displays actual text increments from the selected model rather than waiting for a completed answer and simulating typing. If the reader stops the request or the provider fails after producing some text, the received portion can remain visible and the turn can be marked stopped or failed. This makes the visible answer a state with a lifecycle, not a binary promise that either a perfect response or nothing exists.
A conversation that can continue without becoming an agent
The card’s history rules distinguish a new learning action from a real follow-up. Switching from “Understand” to “Analyze sentence” should analyze the selected text under the new purpose, not silently feed the previous answer into a new task. A follow-up question is different: it refers to the conversation the reader is deliberately continuing. FluentRead uses recent answered turns for that continuation rather than treating every stored conversation as an ever-growing prompt.
That distinction prevents two common kinds of drift. The first is accidental inheritance: an earlier explanation can bias a later independent action, even when the reader only wanted a different view of the same sentence. The second is historical overload: sending a long record of every previous exchange can bury the current question, increase use, and make old assumptions look like current context. A bounded recent history gives a follow-up continuity without claiming that the system is resuming a complete upstream execution state.
The stored record is also narrower than a full agent log. FluentRead saves the selected text, the permitted paragraph context, questions, answers, status, and service/model information needed for the reading experience. That choice changes what “resume” means. The reader can reopen a completed answer, see a stopped or partial turn, or ask a new follow-up from recent completed material. The extension is not claiming that it can reconstruct every internal step that produced an answer. It reconstructs the reader-facing conversation that is useful for reading.
This distinction also makes invalid continuation a meaningful state rather than a hidden repair. If the reader’s selected action no longer matches the stored answer, or a referenced turn has been removed, the system can reject the stale anchor and ask for a new analysis. It is better to require a fresh selection or answer than to attach a new question to a conversation that the reader can no longer identify. The same principle appeared in page translation: a result is useful only when its source and owner are still clear.
It does not preserve a complete recoverable event ledger, internal reasoning, tool cursor, or upstream session snapshot. When a reader opens history, the extension reads local records; it does not automatically make a new model request. Continuing the conversation creates a new bounded run from the stored turns rather than waking an old process.
Regular-window conversations remain available locally for a limited period, described in the guide as 30 days. Each turn has its own completion state, and the system can save a partial answer during generation before writing the final status. Cancellation, a storage failure, or deletion while a request is in flight must not make an old answer reappear after the reader has removed it. These are quiet details from the reader’s point of view, but they determine whether “history” behaves like a trustworthy record or like a collection of stale interface fragments.
Private windows use a different rule. They do not read ordinary saved conversations and do not create persistent reading history. That protects the separation between a temporary reading session and the regular browser profile, but it also means that continuity is intentionally unavailable. A reader who wants to continue an explanation later must do so in a regular window or keep the relevant source and question independently.
Optional learning memories add another controlled input. They can retain preferences or notes that the reader chooses to keep and can be reviewed, disabled, deleted, or cleared. When used for a cloud explanation, those memories are sent to the selected AI service. They are not a silent license to send the entire learning collection: the reading-card workflow recalls a limited amount relevant to the current selection and question. The reader can therefore trade personalization for additional data sharing deliberately rather than discovering after the fact that every saved word became model context.
The learning center extends this lifecycle beyond one answer. A reader can save a word, phrase, or sentence with the original context, sometimes before the AI response has finished. Later, an entry can request an explanation of meaning and usage, invite the reader to write an example, or support a review prompt that asks them to recall the expression. Opening the entry or the history page does not itself call the model. A deliberate learning action is what sends the expression, the reader’s own sentence when relevant, and the allowed context. This is a useful separation between local retrieval and cloud inference. A reader can inspect what was saved without silently transmitting the collection again, then choose a single explanation or practice action when the benefit is worth the request.
This matters because a translated word without a source sentence is easy to detach from the situation that made it meaningful. The original sentence records how the expression was used, what surrounded it, and what the reader was trying to understand. During review, the reader may be asked to recall a missing expression from that context, or to recognize the expression when no useful sentence was saved. Either way, the system presents an opportunity to retrieve meaning; it does not declare that seeing an explanation equals mastery. The reader’s own recall and usage remain part of the learning loop.
There is still a limit that no session design removes. The model can misread tone, grammar, or facts. Paragraph context can resolve a reference without proving the explanation is correct, and a fluent example can sound natural while missing the source’s exact meaning. The card’s bounded scope makes comparison easier: the reader can look back at the selected sentence and the permitted paragraph, ask a follow-up about an ambiguity, or compare the explanation with the original. It does not replace that act of checking.
The reading card therefore adds a second layer to FluentRead’s context-preserving approach. Page translation keeps source and translation together in a changing document. The card keeps a selected source, a controlled amount of context, a visible answer, and a bounded history together in a conversation. Its value comes from the combination of explanation and limits. Once those limits are clear, the same questions can be applied to images, documents, and video: what was captured, what was authorized, what can be reviewed, and which parts of the workflow remain separate.