Plexara
What you will take away from this lesson
Your team already has the report template, the brand header, the data dictionary, and the pre-flight checklist. They exist, and somebody spent real time getting them approved. Then an AI tool produces a report in a layout it invented, and somebody pastes the real template into the chat by hand for the third time this week.
Resources are where those files live, so that stops happening. In 208 - The prompt library: versioned, shared, and measurable, the procedures got a home. This lesson is the material those procedures depend on: what counts as one, how the agent finds it, how it changes without breaking anything that points at it, and how an approved template stops being a suggestion.
Learning Objectives
- 01Apply the one-sentence rule that decides whether a file is a resource, an asset, a knowledge page, or a memory, and say what breaks when it lands on the wrong one.
- 02Tell the four resource categories apart by the verb each one implies: produce it in this layout, follow this procedure, match this example, consult this document.
- 03Describe how an agent reaches a resource: search returns a reference, fetch reads it in full, and the protocol methods stay available to a persona that cannot use search.
- 04State what a deployment with uploaded material adds to the agent instructions, and why the section names a tool only when the caller can reach it.
- 05Replace a resource in place and read its version history without breaking a single citation or prompt attachment.
- 06Read the usage panel and the Last read column to find the material nothing has touched.
- 07Take an approved template from a suggestion to a rule through the Agent Instructions page, for the whole deployment or for one audience.
Where we are in the curriculum
If any term in this lesson feels unfamiliar, the 100 series is one click back. The 200 series assumes that mental model.
100 Series: the foundation
- 101What is a Large Language Model?Brilliant at language, blind about your data. Tokens, hallucination, the grounding problem.
- 102Tokens and your budgetSubscription-plan economics, session limits, and Plexara enrichment dedup.
- 103Context, compression, and memoryThe keep / compress / clear playbook and how memory carries across sessions.
- 104Frontier models, specialized models, and why enterprise AI uses bothThree knowledge sources (training, web search, tools). MCP as the exposure protocol.
- 105What is an AI agent?The think/call-tool/observe loop. Professor's knowledge, child's literalism.
- 110Is MCP just an API wrapper?MCP as an application layer. Spectrum from thin wrapper to full application server.
If a term in this lesson looks unfamiliar, back up to the 100 series. The 200 series assumes that mental model. Every row above is a direct link.
One sentence, held identical everywhere
A resource is a human-authored input the agent uses as-is. That is the whole idea, and the thing worth noticing is not the definition but what the product does with it.
The sentence, as the product states it
Resources are human-uploaded inputs an agent uses as-is: report templates, brand files, data dictionaries, sample payloads, and reference documents. Assets are AI-generated outputs. Knowledge pages are curated facts to search and synthesize. Memory is per-user recall. If it existed before the conversation and the agent should use it verbatim, it is a resource.
That is one string. The agent receives it in the instructions it is given at the start of every session, the person uploading a file reads it on the Resources page and again in the upload dialog, and a test fails the build if any of those copies drifts from the others. The definition of a resource cannot quietly become three slightly different definitions, because the build stops when it does.
Where you meet that sentence
A definition in documentation is a definition nobody reads. This one is placed where the decision is made.
samples reads “example payloads and extracts the agent can pattern-match against”.Choosing, as four questions
Plexara has four places content lands, and people reliably put things in the wrong one, because the instinct is to sort by file type. A PDF goes with the PDFs. That instinct is wrong here: the split is about who wrote the thing and what the agent is supposed to do with it.
Four questions, four layers
| Ask | It is a | Portal page |
|---|---|---|
| Did it exist before the conversation, and should the agent reproduce it rather than rewrite it? | Resource | Resources |
| Did the agent make it in a session, and does a person want to keep or share it? | Asset | Assets |
| Is it a fact you want found, cited, and synthesized into new answers? | Knowledge page | Knowledge |
| Is it about how one person works? | Memory | Knowledge |
The four layers are covered side by side in 201, with what each holds and how the agent reaches it. What matters here is that the distinction is authorship, not file format. The same PDF is a resource when a person uploaded it and an asset when the agent produced it.
What happens when it lands on the wrong layer
This is the part that makes the model stick, because the consequences are not abstract and they show up weeks later, when nobody connects them back to a decision made at upload time.
What getting it wrong actually costs
A report template saved as an asset
An asset is something the agent believes it produced, so the next session regenerates the template rather than reusing it. The layout drifts a little every quarter and nobody can point at the moment it changed.
A reference PDF pasted into a knowledge page
A knowledge page holds text to be searched and synthesized. Pasting a document into one loses its formatting and its bytes, which is exactly what a brand file exists to preserve.
A durable fact filed as a personal memory
Memory is per-user recall. A fact that belongs to the business reaches one person instead of the team, and the next colleague to ask has to be told it again.
The categories carry the same distinction one level down
Every resource takes a category, and the four built-in ones are not a filing taxonomy. Each names a different relationship between the agent and the file.
The four categories, and the verb behind each
templates
Produce it in this shape
Layouts a deliverable must be produced in. The quarterly report skeleton, the incident writeup, the compliance export. The template defines the structure, the section order, and the headings; the analysis fills it.
playbooks
Follow this, do not summarize it
Procedures to work through step by step. A runbook for diagnosing a slow query, a pre-flight checklist for a migration. The distinction matters: an agent that summarizes a checklist has skipped every item on it.
samples
Match this
Examples to pattern-match against. A finished report from last quarter, a sample payload, a well-formed export. The tone, the depth of detail, and the shape of the output propagate without anyone writing them down as rules.
references
Consult this
Documents to look things up in. A data dictionary, a SQL style guide, a glossary of regional codes. The agent is not reproducing them, it is reading them to get something else right.
The category is not a folder. It is the same distinction as the four layers, one level down: it tells the agent what to do with the file it just opened. Anything that fits none of the four takes a category of your own naming, which is why real libraries also carry runbooks, checklists, and queries.
The Resources page
Uploading takes a file, a category, a display name, a description, and tags. The description is the field that decides whether anyone finds the file again, because it is what a semantic search ranks and what the agent reads when it is choosing between two plausible candidates. "Q3 template" is a name. "The approved layout for quarterly business reviews, including the required section order" is a description.
How the agent finds one: search, then fetch
The old answer to this question was the protocol: list the resources, read the one you want. That still works and it still matters, but it is no longer the main path. Uploaded material is indexed into the same universal search that reaches the catalog, knowledge pages, assets, and prompts, which means the agent finds a template the way a person would, by describing it.
How a session actually reaches a file
search
One query fans across everything the caller can reach, uploaded material included, and comes back grouped by source. A resource hit carries its name, description, and category, plus a reference of the form mcp:resource:<id>.
the index
Each resource is indexed on its metadata and, for text-family files, on a bounded prefix of its contents, so a data dictionary is found by a column name that appears only inside the file. Indexing runs off to the side: a new upload is findable by name and description immediately, and by its contents once the indexer has read it. Files past 8 MB are indexed on metadata alone.
fetch
Pass the reference back and the content comes in full: text inline, a binary file as its metadata plus the URI to read it by. Search results also carry a resource link, which a client with native resource support can attach directly.
visibility
The same rule as everywhere else. Global material reaches every caller, persona material only its members, personal material only its owner. A search cannot surface a file the caller could not open.
This is the same front door covered in 203. Uploaded material is not a separate lookup the agent has to remember to perform; it is one more source in the search it already runs.
The path that is always available
What the agent is told about your files
Uploading a file is only half of it. The agent also has to know that looking is worth doing, which is why a deployment holding uploaded material adds a section to the instructions every session receives.
What the agent is told, once material exists
The instructions the agent receives carry the positioning statement, then three operating rules:
- Before you format a deliverable, search for an applicable template or reference resource and follow it rather than inventing a layout.
- When the user names a company file ("our template", "the checklist", "the brand header"), resolve it with search and read it in full with fetch instead of asking them to paste it.
- Material attached to a prompt is authoritative: use it as given rather than paraphrasing it or substituting your own.
The section names a tool only when the caller can reach it. A persona denied search is pointed at resources/list instead. A deployment with nothing uploaded gets no section at all, because instructions about material that does not exist only teach the agent to go looking for nothing.
Steering, not enforcement
Making an approved template mandatory
When a template is a standard rather than a suggestion, an administrator writes that as a rule on the Agent Instructions page, and it applies from the next session onward.
Making an approved template mandatory
Write the rule
The Agent Instructions page in the admin portal edits the operating guidance every session receives. It is a split editor, source on the left and rendered preview on the right, and what you save takes effect immediately.
Read the baseline first
Above the editor sits the read-only platform baseline: the guidance already composed beneath yours, naming only the tools this deployment actually exposes. Reading it first is how you avoid restating what is covered and contradicting what is not.
Make it binding
A reporting standard reads roughly as: every report, summary, or briefing must use the approved template for that deliverable; search the templates category for one matching the deliverable, produce the output in its structure, section order, and headings; and if no approved template exists, say so in one line before the output so the gap is visible.
Scope it to one audience
A rule that should apply to client-facing work but not internal analysis goes on the persona rather than the deployment, through that persona’s instruction suffix. Both land in the same instructions the agent reads, so the analyst persona can carry a brand-header requirement nobody else is held to.
The clause that earns its place is the last one. An instruction to use the approved template, with no instruction about what to do when there is not one, produces an agent that quietly invents a layout and says nothing. Requiring it to name the gap turns a missing template into a line somebody can act on.
Resources change, and changing one is the interesting part
Calling a resource "read-only content" was always slightly wrong. Read-only describes what the agent does with it, not what it is. The template gets revised every year, the style guide gets a new section, the brand header changes when marketing changes it. What matters is that the revision does not break the prompts and the citations already pointing at the file.
Revising a resource without breaking what points at it
Replace content, do not re-upload
Replacing the file on the detail view keeps the resource id, its canonical URI, and its file name, so every citation and every prompt attachment pointing at it keeps resolving. Only the bytes, the type, and the size change. Deleting and re-uploading looks equivalent and is not: it mints a new id and breaks all of them at once.
The name on your file is ignored
The uploaded file’s own name is deliberately discarded, for the same reason. A resource whose file name changed under a stable id is a resource whose citations still point somewhere but no longer read as the same thing.
Sessions are told
Agents connected at the moment of the change are notified that the material changed, so a client re-reads rather than serving what it already had.
Restore promotes, it does not rewind
Version history records every revision with its number, who uploaded it, when, and how large it was. Any version can be downloaded, and restoring an older one re-promotes that exact content as a new head revision, labeled with the version it came from. The trail only ever grows, so what you restored is itself restorable.
History is bounded, live content is not
A resource keeps its ten most recent revisions, and a new revision past that cap removes the oldest stored file. The live content is never pruned. This is a version history, not an archive, and knowing which one you have matters before you rely on it.
One resource, open
Seeing what is actually used
The failure mode of a shared library is not that it stays empty. It is that it fills, and then nothing on the page distinguishes the template three teams depend on every Monday from the one somebody uploaded in March and forgot. Both look like a name, a category, and a size.
Seeing what is actually used
Reads, by the door they came through
The detail view reports reads over the last 30 and 90 days, split by how the content was served: an agent reading it over the protocol, a search result fetched in full, or a person downloading it from the portal. Plus when it was last read at all.
A Last read column, and a sort for it
The admin table carries last-read on every row and sorts by it, so a curator can order the library by recency instead of guessing. Material never read since it was uploaded, over a month ago, is flagged rather than left to be noticed.
Listing is not reading
Enumerating the library does not count. Only content actually served counts, which is what keeps the number a measure of use rather than a measure of traffic.
These counts come from the read audit trail, so they reach back as far as your audit retention does. A library nobody curates fills with material that was urgent once, and without a read count every row on the page looks equally important.
The curator view
Never under Last read, and two of them are called out in amber. Four uploaded runbooks and checklists that no session has ever opened is a finding, and it is not one anybody would reach by reading the names.Attaching a resource to a prompt
Searching for the right template works. Not having to search is better, and that is what an attachment is: the material bound to the procedure that needs it, delivered with every run.
Starting a library from nothing
Where this leads
Key terms
Eight terms cover the vocabulary. Category, replace content, and attached material are the ones a person meets on screen; the resource reference and the protocol methods are what explain how the agent got there.
Key Terms
- Resource
- A human-uploaded input an agent uses as-is: a report template, a brand file, a data dictionary, a sample payload, a reference document. Distinguished from the other three content layers by who authored it and when, not by file format.
- Category
- What the agent should do with the file. templates are layouts a deliverable must be produced in, playbooks are procedures to follow rather than summarize, samples are examples to pattern-match against, references are documents to consult. Anything else takes a category of your own naming.
- Resource reference
- The mcp:resource:<id> handle a search result carries. Pass it to fetch to read the file in full. It is bound to the resource rather than to its content, which is why replacing the content leaves every citation resolving.
- Replace content
- Uploading new bytes for an existing resource, keeping its id, canonical URI, and file name. The path that preserves citations and prompt attachments, as against delete-and-re-upload, which mints a new id and breaks them.
- Version history
- The append-only record of a resource’s revisions, each with its number, uploader, timestamp, and size. Restoring an older version re-promotes its exact content as a new head revision. Bounded at the ten most recent; the live content is never pruned.
- Read accounting
- Reads over the last 30 and 90 days, broken down by whether an agent read the file over the protocol, a search result was fetched, or a person downloaded it. Surfaces as a Last read column and a sort in the admin table. Listing the library does not count as a read.
- Attached material
- Resources bound to a prompt in an authored order and delivered to the agent as authoritative. An attachment must be at least as widely visible as the prompt that carries it.
- resources/list and resources/read
- The protocol methods for enumerating and reading this material by URI. Persona-filtered like everything else, but not tools, so they remain available to a caller whose persona grants no tools at all. The fallback path when search is out of reach.