Plexara
What you will take away from this lesson
Article 304 wrapped assets into collections. This article is about what happens when the assets themselves need to change: a number was revised after the close, a chart should show one more region, a sentence in the report came out wrong. The right move is to edit the existing asset, not generate a new one. The recipient's link keeps working, the history stays on a single asset, and any collection that references it picks up the change automatically.
The mechanism is Manage Artifact (manage_artifact) with action=update, plus two related actions that come up almost as often: list_versions to read history, and revert to roll back. All three are owner-only on the agent path. Editor-share recipients can update content from the portal, which is covered in passing at the end. Everything else in this lesson is the day-to-day editing workflow.
Learning Objectives
- 01Edit an existing asset in place instead of generating a new one, so the link your boss has keeps working and the audit trail stays on the same asset.
- 02Tell the difference between a content edit and a metadata edit, because only one of them creates a new version (and one of them is what you reach for when you fixed a typo in the name).
- 03Read an asset version history and pick the right version number to revert to.
- 04Recognize that revert is append-only: it creates a new version with old content, it does not erase newer ones.
- 05Know who can edit what: owner via the agent and the portal, editor-share recipients via the portal only.
Where this lesson sits in the curriculum
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.
300 Series: getting more out of Plexara
- 301Creating reports and dashboardsHow to ask the agent for shareable work product instead of chat that scrolls away. The habits that decide whether your dashboard survives next week.
- 302Exporting dataWhen you need a spreadsheet a teammate can sort, or a data file for another system, instead of a view.
- 303Sharing your workTwo ways to share: a user share to a named teammate, or a public link anyone with the URL can open. Three controls on either: expiration, notice text, revocation.
- 304Creating collectionsBundle a dashboard, a summary, and the underlying data into one navigable briefing. Build it during the session via the agent, or by hand on the portal's Collections page.
- 305Editing what you already haveUpdate an asset in place so shared links keep working and history stays on one record. Metadata edits do not bump the version; content edits do; revert is append-only.
- 306How an asset was builtThe audit trail Plexara records at the MCP boundary: which tool calls the agent invoked, with what parameters, in the producing session. Captured at save time, readable by you or the agent.
- 308Reproducible promptsSave the starting instruction as a first-class prompt with named arguments via Manage Prompts (manage_prompt). Re-run it later with different values. Personal, persona, or global scope. What re-running does and does not guarantee.
The 300 series is practical recipes for working with Plexara day to day. It assumes the mental model from 205.
Why edit instead of generating a new asset
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.
Why editing in place beats re-saving as new
Shared links keep working
The portal URL points at the asset_id, which never changes. Update content and the next view returns the new body at the same URL. Your boss does not get a "this link no longer works" email when you fix the chart.
History stays on one asset
Versions stack on the same asset. When someone asks where a number came from six weeks later, the audit trail is one list_versions call away. Re-saving as a new asset scatters the history across two records that nobody knows are related.
Collections pick up the change
A collection item is an asset_id reference, not a copy. Edit the underlying asset and every collection that includes it shows the updated content next time it is opened. Re-saving as a new asset leaves the old reference pointing at stale content.
Three kinds of change
There is one Manage Artifact (manage_artifact) action called update, plus a related action called revert, but 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.
Three kinds of change, with whether each one bumps current_version
Metadata: name, description, tags
Bumps current_version: No
Renaming an asset, rewriting the description, adding or replacing tags. None of these touch the content body in S3, and none of them create a new version. The asset record updates in place.
"Rename the Q3 2025 sales review asset to Q3 2025 regional sales review and add the tag southwest."
Content: the asset body itself
Bumps current_version: Yes
Replacing the HTML of a dashboard, rewriting a markdown report, regenerating an SVG chart with corrected numbers. The new content lands in S3 under a fresh version key; current_version bumps. Older versions are preserved.
"Update the Q3 2025 regional sales review with the corrected Southwest figures and a new YoY tab."
Revert: roll back to an earlier version
Bumps current_version: Yes
You decide a recent change was wrong and want the previous content back. Revert reads an older version's content and writes it as a new version. The old "wrong" version is preserved in the history; you have not erased it.
"List versions of the Q3 regional sales review. Revert it to version 3."
The metadata-vs-content split matters when you are reading the audit trail. A version history that shows three entries does not mean three name changes; it means the body was replaced three times. Renames and re-taggings happen out of band. A single update call can carry both kinds at once (new name plus new content); the result is one version bump, not two.
What the version history looks like
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.
What list_versions returns for each entry
version
The integer position in history. v1 is the original save. Each content update increments by one.
created_at
When this version of the content was written. Use this to correlate with chat sessions or audit log entries.
created_by
Email of the user whose session produced this version. Useful when more than one editor has access through editor-share.
change_summary
"Content updated via MCP" for agent updates, or "Reverted from v{N}" for reverts. Short by design.
size_bytes
Body size at the time of the version. A sudden drop or spike is worth noticing when you are auditing.
content_type
The MIME type at the time of the version. Usually constant across versions; if it changed, that was an intentional shape change.
Default page size is 50 versions, which is more than most assets ever accumulate. For an asset with more history than that, ask the agent to raise the limit explicitly: the list_versions action takes a limit argument but not an offset, so a single call has to fetch everything you want to see.
How revert actually works
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.
Who can edit what
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.
A note on the portal edit surface
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.
What this looks like in practice
A real session: the user asks the agent to update a dashboard with corrected numbers, then realizes the corrected source was itself wrong, asks for the version history, and reverts to the prior version. The asset URL never changes across any of it.
Update, regret, revert, audit
You
The Southwest Q3 numbers in the regional sales review are wrong. Re-run the query against the corrected source table and replace the dashboard content with the updated numbers. Keep the same asset.
Agent
Done. I re-ran the regional revenue query against the corrected source table and updated the dashboard content. Same asset, same URL.
Asset: portal/assets/{asset_id}
Previous current_version: 3. New current_version: 4. Change summary: Content updated via MCP.
You
Wait, the Southwest column went down again after the update; the corrected source table looks wrong. Show me the version history and revert to version 3 while we sort it out.
Agent
Version history (most recent first):
v4 - 2026-05-16 - Content updated via MCP - [email protected]
v3 - 2026-05-15 - Content updated via MCP - [email protected]
v2 - 2026-05-14 - Content updated via MCP - [email protected]
v1 - 2026-05-13 - Initial version - [email protected]
Reverted. New current_version: 5. Change summary: Reverted from v3. The body now matches what was at v3. v4 is still in the history so we can see what the bad data looked like.
The portal URL did not change across the three updates. Any share link you handed out before turn one still points at the same asset; the recipient sees v5 on their next view. The history is auditable end to end: an analyst tomorrow can see exactly which version of the data was current at every point this week.
Prompting tips for editing
Three small phrasings make the agent path produce what you wanted consistently. None of them require knowing how the Manage Artifact actions work internally.
Prompting tips for editing
Say "update the existing X" or "edit the X in place" so the agent picks update over save_artifact. A prompt that just asks the agent to "redo X with the new numbers" sometimes produces a new asset and a new URL.
When you want a metadata change, say so explicitly: "rename to Y" or "set the description to Z" or "replace the tags with A, B, C". The agent will not bump the version, and the audit trail stays clean.
When you want to revert, ask for the version history first. A revert by recency ("go back one version") is almost always wrong; revert by version number is what you want.
Editing habits worth building
The mechanics are not the hard part of editing well. The habits are. Three of them carry most of the value.
Editing moves worth building into your habits
Read the history before you revert
A 60-second list_versions check turns a guess ("go back one") into a deliberate decision ("revert to v3"). The version with the right body is rarely the one immediately before the one you regret.
Treat the asset, not the chat, as canonical
Across a multi-day analysis, the chat will scroll, the prompts will accumulate, the answers will drift. The asset is the one place the right numbers live. Updating it after every meaningful correction means the URL you shared yesterday is still the source of truth today.
Use rename and re-tag freely
Metadata edits are cheap. They do not bump the version. If a name turns out to be confusing six weeks in, rename. If you realize a tag would help search, add it. The audit trail stays focused on the content changes that actually matter.
What 306 covers
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).
Key terms
Six terms cover the vocabulary of editing. The first four are the Manage Artifact mechanics the agent uses. The last two are the audit-trail field and the share kind that bring non-owner contributors into the picture.
Key Terms
- action=update
- The Manage Artifact (
manage_artifact) action that changes an asset in place. Owner-only. Metadata changes (name, description, tags) do not bump current_version; content changes do. - current_version
- The integer position of the most recent version. Starts at 1 on save_artifact. Increments on every content update and on every revert. Never decrements.
- list_versions
- Action that returns the version history for an asset. Each entry has version, created_at, created_by, change_summary, size_bytes, and content_type. Default page size: 50.
- revert
- Action that creates a new version whose content is copied from an older version. Does not erase newer versions; the rollback itself is a versioned event with change_summary "Reverted from v{N}".
- change_summary
- Short label on each version explaining what happened. "Initial version" for v1, "Content updated via MCP" for agent updates, "Reverted from v{N}" for reverts.
- Editor share
- A user share with
permission=editor(from 303) that lets a recipient update an asset's content from the portal. The agent path remains owner-only.