Plexara
What you will take away from this lesson
Capable AI chat applications already produce excellent work product. Ask one for an interactive dashboard, a written report, or a chart and you get back something polished, often as HTML, JSX, or SVG. These are fine formats for an agent to generate and difficult formats for a business workflow to move around. You cannot email an HTML file and trust it to render in your boss's mail client; you cannot paste a JSX dashboard into a PowerPoint. So the artifact stays in the chat where it was generated, the next person who needs the same kind of analysis starts from a blank prompt, and the value built in that session does not compound.
The Plexara asset system gives the agent's work a real home. When the agent saves an artifact during a Plexara session, it lands in your portal under Assets: your team's catalog of AI-generated work. From there you share it the way you share a Google Doc, with specific teammates as viewer or editor, or as a public link with an expiration date. The bytes live in your company's S3 bucket, not a Plexara-owned database. You can edit assets in place. The next agent session searches your assets and builds on them. Article 205 introduced this idea; this article is the working habits that get the most out of it.
Learning Objectives
- 01Understand why a great chat artifact is not the same as a shareable business asset, and what the Plexara portal gives you that a chat tool alone cannot.
- 02Adopt the two prompting habits that make the agent produce a saved asset efficiently: ask for the save in one breath, and name the shape.
- 03Pick the shape that fits the audience: interactive dashboard, markdown report, chart, or CSV.
- 04Know what happens the moment you save: the file opens as what it is, and it lands with the right extension whether or not anyone labeled it.
- 05Name and describe assets so future you, your team, and the next agent session can find them.
- 06Know when to mention a tool by name in your prompt and when to trust the agent to choose.
Where this series sits in the curriculum
The 300 series is the working playbook for getting more out of Plexara as a daily user. Eight short lessons, each on a different habit. The index below is your map.
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. What happens when you save, and 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 workName a teammate and they get mail with your note in it and a link straight to the work. Name somebody with no Plexara account and they can still read it. Or mint a link for an audience, with an expiration and an access mode you pick.
- 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 haveName the part you want changed and the agent edits that piece in place. Ask what is in a report, compare two versions, and keep shared links working. 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.
- 307Turning a comment into something the agent remembersA reviewer opens a correction on your dashboard, an agent folds it into the knowledge loop with memory_capture thread_ids, and the person who raised it confirms or disputes the resolution. Worklists keep the open ones visible; manage_feedback works the whole backlog in one pass.
- 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.
What the asset system actually gives you
A capable AI chat tool can already build a polished dashboard or a thorough report. The hard part is what comes next. HTML and JavaScript do not move through ordinary business workflows the way a PDF or a link does. Email cannot render an HTML attachment reliably. PowerPoint cannot host JSX. The artifact stays where the agent rendered it, and your team has no shared catalog to find it again. The Plexara portal closes that gap by giving every asset a home in your Assets page, sharing controls that work like Google Docs, and an S3 bucket of your own as the storage layer.
Five properties carry the value, and they show up in every later article in this series. Read them before getting into prompt habits; the rest of the 300 series is the working playbook for one or another of these five.
What Plexara does with the agent's work that a chat tool alone cannot
A URL is the format your team already speaks
HTML, JSX, and SVG are excellent formats for an agent to generate, and a terrible format for a business report to travel in. You cannot email an HTML file and expect it to render the same way in someone's mail client; you cannot paste a JSX dashboard into PowerPoint; Confluence will not embed arbitrary JavaScript. Plexara sidesteps the entire format problem by hosting each asset at a stable URL. The recipient does not need to know what HTML is. They click the link and see the dashboard.
The bytes live in your S3, not ours
Plexara writes each asset directly to your company's S3 bucket. Your existing storage policies, retention rules, and lifecycle settings apply unchanged. Plexara renders and catalogs; your storage owns the bytes. Nothing about the artifact lives in a proprietary Plexara database that you would lose access to if you ever changed vendors.
A real catalog, not a chat history
The portal Assets page lists every asset your team has built, with search by name and description, filters by kind of file and tag, and metadata for owner and creation date. The list keeps loading as you scroll, so a year of saved work is something you can actually reach the bottom of. A chat archive was never designed to be a catalog. The same artifact in a chat is one event in a transcript; in Plexara it is a row in your organizational asset registry.
Governed sharing and in-place edits
Share an asset with a named teammate at viewer or editor permission and they get mail about it, with a note from you, a link that opens the work, and a way in even if they have no account. Or mint a link for an audience, with an expiration and an access mode you choose. Update the asset in place when something changes and the link keeps working; the old version is preserved and revertible. Articles 303 (sharing) and 305 (editing) cover the workflows.
The next agent session can find it
The most useful property, because it compounds. The next time you or a colleague starts a Plexara session and asks 'has anyone built a Q3 regional review?' the agent searches your assets, finds it, and reuses or extends it rather than starting from a blank prompt. Your saved work comes back from the same search that finds knowledge pages, prompts, and reference material, and the agent can read the one it found in full, so the portal is where you browse, not the only door back to your own work.
Together, these five properties are the difference between a smart chat assistant and a governed workspace where the agent's output becomes a real organizational asset. The rest of the 300 series is the working playbook for each of them.
Two prompting habits that make the difference
The why is the asset system. The how is in two small habits when you talk to the agent. The first is asking for the save in the same breath you ask for the artifact, instead of letting the agent render the whole dashboard in chat and then telling it to save. The second is naming the shape of output explicitly ("interactive dashboard", "markdown report", "CSV", "SVG chart") so the agent saves the asset in a form your teammates can use.
Both habits are about routing the agent's effort to the right place. Save Asset (save_asset) is designed to be called directly with the content; when you ask for the artifact in one breath the agent skips rendering into chat entirely. The shape word is what tells the agent which form to save it as.
Two prompting habits that change the outcome
- 01
Ask for the save in one breath, not two
When you split the request into two turns ('show me the dashboard,' then 'OK now save that'), the agent renders the full artifact into the chat first, and then either has to save it from there or regenerate it. That costs you tokens twice and risks a slightly different second render. When you ask in one turn, the agent goes straight to Save Asset (save_asset) with the content and skips the chat detour entirely.
- Two-step ask
- "Show me a Q3 sales dashboard by region." … "OK, save that as an asset."
- One-step ask
- "Build an interactive dashboard for Q3 sales by region and save it as Q3 2025 sales review - by region."
- 02
Name the shape of output you want
The agent chooses how to save the artifact based on the words you use. 'Interactive dashboard' produces a clickable view; 'markdown report' produces a written document; 'CSV' produces a sortable data file; 'SVG chart' produces a graphic. Naming the shape ensures the teammate who opens the asset sees what you intended to build, not what the agent guessed you wanted.
- No shape named
- "Show me Q3 sales by region."
- Shape named
- "Build an interactive dashboard for Q3 sales by region." (Or "Write a markdown report…", "Create an SVG chart…", "Export as a CSV…".)
You do not need to phrase prompts as commands and you do not need to be terse. The two additions above are usually enough on their own; everything else (naming, audience, context for the agent) is icing.
Four shapes of output, and how to ask for each
Most of what you build in Plexara falls into four shapes: an interactive view, a written report, a single chart, or a data file. Picking the right shape is mostly about who is going to consume it. A stakeholder who wants to explore wants a view; an executive who wants the takeaway wants a report; a board deck wants a single chart; another analyst wants a data file.
The agent picks the shape that fits your wording. The table below shows the four shapes side by side with an example prompt for each.
Four shapes of output you can ask for
An interactive view
A clickable dashboard with filters, tabs, and linked charts. Lives in the portal; teammates open it in their browser.
For: Stakeholders who want to explore the numbers themselves.
"Build an interactive dashboard for Q3 2025 sales by region with a year-over-year tab. Save it as Q3 2025 sales review - by region."
A written report
A narrative document with headings, embedded charts, and conclusions. Renders top to bottom; reads on a phone.
For: Executives, anyone who wants the takeaway without clicking around.
"Write a markdown report summarizing the Q3 numbers and highlighting the three stores with the biggest swings. Save it as Q3 exec summary."
A single chart
One self-contained visualization that scales cleanly. Easy to embed in a deck or document.
For: A board deck, a status email, a single slide.
"Create a chart of revenue per store for the top ten stores by Q3 volume. Save it as Top 10 stores Q3."
A data file
The full rows behind your analysis. Lands in the portal as a downloadable file; teammates can sort and filter in Excel or pull into another tool.
For: Other analysts, downstream pipelines, a finance team that wants its own pivot.
"Export the full 2025 Southwest-region transaction table as a spreadsheet. Save it as Southwest 2025 transactions."
The shape is the part the agent picks based on what you ask for. You can also mix shapes in a session: a written report, a supporting chart, and a backing data file all from the same analysis, each saved as its own asset and linkable on its own.
What happens when you save
Save an HTML report and it opens as a report. Save a dashboard and it is interactive. A markdown report renders formatted, a CSV opens as a table, an image displays, a PDF opens in the viewer. Getting that right is not something you or the agent have to arrange in the prompt.
What you save, and what the recipient sees
An HTML report
Opens as the report, laid out the way you built it.
An interactive dashboard
Opens interactive. Filters, tabs, and linked charts all still work.
A markdown report
Renders formatted, with its headings, lists, and tables intact.
A CSV
Opens as a sortable, searchable table rather than a wall of commas.
A JSON file
Opens as a browsable tree you can search by key or by value.
An image
Displays, with zoom, pan, and a size readout.
A PDF
Opens in the viewer, with download as the fallback.
You do not have to label what you saved, and neither does the agent. When the label is missing or generic, the platform works out what the file actually is from the file itself, and the file lands with the right extension, so a download, a share, or a bucket listing shows q3-revenue.csv and board-report.html rather than something generic. A large export does not slow down for the check. A label that was specific and correct is taken at its word, so an export that already knows exactly what it produced is never second-guessed.
Naming the asset is most of what makes it findable later
You will not remember which "Sales dashboard" was which after the second one, and neither will the agent searching for it next month. The single best habit a Plexara user can build is naming each asset like you are titling a document that will live for a quarter. A specific name plus a one-line description plus a couple of durable tags is what lets the agent (and search, and you, and a teammate who was not in the session) pull it up again in a future session.
Names: forgettable vs findable
A quarterly review
- Forgettable
- Sales dashboard
- Findable
- Q3 2025 sales review - by region
Two months from now you will have several "sales dashboards" and no way to tell them apart. The good name carries the period, the topic, and the cut, which is what your eye scans for on the Assets page and what the agent uses to recall the right one in a later session.
A one-off chart
- Forgettable
- chart 1
- Findable
- Top 10 stores Q3 2025 revenue chart
You will paste this chart in a deck next week. A descriptive name reminds you what it shows; a generic name makes you re-generate it from scratch because you cannot tell which "chart 1" was the right one.
An exploratory report
- Forgettable
- Findings
- Findable
- Refund-rate anomaly investigation - October 2025
Investigations are the easiest work to lose. A dated topic in the name lets you (or a teammate) come back to it without having to re-trace the whole thread.
A useful pattern: topic - cut - period or period - topic - cut. Add a one-sentence description when you save (the agent will offer; you can also dictate it inline). Tags are optional but help when you want to scope a search to one project later.
When to mention a tool name in your prompt
A natural question once you know Save Asset and Manage Asset are real tools: should you name them in your prompts? The short answer is no, not usually; the agent reads the description of each available tool every turn and picks. The slightly longer answer is that naming a tool is for the moments when the agent picked something other than what you wanted.
What this looks like in practice
A short conversation, in the shape you might actually have one. Notice the chat itself stays light; the dashboard and the summary both live as separate, linkable assets. Notice that the follow-up prompt does not need to re-explain anything because the agent has the saved dashboard as context.
One conversation, end to end
You
I need to compare Q3 sales by region this year vs last year. Build me an interactive dashboard with a year-over-year tab and a top-five movers chart. Save it as Q3 2025 sales review - by region.
Agent
Done. I pulled 2024 and 2025 regional revenue from the warehouse and built a dashboard with three views: a Q3 comparison table, a year-over-year percentage tab, and a top-five movers chart. The Southwest region is the standout, up 14% year over year.
View the dashboard: portal/assets/Q3-2025-sales-review-by-region
Three data steps are recorded in the asset's history if you need to see how the numbers were built. Let me know if you want me to drill into the Southwest or send a written summary to forward to your team.
You
Yes, do the written summary. Two short paragraphs, focus on the Southwest. Save it as Q3 exec summary.
Agent
Saved. portal/assets/Q3-exec-summary ; two paragraphs leading with Southwest's 14% growth, citing the dashboard above.
Notice what is in the chat and what is not. The chat has a short summary and a link into your portal, not the dashboard body itself. The dashboard lives under Assets, where you open it, edit it, and share it with teammates (article 303 is the sharing workflow). The follow-up prompt builds on the saved asset without having to re-explain anything.
The asset remembers how it was built
A real concern for anyone presenting numbers to a stakeholder: if the number is questioned, can you explain where it came from? Plexara captures the data history of every asset automatically. The catalog searches and queries the agent ran, the parameters it passed, and when each one happened: all of it is attached to the asset. What you and the agent said to each other is not, which is deliberate and is why the record is a strong account of where the numbers came from rather than a transcript of your thinking. You did not have to ask for the record and you do not have to maintain it. Article 306 covers how to read it and where it stops short; the productivity point for today is that the dashboard you save is also documentation of itself.
What 302 covers
A dashboard is a view that lives in the portal. A data export is a file meant to leave the portal: a spreadsheet a colleague will sort in Excel, a CSV your finance team pulls into a pivot, a JSON your engineering team hands to another system. Same asset system, same durability, different shape. Article 302 is the one for that case.
Key terms
Six words you will see across the rest of the 300 series. Each one is named from the user's perspective; the platform mechanics behind them are background, not the point.
Key Terms
- Asset
- A saved piece of work in your Plexara portal: a dashboard, a written report, a chart, or a data file. Has a name, an owner (you), and a link your teammates can open if they have access.
- Save Assetsave_asset
- The tool the agent uses to save your work to the portal. You almost never need to name it; saying "save it as an asset" usually triggers it.
- Manage Assetmanage_asset
- The tool the agent uses for everything after a save: finding existing assets, updating them, sharing them, organizing them into collections. Subsequent articles in this series cover the individual workflows.
- Plexara portal
- The web interface where your saved work lives. The Assets page lists everything you have created, loading more as you scroll; each asset opens in a viewer suited to what it is (clickable dashboard, formatted report, sortable table). It is where you browse, not the only way back to an asset: the agent can find one for you from any session.
- Provenance
- The record of how an asset was built, attached automatically. Lets you (or a teammate) trace numbers back to their queries without re-doing the work.
- Version
- Each update to an asset creates a new version while keeping the old one. The shared link keeps working; you can also roll back if a change was wrong. Article 305 covers editing.