Turning a comment into something the agent remembers

What you will take away from this lesson

Most tools let you comment on a document. The comment sits there. Someone reads it, maybe acts on it, and the correction lives on in that one person's head. Next quarter a different analyst builds a similar report and makes the same mistake, because nothing about the first correction survived the thread it was written in.

Plexara treats a comment as raw material. A reviewer writes “we don't use that term, churn is actually retention” on your Q4 dashboard, an agent captures the lesson, and it enters the same review queue that produces knowledge pages and catalog descriptions. Once it is promoted, the next session that touches churn already knows. Article 306 covered the record of how an asset was built. This lesson covers what happens after somebody reads it and disagrees.

Learning Objectives

01Open a comment, question, or correction on a saved asset in the place it refers to, instead of relaying it over email.
02Know who hears about it: the target owner, the thread author, and the people it is shared with, with anyone named by @-mention notified separately so one comment never sends the same person two emails.
03Turn a correction into a pending insight with memory_capture thread_ids, which resolves the thread and puts the lesson in the same review queue that produces knowledge pages and catalog changes.
04Close the loop honestly: the person who raised the feedback confirms or disputes the resolution, and a dispute re-opens the thread.
05Use worklists and the Feedback hub so open items stay visible, and work a whole backlog through one manage_feedback call.
06State the access rules, including the general channel exception and how a reviewer with no account participates through a public link.

Where this lesson sits in the curriculum

306 covered the record the platform keeps of how an asset was built. 307 covers the record people write about it afterward, and what the platform does with that record instead of letting it expire.

300 Series: getting more out of Plexara

Open index

The 300 series is practical recipes for working with Plexara day to day. It assumes the mental model from 205.

The loop, in six steps

Feedback in Plexara is a pipeline with six stages, not a comment box. Reading the stages in order first makes the rest of the lesson easier to place, because each section below is one of them in detail.

The loop, end to end

01
A reviewer writes on the work itself
A comment, question, or correction opens directly on the saved asset, anchored to the passage it refers to rather than sent as a separate message. The feedback travels with the artifact, so the next person to open the dashboard sees the objection next to the number that provoked it.
02
The people who should see it are notified
Writing a thread event queues mail for the target's owner, the thread's author, and the people it is shared with. Anyone the comment @-mentioned is notified in the mention category instead, so one comment never sends the same person two emails. The person who wrote the event is never a recipient of it.
03
An agent resolves it by capturing the lesson
This is the step that makes the loop worth building. The agent calls memory_capture with thread_ids set to the thread it is answering. The capture becomes a pending insight, the thread picks up an insight_linked event, and its status moves to resolved. The comment is now a candidate piece of knowledge instead of a comment.
04
The original author confirms or disputes
The loop does not close on the agent's say-so. request_validation routes the resolution back to the person who raised the feedback, and they answer validated or disputed, with a reason if they want one. Disputing re-opens the thread and puts it back on the practitioner worklist.
05
Worklists keep the open items visible
Two self-scoped views carry the backlog: open resolution-required threads across everything you own or can edit, and threads waiting on your validation. A Feedback hub gathers every comment across the assets, collections, and prompts you can see, and the sidebar carries a badge when something is waiting.
06
One tool call works the whole backlog
manage_feedback with action=list and no target is the "review and act on any pending feedback" entry point. From that one response the agent can get a thread, reply, resolve, request validation, and respond to a validation request, in a single pass.

Steps 1, 2, 5, and 6 are the plumbing that any competent comment system needs. Step 3 is the one that changes what feedback is for, and step 4 is what keeps step 3 honest. The rest of this lesson takes them in that order.

Step 1: the comment opens on the work

Feedback lets the people who review your work, including subject-matter experts and stakeholders who never open an agent, leave structured corrections and questions on the things you share with them. The Feedback button in an asset, collection, prompt, or knowledge-page viewer slides out the panel.

The asset viewer for a Q4 revenue dashboard with the feedback panel slid out on the right, headed 1 open and 1 need resolution, listing three threads: an open correction titled We don't use that term anchored to the phrase monthly active users with two replies, an answered question titled Where does the revenue column come from, and a resolved correction titled Churn is actually retention — The panel slides out over the work rather than replacing it, so the dashboard stays on screen while you read the objection to it. The header counts open threads and threads that still need resolution. The top thread is anchored to the phrase `monthly active users`, which is why it renders under the title: that correction is pinned to the place in the content it refers to, along with the version it was raised against.

What a thread actually is

Threads are built on a generic substrate where a comment is one event type among many, which is why a rating, an approval, and a status change all live on the same timeline as the words people typed.

What a feedback thread carries

target: One asset, collection, prompt, or knowledge page. Or no target at all, which puts the thread on the standalone general channel.
kind: comment, question, correction, rating, approval, rejection, or suggestion. Kind is what makes a thread actionable: only corrections and suggestions are candidates for the Capture as insight action in the portal.
status: open, answered, resolved, won’t fix, or acknowledged. Every status change writes a timeline event in the same transaction, so the timeline never shows a status with nothing behind it.
requires_resolution: A flag saying this one cannot be left open. It is what puts a thread on the practitioner worklist rather than merely in the activity feed.
anchor: An optional quote of the selected passage, captured when you select text in markdown or plain-text content before opening New. Stored with the version it was raised against, so a later edit does not silently move the objection.
timeline: The ordered event log: the opening message, replies, status changes, resolutions, ratings, approvals, and the knowledge-link events that connect the thread to an insight.

Anyone who can open the item can reply. Changing the status or deleting the thread is limited to the thread author, the item's owner or an editor, and admins.

Anchoring, and why it survives the next edit

Step 2: the right people hear about it

Writing a thread event queues mail. The interesting part is the de-duplication: a comment that both mentions you and lands on an asset you own sends you one email, not two, because being named routes you into the mention category and out of the general fan-out.

Who gets mail when a comment is written

The target's owner
comments
You built the dashboard, so an objection to it is yours to answer.
The thread's author
comments
A reply to a correction you raised reaches you even if you do not own the asset.
The people it is shared with
comments
Everyone holding a share on the item hears about activity on it, which is what makes a shared briefing a conversation rather than a broadcast.
Anyone named with an @-mention
mentions
Its own category with its own preference, so a person who muted general thread chatter still hears when a comment names them. Being routed here also means they are dropped from the general fan-out: one comment, one email.
The person who wrote the comment
nothing
The author is excluded at the point every trigger passes through, comparing normalized addresses so an owner recorded as a display name plus address is still recognized as the author.

Mentions are queued first and enqueueing is rate-limited per author, so on a widely shared item the people addressed by name are the ones that get through. Each category has its own per-user toggle, and a daily digest mode collapses a day of activity into one message. Replies an agent writes with manage_feedback fire the same notifications as replies typed in the portal.

Naming a teammate in a comment

Type @ anywhere in a message or reply to address someone directly. The composer suggests as you type and stores the person as an address rather than a display name.

The New feedback composer in the asset feedback panel, with a Kind dropdown set to Comment, an optional title field, and a message box containing the text cc @marcus, below which a suggestion row offers Marcus Johnson at marcus.johnson@example.com — Typing `@` suggests people as you go and inserts the person as `@marcus.johnson(example.com)`. It reads as a name in the thread and is stored as an address, so it keeps working when somebody's display name changes.

Who you are allowed to name

A mention can only reach someone who could already open it

The suggestions are the item's audience: its owner plus everyone it is shared with, directly or through a collection. Knowledge pages and the general channel are open to every signed-in user, so anyone in the directory can be named there. This is deliberate, because a mention mails the item's title and an excerpt of your comment.

You can still type an address by hand. If it belongs to someone outside the audience, the composer tells you while you are writing, and the mention posts as ordinary text: not recorded, not rendered as a chip, nothing delivered. Share the item with them first, then mention them. The Mentions of me tab in the feedback inbox lists every thread where a comment addressed you, re-checked against present-day access so a revoked share stops surfacing the item.

Step 3: the comment stops being a comment

This is the step the rest of the feature exists to serve. A correction is only worth collecting if it can change something, and in Plexara the thing it changes is what the next session knows.

Thread to insight to knowledge

thread
The comment
"We don’t use that term. Churn is actually retention, and the dashboard has the sign backwards." Written by a subject-matter expert on the asset, anchored to the tile it refers to.
insight
The pending insight
memory_capture with thread_ids set records the lesson as a business_knowledge memory and, because that class is reviewed rather than live, files it as a pending insight. The thread gets an insight_linked event and moves to resolved.
review
The review queue
The insight lands in the same queue as insights captured by agents on their own. Whoever holds apply_knowledge reviews it. Nothing has changed for anyone else yet, which is the point of the queue.
knowledge
The canonical change
On promotion the insight becomes a knowledge page, or applies to the catalog as a corrected column description. The thread’s knowledge chain then shows the resulting change, so the reviewer who raised the objection can see what their comment did.

This is the pipeline lesson 206 covers in full, entered from a comment instead of from a chat turn. A comment that becomes a knowledge page changes the next answer for everyone, not just for the person who complained.

Two ways to capture the same lesson

The agent path and the portal path reach the same review queue. Which one you use depends on where you are standing when you decide the correction is right.

Agent path

memory_capture thread_ids=[…]

Each named thread has its insight recorded, an insight_linked event appended to its timeline, and its status moved to resolved. Linking is authorized with the same owns-or-edit check as resolving the thread by hand, so this is not a back door around the access model. The link is best-effort: a failure never fails the capture, and the response reports how many threads linked and which ids matched nothing, so the agent can tell a typo from an already-resolved thread.

Portal path

Capture as insight

An unresolved correction or suggestion shows a Capture as insight action in its detail view when you hold apply_knowledge. It builds a pending insight from the thread's title and first comment and resolves the thread with a link to it. Same destination, same review queue, for the reviewer who is reading in the portal rather than working through an agent.

Step 4: the author confirms or disputes

A resolution is a claim, and the person best placed to check it is the one who raised the objection. Plexara routes the claim back to them rather than treating resolved as final.

Confirm or dispute

The practitioner or agent
request_validation
Routes the resolution back to the person who raised the feedback. The thread is resolved, but not settled.
The feedback author
respond_validation validation_result=validated
Records a validation event on the timeline and sets the thread’s validation state. The loop closes.
The feedback author
respond_validation validation_result=disputed
Records the same kind of event with an optional reason, and re-opens the thread so it returns to the practitioner worklist. The resolution was wrong and the system says so.

Only the feedback author or an admin may respond, which is what makes the confirmation worth anything: an agent cannot mark its own homework, and neither can the practitioner who resolved the thread. Assets and collections also aggregate approvals into a signed off by N of M readout, counting the distinct people who left an approval against the owner plus everyone holding a share.

Step 5: open items stay visible

Worklists are what stop a thread from being resolved by neglect. The Feedback page in the sidebar gathers every comment across the assets, collections, and prompts you can see, and My Assets and Collections carry an open-thread badge on items you own.

The portal Feedback page with Recent, Worklist, and General tabs, the Worklist tab carrying a badge of 1, and five rows spanning a knowledge page, three assets, and a collection, each showing its kind and status chips, the author address, and a reply count — One page for every comment you can see, across knowledge pages, assets, and collections. **Recent** is the cross-target activity feed, each row linking back to its item. **Worklist** holds the two self-scoped queues. **General** is the standalone channel. The sidebar badge counts your open worklist, which is how you find out something is waiting without a push notification.

Step 6: one tool call works the backlog

Manage Feedback (manage_feedback) is the agent-side surface for all of it. A single list call with no target answers the question "is anything waiting on me?" across everything you own or can edit plus the general channel, and the remaining actions work the results without another round of searching.

manage_feedback: seven actions

list (no target): The entry point. Unresolved threads the caller did not author, across every asset and collection they own or can edit, plus the general channel, plus anything awaiting their validation. Newest first.
list (with a target): Threads on one asset, collection, prompt, or the general channel, filterable by status, validation state, and whether resolution is required.
get: One thread with its full event timeline, which is what the agent reads before it decides whether the objection is a correction worth capturing.
reply: Append a comment. Carries @-mentions and fires the same notifications as a reply typed in the portal.
resolve: Mark the thread resolved without capturing anything, for the question that only needed an answer.
request_validation: Route the resolution back to the thread author for confirmation.
respond_validation: The thread author records validated or disputed, with an optional reason. Disputing re-opens the thread.

Feedback is its own tool rather than another action on manage_asset, so an agent finds it by name when you say “is there any feedback waiting on my work?” Prompt threads are reached by naming the prompt explicitly and are admin-only; they are not part of the no-target feed, which keeps the feed personal.

What this looks like in practice

A session that starts with a backlog and ends with a correction filed as a candidate piece of team knowledge.

Working a feedback backlog in one session

You

Is there any feedback waiting on my work?

Agent

Three open threads and one waiting on you to validate.

1. Q4 Revenue Dashboard, correction from [email protected]: “We don't use that term.” Anchored to monthly active users. Two replies, needs resolution.
2. Q4 Revenue Dashboard, question from [email protected]: where the revenue column comes from. Already answered, not yet closed.
3. Q4 Performance Review collection, suggestion: add a glossary section.
4. Awaiting your validation: the retention correction you raised last week, resolved Tuesday.

You

Dana is right, we standardized on “active accounts” last quarter. Capture that so it stops coming up, and ask her to confirm.

Agent

Captured. The standard term for the metric is “active accounts”, recorded as business knowledge and linked to Dana's thread, which is now resolved with the insight attached. It is pending review, so it is a proposal rather than a change to the catalog yet.

I replied on the thread explaining the capture and requested her validation, so she will get the confirm-or-dispute prompt rather than the thread just going quiet. The question about the revenue column I have marked resolved, since the answer was already in the timeline.

The agent hedged where it should: it said pending review rather than claiming the catalog changed, because promotion is a person's decision. It also did not close the loop on its own authority. It asked Dana to confirm the resolution she is in the best position to judge.

The access rules

Feedback follows the access of the thing it is attached to, with one deliberate exception that runs the other way.

Who can see and do what

Assets and collections
Scoped to what the caller owns or can edit. Reading feedback on an item you cannot open is not possible, because the threads follow the item’s existing view access.
Admins
See all of it. The one blanket exception, and the reason an admin can unstick a thread whose owner has left the company.
The general channel
The exception that runs the other way. Standalone threads are readable and replyable by any authenticated caller, and resolvable only by the thread author or an admin. It is a shared room, so nobody but the person who opened a topic gets to declare it closed.
Knowledge pages
Org-shared, so any signed-in user can read and add feedback on them. Moderation there belongs to apply_knowledge holders rather than to an owner.
Capturing as knowledge
memory_capture thread_ids is gated by the same owns-or-edit check as resolving by hand. A thread you could not resolve is refused and reported back as unlinked.

The exception, stated plainly

Feedback from someone with no account

Working feedback day to day

Three habits decide whether this feature is a comment box you eventually stop reading or the mechanism by which your team stops repeating itself.

Three habits that make the loop work

Select the passage before you open New
A correction anchored to the sentence it disputes is answerable without a round trip. An unanchored "this number looks wrong" costs the practitioner a message just to find out which number.
Set requires_resolution on the ones that matter
The flag is what moves a thread from an activity feed nobody scrolls to a worklist someone works. Leave it off for a passing remark and on for anything a stakeholder is waiting on.
Ask the agent to capture, not just to reply
"Reply and tell her we fixed it" closes one thread. "Capture that as knowledge and resolve the thread" changes what the next session knows. The second is barely longer to type and is the entire point of the feature.

How this connects to 306 and 206

What 308 covers

Key terms

Seven terms cover the vocabulary of the feedback loop. The first three are the mechanism; the rest are the surfaces you will meet in the portal.

Key Terms

Thread: One conversation about one thing: an asset, collection, prompt, or knowledge page, or the general channel. Carries a kind, a status, an optional anchor, and a timeline of events.
Manage Feedbackmanage_feedback: The tool an agent uses to review and answer feedback: list, get, reply, resolve, request_validation, respond_validation. Calling list with no target returns everything pending across your work and the general channel.
thread_ids: The memory_capture parameter that folds a thread into the knowledge loop: the capture links to the thread, appends an insight_linked event, and resolves it, under the same owns-or-edit check as resolving by hand.
Validation: The confirm-or-dispute step. request_validation routes a resolution back to the person who raised the feedback; respond_validation records validated or disputed. Disputing re-opens the thread.
Worklist: Two self-scoped queues: open resolution-required threads across what you own or can edit, and threads awaiting your validation. The sidebar badge counts the first.
General channel: The standalone Feedback page for comments not tied to a single object. Readable and replyable by any signed-in user; resolvable only by the thread author or an admin.
Knowledge chain: The trail a resolved thread shows once its insight has been acted on: thread, insight, and the catalog changes that insight produced.

307 - Turning a comment into something the agent remembers