305 - Editing what you already have

304 wrapped multiple assets into collections. 305 zooms back in on a single asset and walks through what happens when the content needs to change after the first save.

It is tempting, especially during a fast-moving analysis, to ask the agent to redo a dashboard with the new numbers and treat the result as a new asset. That works for one-off cases. For anything you have already shared, or anything that lives inside a collection, in-place editing is the right move. Three concrete reasons make the difference.

Most corrections are small: one chart is the wrong color, one figure was restated, one heading has a typo. For those, ask for the change itself rather than for the document. The agent finds the part you named and edits it there, which is why a one-line fix to a fifty-page report costs about what a one-line fix should cost, and why the fifty pages you did not mention come out the other side unchanged. This is the default move for editing in Plexara; replacing a whole body is what you reach for when the whole body is genuinely what changed.

There is one Manage Asset (manage_asset) action called update, a targeted-edit action alongside it, and a related action called revert. Between them they cover three operationally distinct kinds of change: a metadata edit, a content edit, and a rollback. The difference matters because only two of them create a new version, and the audit trail is easier to read when you know which is which. Where a targeted edit lands is the first question people ask, and the answer is that it is a content edit like any other.

When you ask the agent for the history of an asset, it calls list_versions and you get back a list. Each entry has the same shape, and reading it well is the difference between a confident revert and a guess. The fields below are what each entry carries.

Revert is the one mechanic in this lesson that frequently surprises people on the first use. It does what you want at the level of "the asset now shows the old content," but the way it gets there is worth knowing so the audit trail makes sense afterward.

The agent path and the portal path do not allow exactly the same operations to the same set of users. The difference is small but worth knowing if you ever share an asset with editor permission and your collaborator asks why the agent will not let them update it. Editing rights follow the same least privilege as the starting point that governs the rest of the platform.

Most of this article assumes the agent path because it is the most common workflow. The portal has its own surface for editing assets you own and (with an editor share) assets others have shared with you. Both surfaces produce versions the same way; the rules above apply identically.

A real session, running from the smallest kind of change to the largest. The user asks for one chart to be recolored, then for the dashboard to be rebuilt against a corrected source, then realizes the corrected source was itself wrong, asks for the version history, and reverts. The asset URL never changes across any of it.

Four small phrasings make the agent path produce what you wanted consistently. None of them require knowing how the Manage Asset actions work internally.

The mechanics are not the hard part of editing well. The habits are. Three of them carry most of the value.

A version history tells you what changed and when, but not how. The other half of the audit story is provenance: the catalog searches and queries the agent invoked during the producing session, with what parameters. 306 opens that record and names what it can and cannot tell you (prompts and agent responses, for example, are not in it).

Nine terms cover the vocabulary of editing. The first three are the targeted-edit moves. The next four are the Manage Asset mechanics behind versions and rollback. The last two are the audit-trail field and the share kind that bring non-owner contributors into the picture.