# Plexara > A fully managed MCP data platform from Deasil Works. Plexara connects AI agents to enterprise data through one governed Model Context Protocol endpoint, and every answer arrives with the business context, institutional knowledge, and access rules the agent needs to be right. Plexara is operated by Deasil Works, Inc. Each customer gets a dedicated installation that Deasil provisions, hosts, upgrades, and monitors; the customer connects an AI agent over MCP and works in the Plexara portal. The platform provides federated SQL across warehouses and databases (Trino), catalog metadata and governance (DataHub), object storage, REST API and MCP gateways, persona-based access control, audit logging, a memory and knowledge layer that promotes what people teach the agent into shared documentation, spreadsheets registered as queryable tables, and automations that run agent-written scripts on demand or on a schedule. The full text of every page listed here is available in one file at https://plexara.io/llms-full.txt. # Plexara URL: https://plexara.io/ > Plexara transforms your enterprise data into a domain-expert training manual for AI through governed, semantically rich integration. Fully managed. Connect your agents over MCP. Nothing to run. ## Your whole data estate, open to your AI agents. Your AI should know your business as well as your best people do. Plexara puts your warehouses, catalog, files, and APIs behind one governed endpoint your AI agents reach over MCP, the open standard for connecting agents to tools and data. What an agent learns becomes reviewed knowledge that every teammate's agent shares. In our benchmark, a fact taught by one person reached a different teammate 98.9% of the time. [See How It Works](https://plexara.io/product) [Talk to us](https://plexara.io/contact) Agents over MCP Claude Claude Code ChatGPT Gemini Grok Cursor your own agents A Finance analyst teaches Plexara that total_amount is gross and net revenue must subtract returns. After review, an Operations lead asks a related question and their agent uses the same fact, credited to who taught it. In our benchmark, 98.9% of taught facts were used correctly by a different teammate. [98.9% of facts taught by one person are used correctly by a different teammate's agent](https://plexara.io/benchmark/accuracy) Benchmark ### Empirical rigor, quantitative and qualitative Our accuracy study held the AI model and the data fixed, changed only whether Plexara was in the loop, and graded thousands of repeated runs; its lifecycle scorecard follows a taught fact all the way to a different person, and a companion cold-start experiment watched a fresh install learn each fact it was taught. Our knowledge-use study asks whether agents act on the knowledge the platform delivers, and found the value concentrates in exactly the facts an agent cannot look up or work out on its own. Our knowledge-pollution study asks the harder question underneath both: what an approval mistake costs once a wrong fact is in the shared knowledge layer, and which model tier is exposed to it. And our graph-completion study measures what the connections between knowledge pages buy an agent that has to produce a complete document, not just a correct answer. Every number ships with a DOI-archived report, the raw runs, and the code to reproduce it. Correct answers on business-rule questions +56 pts Raw data tools 43% Plexara 99% same model, same data, same questions; 95% CI +44 to +67 [From the accuracy study](https://plexara.io/benchmark/accuracy) 47%→99% what one person teaches, the next teammate gets A fact taught in one person’s session, once reviewed and applied, is there for a colleague who was never in that conversation. Teaching the platform the same thing twice used to be the norm; now it almost never happens. [From the accuracy study: the lifecycle scorecard](https://plexara.io/benchmark/accuracy) 75%→0% made-up company definitions in answers Without your definitions, an agent invents plausible ones and answers confidently. Our knowledge-use study found that once Plexara delivers the real definition, the agent uses it every time and the inventing stops. [From the knowledge-use study](https://plexara.io/benchmark/knowledge-use) 47%→91% a fresh install, learning as it is taught Starting from an empty knowledge layer, accuracy climbed as business facts were taught one at a time, each question class jumping from floor to ceiling at its own lesson. [From the accuracy study: the cold-start experiment](https://plexara.io/benchmark/accuracy) 0 of 96 wrong facts a frontier-class model took over the correct source We planted a wrong fact through our own review queue to find out what an approval mistake costs. A cheap model took it and stopped checking; the frontier-class models we run in production re-derived the answer and declined it every time. The study now decides which claims our review tooling puts a verified number next to, and it is why we pair Plexara with frontier-class models rather than the cheapest one that fits. [From the knowledge-pollution study](https://plexara.io/benchmark/knowledge-pollution) 0.2% of a 5,000-page knowledge base read to ground every governing constraint We asked agents to write complete operational documents, a change plan, an incident write-up, with the governing constraints scattered across an operations wiki. Agents followed the references between knowledge pages voluntarily, and the references held the effort of finding each constraint flat as the corpus grew a hundredfold; stripping them roughly doubled the effort and produced the only failed run. With search off, references were the only route that worked at all. [From the graph-completion study](https://plexara.io/benchmark/graph-completion) The benchmark ablates the platform, not the model, with ground truth generated from a fixed seed and every number read from the platform’s own audit log. Full methodology, figures, and reproduction commands are published. [Explore the research](https://plexara.io/benchmark) [Inspect the open harness](https://github.com/txn2/mcp-data-platform/tree/main/bench) How it works ### One endpoint. Every answer in context. Your agents connect once. Plexara reaches your catalog, your databases through Trino, your object storage, and any MCP server or API you already run. Every call is scoped to the persona asking, every result comes back carrying the catalog context and reviewed knowledge the answer needs, and the whole exchange lands in the audit log. AI assistants [Image: Claude] Claude [Image: ChatGPT] ChatGPT Custom Agent [Image: Plexara] One MCP endpoint Added to every call Catalog context Owners, glossary, lineage Applied knowledge Reviewed facts your team taught Persona scope Only what the asker may see Memory What the agent learned, kept Audit trail Every call on the record What it reaches [Image: DataHub] DataHub Catalog [Image: Trino] Trino Federated SQL [Image: S3] S3 Object Storage MCP Gateway Any MCP server API Gateway Any REST or GraphQL Via Trino federation [Image: PostgreSQL] PostgreSQL [Image: MySQL] MySQL [Image: Snowflake] Snowflake [Image: BigQuery] BigQuery [Image: MongoDB] MongoDB [Image: Elasticsearch] Elasticsearch + 35 more connectors via Trino Why this stack ### Tools, meaning, and memory in one envelope Most agent platforms are tool-callers wrapped in auth. They route the call but pass nothing about what the data means. Plexara's MCP envelope carries three things at once: the tool, the catalog context that explains the response, and the knowledge captured from how this kind of question was answered before. Single MCP envelope Tools How the agent acts - MCP Gateway - API Gateway - Trino + S3 Meaning What the response is for - Semantic Enrichment - Catalog context - PII + ownership Memory What was learned before - Knowledge Capture - Past sessions - Applied corrections Agent tool call returns enriched Tools Any MCP server, any REST or GraphQL endpoint, behind one MCP endpoint. Existing investments plug in without rewrite. Meaning Catalog context, ownership, PII flags, deprecation notices, and glossary terms attached to every response. The agent does not have to ask. Memory Corrections from past sessions feed the catalog. The next agent inherits what the last one learned. The platform improves with use. Other stacks force the agent to reason across separate products. Plexara makes meaning a property of every tool call. Intelligence ### Search, Context, and Health You Can See The platform grounds every answer in your business context and keeps the semantic search behind it healthy and measured. 01 Universal Search #### One Search Across Everything the Platform Knows A single query fans across the DataHub catalog, canonical knowledge pages, memory, captured insights, saved assets, prompts, connected API endpoints, and connections, grouped by source with a coverage summary and balanced so the largest source never drowns the rest. Your agents call the same federation you see here. [Image: Unified search across catalog, knowledge pages, memory, insights, assets, prompts, and connections] Intelligence ### Memory, Insight, Knowledge One pipeline turns what your team knows into shared, governed knowledge. Memory is captured automatically, the facts worth sharing become insights for review, and approved insights are promoted into canonical knowledge. 01 Memory #### Everything the Platform Learns Starts as Memory Corrections, business context, and preferences shared during sessions land in memory, classified by type: preference, event, business knowledge, operational rule, or schema and entity fact. Most memory is personal and stays with you. It is the raw substrate everything else is promoted from. [Image: Personal memory records classified by type with active, stale, and archived states] Connectivity ### Connect Any API, Federate Any MCP Server Bring every REST API and MCP server your agents need under one governed, audited, context-enriched endpoint. 01 Any REST API #### Turn Any REST API Into Agent Tools Point the platform at an API and it reads that API's own OpenAPI description to learn every operation and input. Ten APIs do not add a thousand tools: the whole surface is served through four tools, backed by versioned catalogs many connections can share. [Image: API catalogs list showing versioned OpenAPI specs that connections reference] Portal ### Durable Assets, Curated and Reviewed Every insight an agent generates becomes a managed, rendered, shareable asset that people can curate, share, and review in place. 01 Live Assets #### AI Output That Renders, Not Just Text Dashboards, reports, and charts an agent produces are saved as versioned assets and rendered natively in the portal: HTML and JSX as interactive components, SVG as crisp vector graphics, Markdown formatted, CSV as sortable tables. Each carries a record of the tool calls that produced it. [Image: Live-rendered HTML dashboard with KPI cards, a regional bar chart, and a product table] The Challenge ### Most Organizations Are Not AI-Ready It is not an AI problem. It is a data problem. 95% of generative AI pilots are failing, largely due to data infrastructure gaps Source: [MIT NANDA, The GenAI Divide: State of AI in Business (2025)](https://fortune.com/2025/08/18/mit-report-95-percent-generative-ai-pilots-at-companies-failing-cfo/) 15% of organizations have networks fully ready for AI workloads Source: [Cisco AI Readiness Index (2025)](https://www.cisco.com/c/m/en_us/solutions/ai/readiness-index.html) #### AI sees rows, not meaning AI can query your data, but it does not know what the data means. It cannot distinguish deprecated tables from active ones, or identify which columns contain sensitive information. #### Context lives in people, not systems Business rules, data ownership, quality caveats: this context exists only as tribal knowledge in people's heads. When they leave, the knowledge walks out the door. #### The real bottleneck is understanding The bottleneck is not AI capability. It is the gap between raw data and business understanding. AI needs context to deliver trustworthy answers. #### Infrastructure was not built for AI Most data infrastructure was designed for human analysts, not AI agents. Connecting AI to existing systems without semantic context produces unreliable results. The Process ### Three Stages to AI-Ready Data Plexara is both a product and a progressive process. Start where you are, and build toward full AI integration. Stage 01 #### Data Platform Foundation Don't have a modern data platform? We'll build one. Plexara begins with implementing a data platform tailored to your data and your business. This is not off-the-shelf. It is an architecture designed around your specific data landscape, built on proven open-source technologies that Deasil Works has deployed and managed for over 25 years. Components may include federated SQL query engines, distributed object storage, data pipelines, and the infrastructure to connect your existing databases into a unified, queryable estate. Stage 02 #### Semantic Layer & Knowledge Capture Don't have a semantic data layer? We'll create one. It becomes your AI's training manual. We configure a semantic and metadata layer that captures and organizes the business details that often exist only as tribal knowledge: the meaning behind column names, the business rules no one documented, the context that makes data useful. People leave. Context is lost. Institutional memory fades. Plexara turns that tribal knowledge into a durable asset, and that asset becomes context AI uses to give better, more accurate, more trustworthy answers. Stage 03 #### AI Integration: The Weave Plexara means interwoven. We take these components and weave them together into the ultimate tool for AI. Plexara connects your data platform and semantic layer to AI agents through the Model Context Protocol (MCP), the emerging standard for AI-to-data integration. When AI queries your data, it does not just get rows and columns. It gets business context automatically: ownership, quality scores, deprecation warnings, PII tags, glossary definitions, lineage tracking. AI becomes a domain expert on your business. Differentiation ### What Plexara Is Not Not Not a chatbot. Plexara is infrastructure, not a conversational interface. Not Not a copilot. It does not compete with Claude, GPT, or any AI model. It makes them all better. Not Not a generic MCP connector. It does not blindly execute queries against your data. It ensures AI understands the meaning behind your data. Not Not an AI product. AI models evolve rapidly and AI-specific products become outdated immediately. Plexara is integration infrastructure that supercharges the best AI agents of today and tomorrow. Not Not proprietary lock-in. Built on open standards being adopted by all major AI providers. Standards ### Protocols Outlast Products The most durable technology investments are protocol-level, not product-level. HTTP outlasted Netscape SQL outlasted every database vendor of the 1990s TCP/IP outlasted everything #### MCP: The Next Durable Standard The Model Context Protocol was created by Anthropic in November 2024, donated to the Linux Foundation in December 2025, and co-founded by Anthropic, Block, and OpenAI. Supporting members include Google, Microsoft, AWS, Cloudflare, and Bloomberg. 97M+ monthly SDK downloads 10,000+ active MCP servers 300+ MCP clients Source: [Agentic AI Foundation announcement (December 2025)](https://www.anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation) Plexara bets on the protocol layer, not the model layer. Integration infrastructure is more durable than any specific AI product. While Plexara currently provides the richest experience with Anthropic's Claude, it is built on standards being adopted by all major AI providers. Capabilities ### Built for Enterprise Data Integration #### Semantic Enrichment Query any data source and receive business context alongside your results. Every response includes ownership, quality scores, PII warnings, deprecation notices, and glossary definitions. #### Knowledge Capture Domain knowledge shared during AI conversations (column meanings, business rules, data quality observations) is captured, reviewed, and written back to your metadata catalog. #### Knowledge Graph The same corpus reads as a reference network: every knowledge page, asset, prompt, connection, and catalog entity a page cites is a node, and every stored reference is an edge. Nodes are sized by how much of the graph they bridge, so the facts holding otherwise separate topics together are the ones you see first. #### Lineage-Aware Metadata Downstream datasets automatically inherit documentation, quality indicators, and business context from their upstream sources. #### Enterprise Security Fail-closed authentication with OIDC, API keys, and a built-in OAuth 2.1 server. Every request is verified against your identity provider before any tool executes. #### Personas & Access Control Define who can access which capabilities based on roles mapped from your identity provider. #### Federated SQL Query across PostgreSQL, MySQL, Elasticsearch, Cassandra, BigQuery, MongoDB, Hive, and other sources through a single SQL interface. #### Spreadsheets as Tables A CSV somebody uploads, or one the agent builds and saves, registers as a queryable table in one step. The file is read where it sits, joins the warehouse with SQL, and is flagged the moment it goes stale. #### Automations Your agent works a report out once, then saves it as a script Plexara runs on demand or on a schedule. Dashboards and data feeds stay fresh with no agent in the loop, no token spend, and no database access handed to a BI tool. #### MCP Gateway Bring any MCP-compatible server into the Plexara envelope. Existing MCP investments inherit catalog context, persona-based access, and audit logging without rewrite. #### API Gateway Reach any REST or GraphQL endpoint as a tool. Existing services become first-class agent capabilities, with the same enrichment and governance applied to every call. #### Fully Managed Platform Plexara runs as a fully managed service operated by Deasil. Upgrades, monitoring, and scaling are handled for you. Connect your AI agent to one governed endpoint and start working. #### Asset Management AI-generated analyses become organizational assets. Interactive dashboards, reports, charts, and documents are saved with provenance tracking, versioned with full history, organized into curated collections, and shared across the team or through a time-limited public link. #### Prompt Library Repeatable work becomes a governed prompt rather than pasted text. Approved prompts group into collections, their arguments stay typed, and the reference material a procedure depends on travels attached to it. Approval is stamped per version, so the name beside it signed off on that exact text, and every prompt carries its run count and how long since it last ran. #### Review That Becomes Knowledge Reviewers, including subject-matter experts who never open an agent, leave corrections and questions anchored to the exact passage and to the version they were raised against. Threads carry a kind and a status lifecycle, open items that need resolution are counted rather than lost, and an agent closes one by capturing the correction as an insight for review. #### MCP Apps A tool result can carry a reference to a UI resource, and a host that understands it renders that interface beside the answer. Plexara delivers two: a platform overview and an interactive prompt browser. Both are presentation only, so a client that renders no UI still receives the same structured data. #### Email Notifications Shares, comments, mentions, and review-queue alerts reach people in their inbox, on terms each person sets. Mail leaves through a Deasil Works mail server, and your admins can point delivery at your own provider instead, confirm it with a test send, and watch every message in the delivery log. Production ### Proven in Production Across Industries Plexara is not theoretical. It is running in production today. #### Retail Analytics A multi-tenant retail analytics platform integrating point-of-sale data, inventory management, and revenue reporting across multiple data systems. - Five persona types - Cross-system query orchestration - Live knowledge capture and governance #### Media & Broadcasting A media analytics platform spanning six data domains with 141+ cataloged entities, covering video streaming, broadcast ratings, digital analytics, email marketing, audience data, and operational metadata. - Non-technical leaders asking natural language questions - Contextually rich answers without SQL - No data team intermediation required Partnership ### Plexara + Deasil Works Plexara is a product of Deasil Works, Inc., a technology services company with over 25 years of software development, systems integration, and infrastructure management experience. Deasil Works builds custom data platforms and data warehouse solutions for organizations across media, retail, entertainment, manufacturing, and finance. The Plexara go-to-market pairs the product with Deasil Works professional services. You get both the platform and the expertise to deploy it in your environment. This is not a SaaS tool you configure yourself. It is an engineered solution backed by a team that has been building enterprise data infrastructure for decades. [Learn more about Deasil Works](https://deasil.works) From the Blog ### Latest Insights [15 min Philosophy The Frontier Report: 2026 Q3 Independent scores for current frontier flagships as of September 2026, written for someone putting an assistant in front of company data. Read](https://plexara.io/learning/insights/frontier-report-v1) [9 min Governance Every call your agent makes states its purpose An AI agent that can query your warehouse leaves a question behind: what did it run, and why? On Plexara every query and API call carries the purpose the agent stated for it, every session can be opened long after it ended, and every saved report names the calls it was built from. Read](https://plexara.io/learning/insights/every-call-states-its-purpose) [10 min Product The report that runs without the agent An hour with an AI assistant produces the perfect sales report. Re-deriving it every week burns tokens on logic that is already settled. Plexara lets the agent save that logic as a script the platform runs on demand or on a schedule: reports, exports, and dashboards that stay fresh with no model in the loop. Read](https://plexara.io/learning/insights/the-report-that-runs-without-the-agent) Common questions ### Plexara FAQ The Model Context Protocol is an open standard from Anthropic for connecting AI agents to tools and data. Plexara packages your enterprise data behind a single MCP server with semantic context, persistent memory, and governance, so any MCP-capable client (Claude, ChatGPT, custom agents) can answer questions about your business without bespoke integrations per agent. [Learn more: Is MCP just an API wrapper?](https://plexara.io/learning/ai-concepts/mcp-vs-apis) Snowflake stores and queries data for human analysts. Plexara sits in front of your existing data infrastructure (Snowflake included) and exposes it to AI agents through MCP, with the semantic catalog, governance, and memory those agents need. Plexara does not replace your warehouse. It makes the warehouse usable by AI without bolting on more vendors. Plexara ships a governed semantic catalog built on DataHub as a first-class component. If you already run DataHub, Plexara reads from your existing instance. If you do not, the platform deploys one. Other catalogs that expose an MCP server can integrate today through Plexara's MCP gateway, and native support for additional metadata providers is on the roadmap. Every conversation captures new business context as catalog metadata, so the catalog improves with use. [Learn more: Why point-solution catalogs and semantic layers are not enough](https://plexara.io/learning/insights/why-point-solution-catalogs-are-not-enough) Plexara is a managed, fully-engineered solution priced per deployment based on data sources, expected agent volume, and the support tier you need. No per-seat pricing, no marketplace tier. Contact us with a description of your data landscape and use cases for a concrete quote. [Learn more: Replacing the five-vendor data stack with one platform](https://plexara.io/learning/insights/replacing-the-five-vendor-data-stack) Governance is enforced when an agent calls a tool, not described in a policy document. Personas restrict which tools an agent can see and use. Default-deny applies to anything not explicitly allowed. Every tool call is logged in a single audit stream tied back to a human user. Connections are managed centrally, with key rotation and revocation as one-click operations. [Learn more: Governance: personas, access, and audit](https://plexara.io/learning/mcp/governance-personas-and-access) Next ### Product Overview See how Plexara unifies query execution, semantic metadata, and governance into a single MCP server. [Continue](https://plexara.io/product) --- # Our Thesis URL: https://plexara.io/approach/ > The thesis behind Plexara: standards over products, composable architecture, and progressive implementation that captures tribal knowledge. Our Thesis ## Standards Over Products Plexara is built on the thesis that the most durable technology investments are protocol-level, not product-level. We build integration infrastructure that outlasts any specific AI model or vendor. Market Context ### The AI Readiness Problem The data infrastructure market is consolidating rapidly. IBM acquired Confluent for **$11B**, Fivetran and dbt Labs merged, Databricks acquired Neon for **$1B**. Everyone is racing to add AI capabilities, but they are bolting on support as an afterthought. > Plexara is different. It is built natively for AI integration from the ground up. Not as an add-on feature. Not as a marketing checkbox. As the core architectural purpose. Architecture ### The Composable Platform Plexara assembles modular components into a unified integration layer. Each component can be deployed individually or composed into a complete platform. Start with what you have and what you need. No rip and replace. No big-bang migration. Data Querying Federated SQL across your entire data estate Metadata Governance Ownership, quality scores, and lineage tracking Object Storage Distributed storage for any data format Knowledge Capture Tribal knowledge as structured intelligence Implementation ### Progressive Implementation 01 #### Data Foundation Build a data platform foundation tailored to your infrastructure: federated query engines, object storage, data pipelines, all connecting your existing databases into a unified estate. 02 #### Semantic Layer Add a semantic layer that captures the business context living in your team's heads: column meanings, business rules, data quality observations, ownership records. This becomes your AI's training manual. 03 #### AI Integration Weave everything together through the Model Context Protocol, connecting your enriched data estate to any AI agent. The result: AI that understands your business as deeply as your best people do. Feedback Loop ### Knowledge as a First-Class Citizen Most platforms treat metadata as documentation, something you fill in if you have time. Plexara treats knowledge as a first-class citizen in the data architecture. Domain knowledge shared during AI sessions (corrections to metadata, business context about data meaning, quality observations, usage tips) is captured through a governance workflow. It is reviewed, synthesized, and written back to the metadata catalog. Your organization gets smarter over time. Every conversation makes the next one better. The Knowledge Cycle 1. 1. AI Session 2. 2. Knowledge Capture 3. 3. Review & Governance 4. 4. Catalog Integration Cycle repeats continuously > Tribal knowledge becomes structured institutional intelligence. Common questions ### Plexara Approach FAQ Open protocols (MCP, Trino, DataHub) outlast any single vendor. Building on protocols rather than proprietary platforms means your investment in semantic context, memory, and audit is not coupled to a vendor roadmap. If you swap query engines or catalogs later, the protocol layer absorbs it. [Learn more: Protocols outlast products](https://plexara.io/learning/insights/protocols-outlast-products) A first deployment connects two or three data sources and one persona. Subsequent rollouts add sources, personas, and use cases without rewriting what came before. Each conversation strengthens the catalog and memory, so depth compounds rather than requiring a single large up-front effort. [Learn more: Why a Plexara rollout starts small](https://plexara.io/learning/insights/why-a-plexara-rollout-starts-small) All semantic metadata captured through Plexara lives in DataHub in standard formats. You keep what your team has authored regardless of whether you continue with Plexara. The platform does not hold metadata hostage behind a proprietary store. [Learn more: What you keep if you leave](https://plexara.io/learning/insights/what-you-keep-if-you-leave) Plexara stays out of the way of the protocols it composes. Agents call standard MCP. Queries run on standard SQL via Trino. Metadata lives in standard DataHub formats. Plexara is the orchestration and governance layer; the data, queries, and metadata stay portable. [Learn more: Protocols outlast products](https://plexara.io/learning/insights/protocols-outlast-products) A homegrown MCP server gets you the protocol. It does not get you persona-based access control, default-deny security, audit logging tied to identity, semantic enrichment, persistent memory, knowledge capture, or federated query execution across 40+ data sources. Plexara is what those layers look like when built once, by a team that does this for a living, and operated as a managed service. [Learn more: Why MCP gateways are not enough](https://plexara.io/learning/insights/why-mcp-gateways-are-not-enough) Next ### Product See how the thesis shows up in the platform: enrichment, memory, knowledge capture, and governance. [Continue](https://plexara.io/product) --- # Services URL: https://plexara.io/services/ > Deasil Works provides custom data platforms, Plexara implementation, and managed services backed by 25+ years of enterprise data infrastructure experience. Services ## Platform + Expertise Plexara is not a SaaS tool you configure yourself. It is an engineered solution backed by Deasil Works, a team that has been building enterprise data infrastructure for decades. Service ### Custom Data Platforms Deasil Works designs and builds custom data platforms and data warehouse solutions. Over 25 years of experience in software development, systems integration, and infrastructure management. Every platform is architected for your specific data landscape and business requirements. Experience 25+ Years Approach Architected for your specific data landscape Scope Systems integration, infrastructure, pipelines 1. 01 Assessment Data landscape review and platform design 2. 02 Build Semantic layer, knowledge capture, AI integration 3. 03 Operate Production deployment and ongoing support Service ### Plexara Implementation End-to-end deployment of the Plexara platform, from initial assessment through production operation. This includes data platform design, semantic layer configuration, knowledge capture setup, AI integration, and ongoing support. You get a working platform, not a pile of documentation. Service ### Managed Services Ongoing platform management, monitoring, and optimization. Deasil Works can operate your Plexara deployment so your team focuses on using the data, not managing the infrastructure. Includes performance tuning, security updates, and capacity planning. > Your team focuses on using the data. We handle the infrastructure. Clients ### Industries Served Media & Broadcasting Retail & E-commerce Entertainment Manufacturing Finance Deasil Works has built data infrastructure across these industries over 25+ years of engagements, from media companies managing audience analytics to retailers unifying point-of-sale systems across locations. Plexara deployments to date are in retail analytics and media; the platform inherits this engineering history. [Learn more about Deasil Works](https://deasil.works) Common questions ### Services FAQ Three things. The platform itself (managed deployment, infrastructure, ongoing operation). The integration work to connect your data sources, define personas, and tune the catalog. And the support tier you select for response time, advisory, and escalation paths. Pricing combines all three; nothing is sold a la carte. A consulting firm hands you a deck. Plexara hands you a running platform with documented connections, defined personas, and a working agent surface, plus the team that built it on call to evolve it. The deliverable is a production system, not a strategy document. Yes. A typical PoC connects two data sources and one persona to validate that the agent surface answers the questions your team actually asks. PoC scope is defined in the initial assessment so success criteria are explicit before work begins. [Learn more: Your first day with Plexara](https://plexara.io/learning/mcp/first-engagement) Deasil Works is the engineering team behind Plexara. The firm has 25+ years of enterprise data platform experience and continues to take on custom data platform engagements alongside Plexara deployments. If your need extends beyond what Plexara covers natively, the same team can build the rest. Plexara is a managed service. The platform is upgraded centrally; you do not run a release process. Changes that affect customer-facing behavior (new tools, persona model changes) are reviewed with your team before they land in your deployment. Audit history persists across upgrades. Next ### Locations Six data center facilities across the United States. Over 30 years of real infrastructure. [Continue](https://plexara.io/locations) --- # Contact URL: https://plexara.io/contact/ > Start a conversation about your data landscape. Tell us what you are trying to achieve with AI and we will respond within one business day. Contact ## Start a Conversation Tell us about your data landscape and what you are trying to achieve with AI. We will respond within one business day. ### What to expect 1. Step 1 Response within one business day A real person from the team reads every inquiry. No auto-responder bouncebacks. 2. Step 2 30-minute scoping call We walk through your data landscape, the AI use cases you are targeting, and what success looks like. 3. Step 3 Clear next step If there is a fit, we propose a concrete next step: assessment, pilot, or deployment. If not, we tell you. Email [support@plexara.io](https://plexara.iomailto:support@plexara.io) Phone [(818) 945-0821](https://plexara.iotel:+18189450821) Mailing 121 W. Lexington Drive Glendale, CA 91203 ### Subscribe to the Plexara Newsletter Once a month: new product features, MCP and AI educational resources, practical tips, and enterprise AI insights. Written for data leaders, engineers, and developers. --- # Architecture URL: https://plexara.io/architecture/ > Plexara's 8-layer middleware pipeline composes Trino, DataHub, and S3 through provider abstractions into a single governed MCP server with fail-closed security. Architecture ## 8-Layer Middleware Pipeline Plexara processes every MCP request through a configurable middleware pipeline that composes three provider-abstracted systems into a single governed server. Middleware ### The Pipeline Every MCP request flows through eight independently configurable layers. Each layer can be enabled, disabled, or customized without affecting others. Layer 1 #### Description Overrides Rewrites tool descriptions with workflow guidance, operational requirements, and contextual instructions. Layer 2 #### Tool Visibility Filtering Hides tools the user is not authorized for, reducing LLM token consumption and preventing unauthorized access attempts. Layer 3 #### MCP Apps Metadata Attaches the UI resource reference that lets a host render an interactive app beside a tool result. Presentation only: the same result is complete for clients that draw no UI. Layer 4 #### Authentication and Authorization Validates credentials (OIDC, OAuth 2.1, API keys), resolves persona, and enforces tool-level access control. Layer 5 #### Audit Logging Records every tool call with user identity, persona, connection, duration, and success or failure status. Layer 6 #### Rule Enforcement Session-aware workflow gating that tracks whether discovery tools were called before query tools, with configurable escalation thresholds. Layer 7 #### Client Logging Provides structured logging output for MCP client consumption and debugging. Layer 8 #### Semantic Enrichment Intercepts every tool response and enriches it with business context from complementary services. The architectural core of the platform. Abstraction ### Provider Interfaces Three provider interfaces decouple enrichment logic from specific implementations. The platform can evolve its backing services without changing the enrichment pipeline. #### SemanticProvider Abstracts access to the metadata catalog. Resolves entity URNs, retrieves descriptions, tags, glossary terms, lineage, and quality signals. DataHub is the default implementation. #### QueryProvider Abstracts access to the query engine. Exposes schema information, table availability, and connection routing. Trino is the default implementation. #### StorageProvider Abstracts access to object storage. Manages bucket listing, object retrieval, presigned URLs, and prefix-level access control. S3 is the default implementation. Security ### Fail-Closed by Default Missing or invalid credentials deny access. No persona assigned means zero tool access. Default-deny posture with explicit allow rules. Authentication supports OIDC with required JWT claims, OAuth 2.1 with PKCE and Dynamic Client Registration, and API key management for service accounts. Persona-based authorization maps IdP roles to tool allow and deny patterns with wildcard support. Each tool call is logged with user identity, persona, connection, duration, and outcome. Supply chain security includes signed build provenance published as GitHub artifact attestations on every release, static analysis with Semgrep and CodeQL, race condition detection, and OpenSSF Scorecard tracking. Common questions ### Architecture FAQ Plexara composes eight layers between the AI client and your data: MCP transport, authentication and authorization, persona resolution, tool visibility filtering, semantic enrichment, query execution (Trino), metadata catalog (DataHub), and object storage (S3). Each layer is a provider abstraction, so the default implementations are swappable. [Learn more: Anatomy of a Plexara MCP](https://plexara.io/learning/mcp/what-is-an-mcp) Every unauthenticated request, unmapped persona, undefined tool, undefined argument, or unknown data source is rejected by default. A persona is what opens a surface, so a caller whose roles match no persona reaches nothing at all. There is no anonymous mode, no permissive default, no bypass. AI agents only see and call what is explicitly allowed for the authenticated identity behind them. [Learn more: Closed by default: least privilege as the starting point](https://plexara.io/learning/insights/closed-by-default-access) The Model Context Protocol from Anthropic for the AI-facing surface. Apache Trino for federated SQL across data sources. DataHub for the semantic catalog. S3 for asset storage. None of these are proprietary to Plexara; the platform is the integration and governance work above them. [Learn more: Protocols outlast products](https://plexara.io/learning/insights/protocols-outlast-products) Trino routes a single SQL query across multiple physical data sources (PostgreSQL, Snowflake, Iceberg, S3, and Kafka among its 40+ connectors) and assembles the result. Agents write standard SQL without knowing where data physically lives. The federation layer handles connector-specific quirks, query optimization, and result composition. [Learn more: Trino Query: analytics and insights](https://plexara.io/learning/mcp/trino-query-analytics-and-insights) Every tool call is logged with the user identity, the persona under which the call was made, the resolved connection, the tool name, the arguments, and the truncated result. A failure also carries its category, so a denied permission, a malformed call, and a platform fault stay distinguishable in the stream. The audit stream is queryable in the portal and exportable to your SIEM. Persona filtering is enforced before the call, not after, so denied calls also appear in the log. [Learn more: Governance at execution time vs. catalog time](https://plexara.io/learning/insights/governance-at-execution-time) Next ### Use Cases See what a connected agent can do with your data and your APIs, and how the two compound over months of use. [Continue](https://plexara.io/use-cases) --- # Locations URL: https://plexara.io/locations/ > Six data center facilities across the United States. Over 30 years of managing real infrastructure, from bare-metal hardware to custom Kubernetes clusters. Infrastructure ## Built on Real Infrastructure Over 30 years of building and managing real infrastructure, from physical hard drives to custom Kubernetes clusters. Hands-on experience with every layer of the data stack. Foundation ### Infrastructure Company First Plexara is built by Deasil Works, an infrastructure company that has been managing networks and bare-metal hardware across the United States for more than 25 years. We started with custom servers and private clouds long before cloud computing was a category. That foundation matters. When we build a data platform, we understand what happens at every layer: the physical drives, the network topology, the operating systems, the container orchestration, the databases, the query engines, and the applications that sit on top. There are no black boxes in our stack. Our facilities are secure with highly managed access controls, redundant power and cooling, and direct peering connections to major network exchanges. Every location is staffed by engineers who maintain the physical infrastructure that runs our platforms. This is the difference between a company that rents compute from a hyperscaler and one that owns the metal. We control the full stack because our customers depend on it. Data Centers ### Six Facilities Across the United States Geographically distributed for redundancy, low-latency coverage, and compliance with data residency requirements. All facilities are secure with managed physical access controls. #### Dallas/Fort Worth Central US hub with direct connectivity to major internet exchanges. Low-latency access to midwestern and southern enterprise customers. Strategic geographic position minimizes round-trip times to both coasts. #### Las Vegas Western interconnection point with strong connectivity to Los Angeles and the broader Southwest. Benefits from Nevada's stable power grid and favorable operating environment for high-density compute. #### Los Angeles Multiple facilities serving the largest metropolitan economy on the West Coast. Direct peering with Pacific Rim networks and submarine cable landings. Critical for latency-sensitive workloads serving western US and Asia-Pacific clients. #### Pasadena Secondary Los Angeles metro facility providing geographic redundancy within the Southern California region. Dedicated low-latency connectivity to the Los Angeles facilities with automatic failover. #### Phoenix Southwest facility with access to low-cost, reliable power. Serves as a disaster recovery and burst capacity site for western US deployments. Growing connectivity hub for enterprises expanding outside traditional coastal data center markets. #### Washington, D.C. East Coast presence in the densest interconnection market in North America. Direct access to Ashburn's carrier hotel ecosystem. Supports deployments with east coast data residency requirements. Read More ### Insights Technical deep dives, architecture decisions, and perspectives on governed context. [Continue](https://plexara.io/learning/insights) --- # History URL: https://plexara.io/history/ > Plexara began in 2024 as Methodology, an internal Deasil Works project for text-to-SQL. The timeline from sentence embeddings and StarCoder to MCP and the platform Plexara is today. Our History ## From Methodology to Plexara Plexara did not start with a pitch deck. It started with a thesis: that the truest description of a company is the SQL its analysts have already written. Everything that followed is the story of what happens when a thesis like that meets the right wave of technology at the right time. Foundations: 2018 to 2022 ### The pieces were already in motion Plexara would not have been possible five years earlier. The story really begins with the four primitives that quietly arrived in the late 2010s and early 2020s: a benchmark, an embedding, a database for vectors, and a paper that named the pattern everyone would soon be building. 1. 2018 #### Spider sets the bar for text-to-SQL Yale researchers publish the Spider benchmark, the first cross-domain test for natural-language-to-SQL systems. It becomes the yardstick the field will chase for the next half decade. 2. 2019 #### Sentence-BERT puts meaning in a vector Reimers and Gurevych release Sentence-BERT, making it practical to compare entire sentences by semantic similarity at scale. Embeddings move from research curiosity to production primitive. 3. 2019 to 2021 #### Vector databases enter the stack Milvus is open-sourced. Weaviate ships. Pinecone exits beta. Andrew Kane releases pgvector. Within two years, dense-vector retrieval has gone from a special-purpose technique to a feature you expect from your database. 4. 2020 #### The RAG paper formalizes a pattern Lewis et al. at Facebook AI publish "Retrieval-Augmented Generation," giving a name to the architecture that will dominate the next wave of language-model applications: retrieve relevant context, then generate against it. 5. 2022 #### ChatGPT arrives GPT-3.5 reaches a million users in five days. Every enterprise data team starts asking the same question that week: how do we point this thing at our data without giving away the keys? The Spark: 2023 ### Purpose-trained models become viable 2023 is the year the toolkit arrives. Frontier models become genuinely useful for code. StarCoder and SQLCoder make local, fine-tuned generation a real engineering option. Across the industry, the dominant pattern crystallizes: retrieve known answers as context, then let a code-trained model adapt. 1. March 2023 #### GPT-4 and Claude raise the ceiling Frontier models cross the threshold of being usefully reliable for code and reasoning tasks. Tool use and function calling land mid-year, turning chatbots into something that can actually do work. 2. May 2023 #### StarCoder ships BigCode, ServiceNow Research, and Hugging Face release StarCoder, a fifteen-billion-parameter code model trained on permissively licensed source. For the first time, a capable code model can run inside a private network without sending tokens to a vendor. 3. August 2023 #### Defog open-sources SQLCoder A StarCoder derivative tuned specifically for SQL generation lands on Hugging Face, posting strong numbers on the Spider variant benchmarks. Local, purpose-trained text-to-SQL becomes a viable engineering plan, not a research paper. 4. Late 2023 #### The semantic-search-plus-coder pattern matures Across the industry, teams converge on the same recipe: encode known queries and documentation as vectors, retrieve the closest matches, hand them to a code-trained model as context, and let it draft an answer. It works, with caveats. Origin: 2024 ### Methodology, an internal project at Deasil Works Plexara begins life as Methodology, a research effort inside Deasil Works to make text-to-SQL actually work for real customer data. The thesis is simple, and at the time, slightly unfashionable: the canonical description of a business is the corpus of SQL its analysts already write. 1. Early 2024 #### A thesis: a company is its SQL Deasil Works has spent decades running data platforms for enterprise customers. One observation keeps surfacing: the truest description of a company's data is not a wiki page or an entity-relationship diagram. It is the hundreds of ad-hoc SQL queries that analysts have written to answer real questions. Those queries encode the joins, filters, business definitions, and edge cases that nobody bothered to write down. 2. Q1 2024 #### Methodology begins as an internal project An internal effort named Methodology starts inside Deasil Works to test the thesis. Curate the queries the analysts already trust. Describe each one in plain language. Index those descriptions as embeddings. When a new question comes in, retrieve the closest curated query, then hand it to a purpose-trained SQL coder to adapt. The pattern works well enough on customer pilots to keep going. 3. Mid 2024 #### The ceiling becomes visible Two limits emerge at once. Methodology only knows what was seeded into it: questions that drift outside the curated set produce mediocre answers. And the purpose-trained coders, capable as they are, lack the open-ended reasoning that frontier models make look easy. Customers start asking the wrong question of the right system. 4. Mid 2024 #### DataHub joins the stack LinkedIn open-sourced DataHub in 2020 and Acryl had been commercializing it since 2021. Methodology adds DataHub as a metadata enrichment layer over the curated queries: column lineage, ownership, glossary terms, quality scores. Answers get better. The walls of the walled garden get a bit higher, but they are still walls. Inflection: November 2024 ### MCP arrives, and the strategy inverts On November 25, 2024, Anthropic published the Model Context Protocol. For an internal project that had been steadily climbing the curated-query, semantic-search, fine-tuned-coder ladder, MCP was not an incremental improvement. It was a different game. The right move was to stop competing with frontier models and start integrating with them. 1. November 25, 2024 #### Anthropic announces the Model Context Protocol MCP is published as an open specification with reference servers and SDKs in Python and TypeScript. The shape of the problem changes overnight. The question is no longer how to build a better text-to-SQL system. It is how to make every frontier model a first-class client of your enterprise data, with governance, memory, and semantic context preserved across the boundary. 2. Late 2024 #### Stop competing. Start integrating. The internal decision is straightforward. Methodology had been trying to win against frontier models with a smaller, purpose-trained stack. MCP makes that the wrong fight. The work pivots: the curated query corpus, the semantic catalog, the DataHub enrichment, the governance, and the memory all become services exposed through a single MCP server. Frontier models bring the open-ended reasoning. The platform brings the context they don't have. 3. Q1 2025 #### Methodology becomes Plexara The internal project is hardened, packaged, and rebranded as Plexara, the commercial product. Same lineage, different mission. Plexara is no longer a custom-trained answer generator. It is an integration platform that any MCP-capable client can attach to and immediately understand the business behind the data. 4. 2025 #### MCP becomes the standard OpenAI adopts MCP across ChatGPT and the desktop app. Google confirms support in Gemini. Microsoft previews MCP in Windows and across Foundry and Azure. The bet that integration would beat differentiation is settled in public. By the end of the year, Anthropic donates the protocol to the Agentic AI Foundation under the Linux Foundation, ensuring the standard outlasts any single vendor. Today ### The thesis, intact Two years after Methodology started, the original idea has held up better than the original implementation. The truth is still in the SQL. The catalog is still where business meaning lives. The difference is what sits on top: not a smaller model trying to compete, but a governed integration layer that makes the best models in the world fluent in your business. 1. 2026 #### Where Plexara stands today Plexara is a fully managed enterprise integration platform. Federated query through Trino. A governed semantic catalog through DataHub. Persistent memory and knowledge capture as first-class services. Every component reachable through one MCP server, with fail-closed governance on every tool call. The thesis from Methodology is intact: a company's data is described by the way its people query it. Plexara is what happens when that thesis grows up, lets go of trying to be the model, and instead becomes the layer that makes every model an expert in your business. [The story continues, week by week, in the changelog](https://plexara.io/product/changelog) What's next ### Our Thesis Where the history points: standards over products, composable architecture, and knowledge captured as a first-class citizen of your data estate. [Continue](https://plexara.io/approach) --- # Team URL: https://plexara.io/team/ > Plexara is a product of Deasil Works, Inc. Meet the engineers behind it: founders Jeff Masud and Craig Johnston and the core team that has built and operated enterprise systems together for over 25 years. Our Team ## The Team Behind Plexara Plexara is a product of Deasil Works, Inc. Adopting it means working with the engineers who built it, a team that has designed, shipped, and operated enterprise systems together for over twenty-five years. Product of Deasil Works, Inc. ### You Get the Team, Not Just the Software Plexara is built and operated by Deasil Works, an engineering company that has been shipping software and running real infrastructure for enterprises for over twenty-five years. The principals and core team have worked together since the 1990s, across entertainment, retail, logistics, automotive, and manufacturing. That continuity is the point. The thesis behind Plexara came out of decades of running real data platforms for real customers, not from a whiteboard. The people who formed that thesis are the people who maintain the platform today. When you adopt Plexara, you are not handed a login and left alone. You get direct access to the people who built it: the founders, the product lead, the engineers tuning the AI integration, and the team that keeps the infrastructure running. The same hands that shipped the platform are the ones who help you put it to work. That is what a fully managed product backed by an engineering company is supposed to mean. The People ### The Core Deasil Works Team Plexara customers work directly with the founders and the engineers responsible for product, AI integration, education, and infrastructure. #### Jeff Masud Co-founder Jeff has been building software for more than twenty years, from a single clear vision through the complex business logic that enterprises actually run on. He founded Deasil Works to do hands-on engineering for companies that need systems built right, and he co-founded Plexara to turn decades of that work into a governed integration layer any AI agent can use. CEO, Deasil Works #### Craig Johnston Co-founder Craig has led software and creative engineering teams at Deasil for over two decades, across entertainment, retail, logistics, and manufacturing, and has written extensively on Kubernetes and cloud-native architecture. He sets the technical direction for Plexara: open standards, composable architecture, and no black boxes anywhere in the stack. CTO, Deasil Works #### Dan Mehta Product Management As a senior project manager and QA engineer, Dan specializes in developing and executing exploratory and automated tests, the discipline that keeps complex platforms reliable. On Plexara he owns product management, turning what customers need into a roadmap and making sure every release behaves the way the documentation says it does. Sr. Project Manager and QA Engineer, Deasil Works #### David Elsensohn Integration and Education David has worked at the intersection of online development and music for over twenty-five years. He leads integration and education for Plexara, helping teams connect their data sources and learn to get real work done with a governed MCP server, so the platform lands as working practice rather than a slide deck. Lead UX/UI Engineer, Deasil Works #### Jonathan Garcia AI Integration, Tuning, and Development Jonathan leads senior backend development at Deasil, designing and building the services and APIs the platform runs on. For Plexara he focuses on AI integration, model tuning, and development: the work of making frontier models fluent in a customer's business through enrichment, memory, and retrieval that holds up in production. Sr. Backend Development, Deasil Works #### Mikel Arvizu Infrastructure and Support Mikel keeps the metal running. He manages the bare-metal hardware, networks, and Kubernetes clusters behind Plexara across Deasil's United States facilities, and he is the person on the other end when something needs attention. To him, infrastructure and support are the same job: the platform is only as trustworthy as the systems underneath it. Infrastructure and Support, Deasil Works Work With Us ### Talk to the Team Tell us what you are trying to do with AI and your data. The people who build Plexara are the people who will answer. [Continue](https://plexara.io/contact) --- # Developers URL: https://plexara.io/developers/ > Build on Plexara. Complete REST API for assets, collections, knowledge capture, memory, personas, prompts, audit, governance, and tool execution. Developers ## Build on Plexara Plexara exposes every portal capability as a typed, authenticated, audited REST API. Assets, collections, knowledge capture, memory, personas, prompts, audit, governance, and tool execution. The same endpoints the portal uses are available to your integrations, agents, and pipelines. [Full API Reference](https://plexara.io/api-reference/) [Get API Access](https://plexara.io/contact) Why it Matters ### Not an Afterthought API The Plexara REST API is the canonical surface of the platform. The portal is a SPA that consumes it. Admin tooling, user workflows, and automated pipelines all speak the same HTTP. Whatever the portal can do, your code can do, under the same governance. #### Fail-Closed Authentication Every request is authenticated against your identity provider before any tool or data access occurs. No anonymous mode. No permissive fallback. #### Persona-Enforced Authorization Each call is evaluated against the caller persona. Unauthorized tools, connections, and resources are not just blocked; they are not visible. #### Audit on Every Call Tool calls, queries, and errors flow into structured audit with indexed fields for user, tool, timestamp, status, and latency. Query the same log the platform does. #### Typed Schemas, Live Catalog Every tool exposes a JSON schema. Every endpoint returns typed responses. The catalog is live: new tools appear the moment they are registered. Authentication ### Three Methods, One Identity Model Every method resolves to the same persona system. Whether a request arrives from a human, a service, or an MCP client, Plexara evaluates it against the same policy graph and writes the same audit record. #### API Key Service accounts, CI pipelines, scheduled jobs. Minted per service with explicit persona scope, expiration, and rotation. Revocable in one click. Usage is audited. ``` X-API-Key: ``` #### Bearer Token (OIDC) Interactive human users via your identity provider. Tokens validated against your upstream IdP with JWKS auto-discovery. Roles map to personas through your existing identity infrastructure. ``` Authorization: Bearer ``` #### OAuth 2.1 + PKCE MCP clients, desktop agents, third-party integrations. The built-in OAuth 2.1 server bridges MCP clients to your upstream IdP with PKCE, rotating refresh tokens, and bcrypt-hashed client secrets. ``` Authorization: Bearer ``` [Image: The Keys admin screen listing API keys in a table with name, email, description, roles, expiration, and a delete action per row, one key struck through and marked Expired, and an Add Key button at the top right] Every service key in one table: who it belongs to, what it is for, which roles it carries, and when it expires. An expired key stays listed, struck through. [Image: The Keys admin screen with the Add Key form expanded above the table, showing name, email, and description fields, a roles input with a Browse available roles link, an expiration picker set to Never, and a Create button] Minting a key is a name, an owner, the roles it should resolve to, and an expiration. The roles decide the persona, so a key never gets more than its role allows. Quickstart ### Your First Request List the tools your persona has access to. No SDK required. Any HTTP client works. List tools (Admin) ``` curl https://api.plexara.io/api/v1/admin/tools \ -H "X-API-Key: $PLEXARA_API_KEY" \ -H "Accept: application/json" ``` Get current session (Portal) ``` curl https://api.plexara.io/api/v1/portal/me \ -H "Authorization: Bearer $PLEXARA_TOKEN" \ -H "Accept: application/json" ``` Execute a tool ``` curl https://api.plexara.io/api/v1/admin/tools/call \ -X POST \ -H "X-API-Key: $PLEXARA_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "name": "trino_query", "arguments": { "query": "SELECT 1" } }' ``` [Image: The Try It tab for the Trino Query tool in the Tools admin screen, with a SQL text area, limit, timeout, and output format fields, an Execute button, and an empty History panel reading no test calls yet] The same tool call from the portal: Try It on any tool in Admin runs it with the arguments you type and keeps a history of the test calls, so you can check a request before scripting it. API Surface ### Three Namespaces, One Platform Every route lives under one of three top-level namespaces, across more than 200 paths. A representative subset of each is shown below. The complete endpoint catalog, with request and response schemas, lives in the API reference. #### Portal `/api/v1/portal` Practitioner-scoped endpoints. Everything the portal SPA calls on behalf of a signed-in user: assets, collections, knowledge pages, prompts, scripts, feedback threads, worklists, and recorded calls. Scoped to the caller and their persona. - GET `/api /v1 /portal /me` Current session identity and persona. - GET `/api /v1 /portal /search` One query across every source the caller can reach. - GET `/api /v1 /portal /assets` List personal assets. - GET `/api /v1 /portal /assets /{id} /versions` Asset version history. - GET `/api /v1 /portal /assets /{id} /signoff` How many stakeholders have signed off. - PUT `/api /v1 /portal /collections /{id} /sections` Reorder collection sections. - GET `/api /v1 /portal /knowledge-pages /graph` The knowledge corpus as typed nodes and edges. - GET `/api /v1 /portal /knowledge-pages /{id} /lineage` The insights a page was built from. - POST `/api /v1 /portal /threads /{id} /insight` Capture a feedback thread as an insight. - GET `/api /v1 /portal /worklist /sme` Threads awaiting your validation. - POST `/api /v1 /portal /scripts /{id} /runs` Run a saved script. - POST `/api /v1 /portal /calls /{id} /promote` Publish a satisfied query or API call. - GET `/api /v1 /portal /shared-with-me` Assets shared with me. - GET `/api /v1 /portal /memory /records` My memory records. - GET `/api /v1 /portal /prompts` Personal and accessible prompts. - GET `/api /v1 /portal /notifications` My notification feed. #### Admin `/api/v1/admin` Platform administration. Audit, personas, connections, API catalogs, knowledge governance, index health, managed scripts, mail settings, the user directory, the tool catalog, and tool execution. - GET `/api /v1 /admin /system /info` Platform identity and features. - GET `/api /v1 /admin /audit /events` Structured audit log search. - GET `/api /v1 /admin /audit /metrics /overview` Latency and success rates. - GET `/api /v1 /admin /tools` Full tool catalog. - POST `/api /v1 /admin /tools /call` Execute a tool. - PUT `/api /v1 /admin /tools /{name} /visibility` Show or hide a tool platform-wide. - POST `/api /v1 /admin /personas /{name} /test-access` Preview a persona decision before saving it. - GET `/api /v1 /admin /connections /oauth-health` Authorization health for every connection. - GET `/api /v1 /admin /api-catalogs /{id} /embedding-health` Indexed, pending, and failed specs per catalog. - GET `/api /v1 /admin /index-jobs /failures` What failed to index, and why. - PUT `/api /v1 /admin /knowledge /insights /{id} /status` Approve or reject a captured insight. - POST `/api /v1 /admin /knowledge /changesets /{id} /rollback` Reverse a changeset. - GET `/api /v1 /admin /scripts /runs` Every managed-script run. - PUT `/api /v1 /admin /scripts /{id} /schedule` Put a script on a schedule. - POST `/api /v1 /admin /settings /smtp /test` Send a test message through your mail settings. - GET `/api /v1 /admin /notifications` Delivery status of every sent notification. - GET `/api /v1 /admin /users` The user directory. - POST `/api /v1 /admin /auth /keys` Mint a service API key. #### Resources `/api/v1/resources` MCP resource CRUD. The same resource surface exposed to AI agents, directly accessible for tooling, validation, and automation. - GET `/api /v1 /resources` List visible resources. - POST `/api /v1 /resources` Create a resource. - GET `/api /v1 /resources /{id}` Get resource metadata. - GET `/api /v1 /resources /{id} /content` Download resource content. - POST `/api /v1 /resources /{id} /content` Replace resource content. - GET `/api /v1 /resources /{id} /versions` Resource revision history. - POST `/api /v1 /resources /{id} /versions /{version} /restore` Restore a prior revision. - PATCH `/api /v1 /resources /{id}` Update resource. - DELETE `/api /v1 /resources /{id}` Delete resource. [Open Full API Reference](https://plexara.io/api-reference/) MCP Apps ### Interactive UI Alongside a Tool Result A tool result can carry a reference to a UI resource. A host that understands the reference fetches the app HTML and renders it in a sandboxed iframe beside the answer, passing the tool result in. Plexara delivers two of these apps today, and adds more as host support for MCP Apps matures. #### Platform Info `platform_info` Renders the platform name, version, and description, the connected toolkits with their icons, which feature flags are on, and the personas active for the session. It is there in every conversation with nothing to set up. #### List Prompts `show_prompts` The prompt browser: search-as-you-type over the ranked query, My Prompts and Library buckets, collection and tag filters, usage-based sorting, and cards carrying display name, description, version, approval provenance, and run count. A detail view generates its form from the prompt argument specs, and Run resolves through manage_prompt use, placing the rendered prompt directly into the chat where the host supports conversation insertion. Presentation only, never required An app is a rendering of data that is complete without it. The same `manage_prompt` calls the prompt browser makes return full structured JSON in clients that render no UI, so a terminal client and an app-capable desktop client see the same library with different amounts of chrome. Nothing is only reachable through an app, which is what makes it safe to build against one. Apps call tools through the same gates An app calls tools itself rather than only rendering the result that opened it, and those calls travel the same MCP transport as the agent's, meeting the same persona checks and writing the same audit records. The session handle applies too: an app calls `platform_info` first and threads the returned `session_id` on every call after it. Skipping the handshake returns `SESSION_REQUIRED` on the app's first data call. `platform_info` is never gated, since it is the call that mints the handle. Bound to a display tool on purpose The prompt browser hangs off `show_prompts`, a tool that performs no data operation and does nothing but ask for the library to be displayed. `manage_prompt`, which resolves, runs, creates, and edits, carries no app. A window opens when a person asked to see one, not every time an agent touches a prompt. The error contract ### Every Failure Names Whose Fault It Is An agent that cannot tell a bad argument from a denied permission has one response to every failure: try again and hope. A failed tool call sets `isError` and returns both a human-readable message and a machine-readable `structuredContent.error` object, so the agent can branch on the difference. ``` { "isError": true, "content": [ { "type": "text", "text": "the \"asset_id\" parameter is required (code: missing_required_parameter) Hint: Supply \"asset_id\" and retry." } ], "structuredContent": { "error": { "code": "missing_required_parameter", "category": "client_input", "message": "the \"asset_id\" parameter is required", "hint": "Supply \"asset_id\" and retry. This is a problem with the call's arguments, not a platform fault." } } } ``` `code` A stable identifier the agent may branch on, such as `missing_required_parameter`, `invalid_arguments`, `not_found`, or `setup_required`. `category` The broad class of failure, which is what tells the agent whose fault it is. `message` The specific failure, in the terms of this particular call. `hint` The corrective action, whenever the caller can take one. | Category | Whose fault | What the agent should do | | --- | --- | --- | | `client_input` | The call | Fix the arguments and retry. | | `not_found` | The call | The named resource does not exist; correct the reference. | | `authentication_failed` | Caller identity | Provide valid credentials. | | `authorization_denied` | Caller identity | The persona is not permitted; request access. | | `user_declined` | The user | A consent prompt was declined. | | `setup_required` | Session state | Call the required setup tool first. | | `feature_unavailable` | Nobody | The capability is not part of this deployment. Report it as unavailable rather than as an outage, and do not retry. | | `internal` | The platform | Not the caller's fault; do not retry with modified input. | | `tool_error` | Unclassified | A failure that has not been given a finer category. The message is still descriptive. | The envelope is uniform by construction. A normalization layer wraps every error result even when an individual tool returns nothing but a bare string, so an agent never receives an opaque failure it cannot classify. The category is written to the audit log as `error_category`, which is how a spike in denials is distinguished from a spike in outages. #### Unknown arguments are refused, not ignored Plexara tool schemas are closed to unknown top-level arguments. A misnamed argument fails at the tool boundary, before the handler runs, with the offending property named in the message. Passing `parameters` to `api_invoke_endpoint` instead of `query_params` returns this: ``` { "error": { "code": "invalid_arguments", "category": "client_input", "message": "validating \"arguments\": validating root: unexpected additional properties [\"parameters\"]", "hint": "Read the tool's schema, correct or drop the named property, and retry." } } ``` The alternative, dropping the field and running anyway, is how an agent comes to believe it applied a filter it never applied, then reports a number computed over the wrong rows. A refusal at the boundary is a mistake the agent can correct on the next call. A silent drop is a wrong answer nobody catches. Nested maps stay open where the names inside them belong to somebody else. `query_params`, `headers`, and `body` on the `api_*` tools accept arbitrary keys, because those names are the upstream API's vocabulary rather than the tool's. Content verbs ### Edit a Document Without Resending It Regenerating a whole report to change one sentence costs output in proportion to the document rather than the change, and every regeneration is another chance to silently drop an unrelated paragraph. `manage_asset` and `manage_prompt` carry the same six content verbs, with the same argument names, the same operations, and the same error codes on both. The loop for a large document is `outline` or `locate` to decide where, then `patch` that place. The body crosses the wire in neither direction. `outline` The heading tree with levels, line numbers, and per-section byte size. On an HTML, JSX, or SVG asset it also returns the addressable landmarks: every element carrying an id or a data-* marker, with its tag, a copyable selector, its line, and its size. `locate` Literal or regex matches with the total count, line numbers, enclosing section, and a context window wide enough to copy verbatim into an anchor. The count is the point: an agent that checks first never guesses. `get_content` Read one span rather than the document: the whole body, a single section or selector-addressed element, or a line range. `stats` Size, line count, current version, content type, and body hash. `patch` Apply an ordered list of anchored edits. Every edit resolves against an in-memory copy first, and the first failure aborts the whole call and writes nothing, naming the failing edit by index. `diff` Compare two versions, or a pending prompt draft against the approved snapshot still being served, which is the question a reviewer actually has. #### On HTML, JSX, and SVG, you address a node A `selector` names an element by CSS selector, and the region is that element's balanced subtree, running from its start tag through its matching end tag. A replace or a move cannot cut a tag in half. Type, `#id`, `.class` (which also matches a JSX `className`), `[attr]` and `[attr=value]` are supported, joined by descendant or child combinators. A selector matching several elements is refused, with the count in the message, and `occurrence` is the explicit opt-in when the caller means a specific one. On a dashboard with no headings, `outline` returns the landmarks, so an agent finds where to patch without reading the body. Markdown addresses regions by heading instead, and a structureless format like JSON or CSV refuses both and takes anchored edits. Matching is exact, with a single retry that normalizes line endings and trailing whitespace. Nothing beyond that: no fuzzy or semantic matching, because a plausible-but-wrong edit applied silently is worse than a rejection the agent can correct. The response never echoes the new body, only the new version, the new size, a per-edit outcome, and a unified diff of the changed hunks. `dry_run` returns exactly that report without writing. Patch two regions of a dashboard ``` { "action": "patch", "asset_id": "ast_...", "base_version": 7, "edits": [ { "op": "replace_section", "selector": "[data-region=\"revenue\"]", "text": "..." }, { "op": "replace", "selector": ".metric", "occurrence": 2, "find": "Users", "replace": "Active Users" } ], "change_summary": "restate the revenue card, relabel the second metric" } ``` `base_version` is optional and checked when supplied. A mismatch is refused with the current version in the error, so an agent that threads the version it read gets lost-update protection for free. A patch writes an ordinary new version, so history and revert keep working, and a patch to an approved prompt still produces a pending draft for review. Content-type detection ### The Stored Type Is Detected, Not Taken on Faith An upstream API that answers a JSON endpoint with `text/plain`, a browser that sends `application/octet-stream` for an extension it does not recognize, and an agent that saves a payload under a catch-all type would each otherwise produce an asset the portal can only show as raw text. Detection runs on every write path that accepts outside content: `save_asset`, `manage_asset` updates, `api_export`, and resource uploads. A specific declaration still wins. Detection only runs when the declaration is absent, `application/octet-stream`, or `text/plain`. Binaries from magic bytes, structured text from bounded heuristics Images, audio, video, PDF, and archives are recognized from the first 512 bytes. JSON, NDJSON, XML, YAML, CSV, and TSV all look like plain text to a byte sniffer, so each gets its own heuristic over a bounded prefix. A prefix, never the whole payload A streaming export stays streaming. The prefix is replayed ahead of the untouched remainder, so detecting the type of a multi-gigabyte export costs the same as detecting the type of a one-line file. One family, one type string Aliases normalize, so `text/json` and `application/json` both store as one type and everything downstream compares one string. The stored object key follows the detected type, so a bucket listing shows `.json` rather than `.bin`. The original declaration is kept When detection overrides a declaration, the original is recorded in the asset's provenance as `declared_content_type`. A stored type that disagrees with its source stays explainable after the fact instead of looking like a mystery. API Gateway ### Reach any connected API over HTTP The same external APIs your agents call are reachable from tools that do not speak MCP. One route proxies any operation on a connected API, so an Apache NiFi processor, an n8n workflow, an Airflow task, or a shell script gets the persona limits, stored credentials, and audit trail without holding a secret of its own. The response carries two separate statuses: the API's own status inside the body, and an HTTP status for whether Plexara allowed and completed the call. A pipeline can check one for the API result and the other for a platform error. [Explore the API Gateway](https://plexara.io/product/api-gateway) Call a connected API ``` curl https://api.plexara.io/api/v1/gateway/vendor/invoke \ -X POST \ -H "X-API-Key: $PLEXARA_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "method": "GET", "path": "/v1/orders", "query_params": { "status": "open", "limit": 25 } }' ``` Addressing an operation ### Call It by the Name Discovery Gave You `api_invoke_endpoint` and `api_export` address an operation in one of two ways. The first is the `operation_id` that `api_list_endpoints` and `api_get_endpoint_schema` already returned, which makes invocation the natural continuation of discovery: read a schema by that identifier, then call it by the same one. Plexara resolves the identifier to the method and path template from the connection's catalog, then substitutes and URL-escapes the values in `path_params`. Nobody hand-builds `/v1/users/123` out of `/v1/users/{id}`, which is where escaping bugs come from. When the same identifier appears in more than one spec in the catalog, `spec` disambiguates and the error names the candidates. The second is raw `method` plus `path`, for an uncataloged call. Supply one form or the other, never both. Invoke by operation_id ``` { "connection": "vendor", "operation_id": "getUser", "path_params": { "id": "123" } } ``` #### The built-in util connection A connection named `util` is present alongside your own, discovered and invoked exactly like any other. Its `fetch_url` operation reaches a public URL server-side and returns it inline or streams it straight into a saved asset. That closes a real gap: an ordinary gateway call joins a path to a registered base URL, so it cannot follow a one-time presigned download link whose host and token are generated on the spot. ``` api_invoke_endpoint vendor POST /exports -> job id api_invoke_endpoint vendor GET /exports/{id} -> signed download_url api_export util POST /util/fetch -> saved asset ``` The URL is used exactly as given and the query string is never re-encoded, so a signature survives byte for byte. No credential is ever attached, only `GET` and `HEAD` are accepted, and internal address space is closed: loopback, private ranges, link-local including the cloud metadata endpoint, and internal hostnames. The hostname is resolved first and only the vetted address is dialed, on every redirect hop, so a public name cannot rebind to an internal one between the check and the connection. Like every connection, `util` is deny-by-default and a persona reaches it only when its rules allow it. Conventions ### Predictable by Design Versioned, stable paths Every route is rooted at `/api/v1`. Breaking changes are versioned, never patched in place. Pagination List endpoints accept `page` and `per_page` query parameters. Responses include `total`. Content types JSON request and response bodies. Binary asset content is returned with the original content type. Errors use `application/problem+json`. Idempotency PUT and DELETE are idempotent. POST creation endpoints accept an `Idempotency-Key` header when deduplication matters. Errors ### RFC 7807 Problem Details HTTP errors are never a wall of HTML or a terse string. Every failure returns a structured problem response with a machine-readable `type`, a human-readable `title`, an HTTP `status`, and a `detail` line that explains what went wrong in the context of this specific call. A tool call that fails carries the richer error contract above instead, with its category and hint. ``` HTTP/1.1 403 Forbidden Content-Type: application/problem+json { "type": "about:blank", "title": "Forbidden", "status": 403, "detail": "persona 'analyst' does not allow tool 'trino_execute'", "instance": "/api/v1/admin/tools/call" } ``` Common questions ### Developer FAQ OIDC with required JWT claims is the primary path. OAuth 2.1 with PKCE and Dynamic Client Registration is supported for new client types. API key management (X-API-Key header) is available for service accounts that cannot do interactive auth. Your IdP provides the identity; Plexara provides the persona resolution. [Learn more: Meeting enterprise systems where they are](https://plexara.io/learning/insights/enterprise-authentication-and-isolation) They expose the same governed surface (assets, collections, knowledge, memory, prompts, personas, audit, tool execution). Choose REST when you need a service-to-service call with a stable contract. Choose MCP when an AI agent needs the same operations through a protocol it already understands. Both share one identity, audit, and persona model. [Learn more: Is MCP just an API wrapper?](https://plexara.io/learning/ai-concepts/mcp-vs-apis) The MCP server works with any MCP-compatible client SDK (Anthropic, OpenAI, the open-source MCP libraries in TypeScript and Python). The REST API ships an OpenAPI specification, so generated clients work with the standard openapi-generator tooling for whichever language your service is in. [Learn more: Two front doors, one governed surface](https://plexara.io/learning/insights/the-developer-surface) Tool calls and queries are bounded per persona, with hard limits on result size to keep responses inside agent context windows. Customer-specific quotas (concurrent agents, queries per minute, storage) are negotiated as part of the engagement. The audit log records throttling events so capacity tuning is data-driven, not guesswork. [Learn more: Token efficiency in enterprise MCP deployments](https://plexara.io/learning/insights/token-efficiency-in-enterprise-mcp) Yes. Custom tools can be registered through the Portal or via the management API, with persona-scoped visibility. They appear in the agent's tool list like any other Plexara tool, with the same audit and authorization treatment. [Learn more: Two front doors, one governed surface](https://plexara.io/learning/insights/the-developer-surface) Reference ### Full API Reference Browse every endpoint, request and response schema, and authentication detail in the complete reference. [Open Reference](https://plexara.io/api-reference/) Next ### Architecture The middleware pipeline, the provider abstractions, and where enforcement happens on every call. [Continue](https://plexara.io/architecture) --- # Security URL: https://plexara.io/security/ > How Plexara's managed architecture addresses MCP vulnerabilities disclosed in recent security research, including the April 2026 OX Security findings. Security ## MCP Security at Plexara MCP security research is moving fast, and the headlines are alarming. Here is each major disclosure, what it actually found, and how Plexara's managed architecture answers it. Last reviewed August 2026 Through 2025 and 2026, security researchers published a steady stream of findings about the Model Context Protocol: systemic remote code execution in the official SDKs, OAuth token theft through hijacked client configuration, tool descriptions that hide instructions from the user, and data that quietly steers an agent into leaking other data. The coverage is real and the research is good work. It is also, almost without exception, aimed at one side of the MCP landscape. Nearly every disclosed attack depends on the same conditions: a local developer workstation, end users installing untrusted servers on the fly, or a self-hosted framework that lets unauthenticated input reach server-launch configuration. Plexara is the other side. It is a managed service, delivered over authenticated HTTPS, with a fixed and versioned tool surface defined and deployed by our team, mapped to the OWASP MCP Top 10. This page is a living catalog. Each entry below names a specific disclosure, links to the primary research, and states plainly whether Plexara is exposed and why. Where the answer is “shared responsibility,” we say so. If a new finding lands, it gets added here. After the catalog, the control set: what the platform enforces on every request, independent of any one disclosure. That is where a reviewer will find persona-gated visibility, the tool argument boundary, how a stored file is served, and who a share link opens for. For Plexara as a vendor, tenancy, encryption, backups, incident response, and subprocessors, see the [Trust Center](https://plexara.io/trust). The Model ### Why Plexara is Secure Every threat in the catalog below maps back to the same six properties. Plexara sits on the managed-deployment side of the research, not the local-install or self-serve side. 01 #### No STDIO transport in the serving path Plexara's MCP servers run as long-lived HTTP services. Clients connect to an authenticated HTTPS endpoint. There is no subprocess spawned per request, and the StdioServerParameters code path that recent research identifies as the root cause is not in the request path at all. 02 #### No user-installable MCP servers Users of Plexara do not install, add, or configure MCP servers. The set of tools exposed to the model is defined, built, and deployed by our team, and versioned in source control. Marketplace-poisoning and typosquatting vectors rely on end users pulling untrusted servers into their environment, which is not part of this architecture. 03 #### Not built on the SDKs the research targets The CVEs concentrate in the official Python and TypeScript MCP SDKs and the agent frameworks built on them. Plexara's servers are implemented in Go using libraries we control. They do not inherit the vulnerable STDIO pattern. 04 #### Authenticated access with scoped tokens Every connection requires authentication tied to an identified user, over OAuth 2.1 with PKCE or an API key. Proving who you are is where access starts, not where it ends: a persona has to match the caller's roles before any surface opens, access tokens are short-lived, and persona allow and deny rules bound what a token can do. There is no public, unauthenticated surface to inject into. 05 #### Constrained tool surface The MCP tools Plexara exposes are read-oriented query tools against defined, managed data sources. They do not shell out, they do not accept arbitrary commands, and the blast radius of any individual call is bounded by the underlying query engine and the authorization of the calling user. 06 #### Managed, sandboxed runtime with full audit Plexara runs in Kubernetes with scoped service accounts, network policies, and resource limits. The servers have no shell execution privileges and no unscoped filesystem access, and every tool invocation is logged through platform telemetry. Threat Catalog ### The disclosures, one by one Each card names the research, summarizes the finding, links the source, and states Plexara's exposure. Remote code execution Not exposed #### STDIO transport command execution OX Security, April 2026 What the research found MCP's STDIO transport launches a local server by running an operating system command, and the official SDKs run that command before confirming the server actually started. Anything that can influence the command, through UI injection, a poisoned configuration file, or a prompt-injected agent, gets silent code execution on the host. OX assigned more than ten CVEs across local IDEs and self-hosted agent frameworks. Anthropic deemed the behavior by design. How Plexara addresses it Plexara's MCP servers run as long-lived authenticated HTTPS services. No subprocess is spawned per request, the StdioServerParameters code path is not in the request path, and the servers are written in Go using libraries we control rather than the SDKs the research targets. The exploit primitive does not exist in this deployment model. - [OX Security: The Mother of All AI Supply Chains](https://www.ox.security/blog/the-mother-of-all-ai-supply-chains-critical-systemic-vulnerability-at-the-core-of-the-mcp/) Indirect prompt injection Bounded: shared responsibility #### Toxic flows: instructions hidden in data Invariant Labs, May 2025 What the research found The hardest class of attack is not a malicious tool, it is malicious data. Instructions hidden inside content the agent reads, a database row, a stored document, an API response, can steer the agent into chaining its legitimate tools to exfiltrate other data. Invariant Labs demonstrated this against the official GitHub MCP server: a poisoned public issue drove an agent into leaking private repositories. The root cause was an over-scoped token that let the agent reach data the user could not see directly. How Plexara addresses it This is a shared responsibility between the platform and the calling agent, and we are candid about that. Plexara bounds the blast radius where it can: every tool call is authorized server-side, per request, against a fail-closed persona, so an agent can never exceed the calling user's own access. That removes the over-scope condition behind the GitHub exfiltration. Tools are read-oriented, SQL runs read-only with row and time limits, and every call is audited. What Plexara cannot do is stop a model from being persuaded by poisoned content, so a least-privilege user identity and defense-in-depth at the agent remain essential. - [Invariant Labs: GitHub MCP Exploited](https://invariantlabs.ai/blog/mcp-github-vulnerability) - [OWASP MCP Security Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/MCP_Security_Cheat_Sheet.html) Tool poisoning Not exposed in the default surface #### Hidden instructions in tool descriptions Invariant Labs, 2025 What the research found An LLM reads a tool's description before calling it. A malicious MCP server can hide instructions in that description that tell the agent to read files or exfiltrate secrets while returning a normal-looking response. The attack depends on connecting untrusted, third-party tool descriptions into the agent. How Plexara addresses it Plexara's default tool surface is fixed, reviewed, and versioned by our team; there are no third-party tool descriptions in that path. Where operators add gateway connections to external MCP or REST upstreams, those connections are curated through the admin portal with encrypted credentials, persona allowlists, and audit, not pulled from a public registry at runtime. Operators decide what enters the surface. - [Invariant Labs: MCP Tool Poisoning Attacks](https://invariantlabs.ai/blog/mcp-security-notification-tool-poisoning-attacks) Tool mutation and shadowing Not exposed (native), controlled (gateway) #### Rug pulls and cross-server shadowing Invariant Labs and community research, 2025-2026 What the research found Two related tricks target the trust placed in an approved tool. In a rug pull, a server silently changes a tool definition after it was approved; MCP has no built-in re-approval when definitions change. In tool shadowing, a malicious server registers a tool whose description manipulates how the agent uses a different, trusted tool. How Plexara addresses it Plexara's native tool surface is fixed, reviewed, and versioned in source control, so there is nothing to rug-pull. Where operators connect third-party MCP or REST upstreams through the gateway, those connections are curated through the admin portal rather than pulled from a public registry, proxied tools are namespaced as connection__tool so they cannot shadow native tools, and every definition and call is audited. Operators decide what enters the surface and see when it changes. - [Invariant Labs: MCP Tool Poisoning Attacks](https://invariantlabs.ai/blog/mcp-security-notification-tool-poisoning-attacks) Authorization Not exposed by default #### Confused deputy and token passthrough MCP specification security guidance, 2025 What the research found A gateway that proxies to third-party APIs can be turned into a confused deputy. If it forwards the client's inbound token to upstreams, the token-passthrough anti-pattern the MCP specification explicitly forbids, a stolen or misdirected token lets an attacker ride the gateway's trust into systems the user never authorized. The spec also documents consent-skipping attacks against static-client-ID OAuth proxies. How Plexara addresses it Plexara does not forward client tokens to upstreams by default. Each gateway connection authenticates to its upstream with separate, operator-configured, encrypted credentials: bearer, API key, or OAuth 2.1 client_credentials or authorization_code. Token passthrough exists only as an explicit opt-in and is mutually exclusive with stored credentials, so the confused-deputy condition cannot arise unless an operator deliberately enables it. - [MCP Specification: Security Best Practices](https://modelcontextprotocol.io/specification/2025-06-18/basic/security_best_practices) - [OWASP MCP Security Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/MCP_Security_Cheat_Sheet.html) Client-side token theft Server-side: limited blast radius #### MCP traffic hijack via the client config Mitiga Labs, May 2026 What the research found A malicious npm package with a postinstall hook rewrites a developer's local ~/.claude.json so a sessionStart hook reroutes MCP server URLs through an attacker proxy, capturing OAuth bearer tokens as they pass, and reasserting itself after token rotation. This is a compromise of the developer's workstation and the client trust model, not of any MCP server. Anthropic classified it out of scope. How Plexara addresses it Nothing Plexara ships can be the vector: it is a Go service, not an npm package, with no install lifecycle hooks. As a destination, a token stolen from a compromised workstation is constrained by design. OAuth 2.1 with PKCE keeps access tokens short-lived, persona allow and deny rules scope what any token can do, and every tool call is audited. The persistent, broadly scoped, unlogged access the research warns about is exactly what the managed model limits. The real fix lives on the workstation: audit npm post-install hooks and watch the client config for unexpected URL changes. - [Mitiga Labs: Stealing MCP Tokens in Claude Code](https://www.mitiga.io/blog/claude-code-mcp-token-theft-mitm) - [SecurityWeek coverage](https://www.securityweek.com/claude-code-oauth-tokens-can-be-stolen-through-stealthy-mcp-hijacking/) Session hijacking Not exposed #### Predictable or unbound session IDs JFrog, CVE-2025-6515, 2025 What the research found On the Streamable HTTP and SSE transports, predictable or unbound session IDs let an attacker replay a session ID to impersonate a client or inject events into their stream. Real implementations shipped this: oatpp-mcp used a memory pointer as the session ID (CVE-2025-6515), and the MCP Ruby SDK allowed SSE stream hijacking via session-ID replay (CVE-2026-33946). How Plexara addresses it Plexara generates 128-bit session IDs from a cryptographic random source, binds each session to a hash of the authenticating token, and revalidates that token on every request, including SSE streams. Sessions are never used as the authentication mechanism, which is exactly what the MCP specification requires. A session ID on its own is useless to an attacker. - [JFrog: CVE-2025-6515 Prompt Hijacking](https://jfrog.com/blog/mcp-prompt-hijacking-vulnerability/) - [MCP Specification: Security Best Practices](https://modelcontextprotocol.io/specification/2025-06-18/basic/security_best_practices) Server-side request forgery Mitigated #### SSRF via spec and metadata fetching CVE-2026-32871 (FastMCP), 2026 What the research found Gateways that ingest OpenAPI specs or fetch OAuth metadata by URL can be coerced into requesting internal addresses, cloud metadata endpoints (169.254.169.254), or localhost services. FastMCP's OpenAPI provider carried exactly this flaw, CVE-2026-32871, rated CVSS 10.0. How Plexara addresses it Plexara's spec ingestion is HTTPS-only and runs a three-layer SSRF guard: a preflight DNS check, a dial-time re-check of the resolved IP that defeats DNS rebinding, and disabled redirect following. It blocks loopback, link-local and metadata ranges, private ranges, and carrier-grade NAT. - [GitHub Advisory: FastMCP SSRF (CVE-2026-32871)](https://github.com/advisories/GHSA-vv7q-7jx5-f767) - [MCP Specification: Security Best Practices](https://modelcontextprotocol.io/specification/2025-06-18/basic/security_best_practices) Supply chain and marketplace Not exposed #### Typosquatted and poisoned MCP servers OX Security, April 2026 What the research found Several disclosed exploit families rely on end users pulling MCP servers from public registries, where a typosquatted or poisoned package can register a malicious server. The marketplace is the distribution channel for the attack. How Plexara addresses it Plexara users never install, add, or pull MCP servers. The set of tools is defined, built, deployed, and versioned by our team, with no user-facing marketplace and no runtime registry resolution. The distribution channel the attack needs is absent. - [OX Security: The Mother of All AI Supply Chains](https://www.ox.security/blog/the-mother-of-all-ai-supply-chains-critical-systemic-vulnerability-at-the-core-of-the-mcp/) Framework #### Mapped to the OWASP MCP Top 10 The catalog is not an arbitrary list. It tracks the recognized industry framework for MCP risk, so your security team can map our answers to a standard they already use rather than to vendor marketing. - [OWASP MCP Top 10](https://owasp.org/www-project-mcp-top-10/) - [OWASP MCP Security Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/MCP_Security_Cheat_Sheet.html) Controls ### What the platform enforces on every request The catalog above answers published research. This is the working control set behind those answers: who can see what, what an agent is allowed to send, what a stored file is allowed to do, and what proves a change came from your own people. #### Access and identity ##### A persona is required, never assumed Reaching the portal requires a persona that matches the roles your identity provider issued. There is no fallback persona, so an account that maps to nothing reaches nothing, and the roles it presented are written to the log for whoever investigates. ##### What a persona withholds, it withholds from search A persona's connection grants govern what a caller can see, not only what they can call. Search, connection lists, and endpoint lists return the granted connections and nothing more, and a citation cannot be followed around what search left out. When results are held back the response says so and names the persona, so "nothing matched" and "matches you are not cleared for" stay two different answers. ##### A half-granted capability gets reported Some capabilities take two tools working together: one finds the answer, the other opens it. A persona granted one and not the other is flagged as unable to complete the capability, so an administrator hears about the gap instead of a team wondering why their agent could tell them an answer existed and never read it. [Image: The Users admin screen, a directory of people known to the platform with name, email, an Active status badge, last seen date, and Edit and delete actions per row, a search box by name or email, and an Add User button] The identities the log refers to: every person known to your deployment, with when they were last seen. [Image: The Events tab of the admin Dashboard, a searchable and filterable table of tool calls with timestamp, user, tool, toolkit, source, connection, duration, status, and enriched columns, plus Export CSV and Export JSON buttons] What those identities did: one audit row per tool call, filterable by user, tool, and status, and exportable. #### The tool boundary ##### An argument the tool does not define is an error A misnamed argument is refused before the tool runs, and the refusal names the property at fault. An agent therefore never reports a filtered answer it did not actually filter, and never widens a query it believed it had narrowed. ##### Every failure names whose fault it is A denied permission, a malformed call, and a genuine outage come back as three different answers, each carrying a stable code, so an agent retries what is worth retrying and tells the person asking the truth about the rest. A capability that is switched off says so rather than presenting itself as downtime. #### Files, links, and what they can reach ##### An uploaded or shared file opens as itself A file someone uploads, saves, or shares displays as the document it is and cannot act on the platform or on the session viewing it. That holds for every stored file whatever its type, because the viewer serves all of them under a sandbox policy that admits no script rather than classifying each one and hoping the classification is complete. ##### A share link opens for the audience it was made for The audience is chosen when the link is created: the named recipient, your signed-in users, or anyone holding the link. Open to anyone is a deliberate choice and never an inferred one, and the link stops opening the moment it expires or is revoked. ##### A permission-checked response stays with the person it was served to Anything served after an authorization check is marked for that one browser, so no cache sitting between your users and the platform can answer the next holder of the URL with a copy of it. A refusal is not stored either, so a denial cannot later answer for the recipient the share was made for. #### Portal and sign-in ##### A change made in the portal has to come from the portal Every state-changing request from a signed-in browser carries proof the portal issued, and a page on another origin can neither read that proof nor forge it. A site one of your users visits elsewhere cannot make a change in Plexara on their behalf. ##### Sign-in holds to the current standard Authorization codes and refresh tokens are stored hashed rather than in the clear, only the strong PKCE challenge method is accepted, signing keys carry a key identifier so they rotate without cutting off sessions signed under the previous one, sign-in and client-registration endpoints are rate limited, and an upstream identity provider's endpoints are read from its own discovery document. Remediation ### Mapping to the industry remediation checklist The researchers and the MCP specification close their guidance with recommendations for anyone running MCP in production. Plexara already satisfies each one by design. | Recommendation | How Plexara addresses it | | --- | --- | | Block public IP access to sensitive services | Authenticated HTTPS only, with no public admin or configuration surfaces. | | Treat external MCP configuration input as untrusted | User input never reaches process-spawning configuration, because no processes are spawned per request. | | Use official MCP directories only | The set of available servers is defined and versioned by our team, not pulled from public registries at runtime. | | Never forward client tokens to upstreams | Gateway calls use separate, operator-configured upstream credentials; token passthrough is opt-in and mutually exclusive with stored credentials. | | Guard server-side fetches against SSRF | Spec ingestion blocks private, loopback, link-local, and metadata addresses with a dial-time recheck and no redirect following. | | Bind sessions to identity, never authenticate by session | Cryptographically random session IDs are bound to the auth token and revalidated on every request, including SSE. | | Run MCP-enabled services inside a sandbox | Kubernetes with scoped service accounts and network policies. | | Keep tokens short-lived and scoped | OAuth 2.1 with PKCE, short-lived access tokens, and persona allow and deny rules. | | Monitor tool invocations | Every tool call is logged through platform telemetry. | | Keep versions current | Release cadence and patch level are managed centrally. | Bottom Line ### Built around the recommended posture, not the one under attack The MCP security research is legitimate and important. It is aimed squarely at local developer tooling, self-serve installation, and client-side trust. Plexara is a managed enterprise service designed around the architectural posture that research recommends. This page answers whether the MCP architecture itself is safe. For the questions procurement asks about Plexara as a vendor, including tenancy, encryption, backups, incident response, and subprocessors, see the [Trust Center](https://plexara.io/trust). If your security team has questions beyond either page, get in touch. We can provide a formal vendor security memo on request. Next ### Contact Request a vendor security memo or discuss your security team's specific questions about the platform. [Continue](https://plexara.io/contact) --- # Trust Center URL: https://plexara.io/trust/ > Plexara as a vendor: single-tenant deployment model, encryption, access control, incident response, subprocessors, DPA availability, and compliance posture. Trust Center ## Plexara as a Vendor The [Security page](https://plexara.io/security) catalogs MCP threats and how the platform architecture answers them. This page is about Deasil Works as a company you would be trusting with data: how your deployment is built and run, what we commit to when something breaks, and the assurances your security team can verify today. How to read this page Two things carry the Plexara name, and this page keeps them apart. The product is your dedicated deployment and everything Deasil Works runs to operate it. The website is plexara.io, the pages you are reading right now. Every section below names which one it covers, and a statement about one is never a statement about the other. Last reviewed: August 2026 The Product / Tenancy and Isolation ### Every client gets their own installation Most SaaS isolation is a customer ID column in a shared database. A Plexara deployment is a separate stack. 01 #### A dedicated stack Your deployment runs its own MCP platform, query engine, catalog, identity service, PostgreSQL databases, object store, and embedding model, in its own namespace. No component that stores or processes your data is shared with another customer. 02 #### No shared control plane Uptime is a property of your deployment, monitored by its own telemetry and visible in your admin portal. There is no central Plexara service whose outage could reach every customer at once. 03 #### Owned hardware Deployments run on servers Deasil Works owns and operates in six US data center facilities. We manage everything from the bare metal up. When something needs inspecting, we can walk the whole stack. 04 #### The data is yours Platform data lives in databases provisioned for you. There is no Deasil-owned data layer in the middle, you can bring your own S3-compatible storage, and when a contract ends your data is deleted within 30 days. The Product / Data Protection ### How customer data is protected Everything in this section describes your Plexara deployment and the data inside it. #### Encryption in transit TLS 1.2 or higher on every public endpoint, with certificates automated through cert-manager and Let’s Encrypt on per-client hostnames. Platform connections to PostgreSQL require TLS. #### Encryption at rest Customer data is encrypted at rest with AES-256. Data source credentials get a second layer: AES-256-GCM application-level encryption before they ever reach storage. #### Identity and access Sign-in runs through a dedicated Keycloak identity realm per client over OIDC. Agent connections use OAuth 2.1 with PKCE and short-lived tokens. A persona has to match the roles your identity provider issued before any surface opens, and personas deny all tool access until a grant says otherwise. #### Write control on the catalog Editing a table description, tag, domain, or glossary term takes two grants at once: the matching tool on the persona, and a connection marked write-enabled. Both are checked on the server whatever the interface offers, and every write lands in the audit log. #### Shared files and links A file your team uploads, saves, or shares opens as the document it is and cannot act on the platform or the session viewing it. Each share link names its audience when it is created, the named recipient or your signed-in users or anyone holding the link, and stops opening when it expires or is revoked. #### Notification email Messages from your deployment are traceable to the domain they were sent from and carry the legal footer links a recipient expects. Unsubscribe works from the button the recipient’s own mail client offers, so an opt-out takes one click and is recorded. #### Support access Deasil staff look at customer data only when you ask for diagnostic or support help. That access is scoped to the request and logged. #### Data retention Customer data is kept for the duration of your service agreement and deleted within 30 days of termination, unless law or a written request from you says otherwise. #### Audit trail Every tool call is recorded with requester identity, persona, authorization decision, outcome, and timestamp. Records stay in your deployment and export to your SIEM. The Product / Backups and Continuity ### Backups are part of each deployment Backup and recovery are configured per installation, not as a platform-wide setting. The baseline: - Replicated PostgreSQL: a leader and a standby in every deployment. - Continuous write-ahead-log archiving to object storage. - Scheduled logical backups on top of the continuous archive. - Offsite copies, schedules, and retention set in your service agreement. - Restore procedures are written down and have been used on production deployments. The Product / Incident Response ### If something goes wrong, you hear it from us first Detection comes from per-deployment telemetry and the audit trail. Because every tool call and authorization decision is logged, we can tell you what an incident touched instead of guessing. The engineers who respond are the same people who run the infrastructure; there is no tiered support queue between you and them. We commit to notifying affected customers within 72 hours of confirming a security incident that involves their data or service, followed by a post-incident summary of cause and remediation. Security researchers can reach us through the [vulnerability disclosure policy](https://plexara.io/vulnerability-disclosure), with a machine-readable contact at /.well-known/security.txt. [Image: The Health tab of the admin Dashboard, showing per-node runtime health for the deployment's reporting nodes, each with uptime, CPU, memory, heap, goroutine, and in-flight counters, CPU and memory charts over the last hour, and a status badge reading Healthy or Restarted recently] The same telemetry we watch is on your admin dashboard: each node in your deployment, its uptime, and its recent load. [Image: The Events tab of the admin Dashboard, a searchable and filterable table of tool calls with timestamp, user, tool, toolkit, source, connection, duration, status, and enriched columns, plus Export CSV and Export JSON buttons] And the audit trail itself: every tool call, who made it, through which connection, and how it ended, exportable to your own systems. The Product and the Website / Subprocessors ### The product has zero subprocessors #### The product: no third party at all Your deployment runs start to finish on hardware Deasil Works owns and operates. No third party processes customer platform data. No AI provider receives it either: the platform makes no outbound calls to any model provider, and embeddings are computed inside your deployment. Notification email is part of the managed service and adds no vendor to that list. That is the whole list. There is no external logging service, no third-party analytics, no managed database vendor sitting between you and your data. #### The website: three vendors, named plexara.io is a marketing site and processes no customer platform data. It uses Cloudflare for DNS, TLS, and bot protection, Buttondown to deliver the newsletter to people who subscribe, and Google Analytics for consent-based traffic measurement. None of the three has any access to any Plexara deployment, and none appears in the Data Processing Agreement, which covers the product. The [privacy policy](https://plexara.io/privacy) covers what the website itself collects. The Product / Compliance ### The compliance roadmap SOC 2 Type II is on the roadmap for the product. We share our readiness status and a dated plan with prospective customers on request, and this page will carry the report when the audit completes. In the meantime, the assurances below are stronger than a badge: they are inspectable. A Data Processing Agreement is available on request. It covers our processor role, your ownership of the data, confirmation that no subprocessor touches customer platform data, 30-day deletion at termination, and the 72-hour notification commitment. A vendor security memo for your security team works the same way: write to support@plexara.io. What you can verify yourself, today: - [The MCP threat catalog, and the control set the product enforces on every request](https://plexara.io/security) - [How the product authorizes a tool call at the moment it runs, and what it audits](https://plexara.io/product/governance) - [The US data center facilities a product deployment runs in](https://plexara.io/locations) - [Our vulnerability disclosure policy and RFC 9116 security.txt](https://plexara.io/vulnerability-disclosure) - [What the website collects, and the consent it asks for first](https://plexara.io/privacy) #### CSA AI Trustworthy Pledge Plexara has signed the Cloud Security Alliance AI Trustworthy Pledge, affirming alignment with its core principles of safety, transparency, ethical accountability, and privacy in AI systems. It is a public commitment rather than an audit, and the Cloud Security Alliance names every organization that has taken it. The listing reads Plexara, the product the pledge covers. Deasil Works, Inc. is the operator of record behind it and the contracting entity on your service agreement and Data Processing Agreement. [Find Plexara on the CSA signatory list](https://cloudsecurityalliance.org/star/ai-trustworthy-pledge/organizations) The Product and the Website / AI Security ### The AI vendor questionnaire, pre-answered No. This answer is about the product, your Plexara deployment. The platform makes no outbound calls to any AI model provider. The only model it runs is a local embedding model (nomic-embed-text on Ollama) that executes inside your deployment on Deasil-operated hardware, so nothing leaves your environment to compute semantic search. Generative reasoning happens in the AI client you choose to connect, such as Claude, under your own agreement with that provider; the major providers exclude commercial API traffic from training by default. Deasil Works does not use your data for training, analytics, or any purpose other than operating your deployment. With enforcement that lives outside the prompt. This answer is about the product. Persona authorization, connection allowlists, read-only enforcement, and workflow gates run as server-side middleware before any tool executes, so a poisoned prompt cannot grant an agent access it does not already have (OWASP LLM01). The tools also publish closed input schemas, so an argument a tool does not define is refused before the tool runs and a steered agent cannot smuggle a parameter past the contract it advertised. Catalog metadata is screened for instruction-like patterns before enrichment, and detections are logged. No vendor can promise to scrub adversarial language out of legitimate data values, so query results are treated as untrusted content and the defense is bounded blast radius plus a complete audit trail. [Learn more: The full MCP threat catalog](https://plexara.io/security) Every tool call is authorized server-side against a fail-closed persona, so an agent can never exceed the calling user's own access (OWASP LLM06, excessive agency). This answer is about the product. A persona is what opens any surface at all: a caller whose roles match no persona reaches nothing, and the persona's connection grants govern what that caller can see as well as what they can call, so a restricted agent does not discover the datasets, connections, and endpoints it is not cleared for. Query connections can be locked to read-only at the platform layer, storage access is restricted by prefix, and the one write path that feeds agent learning back into the catalog requires human review and approval, records a full changeset with a before-image, and supports rollback. [Learn more: Governance at the point of execution](https://plexara.io/product/governance) Each client runs a dedicated installation: its own MCP platform, query engine, catalog, PostgreSQL databases, identity realm, object storage, and embedding model, in a dedicated namespace on Deasil-operated infrastructure. There is no shared inference service, no shared context store, and no shared control plane, so isolation holds at the context and inference layer, not just the database layer. Within a deployment, memory and session state are scoped per user, and sessions are bound to the authenticating token. Requester identity, the persona in force, the tool and connection called, parameters with sensitive keys redacted, the authorization decision, outcome, duration, and timestamp, plus session and request identifiers. A failure also records its category, so a denied permission, a malformed call, and a platform fault are three distinguishable rows rather than one bucket of errors. Records land in your deployment's PostgreSQL store, partitioned monthly with configurable retention, and are exportable to your SIEM. This is the per-decision traceability that EU AI Act Articles 12 and 13 ask deployers to demonstrate. Platform releases are pinned per deployment and upgraded on a schedule agreed with you, with advance notice before any maintenance window. The embedding model is pinned too, and every stored vector records the model that produced it, so a later model change is visible rather than silent. Because no external generative model sits in the platform's serving path, a model provider's deprecation or quiet update cannot change your deployment's behavior. The model your agents use is whichever AI client you connect, under your control. Yes. Send it to support@plexara.io. The answers on this page already use the vocabulary reviewers embed in questionnaires, including the OWASP LLM Top 10 (prompt injection, excessive agency) and the NIST AI RMF govern, map, measure, and manage functions. A formal vendor security memo and a Data Processing Agreement are available on request, and we will state for each answer whether it covers the product or the plexara.io website so your reviewer never has to guess. No, and the distinction matters when a reviewer scores vendor risk. The product is your dedicated deployment, running on hardware Deasil Works owns and operates, with zero subprocessors. The website is marketing pages, and it uses Cloudflare for DNS, TLS, and bot protection, Buttondown to deliver the newsletter to people who subscribe, and Google Analytics for consent-based traffic measurement. Those three vendors serve the website only. They have no access to any deployment, they process no customer platform data, and they are outside the scope of the Data Processing Agreement. Whoever the person sharing it chose, and nobody else. Each share link names its audience when it is created: the named recipient, your signed-in users, or anyone holding the link. Open to anyone is always a deliberate selection, never a default, and the link stops opening the moment it expires or is revoked. The file itself opens as the document it is and cannot act on the platform or on the session viewing it, and a response served after a permission check is marked for that one browser so no cache in between can hand it to the next holder of the URL. [Learn more: The control set, in full](https://plexara.io/security) Next ### Contact Request a DPA, a vendor security memo, or our SOC 2 readiness status, or send us your security questionnaire. [Continue](https://plexara.io/contact) --- # Vulnerability Disclosure Policy URL: https://plexara.io/vulnerability-disclosure/ > How to report a security vulnerability in Plexara, what is in scope, and what to expect: acknowledgment within two business days and coordinated disclosure. Security ## Vulnerability Disclosure Policy Effective: July 17, 2026 ### Our Commitment Deasil Works, Inc. operates the Plexara platform and the plexara.io website. We take security reports seriously and appreciate the work of researchers who report vulnerabilities to us in good faith. Report anything you find in Plexara directly to us. We own the commercial package our clients run, including the versions we build, test, and pin, so we are the right and only place to send a report about the product or our services. ### Scope This policy covers the plexara.io website and the services we operate for public use, including api.plexara.io, mcp-test.plexara.io, api-test.plexara.io, and our demonstration platform environments. Client production deployments are out of scope. Each Plexara client runs a dedicated platform installation, and testing against a client deployment requires that client’s explicit authorization, not ours. Also out of scope: denial-of-service or volumetric testing, social engineering of Deasil Works staff or clients, physical attacks against facilities, spam, and findings from automated scanners without a demonstrated vulnerability. ### How to Report Email support@plexara.io with the subject line "Security Vulnerability Report". Include a description of the issue, the affected URL or component, steps to reproduce, and your assessment of impact. Proof-of-concept detail helps us triage faster. This is the right channel for anything you find in Plexara, whether in our services or in the product our clients run. We handle triage, remediation, and any coordination that a fix requires. Reports do not need to go anywhere else. ### What to Expect We will acknowledge your report within two business days and keep you informed as we validate and address the issue. We target remediation within 90 days of a validated report, and sooner for issues with serious impact. We ask that you give us that window before public disclosure, and we will coordinate a disclosure timeline with you if remediation takes longer. If you would like credit for a validated finding, we are glad to provide it. We do not currently operate a paid bug bounty program. ### Safe Harbor We will not pursue legal action against researchers who make a good-faith effort to follow this policy. Good faith means testing only in-scope systems, avoiding privacy violations and service degradation, and not accessing, modifying, or destroying data that does not belong to you. If you encounter customer data or personal information during research, stop, do not save or share it, and report what happened. We treat accidental exposure that is promptly reported as part of good-faith research. ### Machine-Readable Policy A machine-readable version of our security contact information is published at plexara.io/.well-known/security.txt, following RFC 9116. See also: [Security](https://plexara.io/security) and [Trust Center](https://plexara.io/trust) --- # Product URL: https://plexara.io/product/ > Plexara unifies query execution, semantic metadata, and object storage into a single governed MCP server with semantic enrichment and enterprise governance. Product ## The Governed Context Layer Connect your AI agent to Plexara and it becomes an expert on your business. Plexara gives AI the ability to capture, apply, and utilize knowledge of your data. The more you use it, the smarter your AI gets and the better your results. Reach ### Everything your agent is allowed to touch Your databases, your catalog, your object storage, and the software your team already pays for, all behind one endpoint your agent connects to once. [Integrations Query across PostgreSQL, MySQL, BigQuery, MongoDB, and the rest through one SQL interface, with catalog coverage and object storage on the same endpoint. Read the page](https://plexara.io/product/integrations) [API Gateway Salesforce, Stripe, and your own internal services become tools the agent can call, through the same logged connection as your data and with nothing custom to build per service. Read the page](https://plexara.io/product/api-gateway) [MCP Gateway Any MCP server your vendors or teams already run joins the same governed endpoint: its tools show up beside your data tools, persona-gated, credentialed server-side, and audited per call. Read the page](https://plexara.io/product/mcp-gateway) [Spreadsheets as Tables A CSV somebody uploads, or one the agent builds, registers as a table in one step and joins against the warehouse with SQL. The file is read where it sits, and nothing is copied. Read the page](https://plexara.io/product/spreadsheets) Judgment ### The difference between an answer and the right answer A query result on its own is just rows. These surfaces turn it into something a person can act on, keep it arriving after the conversation ends, and make the next answer better than the last. [Semantic Enrichment Every tool response arrives carrying ownership, quality scores, PII warnings, and glossary definitions from the complementary services. One enriched call does the work of five. Read the page](https://plexara.io/product/semantic-enrichment) [Memory Persistent knowledge across sessions, recalled automatically by entity, by meaning, or by lineage. The platform remembers what you taught it. Read the page](https://plexara.io/product/memory) [Knowledge Capture A correction someone makes in passing becomes documentation the whole organization holds: captured in the conversation, reviewed by a person, and reversible if it turns out to be wrong. Read the page](https://plexara.io/product/knowledge-application) [Automations Your agent works a report out once and saves it as a script. Plexara runs it on demand or on a schedule: fresh dashboards and data feeds with no agent in the loop and no token spend. Read the page](https://plexara.io/product/automations) [Catalog Governance Your tag vocabulary, business areas, and glossary are curated in the same portal the agent works through, under the same access rules and the same audit log. Read the page](https://plexara.io/product/catalog) Accountability ### Who can ask what, and what happened after Access is decided when a tool runs, not described in a policy document. The portal is where your team sees the work, and email is how it reaches whoever is not looking at the portal. [Governance Access control, audit trails, and quality signals enforced by the same platform that executes the query, at the moment it executes. Read the page](https://plexara.io/product/governance) [Portal Tour The workspace your practitioners open every day, walked section by section: where answers land, where assets live, and how work gets shared. Read the page](https://plexara.io/product/portal) [Portal Administration The half of the sidebar your admins hold: personas, connections, tool inspection, index health, and the audit trail behind every call. Read the page](https://plexara.io/product/portal/admin) [Email Notifications Work happens in the portal, attention happens in an inbox. Shares, replies, mentions, and review-queue alerts reach people where they already are. Read the page](https://plexara.io/product/notifications) One Endpoint ### Greater Than the Sum of Its Parts Plexara does not just connect Trino, DataHub, and S3. It interweaves them. A query result carries catalog context. A catalog search reveals what is queryable. A storage object surfaces its lineage. Each service enriches the others at the protocol level, producing responses that no single system could generate alone. This interweaving replaces the need to stitch together five separate tools: catalog, semantic layer, query engine, observability, and governance. The result is not just fewer moving parts. It is a single MCP endpoint where query execution, business context, and governance enforcement are inseparable. Under the hood ### For the people who will ask how it works [Architecture The middleware pipeline, the provider abstractions, and where enforcement happens.](https://plexara.io/architecture) [Developer Hub The MCP and REST surfaces, the test utilities, and the API reference.](https://plexara.io/developers) [Research Open, reproducible benchmarks of what the platform changes about an agent.](https://plexara.io/benchmark) [Changelog A weekly, plain-language record of what has landed in your deployment.](https://plexara.io/product/changelog) Common questions ### Plexara Product FAQ Any client that speaks the Model Context Protocol. That includes Claude Desktop, ChatGPT, the Anthropic and OpenAI SDKs, Cursor, Continue, and custom agents you build in-house. Plexara is the server; the client is your choice. Plexara is a managed deployment operated by Deasil Works on infrastructure we run across six US data center facilities. AI agents reach Plexara over the standard MCP transport. There is no SaaS marketplace tier and nothing to install on your laptop. [Learn more: Our data center locations](https://plexara.io/locations) Yes. The Trino federation layer routes a single SQL query across 40+ connectors, including PostgreSQL, Iceberg, Snowflake, S3, Kafka, and Elastic. Agents write standard SQL without knowing where the data physically lives. [Learn more: Trino Query: analytics and insights](https://plexara.io/learning/mcp/trino-query-analytics-and-insights) Persona-based access control restricts which tools and which data an agent can see, mapped to your existing identity provider. Default-deny applies to anything not explicitly allowed. Every tool call is logged with user identity, persona, and result so sensitive-data access is auditable end to end. [Learn more: Closed by default: least privilege as the starting point](https://plexara.io/learning/insights/closed-by-default-access) Yes. Plexara exposes a REST API covering assets, collections, knowledge, memory, prompts, personas, audit, governance, and tool execution, so non-MCP systems can integrate the same governed surface. The MCP server and the REST API share one identity, audit, and persona model. [Learn more: Is MCP just an API wrapper?](https://plexara.io/learning/ai-concepts/mcp-vs-apis) Deep Dive ### Semantic Enrichment How bidirectional enrichment gives every tool response complete business context. [Continue](https://plexara.io/product/semantic-enrichment) --- # Semantic Search and Enrichment URL: https://plexara.io/product/semantic-enrichment/ > Bidirectional enrichment augments every tool response with business context from complementary services. One call replaces four. ## Semantic Search and Enrichment Every tool response arrives carrying business context from the complementary services, on a fixed budget with the overhead measured. One enriched call does the work of five or more. Bidirectional cross-enrichment is the architectural difference between Plexara and MCP servers that merely wrap an API. Before and After ### What Cross-Enrichment Means Concretely A single enriched response replaces multiple round trips. The agent receives complete business context without making additional tool calls. #### Without Plexara 5+ sequential tool calls Call 1 Describe table schema Call 2 Fetch column descriptions Call 3 Look up data owner Call 4 Check quality scores Call 5 Get deprecation status Result Agent assembles context manually #### With Plexara 1 enriched response Call 1 Describe table through Plexara Result Schema + descriptions + owner + quality + deprecation + glossary terms + lineage [Image: The Enrichment tab for a CRM Search Accounts tool in the Tools admin screen, listing one enabled rule that attaches DataHub owners, glossary terms, and deprecation warnings to each returned account, with its strategy, status, and last updated date] The rule behind the enriched response, as an admin sees it: which tool it applies to, what it attaches, and whether it is on. [Image: The Try It tab for the Trino Query tool in the Tools admin screen, with a SQL text area, limit, timeout, and output format fields, an Execute button, and an empty History panel reading no test calls yet] Try It runs the same tool from the portal, so an admin can watch a response come back enriched before an agent ever calls it. Four Directions ### Bidirectional Across Every Service Trino DataHub Query results enriched with catalog metadata: column descriptions, owners, tags, glossary terms, lineage, quality scores, and deprecation warnings. DataHub Trino Catalog search results enriched with query engine availability: which datasets are queryable, their resolved table paths, and which Trino connections can reach them. S3 DataHub Storage objects enriched with catalog metadata: what the object contains, who owns it, its lineage within data pipelines, and any associated quality signals. DataHub S3 Catalog entities enriched with storage availability: which objects exist in S3, their sizes, last modified dates, and presigned URL access patterns. Bounded ### Enough Context, Not All of It Automatic context is worth nothing if it buries the answer or makes every call wait on the slowest thing in the building. Enrichment is bounded on both axes, and the cost is measured rather than estimated. #### Context runs on a budget Enrichment gets a fixed byte allowance per response, not a blank check. Each recalled item is rendered summary-first, and anything past the allowance is listed as a compact stub the agent can open on demand. What was analyzed stays the bulk of the response, and supporting context stays supporting. #### One slow source cannot stall a query Search fans out across the catalog, memory, insights, pages, prompts, assets, endpoints, and connections at once, and each arm has its own deadline. A source that misses it drops out and is reported as having dropped out, rather than holding the whole answer while everything else waits. #### The overhead is a number you can look at The platform counts the bytes enrichment adds and the calls it adds them to, so the average context cost per answer is charted rather than assumed. It is the figure to watch when deciding whether the budget is set where you want it. Efficiency ### Fewer Calls, Better Context 1 Tool call instead of 5+ +15.4pts Overall accuracy lift in our published benchmark 0 Redundant metadata fetches per session Enrichment consolidates what would be multiple round trips into single responses. Session-aware deduplication tracks what context has already been provided and avoids repeating it within the same conversation. The accuracy figure is measured, not estimated. Our [published benchmark](https://plexara.io/benchmark/accuracy) holds the model constant and ablates the platform: overall accuracy on the same tasks rose from 83.1% to 98.5% with the semantic layer in place. Tool visibility filtering hides tools the user is not authorized for, further reducing the number of tool descriptions in the agent context window. Fewer tools means fewer tokens consumed by tool metadata on every request. None of this is hardwired to specific products. Enrichment talks to the catalog, query engine, and object store through the provider interfaces described on the [architecture page](https://plexara.io/architecture), so a backing service can be swapped without touching how enrichment works. Next ### Memory Persistent knowledge across sessions that makes your AI smarter over time. [Continue](https://plexara.io/product/memory) --- # Knowledge Capture & Application URL: https://plexara.io/product/knowledge-application/ > Every conversation improves your data catalog. User corrections, agent discoveries, and enrichment gaps flow through admin review into documentation. ## Knowledge Capture & Application A correction someone makes in passing becomes documentation the whole organization holds. Captured during the conversation, reviewed by a person, written to the place that kind of fact belongs, and reversible if it turns out to be wrong. Reach ### What one person teaches, the whole team gets The finance lead explains that a column is gross margin, not revenue. Normally that stays inside one conversation, and the next analyst re-derives it from the data and gets it wrong. Promotion is what changes that. The moment a reviewer applies an insight, it stops being the capturer’s private note and becomes something every identity can find through the same search they already use, still attributed to the person who taught it. Nobody needs to know it exists, or who to ask. Until then it stays private. An insight still waiting on review is visible only to whoever captured it, because a capture under review is not yet something the organization asserts. A teammate who never saw the original conversation, answering correctly 46.7%→98.9% Our lifecycle benchmark teaches a fact with one identity and then asks a different one. Moving the visibility boundary to the act of applying an insight took that from under half the time to near-total. 30 protocols, 95 transfer attempts on claude-sonnet-5; 95% CI 96.8 to 100.0. Measured on v1.102.0 and again on v1.118.0, so the comparison is across code rather than across samples. [Read the accuracy study](https://plexara.io/benchmark/accuracy) Capture ### Three Sources of Knowledge 01 #### User-Provided Knowledge "That column is gross margin, not revenue" When a user corrects an agent during a conversation, the correction is captured as a structured insight with the specific entity, the type of correction, and the suggested catalog change. No separate tool needed. 02 #### Agent-Discovered Insights "Column amt appears to be in cents based on value ranges" When an agent queries data and observes patterns, these observations are captured as lower-confidence insights flagged for human review. The agent does the analytical work. Humans validate the conclusion. 03 #### Enrichment Gap Flags "This table has no description and 12 undocumented columns" When the semantic enrichment middleware finds missing metadata, the gap is recorded automatically. Over time, the gap log becomes a prioritized list of documentation debt ranked by access frequency. [Image: The Insights tab of the Knowledge page with My Insights selected, showing Total, Pending, Approved, and Applied counters, a search box with status filters, and a list of captured insights each carrying a status badge, a category, the tables it references, and the reviewer's note] Whatever the source, a capture shows up here as an insight you can read back, with its status and the reviewer’s note once it has been decided. Pipeline ### The Review Pipeline Nothing becomes shared knowledge without human approval. Review and promotion belong to whoever holds that capability, which your team assigns and which need not be an administrator. 1 #### Capture Insight recorded with source, confidence level, entity reference, and suggested changes. 2 #### Review A reviewer evaluates accuracy and relevance. Bulk or per-entity review workflows, with the whole queue enumerable rather than only searchable. 3 #### Synthesize Related insights about the same subject are combined, and each proposed change is shown beside the value it would replace. 4 #### Apply Approved knowledge is written to whichever of the two homes fits it, as a tracked changeset with full provenance. [Image: The Insight Detail panel open over the review queue, listing who captured the insight, their persona, category, confidence, and status, the insight text, the entity URNs it references, a Suggested Actions table, Related Columns, a Review Notes field, and Approve and Reject buttons] A reviewer opens one insight and sees everything the decision rests on: the claim, what it references, what applying it would change, and a place to say why. A pending insight is not judged in the abstract. The panel looks up the table the claim is about and reports what it finds right now, so the reviewer decides against the data as it stands rather than as the capturer remembered it. [Image: An Insight Detail panel for a pending business-context insight about a daily sales table, with an Observed Now card confirming the table is queryable now and reporting its current row estimate, followed by entity URNs and a suggested column description update] **Observed.** The table is reachable and its current row estimate is shown, so the reviewer can see the claim and the data side by side. [Image: An Insight Detail panel for a pending correction claiming an inventory table holds 1,140 rows, where the Observed Now card shows a current estimate of about 1,200 rows and an amber warning that the claim disagrees with the table, marked advisory only] **Conflict.** The claim names a figure the table no longer matches, so the panel says so in place. It is advisory: the decision still belongs to the reviewer. [Image: An Insight Detail panel for a pending enhancement about a product catalog table, where the Observed Now card confirms the table is queryable now but notes that this connection does not estimate row counts] **No estimate.** The table is reachable but its connection does not report row counts, and the panel says that plainly instead of leaving a blank. Two Homes ### Where a Promoted Fact Lands Not every fact belongs on a table. Promotion routes each one to the place it can be found from: business and domain knowledge becomes a page, technical and entity knowledge goes to the catalog. The reviewer picks the destination at promotion time, and one search covers both. #### Canonical knowledge pages Business and domain facts Durable, human-readable pages written in formatted text with diagrams, version-tracked on every save, searchable by meaning, and open to feedback in place. They hold the vocabulary, definitions, runbooks, and context that do not fit inside the metadata on a single table. - How the fiscal calendar differs from the calendar year - What counts toward net revenue and what does not - The runbook for a month-end close that spans six systems #### The data catalog Technical and entity facts A fact that belongs to one table, column, dashboard, or glossary term is written where that entity already lives, so it arrives with the metadata every time anyone touches the entity. Descriptions, tags, glossary terms, quality flags, curated queries, and incidents are all reachable this way. - The amt column is in cents, not dollars - This extract is deprecated in favor of the modeled table - Rows before the March migration are in UTC [Image: The Knowledge tab with Search All selected and the query revenue entered, returning grouped results from the catalog, knowledge pages, insights, and memory, with source filter chips above the groups and a count of how many matches each group shows] One search, grouped by where each match lives: catalog entries, knowledge pages, insights, and memory come back together. Repeated promotions about the same subject consolidate into one living page rather than piling up beside each other, and when an agent tries to write a page that closely matches one that already exists, the platform steers it into updating that page instead. Canonical knowledge gets deeper over time instead of splintering into near-copies. Structure ### Knowledge Is Linked, Not Filed A wiki asks you to remember where you put something. Knowledge in Plexara hangs off the things it describes, so it arrives when you are looking at them. The result is a corpus with a shape you can inspect: the portal draws it as a reference network, sizes each node by how much of the graph it holds together, and traces the chain of references between any two things. #### Pages cite what they are about A page states the assets, prompts, collections, connections, catalog entries, glossary terms, tags, and domains it concerns. Each one renders as a live chip carrying the current name, not the identifier some system generated, and deep-links to where that thing is managed. #### The link runs both ways Standing on a glossary term, a tag, a domain, or a table, you see the knowledge written about it. A steward reading a definition finds the runbook that depends on it without knowing the runbook exists. #### Access decides what you see A reference to something you cannot reach is omitted from both directions, so you see the part of the corpus you are cleared for and nothing hinting at the rest. Reversible ### Every Promotion Can Be Undone The objection to letting an agent contribute to your catalog is the obvious one: what happens when it is wrong. A person approves every promotion, every promotion records what it wrote over, and a bad one comes back out. #### Every promotion is a changeset Each run records exactly what it wrote and the values it wrote over, on both destinations. The changeset list sits with the promoted knowledge, showing what was applied, to what, by whom. #### A changeset can be rolled back Rolling one back restores what was there before and returns the source insights to the queue. A promotion that created a page removes it; one that revised a page restores the prior version. Reversibility is stated up front, before you apply, so you never learn at rollback time that a change could not be undone. #### Nothing ages silently The review queue reports how old its oldest pending item is and how much has aged past thirty days, and says so in the assistant, in the portal, and on the admin screens. When the backlog crosses the threshold your team sets, it emails a digest with a link straight into the queue. Flywheel ### Usage Improves the Platform 1 Usage generates insights 2 Insights improve documentation 3 Better documentation improves agent accuracy 4 Better accuracy drives more usage This flywheel distinguishes knowledge application from one-time documentation initiatives. A documentation sprint produces a snapshot that begins decaying immediately. Knowledge application produces documentation that improves continuously because it is connected to ongoing data usage. The rate of improvement is proportional to usage. Datasets queried frequently accumulate documentation faster. Columns discussed in conversations get descriptions sooner. Business terms explained to agents get linked to glossary entries. The documentation naturally prioritizes what matters most. Over 15 change types are supported: update descriptions at entity and column level, add tags, add glossary terms, flag quality issues, add curated queries, raise incidents, add context documents, and create prompts. Works across datasets, dashboards, charts, data flows, containers, data products, domains, and glossary terms. Next ### Catalog Governance Where promoted knowledge lands, and how your team curates the catalog around it. [Continue](https://plexara.io/product/catalog) --- # Catalog Governance URL: https://plexara.io/product/catalog/ > Curate the tag vocabulary, the domains, and the business glossary in the same portal your agent works through, under the same access rules. ## Catalog Governance Your tag vocabulary, your business areas, and your business glossary are curated in the same portal your agent works through, under the same access rules, and recorded in the same audit log. Governance work and agent work happen in one system. One Rule ### Everything Under Catalog Is Your Catalog A product that stores knowledge of its own and also shows you a data catalog has an obvious way to go wrong: two piles of similar looking things and a reader who has to guess which pile holds the thing they want. One sentence settles it, and it holds as the surfaces grow. Under Catalog #### Your DataHub catalog Tables and their metadata, context documents, the tag vocabulary, the domains, and the business glossary. Read and written live against the catalog itself, so an edit made here is the edit everyone sees in DataHub. Outside Catalog #### The portal’s own store Canonical knowledge pages and the changesets that record what a promotion wrote. These are the portal’s own records, so they sit alongside Catalog rather than inside it. The catalog connection is chosen once, at the top of the section, and applies to every tab underneath it. Switching it returns each tab to its list, because an open table, document, tag, domain, or glossary term belongs to the catalog it was read from. Every surface is addressable. A single entity keeps its own link, so a reference to Net Revenue from anywhere in the portal opens that term in the tab that manages it, and a refresh or a browser back lands where you were rather than at the top of the section. [Image: The Catalog tab inside the Knowledge section, with Tables, Context Docs, Tags, Domains, and Glossary sub-tabs, a Connection picker set to primary on the right, a search box, and table cards each showing a name, description, and tags] Catalog sits inside Knowledge, with the connection picker at the top and the five curation tabs beneath it. Surfaces ### The Described Things, Then the Words That Describe Them Five tabs, in the order they are best read in. Tables and context documents are the things being described. Tags, domains, and the glossary are the vocabularies doing the describing, and each governs the vocabulary itself rather than one table’s copy of it. #### Tables The described thing Open a table to see its description, tags, owners, glossary terms, domain, and columns, and edit each facet in place. Descriptions are markdown in a split source and preview editor. Tags, terms, and domains come from name search, so attaching Revenue means typing Reven and picking it rather than typing an identifier. Tables originate in your source systems, so this is metadata curation and there is no table create or delete. #### Context Docs The explanation that outgrew a field Markdown notes attached to a dataset, a glossary term, a glossary node, or a container. The migration history behind a column that means two things depending on the date, or the reconciliation procedure a table is part of. The attachment is the point: a note in a wiki is a note somebody has to find, and a note attached to the table arrives with the table. #### Tags The vocabulary itself Not the tags on the table you were just looking at, but the tag vocabulary. Create a tag, say what it means, retire it, and open one to see which tables carry it and which knowledge pages reference it. Every carrier links straight into the table editor, so answering what certified actually means here takes one screen. #### Domains The business areas The areas your catalog is grouped into. Create one, describe it in markdown, retire it, and move tables in and out. A table has at most one domain, so adding a table that already sits in another one moves it rather than giving it a second, and the form says so before you pick. #### Glossary The definitions the business argues about Active customer, net revenue, fiscal quarter: the terms every team uses confidently and no two teams define identically. A tree, walked one branch at a time. A term shows its definition, a breadcrumb of where it sits, its context documents, the knowledge pages that reference it, and the tables annotated with it, with the ones where a column rather than the table carries the term marked separately. [Image: The Description admin screen, a split markdown editor with formatting controls, source on the left and rendered preview on the right, describing a retail data platform, with Revert and Save buttons and a note of who last updated it] The same split source-and-preview editor curates the platform’s own description, the identity every connected agent reads first. [Image: The Enrichment tab for a CRM Search Accounts tool in the Tools admin screen, listing one enabled rule that attaches DataHub owners, glossary terms, and deprecation warnings to each returned account, with its strategy, status, and last updated date] Curated vocabulary travels: an enrichment rule carries catalog owners, terms, and deprecation warnings into the responses of a tool that is not the catalog. Access ### Two Conditions on Every Write A catalog write from the portal passes exactly the checks a catalog write from your agent passes, because they are the same checks. Both conditions are enforced on the server regardless of what any screen renders, and every write is recorded in the audit log with the person, the persona, the tool, and the connection. Gate one #### The persona grants the tool Curating the catalog uses the same catalog tools an agent uses. A persona that is granted them can edit; a persona that is not, cannot. There is no second permission model to keep in step with the first. Gate two #### The connection accepts writes A connection marked read-only stays read-only for everyone, whatever their persona grants. Pointing the portal at a catalog you do not intend anyone to edit is a property of the connection, not a matter of trusting each screen. #### Reading is the floor An analyst whose persona carries catalog reads and no catalog writes opens the same tables, tags, domains, and terms, with the editing controls absent. Access degrades to reading rather than to a permission error, so the catalog stays useful to the people who only need to consult it. The persona model behind both gates is covered on [Governance](https://plexara.io/product/governance). Deletes ### A Retirement States What It Touches Retiring a definition has the widest reach and the least visible consequence, which is the combination that produces regret. Every delete states its effect first, in the units a steward would ask about. Retire a tag How many tables in the connection carry it, so retiring an unused label and retiring one the warehouse depends on do not look identical. Retire a domain How many tables are in it, and that the retirement removes the domain definition and leaves those tables without one. It touches no table. Retire a glossary term How many tables are annotated with it, and that the annotation stays where it is. The definition goes; the labels on the data remain. Retire a glossary node holding entries Nothing, because no delete is offered. Removing the node would leave its contents behind, so the options are to empty it first or leave it, and the tab says which. The principle underneath is stricter than warning about an outcome: when the outcome cannot be stated precisely, the action is not offered at all. That is why one button you might expect to find is simply absent. Knowledge ### The Link Runs Both Ways A tag, a domain, and a glossary term each list the knowledge pages that reference them, so a steward reading Net Revenue sees what has already been written about it without going looking. From the other direction, a knowledge page’s references resolve to real catalog names, so the chip reads Net Revenue rather than the identifier the catalog generated for it. References you cannot access are omitted from both directions, so the reverse lookup never leaks the existence of a page you were not meant to see. [Knowledge capture](https://plexara.io/product/knowledge-application) covers what a promotion writes into the catalog on the other side of that link. Walk the same five tabs at a practitioner’s pace in [lesson 211](https://plexara.io/learning/mcp/catalog-governance-in-the-portal), or see where Catalog sits among the rest of the workspace in the [portal tour](https://plexara.io/product/portal). Stated, not hidden ### Two Limits Worth Knowing #### The domain list is capped at 100 The catalog’s own list query returns at most 100 domains. A full list means there are domains the page cannot reach, and the page reports it as capped rather than presenting it as complete. #### New entries are indexed asynchronously The catalog builds its search index in the background, so a tag, domain, or term you just created can take a moment to appear in the list. The entry itself exists immediately, and the identifier returned on creation is authoritative while the index catches up. Both are stated in the interface where they apply, because a steward who knows why a list stops at 100 trusts the other 99 entries more than one who finds out later. Next ### Governance The persona model behind both gates, enforced at the point of execution. [Continue](https://plexara.io/product/governance) --- # Memory URL: https://plexara.io/product/memory/ > Persistent memory across sessions, structured into five dimensions. Multi-strategy recall via entity lookup, semantic search, and lineage graph traversal. ## Memory Persistent knowledge across sessions. The platform remembers what you taught it, recalls relevant context automatically, and gets smarter with every conversation. Memory Dimensions ### Five Types of Memory Memory is structured into five dimensions, ensuring that different types of knowledge are stored, indexed, and recalled appropriately. #### Knowledge Facts about data, business rules, and domain expertise. "Column amt is gross transaction amount in cents, divide by 100 for display" #### Events Things that happened: migrations, incidents, schema changes. "The revenue table was restructured in Q3 2025, old columns are deprecated" #### Entities People, systems, teams, and their roles in the data landscape. "The finance team owns all revenue datasets and prefers net_amt over amt" #### Relationships Connections between entities, datasets, and business concepts. "The orders table feeds the revenue pipeline through a nightly ETL job" #### Preferences User-specific settings, formatting choices, and workflow habits. "This user prefers CSV exports with headers and ISO date formatting" Classification ### What Stays Yours, and What Gets Proposed Every memory also carries a class, shown beside it in the portal, and the class is the mechanism behind promotion. Two classes are personal by definition and never leave your own records. The other three assert something about the business, so they are recorded as proposals and go to a person before they reach anyone else. Personal #### Live for you immediately Nobody reviews these, because there is nothing for anyone else to agree with. They are yours, and they stay yours. Preference How you like to work: formats, defaults, habits. Event Something that happened, in your own working history. Reviewed #### Recorded as a proposal These are claims about how the business works, so they enter the review queue as insights and become shared knowledge only once someone promotes them. Business knowledge A fact about the business that the rest of the team would benefit from. Operational rule A standing rule about how the work gets done here. Schema/entity A fact about one table, column, or catalog entry. [Image: The Memory tab of the Knowledge page, with Total, Active, Stale, and Archived counters, a search box with status and class filters, and a list of active memories each showing its class, capture date, text, and the table it is linked to] Personal memory is a list you can read, filter, and search yourself. [Image: The Insights tab of the Knowledge page with the Review queue selected, showing Pending Review, Total Insights, Top Category, and Applied counters above a table of insights with captured-by, category, confidence, and status columns] The three reviewed classes land here as insights, each with a visible status. Promotion is covered on [Knowledge Capture](https://plexara.io/product/knowledge-application), including where each promoted fact lands and how a promotion is undone. Recall ### One Search, Four Ways In There is no separate command for reading memory back. The one search that covers your catalog, knowledge pages, assets, prompts, and connections covers memory too, and returns it grouped alongside everything else. Underneath, it reaches memory four ways and merges what they find. #### Entity Lookup Direct retrieval by dataset or entity reference. Finds memories explicitly tagged to a specific table, column, or catalog entity. Best for: When querying a known dataset and need its accumulated context. #### Semantic Search Meaning-based ranking across memory content, blended with an exact-term signal so an identifier, column name, or error code is not underweighted by similarity alone. Best for: Exploratory questions where the relevant dataset is not yet identified. #### Keyword Match Full-text matching on the words themselves, with no interpretation in between. It is also what search falls back to rather than failing, and it says so when it does. Best for: Hunting for a term you know appears verbatim. #### Graph Traversal Follows catalog lineage to find memories attached to upstream and downstream datasets. If you query a derived table, memories about its source tables surface automatically. Best for: Lineage-dependent questions where context propagates across related data. Lifecycle ### Capture, Correct, Consolidate Memory operations are explicit and auditable. Capture is the one way in, and it checks what you already have before writing: a restatement of something you said before supersedes it rather than sitting beside it, and a near-match is offered back so the agent can update instead of duplicating. Memory is personal and persists across sessions. It is distinct from knowledge capture, which is organizational and feeds the catalog. Memory stores what a specific user or agent has learned. Knowledge capture stores what the organization has validated. Memory commands Capture Record a memory with its class and entity links Find Read it back through the one search, alongside everything else Update Revise the content, category, or tags of a record Forget Archive a memory so it stops surfacing List Browse your own records with filters Review stale See what the lineage watcher flagged as outdated Review duplicates See your closest near-duplicate pairs, highest first Consolidate Keep one of a pair and retire the other, chain intact Common questions ### Memory FAQ Plexara structures memory into five dimensions: knowledge (facts, definitions, business rules), events (migrations, incidents, schema changes), entities (people, systems, teams), relationships (how those connect), and preferences (per-user formatting and workflow habits). Storing each kind separately means it is indexed and recalled the way that kind needs, rather than dumped into a single bucket. [Learn more: Five kinds of memory, and how each comes back](https://plexara.io/learning/insights/five-kinds-of-memory) Different questions need different recall methods, so Plexara composes entity lookup (exact match on people, tables, projects), semantic search (meaning-based via embeddings), and lineage graph traversal (related concepts). All three run inside one universal search tool that reaches memory alongside the catalog, knowledge pages, insights, saved assets, and prompts, and returns results grouped by source. The agent does not pick a strategy or a place to look; it asks once and sees the shape of the whole answer space. [Learn more: Letting the agent find the right tool](https://plexara.io/learning/insights/intent-driven-tools-and-memory) Memory is personal and persists across sessions for a specific user or persona. The catalog is organization-wide structured documentation. Memory captures what an individual taught the agent during their work; once an admin reviews and promotes it, that observation can become catalog metadata everyone benefits from. [Learn more: Knowledge: from memory to insights](https://plexara.io/learning/mcp/knowledge-from-memory-to-insights) Yes. Recording is one action, memory_capture, and the memory_manage tool exposes commands to update, forget, list, and review what has gone stale or duplicated. Stale memories surface in periodic review prompts so users can keep their context fresh. Nothing is locked in. [Learn more: Knowledge: from memory to insights](https://plexara.io/learning/mcp/knowledge-from-memory-to-insights) No. Memory is scoped per user and persona. Cross-user sharing happens through the insights pipeline: an observation captured in one user's memory can be promoted, with admin review, to catalog documentation that all future agents see. That is intentional, not a bypass. [Learn more: Knowledge: from memory to insights](https://plexara.io/learning/mcp/knowledge-from-memory-to-insights) Next ### Knowledge Capture How every conversation improves your data catalog through governed knowledge capture. [Continue](https://plexara.io/product/knowledge-application) --- # Governance URL: https://plexara.io/product/governance/ > Governance enforced at the point of execution. Fail-closed security, persona-based tool filtering, comprehensive audit logging, and operational safeguards. ## Governance Governance enforced at the point of execution, not just at catalog time. When an AI agent queries data through Plexara, access controls, audit trails, and quality signals are enforced by the same platform that executes the query. The Gap ### Catalog-Time vs. Execution-Time Governance | Aspect | Catalog-Time | Execution-Time (Plexara) | | --- | --- | --- | | PII Classification | Tag exists in catalog. Agent can still query the data through a separate connection. | Persona filtering blocks unauthorized tool access. PII tag surfaces in every enriched response. | | Access Control | Policy defined in catalog. Enforcement depends on downstream systems honoring it. | Default-deny posture. No persona means zero tool access. Enforced on every request. | | Audit Trail | Catalog logs metadata reads. Query execution logged separately in the database. | Single audit log captures user identity, persona, tool, connection, duration, and outcome. | | Deprecation | Deprecation notice in catalog. Agent may never check the catalog before querying. | Deprecation warning included in every query response for the deprecated dataset. | [Image: The Personas admin screen with a Data Engineer persona selected, showing its identity, roles, and priority on the left, allow and deny patterns below, and a live What can Data Engineer do preview listing each tool as allowed or denied with the pattern it matched] A persona is written as allow and deny patterns, and the preview beside them shows the resulting tool list before you save. [Image: The Visibility tab for the Trino Query tool in the Tools admin screen, with a global kill-switch card, a Persona access table listing each persona's decision and matched pattern, and a field to preview the decision for any persona name] Flip it around and ask one tool who can reach it: every persona, its decision, and the pattern that produced it. Authentication ### Fail-Closed by Default Missing or invalid credentials deny access. No persona assigned means zero tool access. Misconfiguration results in denied access, never unauthorized access. #### OIDC OpenID Connect with required JWT claims (sub, exp). Integrates with any enterprise identity provider. Use case: Interactive users through AI clients and web interfaces. #### OAuth 2.1 Full OAuth 2.1 with PKCE for public clients and Dynamic Client Registration. Built-in authorization server. Use case: Third-party integrations and delegated access patterns. #### API Keys Managed API key authentication for service accounts and automation workflows. Use case: Machine-to-machine communication and CI/CD pipelines. Audit ### Every Tool Call Logged Comprehensive audit logging with PostgreSQL storage and configurable retention. The audit log captures what happened, who did it, under what authority, and through which data path. Platform-level logging captures tool calls invisible at the database level. A database log shows a query from a service account. The platform log shows which human initiated the session, which persona they used, and which tool call triggered the query. Captured per tool call User Identity Authenticated user from IdP Persona Resolved role-based persona Tool MCP tool that was invoked Connection Target data source connection Duration Execution time in milliseconds Outcome Success, failure, or denied [Image: The Events tab of the admin Dashboard, a searchable and filterable table of tool calls with timestamp, user, tool, toolkit, source, connection, duration, status, and enriched columns, plus Export CSV and Export JSON buttons] The audit log as your admins see it: one row per tool call, filterable and exportable. Safeguards ### Operational Controls #### Read-Only Enforcement Trino and S3 connections can be locked to read-only mode, blocking write operations at the platform level. #### S3 Prefix ACLs Restrict storage access to specific S3 paths. Agents cannot browse or retrieve objects outside allowed prefixes. #### Workflow Gating Session-aware enforcement tracks whether discovery tools were called before query tools, with configurable escalation. #### Prompt Safety Catalog metadata is screened for suspicious instruction patterns before enrichment, and detections are logged. This reduces exposure but cannot catch every phrasing; it is one layer in the shared-responsibility defense detailed on the Security page. #### Supply Chain Provenance Signed build provenance (GitHub artifact attestations) with SAST (Semgrep, CodeQL), race detection, gosec, and OpenSSF Scorecard. #### Query Limits Configurable default and maximum row limits, query timeouts, and connection-level resource controls. Next ### Email Notifications How a share, a mention, or an unworked review queue reaches a person who is not looking at the portal. [Continue](https://plexara.io/product/notifications) --- # Portal Tour URL: https://plexara.io/product/portal/ > A guided tour of the Plexara portal: assets and their viewers, collections, a versioned prompt library, resources, feedback, the knowledge pipeline, catalog governance, and the knowledge graph. ## The Workspace Where the Answers Land The Plexara portal is one web application, and its sidebar has two halves. This tour walks the first: what a practitioner opens every day, section by section, in the order the sidebar lists them. Each stop pairs the reason the surface exists with the screen that implements it. 01 Assets ### Everything an Agent Made for You, Kept An asset is what an agent produced during a session and you decided to keep: a dashboard, a report, a chart, a data extract. Assets lead the sidebar because they are what most people open the portal for. My Assets #### Find the Thing You Made Last Tuesday ##### Why it matters A session ends and its output sinks into chat history. Work nobody can find again is work somebody will ask for twice, and the second answer rarely matches the first. ##### How it works My Assets lists everything you saved, searchable by name and description and narrowed by content type and tag, as a grid of preview thumbnails or a sortable table; whichever you prefer is remembered. Markdown and CSV thumbnails are captured in both light and dark and the grid shows the one matching your theme, while content that carries its own colours uses a single preview in both. Rows carry tags, collection badges, file size, sharing state, and creation date. [Image: My Assets grid with search, content-type and tag filters, preview thumbnails, and a grid or table toggle] [Image: My Assets grid with search, content-type and tag filters, preview thumbnails, and a grid or table toggle] Viewers #### What You Saved Opens as What It Is ##### Why it matters A dashboard stored as a screenshot is a picture of an answer, and a data extract you have to download and open somewhere else is a chore with a filename. The portal should show the thing itself. ##### How it works HTML and JSX render as live interactive components with working state. SVG draws as vector art at full resolution, Markdown formats with tables, code blocks, and diagrams, CSV and TSV become sortable tables, JSON a searchable collapsible tree. Images zoom and pan, audio and video seek, PDFs open inline. Anything with no viewer shows a metadata card and a download rather than raw bytes. Every viewer keeps a Preview and Source toggle, so the output and the code behind it are one click apart, alongside full version history. [Image: Interactive JSX dashboard rendered live in the portal with KPI cards, regional charts, and a product table] [Image: Interactive JSX dashboard rendered live in the portal with KPI cards, regional charts, and a product table] Sharing #### A Link That Only Opens for the Person You Named ##### Why it matters Sharing usually forces a choice between a URL anyone can forward and an attachment nobody can update. Neither one tells you who actually looked. ##### How it works Every share carries an access mode. Naming a recipient makes it restricted: the link resolves for that person, signed in, and for nobody else, so forwarding the email grants nothing. A link share opens for any signed-in user unless you deliberately pick Anyone with the link, which warns you before it does. Notify by email comes checked and can be cleared to share quietly, with an optional plain-text note carried in the message. A recipient with no account can request a single-use view link, good for fifteen minutes, that opens a read-only guest session scoped to that one item and dies after its first use. Active shares list their mode, view count, and expiry, and revoking one ends guest sessions immediately. [Image: Share dialog with a named recipient at Viewer permission, notify-by-email, an optional message, and two active shares] [Image: Share dialog with a named recipient at Viewer permission, notify-by-email, an optional message, and two active shares] 02 Collections ### Curate a Deliverable Out of Loose Output Collections live under Assets in the sidebar because they are made of assets. They turn a scattered set of outputs into a titled, sectioned document: a board packet, a weekly review, an onboarding pack. Collections #### Named Deliverables, Not Folders ##### Why it matters Fifteen assets from four sessions are not a report. Somebody still has to say which ones matter, in what order, and what they mean together. ##### How it works A collection renders as a structured document: ordered sections, each with a title and a markdown description, holding asset cards with preview thumbnails, content-type badges, and file sizes. Thumbnail size is set per collection, down to none for a text-first briefing. Every card opens the full asset viewer, with its provenance intact, and comes back. [Image: Collection viewer rendering sectioned asset cards with markdown descriptions and thumbnail previews] [Image: Collection viewer rendering sectioned asset cards with markdown descriptions and thumbnail previews] Editing #### Arrange It Once, Send It Every Week ##### Why it matters A recurring deliverable that has to be reassembled by hand every time is a recurring deliverable somebody eventually stops sending. ##### How it works The editor arranges assets into drag-and-drop sections, each with its own markdown description, and sets the thumbnail size for the whole collection. Sharing works exactly as it does for a single asset, including recipient-restricted access at Viewer or Editor and a share-management list. Both Assets and Collections carry a Mine, Shared, or All scope control, so what a teammate sent you sits beside what you made. [Image: Collection editor with drag-and-drop sections, markdown descriptions, and thumbnail size settings] [Image: Collection editor with drag-and-drop sections, markdown descriptions, and thumbnail size settings] 03 Prompts ### Prompts as a Governed, Measurable Library Prompts are the organization’s manual for agent-run procedures, typed and parameterized rather than pasted around as text. The page shows two buckets: My Prompts, everything you own plus everything shared with you, and Library, the approved team prompts grouped by collection. [Learn the prompt workflow](https://plexara.io/learning/prompts). Library #### The Prompts Worth Keeping, and Proof of Which Ones Are ##### Why it matters Every analyst writes their own version of the same prompt, quality drifts apart, and nobody can say which one produced last quarter’s report or whether anyone still uses it. ##### How it works The Library groups approved prompts into collections by team, domain, or workflow, with uncollected ones under General. Facets narrow by collection, tag, status, owner, and activity. Every row shows its run count and how long since it last ran, aggregated from serve audit events and sortable, and a prompt nothing uses is badged with the exact condition: never run, or unused 60d+. A prompt created in the last week carries no badge while it is still too new to judge. Search ranks by meaning, so a phrase finds the prompt that does that job even when it shares none of its words. [Image: Prompt library grouped into collections with run counts, last-run ages, and never-run and unused badges] [Image: Prompt library grouped into collections with run counts, last-run ages, and never-run and unused badges] Collections #### Group Them the Way the Team Thinks ##### Why it matters A flat list of eighty prompts is a search box with extra steps. The grouping people actually use is by the work, not by who happened to write it. ##### How it works The Collections manager creates, renames, and deletes named groups with their own descriptions. Any user can create one; renaming and deleting stay with the creator or an admin. A prompt belongs to at most one collection, assigned from the prompt page by its owner, or by an admin for shared prompts. Deleting a collection releases its prompts to General rather than taking them down with it. [Image: Prompt collections manager listing named groups with descriptions and prompt counts] [Image: Prompt collections manager listing named groups with descriptions and prompt counts] The Prompt Page #### Typed Arguments, Attached Material, and How to Run It ##### Why it matters A prompt pasted as text loses its arguments, the material it depends on, and any instruction for using it. What was a tool becomes a snippet. ##### How it works The page renders the content with its placeholders extracted into a typed arguments table marked required or optional. An Attached materials panel carries the resources the procedure depends on in an authored order, because that is the order the agent receives them in, and material outside your scope is shown as restricted rather than silently dropped. Run from chat gives you a copyable sentence built from the prompt’s stable name and its required arguments, which any connected agent resolves against the library. [Image: Prompt page with details, a typed arguments table, rendered content, attached materials, and run-from-chat] [Image: Prompt page with details, a typed arguments table, rendered content, attached materials, and run-from-chat] Versions #### Who Changed It, Who Approved It, and What Moved ##### Why it matters A shared prompt anyone can quietly edit is a shared prompt nobody can trust. Approval means something only when it is bound to the exact text that was approved. ##### How it works Every version lists its author, date, and status, and approval is stamped per version rather than per prompt, so approved by names whoever signed off on that text. A pending draft on an approved shared prompt raises a banner and readers keep being served the approved version until an admin approves the draft. Any version diffs against the current content as a line diff. Library readers see the served history; drafts that were never served stay with admins. [Image: Prompt version history with per-version approval provenance, a pending-draft banner, and an expanded line diff] [Image: Prompt version history with per-version approval provenance, a pending-draft banner, and an expanded line diff] Sharing and Promotion #### From Your Prompt to the Team’s ##### Why it matters The good prompts start as somebody’s personal one. If the only way to spread it is to paste it, the team ends up with six drifting copies instead of one. ##### How it works Share sends a prompt to a colleague by email and they receive a real runnable prompt, arguments intact, that their agent invokes directly rather than a flattened markdown copy. Sharing is owner-initiated and revocable at any time. Request Promotion asks an admin to move a personal prompt to one or more personas or to global scope; the prompt stays personal and shows a promotion-requested badge until that review resolves. Save as Asset stays a separate action, for when you want the text as a document. [Image: Prompts page showing the My Prompts bucket with scope badges and shared-by attribution] [Image: Prompts page showing the My Prompts bucket with scope badges and shared-by attribution] In the Conversation #### The Same Library, Without Leaving the Chat ##### Why it matters Switching to a browser tab to find a prompt, then coming back to type its name, is enough friction that people stop using the library and start pasting text again. ##### How it works Asking an agent to show your prompts calls show_prompts, and in a host that renders MCP Apps the List Prompts browser opens inside the conversation: the same My Prompts and Library buckets, collection and tag filters, usage sorting, and cards carrying version, approval provenance, and run count. A detail view generates its form from the prompt’s own argument specs, and Run resolves through manage_prompt and places the rendered prompt straight into the chat. The browser is bound to show_prompts, a tool whose only job is to display the library, so the agent’s routine prompt work never opens a window you did not ask for. It is presentation only: the same calls return complete structured results in clients that draw no UI, so nothing about the library is reachable only through the picture of it. MCP App: List Prompts weekly revenue My Prompts Library Revenue Ops Marketing finance weekly Sorted by usage - Daily Sales Report v4 Regional revenue, order counts, and week-over-week movement for one territory. Approved by carol@example.com 312 runs - Quarterly Churn Review v2 Cohort retention with the accounts that lapsed and the reasons on file. Approved by dan@example.com 48 runs - Campaign Performance Digest v7 Spend, reach, and attributed pipeline for every active campaign. Approved by carol@example.com 126 runs Daily Sales Report v4 approved by carol@example.com, 312 runs Arguments `region` Required West `period` Required Last 7 days `include_forecast` Optional No Run The List Prompts app, which opens on show_prompts in a host that renders MCP Apps: search across My Prompts and Library, cards carrying version, approval provenance and run count, and a detail view whose form is generated from the prompt’s own argument specs. Run resolves through manage_prompt and places the rendered prompt in the chat. The app is presentation only, so the same calls return complete structured results in clients that draw no UI. 04 Resources ### Material the Agent Uses Exactly as You Wrote It Resources run the other direction from assets: files a person made that the agent should use as-is. A template a deliverable must be produced in, a runbook to follow, a data dictionary, a brand file. The test is short. If it existed before the conversation and should be used verbatim, it is a resource. The Library #### Say How the File Should Be Treated ##### Why it matters An agent that has to be told the reporting format every session will get it wrong the session somebody forgets to say it. ##### How it works Upload a file with a category that states how to treat it: 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, and a custom category covers what fits none of them. Any format the library needs is accepted apart from executables. Agents read a resource during a session, and a background indexer embeds each file’s metadata and a bounded prefix of text contents, so a data dictionary is found by a column name that appears only inside the file. Global resources reach every caller, persona resources reach their members, personal resources reach their owner. [Image: Resources page with scope tabs, category filter, and a table of uploaded reference material] [Image: Resources page with scope tabs, category filter, and a table of uploaded reference material] Revisions and Usage #### Replace the File Without Breaking What Cites It ##### Why it matters Deleting a resource and uploading a new one mints a new identity, which quietly breaks every citation and every prompt attachment pointing at the old one. ##### How it works Replace content uploads new bytes to the existing resource. It keeps its identifier, its canonical address, and its file name, so citations and prompt attachments keep resolving and connected agents are told to re-read rather than serving the old content. Each revision is recorded with its author, date, and size; any can be downloaded and any prior one restored as a new head revision, so the trail stays append-only and a restore is itself restorable. The ten most recent revisions are kept, and the live content is never pruned. Usage reports reads over the last 30 and 90 days broken down by which door served them, and the table adds a Last read column so a curator can find the material nothing has touched. [Image: Resource detail showing scope, metadata, canonical address, and an inline preview over a table with a Last read column] [Image: Resource detail showing scope, metadata, canonical address, and an inline preview over a table with a Last read column] 05 Feedback ### A Human Loop That Ends in Durable Knowledge People and agents work on the same artifacts. Reviewers, including subject-matter experts who never open an agent, leave structured corrections in place, and a correction can become something the whole team keeps rather than a comment that dies in a thread. Threads #### Corrections That Stay Attached to What They Are About ##### Why it matters A correction relayed over email loses the thing it refers to. By the time it lands, nobody is certain which version, which number, or which paragraph was meant. ##### How it works A thread targets one asset, collection, prompt, or knowledge page, or lives on a standalone channel, and carries a kind (comment, question, correction, rating, approval, rejection, suggestion), a status lifecycle, and an optional needs-resolution flag. Select a passage before opening one and the thread anchors to that selection and to the version it was raised against. The panel header counts how many threads are open and how many still need resolution, and items you own carry an open-thread badge in the lists. [Image: Feedback panel open beside an asset, listing threads with their kind, status, and open counts] [Image: Feedback panel open beside an asset, listing threads with their kind, status, and open counts] Mentions #### Name Someone and They Actually Hear About It ##### Why it matters A comment nobody is told about is a comment nobody reads, and muting thread chatter should not mean missing the message that was addressed to you. ##### How it works Type an @ in any message or reply and the composer suggests people, inserting the person as an address so the mention keeps working when a display name changes. The suggestions are people who can already open the item, because a mention emails the item’s title and an excerpt of the comment. Type an address by hand and the composer tells you while you are still writing whether that person has access; if not, the mention posts as ordinary text and delivers nothing. Being mentioned is its own notification category, and a Mentions of me tab collects every thread where a comment named you. [Image: Feedback composer suggesting a teammate by name and address as an @ mention is typed] [Image: Feedback composer suggesting a teammate by name and address as an @ mention is typed] Capture #### A Comment That Changes the Catalog ##### Why it matters Telling somebody we do not call it that is worth something only if it can change what the next person, and the next agent, gets told. ##### How it works A reviewer holding apply_knowledge sees Capture as insight on an unresolved correction or suggestion. Capturing creates a pending insight from the thread and resolves the thread with a link to it, and that insight joins the same review queue as the ones agents capture. Once it is promoted, the thread’s knowledge chain shows the resulting change, which closes the loop for the reviewer and for whoever raised it. The Feedback page in the sidebar is both the standalone channel for general feedback and the hub for everything waiting on you. [Image: Feedback hub listing threads across assets, collections, and prompts with their kind and status] [Image: Feedback hub listing threads across assets, collections, and prompts with their kind and status] 06 Knowledge ### Memory, Insight, Knowledge: One Page, One Pipeline Knowledge is one page for the whole lifecycle. Three tabs run across the top, Knowledge, Insights, and Memory, and the Knowledge tab holds four of its own: Search All, Knowledge Pages, Catalog, and Changesets. Review and promotion appear for whoever holds the apply_knowledge capability, which is a capability rather than an admin role. [How promotion works](https://plexara.io/product/knowledge-application). Knowledge #### One Query Across Everything You Can Reach ##### Why it matters Knowledge spread across a catalog, memory, saved work, prompts, and connected APIs is knowledge nobody finds. Discovery has to be a single surface, or agents guess at the data instead of grounding in what exists. ##### How it works Search All fans one query across the catalog, canonical knowledge pages, your memory, captured insights, saved assets, uploaded resources, prompts, API endpoints, and connections, returning results grouped by source with a per-source coverage summary and filter chips, balanced so the largest source never drowns the rest. Ranking blends semantic similarity with exact keyword match, so a question reaches the right record even when it shares none of its words. It is the same federation your agents call. With the box empty, Knowledge Pages browses the canonical pages, and Changesets records what promotion actually wrote, with rollback. [Image: Unified search grouping results by catalog, knowledge pages, insights, memory, assets, and prompts with a coverage summary] [Image: Unified search grouping results by catalog, knowledge pages, insights, memory, assets, and prompts with a coverage summary] Insights #### The Only Memory That Crosses Between People ##### Why it matters Letting an assistant write to the shared catalog unattended is how trust evaporates. A fact worth sharing has to pass a person before it becomes canonical. ##### How it works When a memory asserts something true about the business or the data that others would benefit from, it is captured as an insight: a proposal carrying a status of pending, approved, applied, or rejected, and a category spanning correction, business context, data quality, usage guidance, relationship, and enhancement. Your insights lists the ones captured from your own sessions with relevance search over them. A pending count is badged on the sidebar Knowledge item so nothing sits unreviewed by accident. [Image: Insights list showing each captured insight with its status and category] [Image: Insights list showing each captured insight with its status and category] Review #### Approve, Reject, Then Promote ##### Why it matters A queue that shows a reviewer nothing but a claim makes them guess. They need what it asserts, what it is about, and what applying it would actually do. ##### How it works Whoever holds apply_knowledge gets the review queue across every user, with the pending count and the age of the oldest item up front and filters for status, category, and confidence. Opening one shows the captured statement, the entities it names, the catalog actions it suggests, the related columns, the capture and review trail, and approve or reject. Promotion itself happens when an agent runs apply_knowledge: business and domain facts become wiki-linked knowledge pages that cite the exact data they describe, technical and entity facts are written to the catalog. Every promotion is recorded as a changeset with one-click rollback. [Image: Insight review queue with pending count, oldest age, status and confidence filters, and per-row status badges] [Image: Insight review queue with pending count, oldest age, status and confidence filters, and per-row status badges] Memory #### The Raw Substrate, Captured Without Being Asked ##### Why it matters A stateless assistant starts every session from zero, so the same context gets re-explained on loop and the same mistakes get repeated on schedule. ##### How it works Memory records what sessions surface, classified by lifecycle class: preference, event, business knowledge, operational rule, and schema or entity fact. That class is what decides whether something stays personal or is a candidate for promotion. Recall blends semantic and keyword search, a capture-time check supersedes near-duplicates, and a staleness watcher flags records whose underlying entities have changed. A query error that a later query fixes is captured as a correction on its own. This tab is yours; nothing in it reaches anyone else unless it becomes an insight and that insight is applied. [Image: Personal memory records classified by lifecycle class with active, stale, and archived states] [Image: Personal memory records classified by lifecycle class with active, stale, and archived states] 07 Catalog ### Govern the Catalog Without Leaving the Portal Catalog is a sub-tab of Knowledge and the second of the two knowledge sinks. Everything under it is the DataHub catalog; what the portal’s own database holds stays outside. Five inner tabs sit beneath it, the described things first and the vocabularies that describe them second: Tables, Context Docs, Tags, Domains, and Glossary. The connection is picked once at the top and applies to all of them. Inline Governance #### The Person Who Spots It Is the Person Who Fixes It ##### Why it matters A catalog you can only read is a catalog that rots. Whoever notices a table description is wrong is rarely whoever has a catalog console open, and by the time it is relayed, nobody fixes it. ##### How it works Tables opens a dataset to its description, tags, owners, glossary terms, domain, and columns, each facet editable in place. Context Docs manages the markdown notes attached to a dataset, term, node, or container. Tags, Domains, and Glossary manage the vocabularies themselves: what each entry means, which tables carry it, and which knowledge pages have written about it, so a steward reading a term sees the prose about it and each table links straight into its own editor. Pickers search by display name, so attaching Net Revenue never means typing the identifier the catalog generated for it. Descriptions and definitions are markdown in a split source and preview editor. A write needs both the matching grant on your persona and a write-enabled connection, both checked on the server whatever the screen offers, and every write is recorded in the audit log. [Image: Catalog sub-tab with Tables, Context Docs, Tags, Domains, and Glossary inner tabs, a connection picker, and searchable table cards] [Image: Catalog sub-tab with Tables, Context Docs, Tags, Domains, and Glossary inner tabs, a connection picker, and searchable table cards] 08 Graph ### See the Shape of What Your Team Knows The Knowledge Pages sub-tab holds two layouts of the same corpus, switched with a Cards and Graph toggle that preserves your search text and tag filter across the change. Cards is the browse list. Graph draws the corpus as its reference network: every page is a node, so is every entity the pages cite, and every edge is a stored reference. Graph #### It Opens on One Node, Not the Whole Hairball ##### Why it matters A whole-corpus force layout looks like insight and answers nothing. Forty nodes of spaghetti tell a reader that there is a lot of it, and nothing else. ##### How it works The view starts at the corpus’s strongest bridge, the node the most shortest paths run through, and shows its neighbourhood; Hops widens that one step at a time and Whole corpus drops back to the overview. Clicking a node inspects it rather than navigating away: references in both directions, each selectable in place so you can walk the corpus without a page load, its bridge score and rank, and its cluster. Focus re-centres the view, Expand pulls in neighbours, Path from traces the shortest chain of references to any other node and lists it hop by hop, and Open is the only action that leaves the graph. Type chips filter what is drawn, and the search box focuses matching nodes instead of removing the rest. [Image: Knowledge graph focused on one node with hops and type controls and an inspector listing references in both directions] [Image: Knowledge graph focused on one node with hops and type controls and an inspector listing references in both directions] Structure #### Measured, Not Merely Drawn ##### Why it matters A picture of a network invites a reader to see topics that may not be there. The useful question is whether the corpus really has structure or just edges. ##### How it works The corpus is partitioned into clusters and every node scored for how much of the graph it bridges. Node size is that bridge score, so the entities holding otherwise separate topics together are the largest marks on screen, while shape and colour stay with the type. In the whole-corpus overview each substantial cluster is tinted as a region behind its members and the layout pulls them together so the regions read as distinct. The summary line states how many clusters were found and the partition’s modularity, so the structure is something you can check rather than infer. Selecting a catalog node looks the dataset up and reports what is actually there; when the catalog does not hold it, the inspector says so, because a page citing a dataset the catalog is missing is a real gap. Entities you cannot access are absent entirely, node and edge both, and a cap on a very large corpus is stated above the canvas rather than applied quietly. [Image: Whole-corpus knowledge graph with detected clusters tinted as regions and a node, reference, and modularity summary] [Image: Whole-corpus knowledge graph with detected clusters tinted as regions and a node, reference, and modularity summary] 09 Activity ### Your Own Usage, Not the Platform’s Activity is the personal read: what you have been asking for, how long it took, and which tools carried it. The platform-wide equivalents live in the admin sections. Activity #### What You Have Actually Been Asking For ##### Why it matters People are usually surprised by their own usage. Seeing which tools carry the work, and where the errors cluster, is how a habit turns into a prompt worth saving. ##### How it works Summary cards report total calls, average duration, and how many distinct tools you used over the window you pick, from the last hour out to seven days. A timeseries charts your call volume with errors picked out against it, and a bar chart ranks your most-used tools. [Image: Personal activity page with summary cards, a call-volume timeseries with errors highlighted, and a top-tools bar chart] [Image: Personal activity page with summary cards, a call-volume timeseries with errors highlighted, and a top-tools bar chart] 10 Settings ### What Reaches Your Inbox, and What Already Did Settings holds per-user preferences and closes the sidebar. Its one section today is notifications, and it answers both halves of the question rather than only the first. What sends those messages, and who else hears about the same event, is covered on [Email Notifications](https://plexara.io/product/notifications). Notifications #### Preferences Above, Delivery Receipts Below ##### Why it matters Notification settings usually let you say what you want to be told and leave you with no way to know whether anything was sent. The two questions belong on one screen. ##### How it works Delivery is off, immediate, or a daily digest, with per-category toggles for shares, comments and feedback, and mentions; changes save as you make them. Recent notifications sits directly beneath and lists what was actually sent to your account, newest first, with its subject, category, and delivery status. A message that never went out reads Not delivered. It shows recent activity rather than a full record, and the window it covers is stated on the panel so an empty list is not mistaken for a quiet week. [Image: Settings page with notification delivery modes, per-category toggles, and a recent notifications list with delivery status] [Image: Settings page with notification delivery modes, per-category toggles, and a recent notifications list with delivery status] Next ### Administration The other half of the same sidebar: the dashboard, tools, personas, gateways, and the audit trail behind every call. [Continue](https://plexara.io/product/portal/admin) --- # Portal Administration URL: https://plexara.io/product/portal/admin/ > The administrative half of the Plexara portal: the activity dashboard, audit events, fleet and index health, personas, tools, connections, API catalogs, keys, and the user directory. ## See Exactly What Your Agents Can Reach The same portal, the second half of the sidebar. These sections are shown to whoever holds the role, and they are where access is defined, backends are connected, tools are inspected and tested, and every call is accounted for. This tour walks them in the order the sidebar lists them. 01 Dashboard ### One Page That Answers Whether Anything Is Wrong Dashboard is the administrative landing view and it carries six tabs: MCP, API Gateway, Health, Indexing, Events, and Notifications. The first of them opens on tool-call activity across a window you choose, from the last hour out to seven days. What fills the last of them, and where an admin points outbound mail, is covered on [Email Notifications](https://plexara.io/product/notifications). MCP #### Volume, Success, and the Rhythm of a Working Week ##### Why it matters Adoption questions and incident questions look identical from the outside. Both start with how much is being asked, by whom, and whether it is succeeding. ##### How it works Summary cards report total calls, success rate, average duration, unique users, unique tools, enrichment rate, and errors, each with its trend against the prior window. An activity timeline charts call volume with errors overlaid, and a usage-rhythm heatmap lays the last seven days out by weekday and hour, which is where a nightly job or an abandoned Friday afternoon becomes obvious. Below that sit top tools and top users, response-time percentiles, a clickable recent-errors list, the knowledge review queue, and every connected backend with its tool count. [Image: Admin dashboard on the MCP tab with summary cards, an activity timeline, and a usage-rhythm heatmap by weekday and hour] [Image: Admin dashboard on the MCP tab with summary cards, an activity timeline, and a usage-rhythm heatmap by weekday and hour] Events #### Every Call, With the Arguments It Was Made With ##### Why it matters When something goes wrong you need the exact call, its arguments, its response, the persona that allowed it, and the session it belonged to. A sanitized summary answers none of that. ##### How it works The Events tab indexes every tool invocation, filterable by user, tool, status, and time, with sortable columns and CSV or JSON export. Any row opens a detail drawer carrying identity (user, persona, session), execution (tool, connection, duration), status and enrichment, transport sizes, and the full request parameters as JSON. Distributed tracing follows one request through sign-in, context gathering, and the underlying data call. [Image: Audit event log with user, tool, status and time filters, sortable columns, and export actions] [Image: Audit event log with user, tool, status and time filters, sortable columns, and export actions] Health #### Which Node Is the Problem ##### Why it matters Incident response starts with knowing whether the stack is degraded and which node is degrading it, before anyone starts guessing. ##### How it works The Health tab reports per-node uptime, CPU, resident memory, heap, and goroutine counts across the fleet, with a clear status for each and a dash wherever a metric is genuinely missing rather than a zero that reads as healthy. [Image: Per-node fleet health with uptime, CPU, memory, heap, and goroutine metrics] [Image: Per-node fleet health with uptime, CPU, memory, heap, and goroutine metrics] Indexing #### Watch Semantic Ranking Stay Healthy ##### Why it matters Embedding work runs off the request path, so a slow provider or a run of retries degrades ranking toward keyword-only with nothing but a log line to say so. Search quietly gets worse and nobody is told. ##### How it works The Indexing tab reports the embedding provider, model, and dimension, then a plain verdict per corpus: up to date, indexing, or degraded, each with real indexed-of-expected coverage and when it last ran. Equivalent states look identical, so a healthy corpus is recognisable at a glance rather than read. Below sit a throughput timeline, embed latency at the median with a 95th-percentile marker, in-flight jobs with their lease countdown and progress, retry backoff with attempt counts, and open failures grouped by error signature. A failure resolves itself and leaves the panel once a later job for the same unit succeeds. Re-index re-enqueues everything out of sync for a corpus. [Image: Indexing dashboard with provider health, per-corpus coverage verdicts, throughput, embed latency, and failure triage] [Image: Indexing dashboard with provider health, per-corpus coverage verdicts, throughput, embed latency, and failure triage] Notifications #### Did the Email Actually Arrive ##### Why it matters A share that never reached its recipient looks exactly like a share nobody opened. Without a delivery read, the first sign of trouble is somebody saying they never got it. ##### How it works Counts by status sit above the list, failed, pending, sending, and sent, and each doubles as a filter. Every row shows when it was raised, who it was addressed to, the subject the message carried, its category, its status, and how many attempts were made. Opening a row exists for the failure case: it shows the error the mail server returned, verbatim, alongside the attempt count before the queue gave up. Filters narrow by recipient, status, and category. It holds recent history rather than an archive, and the window it covers is stated above the list. [Image: Notification delivery view with counts by status, a queue list with recipients and subjects, and attempt counts] [Image: Notification delivery view with counts by status, a queue list with recipients and subjects, and attempt counts] 02 Agent Instructions ### Teach Every Session the Same Thing Agent Instructions is the operating guidance every agent session receives before it does anything. It is the highest-leverage screen in the administrative half, because it is the one place a rule reaches every conversation without anyone repeating it. Instructions #### Your Context on Top of the Platform Baseline ##### Why it matters Guidance that lives in somebody’s head gets applied on the sessions they are watching. Written once and served to every session, it applies on the ones nobody is watching. ##### How it works A split markdown editor puts source on the left and live preview on the right. Above it sits the read-only platform baseline: the platform-owned guidance composed beneath your own, naming only the tools this installation actually exposes, so you can see what is already covered and add only your business context on top rather than restating it. Every change made through the administrative sections is recorded with who made it and when, so the guidance has a history rather than a current value. [Image: Agent Instructions split markdown editor with live preview and the read-only platform baseline above it] [Image: Agent Instructions split markdown editor with live preview and the read-only platform baseline above it] 03 API Catalogs ### Turn Whole REST APIs Into Governed Tools An agent can call any external REST or HTTP API by reading that API’s own OpenAPI description to learn its operations and inputs, then signing in and calling it under per-role rules. Ten APIs do not add a thousand tools, and every call rides the same audit pipeline as native data access. [Read the API Gateway page](https://plexara.io/product/api-gateway). Catalogs #### One Spec, Every Connection That Points at It ##### Why it matters Generating one tool per endpoint explodes the catalog: ten APIs would add a thousand tools an agent has to sort through, which wrecks tool selection long before it wrecks anything else. ##### How it works A catalog is a versioned bundle of OpenAPI specs that many connections share, so one upload documents every connection pointing at that vendor. Specs are ingested by paste, file upload, or a public URL fetched once. The whole surface is then served through four tools: browse the spec sections, list a section’s operations, read one operation’s exact schema, and invoke it. Each spec carries an embedding-health badge and a last-fetched time, with refresh, retry, edit, and delete beside it, and a catalog cannot be deleted while a connection still references it. Large or binary responses stream straight to an asset instead of into the answer. [Image: API catalogs with component specs, embedding-health badges, source badges, and connection reference counts] [Image: API catalogs with component specs, embedding-health badges, source badges, and connection reference counts] Gateway Traffic #### Watch Where the Outbound Calls Go ##### Why it matters Outbound traffic is the part of an integration nobody watches until a vendor rate-limits you or an endpoint starts failing quietly. ##### How it works The Dashboard’s API Gateway tab charts connection-to-operation traffic as a flow, with an inbound-versus-outbound health split by status category and breakdowns by status class, method, and calling identity. Every endpoint is semantically indexed, so operations rank by what they mean rather than by name matching, and a plain REST route exposes the same connectors to clients that are not agents at all. [Image: API gateway traffic view with a connection-to-operation flow diagram and breakdowns by status, method, and caller] [Image: API gateway traffic view with a connection-to-operation flow diagram and breakdowns by status, method, and caller] 04 Assets ### Everything Produced, Across Everyone The administrative Assets view is the platform-wide read of what agents have produced: every asset from every user, with the provenance that says where each number came from. All Assets #### What Was Produced, and Who Produced It ##### Why it matters A workspace nobody can see across is a workspace where the same report gets built four times and no one notices the fourth is wrong. ##### How it works The table lists every asset on the platform with its name, owner, content type, file size, sharing state, and creation date, searchable and filterable by type, owner, and connection. [Image: Admin assets table listing every asset across users with owner, content type, size, and sharing state] [Image: Admin assets table listing every asset across users with owner, content type, size, and sharing state] Provenance #### Where a Number Actually Came From ##### Why it matters An artifact without lineage is a claim you cannot check. When a figure is disputed, the argument only ends when somebody can point at the query. ##### How it works Asset detail renders the content in the same full viewer users get, alongside the originating session, the tool calls that produced it, the datasets those calls touched, and the full version history. Delete, download, and share are available from the same screen. [Image: Admin asset detail rendering the asset beside its originating session, tool calls, lineage, and version history] [Image: Admin asset detail rendering the asset beside its originating session, tool calls, lineage, and version history] 05 Connections ### Every Backend, Including Other MCP Servers Connections manages the backend instances the platform serves from: Trino, DataHub, S3, and MCP gateways. A gateway connection proxies an upstream MCP server and re-exposes its tools as native ones, under the same persona rules, audit trail, and enrichment as everything else. Federation #### Upstream Tools Under One Access Model ##### Why it matters Every MCP server a team adopts is another endpoint, another sign-in, another silo. Agents end up juggling connections instead of getting one coherent surface. ##### How it works A split-pane list groups connections by kind with their descriptions and tool counts; selecting one shows its metadata, its configuration with a show-sensitive toggle for credentials, and its actions. A gateway connection re-exposes an upstream server’s tools under a local prefix so they sit alongside native tools and obey the same rules. Test connection dials the upstream with the values on screen, before anything is saved, and reports whether tool discovery succeeded. Refresh tools re-reads a saved upstream and re-registers its catalog live, so every connected agent’s tool list updates without anyone reconnecting. [Image: Connections split pane with backends grouped by kind and a selected connection showing metadata and configuration] [Image: Connections split pane with backends grouped by kind and a selected connection showing metadata and configuration] Enterprise Auth #### Sign In the Way Each Upstream Demands ##### Why it matters Real upstreams authenticate in incompatible ways, and some hosted vendor servers require a human browser sign-in rather than a static token, which is exactly the case a scripted integration cannot cover. ##### How it works Connections support bearer tokens, API keys, HTTP basic, OAuth 2.1 with either machine-to-machine credentials or browser sign-in with PKCE, and client-certificate mTLS. A browser sign-in connection shows a not-connected banner with a Connect button; authorizing opens the upstream’s own sign-in, and the card then names who authorized it and when. Tokens and secrets are encrypted at rest, access tokens refresh silently so scheduled work keeps running, and a certificate’s expiry surfaces as a badge before it bites. [Image: New connection form showing auth modes including OAuth 2.1 browser sign-in and client certificates] [Image: New connection form showing auth modes including OAuth 2.1 browser sign-in and client certificates] Enrichment Rules #### Give a Third-Party Tool Your Warehouse Context ##### Why it matters One source’s response carrying another’s context is the whole point, and it should apply to proxied third-party tools too. Hard-coding that per tool does not scale past the second one. ##### How it works A rule attaches warehouse and catalog context to a proxied tool’s response without any code: a predicate that fires always or when the response contains a value, a source operation against DataHub or Trino, bindings that pull from the call’s arguments, the response, and the caller, and a merge strategy that decides where the context lands. A dry run pastes in a sample call and returns the merged response with no side effects. A rule that fails attaches a warning rather than failing the call it was enriching. Rules are managed from a drawer on the gateway connection and shown on the tool itself. [Image: Per-tool enrichment rules listing predicate, source operation, merge strategy, and enabled state] [Image: Per-tool enrichment rules listing predicate, source operation, merge strategy, and enabled state] 06 Description ### What the Platform Says It Is Description sets the identity the platform reports to connected clients. It is the first thing an agent reads about what it has just connected to, and the sentence that decides whether it uses the platform well. Description #### The First Thing an Agent Learns ##### Why it matters An agent that does not know what a platform is for will use it like a generic database. A description that names the domain, the data, and the intended use changes the questions it asks. ##### How it works The same split markdown editor as Agent Instructions, source beside live preview. What you write is surfaced to connected clients as the platform’s identity, and, like the instructions, every edit is recorded with its author and time. [Image: Description page with a split markdown editor showing source and live preview] [Image: Description page with a split markdown editor showing source and live preview] 07 Keys ### Credentials for the Things That Are Not People Keys mints credentials for programmatic callers: a scheduler, a pipeline, a script, anything that needs the platform without a human at a browser. API Keys #### Scoped, Expiring, and Shown Exactly Once ##### Why it matters A service credential with no scope and no expiry is a credential that outlives the project it was minted for and grants more than that project ever needed. ##### How it works Each key is created with a name, an optional owner and description, its roles chosen from a browser, and an expiration preset from a day out to a year or never. The generated key appears once in a copy-now banner and never again. The table lists every key with its roles, owner, and expiry, dims expired ones with a badge, and revocation takes effect immediately. [Image: API keys table with names, owners, role badges, expiration dates, and an expired key dimmed] [Image: API keys table with names, owners, role badges, expiration dates, and an expired key dimmed] 08 Personas ### Fail-Closed Access, Defined by Role A persona maps the roles your identity provider already issues to exactly the tools and connections that role may reach. It is default-deny: what a persona does not allow is not merely refused, it is never shown to the agent at all. Personas #### What a Role Can Reach, and Nothing Else ##### Why it matters Access defined as a pile of low-level permissions drifts from what the business actually meant, and anything not explicitly denied tends to leak. Roles should get what they need and nothing adjacent to it. ##### How it works A persona carries allow and deny tool patterns, a connection allowlist, a priority, and the identity-provider roles it maps to. Because unauthorized tools are invisible rather than blocked, an agent never spends tokens reasoning about capabilities it cannot use, and access is refused before a request reaches the data layer. Context overrides tune behaviour per role with a description prefix and an agent-instruction suffix, so the same tool can be introduced differently to an analyst and to an engineer. [Image: Persona detail with allow and deny tool patterns, connection allowlist, resolved tools, and context overrides] [Image: Persona detail with allow and deny tool patterns, connection allowlist, resolved tools, and context overrides] Permissions Explorer #### See What the Rule Resolves To Before You Save It ##### Why it matters A pattern that looks right and resolves wrong is the whole risk of pattern-based access. Finding out after the fact means finding out from an incident. ##### How it works The editor puts an identity panel beside a live permissions explorer that previews exactly which tools and connections the current allow and deny patterns resolve to, with a running allowed and denied count and a trace explaining which rule decided each one. Quick templates seed common policies for administrator, read-only, analyst, and engineer shapes, and a separate tab tunes the persona’s assistant behaviour. [Image: Persona editor with an identity panel beside a live permissions explorer showing resolved tools and a rule trace] [Image: Persona editor with an identity panel beside a live permissions explorer showing resolved tools and a rule trace] 09 Prompts ### The Library, From the Other Side The administrative Prompts page manages every prompt at every scope, and it is where a personal prompt someone wrote becomes something their team, or the whole organization, is served. All Scopes #### Global, Persona, Personal, and System in One Table ##### Why it matters Prompt quality drifts where nobody is looking. Seeing every scope in one sortable table is what makes a stale global prompt findable before somebody runs it. ##### How it works A sortable table lists every prompt with a scope badge, a lifecycle badge, its owner, category, and tags, filtered by scope and searched across name and description. Editing exposes the lifecycle selector that moves a prompt from draft to approved to deprecated or superseded, stamping the approving admin; choosing superseded reveals a field for the replacement prompt’s name, so a retired prompt says what took its place. [Image: Admin prompt library with scope badges, lifecycle status badges, owners, and a scope filter] [Image: Admin prompt library with scope badges, lifecycle status badges, owners, and a scope filter] Promotion Queue #### Someone’s Prompt Becomes the Team’s ##### Why it matters The prompts worth standardizing are the ones already being used, and their authors are rarely admins. Without a request path, good work stays personal. ##### How it works A panel at the top of the page lists the personal prompts whose owners have asked for promotion, naming the owner, the scope requested, and the description; it is hidden entirely when nothing is pending. Approve applies the requested scope and marks the prompt approved, reject clears the request and leaves it personal, and a name that already exists at the target scope blocks approval as a conflict so the owner renames first. A prompt an admin creates at a shared scope lands approved with that admin stamped as approver, since the creator is the reviewer. [Image: Prompt create form with a markdown editor, auto-extracted arguments, scope selector, and persona targeting] [Image: Prompt create form with a markdown editor, auto-extracted arguments, scope selector, and persona targeting] 10 Resources ### The Reference Library, Across Every Scope The administrative Resources view is every uploaded file in one place, across every persona and scope, which is what makes curating the library possible rather than aspirational. All Resources #### Find What Nothing Has Read ##### Why it matters A reference library only decays in one direction. Material accumulates, nobody removes anything, and agents start pattern-matching against a template that was replaced a year ago. ##### How it works Scope tabs cover all resources, global, and each persona, with text search and a category filter across them. The table adds a last-read column and a recently-read sort, so the library can be ordered by what is actually used, and a resource never read since it was uploaded over thirty days ago is flagged. An admin can open, edit, and delete any resource, including persona material they do not belong to, while listing and agent-facing reads stay scoped to membership. [Image: Admin resources table with scope tabs, scope badges, categories, uploader, and last-read column] [Image: Admin resources table with scope tabs, scope badges, categories, uploader, and last-read column] 11 Tools ### Every Tool, Typed, Testable, and Attributed Tools is a master-detail view of everything the platform exposes, grouped by the connection that provides it. A tool you cannot inspect is a tool you cannot govern, so each one opens onto its schema, its access rules, an execution surface, and its own usage. Overview #### The Schema and the Rule That Decided Access ##### Why it matters Knowing that a role cannot call a tool is half an answer. The useful half is which rule decided it, because that is the part you can change. ##### How it works The overview shows a tool’s description with an inline override editor, the connection it belongs to, its full JSON input schema, and per-persona access: which personas can call it and the exact pattern that resolved to that verdict. An adjacent activity view aggregates the tool’s own call volume, success rate, and average duration, with a deep link into the audit log filtered to it. [Image: Tool overview with description override, JSON input schema, and per-persona access rules] [Image: Tool overview with description override, JSON input schema, and per-persona access rules] Try It #### Run the Tool Yourself Instead of Asking an Agent To ##### Why it matters Debugging a tool by asking an assistant to call it puts a language model between you and the answer. You want the raw call and the raw response. ##### How it works Try It generates a form from the tool’s schema with type-appropriate inputs, a text area for a query, a number field for a limit, a dropdown for an enum, runs it against the live source, and renders the result as a formatted table with a raw toggle. A timestamped history keeps every test call with its duration and status, and any of them replays. [Image: Tool Try It tab with a generated parameter form, execute action, rendered result, and call history] [Image: Tool Try It tab with a generated parameter form, execute action, rendered result, and call history] Visibility #### Check the Blast Radius Before You Commit ##### Why it matters Turning a tool off platform-wide is the kind of change that is obvious in hindsight and surprising in the moment, because the person making it rarely knows every persona it touches. ##### How it works Visibility toggles a tool’s membership in the platform-wide deny list and previews whether a given persona can still reach it, before the change is applied. [Image: Tool visibility tab with a platform-wide deny toggle and a per-persona access preview] [Image: Tool visibility tab with a platform-wide deny toggle and a per-persona access preview] 12 Users ### A Directory So Sharing Knows Your Colleagues Users is a directory of people, not an authorization layer. It grants nothing on its own; it exists so the share picker can suggest a colleague by name instead of asking somebody to remember an address. Directory #### Suggest the Person Before They Have Signed In ##### Why it matters Sharing fails on the small stuff. A mistyped address sends work to nobody, and a new hire who has not logged in yet cannot be picked at all. ##### How it works Anyone who authenticates is recorded automatically with the name from their sign-in. An admin can pre-add someone by email so they are selectable for sharing before their first login, where they show as invited rather than active. Admin-entered names take precedence: a later sign-in fills blank fields but never overwrites a name someone set deliberately. The table lists name, email, status, and last seen, with search across it. [Image: Users directory with names, emails, active and invited status badges, and last-seen dates] [Image: Users directory with names, emails, active and invited status badges, and last-seen dates] Next ### MCP Security The threat model behind the audit trail: what a governed MCP endpoint has to defend against. [Continue](https://plexara.io/security) --- # Email Notifications URL: https://plexara.io/product/notifications/ > Shares, comments, and mentions reach people in their inbox, on terms each person sets. Your admins can route outbound mail through your own provider. ## Email Notifications Work happens in the portal. Attention happens in an inbox. When a colleague shares something with you, replies in a thread you own, or names you in a comment, Plexara emails you, and you decide what reaches you and how often. Triggers ### Four Things Send Mail Collaboration only closes the loop if it reaches somebody who is not currently looking at the portal. Three of these come from a person doing something; the fourth exists because nobody did. #### A share Someone gives a person access An asset, a collection, or a prompt shared with a named person. The email carries a link to the item and, when the sharer wrote one, a short note from them. #### A comment or reply A thread moves A comment or feedback reply on something you own or something shared with you. The email carries the item, who wrote it, and an excerpt of what was said. #### A mention Someone names you Typing an @ in a comment addresses a person directly. A mention is its own category, so being named reaches you even when you have the general comment traffic turned down. #### A review queue going unworked The one with nobody behind it Captured insights waiting for review age quietly. A scheduled check watches the queue against thresholds your admins set and mails them when it crosses. [Image: The Asset feedback panel open beside a Q4 revenue dashboard, with a New feedback form where the message reads cc @marcus and a suggestion row beneath it offers Marcus Johnson with his address, above Cancel and Post feedback buttons] Typing an @ in a comment offers the people known to the platform; picking one turns the comment into a mention addressed to them. Recipients ### Who Hears About It, and Who Never Does The fastest way to make people ignore a notification system is to email them about their own typing. The rules below are enforced where events are raised rather than in each screen that raises one, so a new trigger inherits them instead of re-implementing them. The people a thread concerns A comment reaches the item’s owner, the thread’s author, and the people it is shared with. That is the general fan-out, and each of them still reads it through their own preferences. Anyone named by hand A person the comment @-mentioned is notified as a mention instead of as part of the fan-out, so one comment never sends the same person two emails. Mentions are queued first, and how much mail one author can generate in a burst is bounded, so on a widely shared item the people addressed by name are the ones who get through. The person who wrote it Never. The author is excluded at the single point every trigger passes through, and the exclusion compares addresses rather than the label in front of them, so an owner recorded as a display name wrapped around an address is still recognised as the author of their own comment. Everyone, when the author cannot be identified An event whose author cannot be resolved sends no general fan-out at all, because it cannot be shown not to be a self-notification. Anyone the comment named explicitly still gets their mention. Someone who has opted out Nothing is sent and nothing is held. Preferences are read before a message is ever queued, so turning a category off means the mail is not written rather than written and suppressed. Your side ### Every Recipient Sets Their Own Terms Settings in the portal carries one control per question. Delivery is immediate, a daily digest, or off, and shares, comments and feedback, and mentions each switch on and off separately. A digest reader gets one message a day summarising the window instead of one message per event. Preferences are keyed to an email address rather than to an account, so they cover people you share with who have never signed in. Someone who cannot reach the Settings page changes their mind from the message itself: every notification carries an unsubscribe link that works without signing in. Directly beneath the preferences sits the list of what was actually sent to you, newest first, with each message’s subject, category, and delivery status. Preferences and receipts answer one question together, which is why they share a screen. See it in place on the [portal tour](https://plexara.io/product/portal). The sharer’s side ### Three Decisions at the Moment You Share #### Share quietly A share addressed to a person notifies them by default, and a toggle in the share dialog turns that off. The share itself is created exactly as it would be otherwise. The recipient’s own preferences still apply when notification is on, so the toggle can remove an email and never force one past somebody who asked not to get it. #### Say why you are sharing it A short note travels in the email as a quoted block attributed to you. It is never stored: it goes with the one message the share produces and lives nowhere afterwards. Markup and links are refused while you are still writing rather than escaped and delivered, because a plausible-looking link inside a trusted email is worth more to an attacker than it is to you. #### Address it to a real person Recipient addresses are accepted the way a mail client puts them on your clipboard, with the display name in front, and only the address itself is stored. A value that names no routable address is refused as the field loses focus, so what you see is what gets stored and mailed. Delivery ### Mail You Do Not Have to Chase Notification systems fail in a particular way: the notification quietly does not arrive, and the thing it was announcing is fine, so nobody notices for a week. Three properties rule that out. #### The share always succeeds Whether an email goes out, and whether it lands, never decides whether the share was created. Nobody waits on mail to get access, and nobody loses access because mail was slow. #### A message keeps trying A send that does not get through is retried rather than dropped, and a message still waiting when the platform restarts is still waiting afterwards. Delivery is a commitment the platform holds, not a single attempt. #### And there is a receipt A message that never went out says so. Nobody has to reconstruct from silence whether an email was sent, held, or never attempted. #### Two views of the same record Each person sees the messages addressed to them on their own Settings page, with the status of each. Admins see every message on the [administration dashboard](https://plexara.io/product/portal/admin): recipient, subject, category, status, attempt count, and, on a failure, the error the mail server returned. The error text is deliberately absent from the personal view, since a recipient can act on none of it and the status alone tells them whether to expect an email. Both are recent history rather than an archive, and both state the window they cover, so an empty list is not mistaken for a quiet week. [Image: The Notifications tab of the admin Dashboard, with Failed, Pending, Sending, and Sent counters, a note that resolved notifications are removed after 30 days, a recipient filter with status and category dropdowns, and a delivery table listing queued time, recipient, subject, category, status, attempts, and sent time] The admin view of delivery: every message, its status, how many attempts it has taken, and the window the list covers stated up top. Where mail goes out from ### Our Mail Server, or Yours Outbound mail leaves through a dedicated mail server Deasil Works operates. That is the arrangement your deployment arrives with, and for most teams it is the arrangement they keep. The mail settings also sit in the portal under Admin, which means an admin on your own team can point delivery at the mail provider your company already uses. Teams do this for a practical reason: mail from a domain your recipients recognise clears filters that mail from an unfamiliar sender does not, and the From address on a share matches the rest of your company’s mail. It is a decision your admins make and change themselves, alongside [the rest of the administrative settings](https://plexara.io/product/portal/admin), with no request to file and no window to wait for. A send test delivers a real message through whatever is currently stored, so a change is confirmed end to end before anybody depends on it. If the address you tested has turned notification email off for themselves, the screen says so beside the action, because a person who receives the test and never a notification is otherwise a long afternoon of troubleshooting. [Image: The admin Settings screen with an Email section at the top, showing an Enabled toggle, the outbound delivery fields, a From address and From name, a Send test email row with a recipient field and Send test button, and a Review queue alert section beneath it with a pending count threshold and an oldest pending age in days] Mail settings live under Admin beside the review queue alert. Save, then send a test to confirm the change end to end. #### No vendor is added to your platform Email delivery is part of the managed Plexara service. It introduces no third-party email vendor, and the product’s subprocessor list stays where it is: at zero. Your deployment runs start to finish on hardware Deasil Works owns and operates, and mail leaves the same way. Should your admins route delivery through your own provider instead, that provider is yours, under your contract, which still adds nothing to Plexara’s side of the arrangement. The analytics and mailing-list services named in this website’s [privacy policy](https://plexara.io/privacy) are vendors of this website. None of them touches the platform your deployment runs, and the newsletter you can subscribe to here has nothing to do with the mail your deployment sends. The [Trust Center](https://plexara.io/trust) keeps the two apart line by line. The message ### Mail That Behaves Like Mail An email your recipients cannot escape is an email their provider learns to filter. Getting the conventions right is what keeps the ones people do want out of the spam folder. #### One-click unsubscribe Every notification carries a working unsubscribe link and the header pair that Gmail and Yahoo require of senders at volume, so a recipient can stop the mail from inside their mail client without opening anything of ours. #### Unsubscribing takes a deliberate second click The link opens a confirmation page with a single button rather than acting on the visit. Corporate mail security scans the links in a message before a person ever sees them, and a link that acted on being fetched would opt people out who never touched it. #### Links that go to the thing itself Each message deep-links to the shared or discussed item and to your own notification preferences, and identifies itself with a proper Message-ID so replies and duplicates thread correctly in your recipients’ mail clients. #### A footer that says who sent it Legal links and a support contact ride in the footer of every message, in both the formatted and plain-text parts, so a first-contact recipient can tell what they have received and from whom. #### Sharing with someone who has no account A share addressed to someone outside the portal lands them on a page for that one item, where they can request a single-use view link sent to the same address the share names. It opens that item, read only, for a few minutes. Forwarding the original message grants nothing, because the link in it is not a credential and the viewer resolves it only for the person the share was addressed to. Revoking the share ends the guest’s access immediately. Opting out of notifications does not strand anyone. A view link is transactional: the recipient pressed a button to ask for it, so it still sends. And a recipient who turned email off and later regrets it finds a way back on the same landing page, without a support request. Operator alerts ### Pending Knowledge Stops Aging Silently An unworked review queue is the one failure in the [knowledge pipeline](https://plexara.io/product/knowledge-application) that breaks nothing. Captures keep arriving, agents keep answering, and none of what was learned becomes shared knowledge. The count has always been visible to anyone who goes looking. This is the signal for everyone who does not. A scheduled check compares the pending queue against two thresholds your admins set: how many insights waiting is too many, and how old the oldest one is allowed to get. Either one alone is enough to trigger the alert, and an empty queue never does. #### What the alert says The pending count, the age of the oldest insight waiting, how many have gone stale, and a link that opens the review queue rather than the section it lives in. The figures are the queue as the check saw it, so an alert read hours later still reports what actually crossed the line. #### A reminder, not a flood A queue that stays over the line produces one alert per cooldown window rather than one per check, and your admins choose that window. A queue worked back under the line resets it, so the next crossing is announced immediately instead of serving out a wait that belongs to a problem somebody already dealt with. #### A named list, not a role Recipients are the addresses your admins list, so it goes to the people who actually work the queue. Removing an address there is how you stop sending it, and any recipient can still opt themselves out from the message. Next ### Integrations Trino, DataHub, S3, and MCP client compatibility through a single endpoint. [Continue](https://plexara.io/product/integrations) --- # Integrations URL: https://plexara.io/product/integrations/ > Trino federation across 40+ connectors, DataHub catalog operations, S3 object storage, and MCP client compatibility through a single governed endpoint. ## Integrations Plexara composes three open-source systems through provider abstractions, enabling multi-source data federation, cross-platform catalog coverage, and universal object storage access through a single MCP endpoint. Query Engine ### Trino Federation A single query can join a PostgreSQL table with an Elasticsearch index, an Iceberg lakehouse, and a Cassandra cluster. Trino does not require data to be moved, copied, or transformed. It queries data where it lives. Multi-connection support lets you configure separate Trino clusters and route tool calls to specific connections via the connection parameter. Read-only enforcement, query timeouts, and configurable row limits keep production systems safe. 40+ supported connectors including PostgreSQL MySQL MariaDB SQL Server Oracle Elasticsearch OpenSearch Cassandra MongoDB Redis Iceberg Delta Lake Hive Hudi Google Sheets Kafka Kinesis Pinot Druid ClickHouse BigQuery Redshift Snowflake [Image: The New Connection form in the Connections admin screen, with the kind set to trino, an identifier field, a split markdown description editor with an empty preview, and a Configuration card holding the connection details and a default catalog and schema, with Cancel and Create buttons] Adding a Trino connection: pick the kind, name it, describe what it is for, and point it at the cluster. [Image: The edit form for an existing Trino connection named acme-warehouse, with the kind and identifier locked, a description reading production data warehouse with retail, inventory, and analytics schemas shown in source and preview, and the Configuration card below with a Save button] Editing keeps the kind and identifier fixed, since persona patterns and tool routes refer to them, and lets everything else change. Metadata Catalog ### DataHub Integration Full catalog operations across datasets, dashboards, charts, data flows, data jobs, containers, data products, domains, glossary terms, and glossary nodes. #### Search Advanced filters by column names, tags, glossary terms, platform, domain, and owner. #### Metadata Entity details, schema with column descriptions, structured properties, data contracts. #### Lineage Dataset and column-level lineage traversal. Upstream and downstream graph exploration. #### Glossary Business term definitions, glossary node hierarchy, term-to-entity mappings. #### Write Ops Create, update, and delete entities. Manage descriptions, tags, glossary terms, incidents. #### Data Products Business-oriented groupings of related datasets for specific use cases and audiences. [Image: The Connections admin screen with connections grouped by kind in a left column, DataHub, MCP, S3, and Trino, and a DataHub catalog connection selected on the right showing its description, kind, creator, last updated time, and Edit and delete buttons] Every connection your deployment has, grouped by kind, with the DataHub catalog connection open. Each one lists how many tools it exposes. Object Storage ### S3 Integration Bucket browsing, object listing with prefix filtering, content retrieval, metadata inspection, and presigned URLs for temporary access. Prefix ACLs restrict access to specific S3 paths. Read-only mode blocks write operations. Size limits protect against oversized transfers: 10MB for GET operations, 100MB for PUT. All storage operations are subject to the same persona-based access controls and audit logging as query and catalog operations. List Buckets Browse available storage buckets List Objects Explore objects with prefix filtering Get Object Retrieve content up to 10MB Get Metadata Inspect object metadata and properties Presigned URLs Generate temporary download and upload links Put / Copy / Delete Write operations with configurable controls External APIs ### Connect external REST APIs Federation is not limited to your data. The API gateway connects Plexara to any external REST or HTTP API, from Salesforce and Stripe to your own internal services, and lets the assistant search and call their operations directly. Each API is described once and shared across connections, Plexara handles the sign-in, and access is limited by role, so those calls are governed and logged on the same endpoint as Trino, DataHub, and S3. [Explore the API Gateway](https://plexara.io/product/api-gateway) OAuth 2.1 API key Bearer token Basic auth mTLS certificates Static headers Compatibility ### Any MCP Client Plexara works with any MCP-compatible client. Agents reach it over the standard remote MCP transport, with nothing to install and no local process to run. Multiple Trino clusters, DataHub instances, and S3 endpoints sit behind that one endpoint, selected per call through the connection parameter. #### Claude Desktop Anthropic's desktop application with native MCP support #### Cursor AI-powered code editor with MCP tool integration #### Custom Agents Build with the MCP SDK in Python, TypeScript, Go, or any supported language Next ### API Gateway The same governed connection, pointed at Salesforce, Stripe, and your own internal services. [Continue](https://plexara.io/product/api-gateway) --- # API Gateway URL: https://plexara.io/product/api-gateway/ > Connect any REST or HTTP API to Plexara and let your AI assistant search and call it directly. One secure connection that handles sign-in, limits access by role, and logs every call. ## API Gateway Your company runs on dozens of software services: Salesforce, Stripe, internal tools, and more. Each one has an API. Plexara connects to those APIs and lets your AI assistant use them directly, through the same secure, logged connection as your databases, with no custom integration to build for each one. Connecting your APIs ### Connect an API once, and the assistant can use it Point Plexara at an API and it reads the documentation that API publishes to learn what it can do. From then on your AI assistant can call it, to look up a customer, create an invoice, or pull a report, right alongside everything else it does in Plexara. Connecting more APIs does not slow anything down. However many you add, and however many operations each one has, the assistant works the same way: it sees what is available, looks up the details of the one operation it needs, and makes the call. Ten APIs with a thousand operations between them stay as simple to use as one. When it makes the call, it asks for the operation by the name the API itself gave it, and Plexara works out the exact address from the documentation. Nobody assembles a web address by hand, so a customer number with a space or a slash in it cannot quietly turn into the wrong request. Salesforce, Stripe, GitHub Connect the services your team already uses Your internal services Any REST or HTTP API you run in-house No integration to build Plexara reads the documentation each API publishes One secure connection Sign-in handled, access limited by role, every call logged [Image: The API Catalogs admin screen with a list of catalogs on the left and a Salesforce REST API catalog open on the right, showing its version, how many connections reference it, a description, and a Component specs table where each spec reports its source, how many operations are indexed, and when it was fetched] An API catalog is the documentation Plexara read, with each component spec showing how many operations it indexed and a note that semantic ranking is active. Finding the right call ### The assistant finds the right operation on its own A single API can have hundreds of operations. Rather than someone picking and setting up each one in advance, the assistant searches the API for what you are trying to do and finds the operation that fits. #### Search by what you mean Ask for the operation that creates an invoice and the assistant finds it, even when the API names it something you would not guess. It matches on meaning, not exact words. #### Describe an API once The documentation for an API is stored once and shared, so a test account and a live account can use the same description. When a vendor changes their API, you update it in one place instead of everywhere it is used. #### Big APIs stay manageable Large services like Google Workspace group their operations into sections such as Drive, Calendar, and Gmail. The assistant looks at the sections first and opens only the one it needs, so a huge API never overwhelms it. #### Save what an API returns A response from an API can be saved into Plexara as a report or file you can share and come back to, instead of disappearing when the chat ends. #### Follow a one-time download link Many services answer a large request with a temporary link rather than the file itself. Plexara follows that link and saves what comes back into your library, so a report you asked for arrives finished instead of stopping at a link that expires before anyone opens it. [Image: The New API Catalog form in the API Catalogs admin screen, with fields for catalog name, version, internal slug, catalog ID, and description, each followed by a short explanation, and Cancel and Create buttons] Describing an API starts with a name and a version; the slug groups versions of the same API together so a vendor update lands in one place. [Image: The Add component spec dialog, with a spec name field, Paste, Upload, and URL tabs for supplying the API documentation, a text area holding the start of an OpenAPI document, an optional base path, an optional title, and Cancel and Save buttons] A large API is added as named component specs, which is how sections like Drive or Gmail stay separate for the assistant to open one at a time. Signing in ### It signs in to each API for you Every API checks who is calling in its own way. Plexara stores the login for each one and signs in on your behalf, so the assistant never sees the credential. It supports the methods APIs actually use: #### OAuth sign-in The sign-in used by services like Google and Salesforce. Someone signs in once, and Plexara keeps the connection working after that. #### Stays signed in Logins that expire are renewed before they run out, so a connection keeps working without anyone signing in again. #### API keys A single secret key or token. The simplest method, and the one many services use. #### Username and password For older or internal systems that still sign in with a username and password. #### Client certificates Certificate-based sign-in for internal and high-security systems that require it. #### Extra requirements Some APIs need a second credential or a private security certificate on top of the login. Plexara handles those as well. Automation and scripts ### Reach the same APIs from your automation tools The same connected APIs are open to software that is not an AI assistant: an automation tool like Apache NiFi or n8n, a scheduled job, or a simple script. Each one calls Plexara instead of the API directly, and gets the same sign-in handling, role limits, and logging. Because Plexara holds the credentials, your automation never has to store them, and every call is recorded in one place. Call a connected API from a script ``` curl -X POST \ https://api.plexara.io/api/v1/gateway/vendor/invoke \ -H "X-API-Key: $PLEXARA_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "method": "GET", "path": "/v1/things", "query_params": { "limit": 50 } }' ``` Plexara signs the request with the login it stores for that API. The script never sees the credential, and the call is checked against the caller role and added to the log. Security and control ### Every call follows your rules Reaching a lot of APIs is only useful if every call is safe. Each request goes through the same checks as the rest of Plexara. #### Access by role People and agents reach only the APIs their role allows, down to individual operations, so a role can read from an API without being able to change anything in it. #### Everything is logged Every API call is recorded with who made it and when, in the same log as your queries and catalog edits. #### Steady under load Large responses are saved to storage instead of held in memory, and a slow API returns a clear signal instead of holding everything up. [Image: The API Gateway tab of the admin Dashboard, with a time range selector, counters for inbound requests, outbound calls, outbound error rate, and upstream 5xx responses, a Status Mix area chart of requests per second by class, and a Usage Rhythm heatmap of requests by weekday and hour] Every API call the assistant makes shows up here, so your admins can see volume, error rate, and when the traffic happens. [See the developer tools and REST API](https://plexara.io/developers) Next ### Developer Hub The MCP and REST surfaces your engineers build against, with the test utilities and the full API reference. [Continue](https://plexara.io/developers) --- # MCP Gateway URL: https://plexara.io/product/mcp-gateway/ > Connect any MCP server to Plexara and its tools join your assistant's toolkit under one endpoint: persona rules, server-side credentials, cross-enrichment with your warehouse, and a single audit log. ## MCP Gateway MCP servers are arriving from every direction: vendors ship them, internal teams build them, partners expose them. Each one wired straight into an AI assistant is another endpoint to secure, another credential to manage, another log to check. Plexara connects to those servers for you and serves their tools through the same governed connection as your data: one endpoint, one identity, one audit log. One envelope ### Connect an MCP server once, govern it like everything else An admin adds an MCP server in the portal by its address, picks how it signs in, and saves. Plexara reads the server's tool catalog and registers every tool under a name that carries the connection, so a vendor's get_contact becomes crm__get_contact, sitting beside your warehouse queries and catalog lookups in the same tool list. From your assistant's side nothing new appears to configure. It discovers proxied tools the way it discovers native ones, calls them through the same connection, and every call passes the same persona check and lands in the same audit log. The vendor server never learns who your individual users are; it sees one service identity per connection, while per-person attribution stays in your audit trail. Before a connection is saved, a test dials the server and reports the tools it would add. After a vendor ships new tools, one refresh re-reads the catalog. The connections screen shows each server's reachability continuously. One endpoint Your assistant connects to Plexara; Plexara connects to the rest Named tools Every proxied tool carries its connection name, like crm__get_contact Same persona rules Allow and deny proxied tools with the same patterns as native ones Same audit log Every proxied call recorded with who, what, and how long [Image: The Connections admin screen listing DataHub, MCP, S3, and Trino connections, with a gateway-proxied CRM MCP server showing a live reachable badge and its tool count] One roster for every connection kind. The MCP section lists each connected server with its live reachability and the number of tools it contributes. Credentials ### The connection signs in, not every user Each connection authenticates to its upstream server with one service credential, managed by your admins in the portal. Users never handle vendor secrets, and vendor secrets never travel through an AI conversation. Four sign-in modes cover the servers in the wild: #### No credential For servers that are open inside your network or public by design. The connection is still persona-gated and audited on the Plexara side. #### Bearer token A token the admin pastes once. It is stored encrypted, sent only server-side, and never appears in a prompt, a session, or a client. #### API key Same handling as a bearer token, delivered in the header the vendor expects. Editing a connection later never requires re-entering the secret. #### OAuth 2.1 For machine-to-machine grants, tokens are fetched and refreshed automatically. For services that require a browser sign-in, the admin clicks Connect, signs in once, and refresh tokens keep the connection alive after that, including for scheduled prompts that run overnight. Salesforce's hosted MCP server is the worked example: it requires the browser sign-in flow. An admin connects it once from the portal, and from then on its tools are available to any persona that allows them. Cross-enrichment ### Vendor answers, joined to your warehouse A vendor tool answers with vendor data, and vendor data alone rarely settles a business question. The gateway can attach context from your own sources to a proxied tool's response: a warehouse lookup keyed by a value in the answer, or catalog context for an entity it names. Admins define these as rules in the portal, per tool, with no code involved. The original response is never altered; the added context arrives alongside it, so the assistant sees both. A rule that fails attaches a warning instead of breaking the call, and a dry-run in the rule editor shows exactly what a rule would fetch and merge before it goes live. enrichment rule · connection crm When crm__get_contact returns a response containing an email address Fetch lifetime value and last order date for that email, from your warehouse Merge the result lands beside the vendor answer as warehouse_signals [Image: The Enrichment tab of a gateway-proxied CRM tool in the Tools admin screen, showing an enabled rule that attaches catalog owners, glossary terms, and deprecation warnings to each returned account] A live rule on a proxied CRM tool: every account the vendor returns comes back carrying catalog owners, glossary terms, and deprecation warnings from your own metadata. Operations ### Built for imperfect upstreams A third-party server will eventually be slow, stale, or down, and none of that should take your assistant with it. Persona rules decide who can call what, with the connection prefix making a whole vendor easy to scope: allow crm__list_* allow crm__send_* deny crm__delete_* The upstream The gateway Where you see it The upstream #### A server is unreachable when connected The gateway The rest of the platform is unaffected. The connection registers no tools until the server is back and refreshed. Where you see it A reachability badge on the connections screen, and a recorded warning. The upstream #### A server fails mid-call The gateway The error your assistant receives names the connection, so it can route around the outage or say what is down. Where you see it The failed call in the audit log, with the same detail as a success. The upstream #### A vendor changes its tool catalog The gateway One refresh re-reads the catalog and updates the tool list. A test before saving shows what a connection would add. Where you see it The updated tool roster under the connection, each tool inspectable. The upstream #### A server speaks an older MCP revision The gateway Plexara negotiates with each side separately and translates between them, so an aging server stays usable from the newest clients. Where you see it Nothing. The difference never reaches your assistant. [Image: The MCP tab of the admin dashboard showing total calls, success rate, average duration, unique users and tools, enrichment coverage, errors, an activity chart, and a usage-rhythm heatmap] The MCP tab of the admin dashboard: call volume, success rate, latency, enrichment coverage, and a usage rhythm across the week, for native and proxied tools alike. How this differs ### Plexara vs MCP Gateways A standalone gateway governs traffic. See what changes when the platform behind the endpoint also owns your data, context, and memory. [Continue](https://plexara.io/compare/mcp-gateways) --- # Spreadsheets as Tables URL: https://plexara.io/product/spreadsheets/ > Upload a CSV to Plexara, register it as a table in one step, and your AI assistant joins it against the warehouse with SQL. Nothing is copied, staleness is flagged, and every registration is audited. ## Spreadsheets as Tables Business runs on spreadsheets: vendor price lists, lease schedules, target lists, exports from tools nobody integrated. Upload one to Plexara, register it as a table, and your AI assistant joins it against the rest of your data with SQL. No pipeline, no ticket to data engineering, no copy of the file to keep in sync. From file to table ### From spreadsheet to SQL, without a load step A spreadsheet becomes useful when it is joined against the data you already have. Rebates against sales. Lease costs against revenue. A target list against the customer table. Getting the file somewhere joinable used to mean a request to data engineering and a loader somebody has to own, so for a file needed once, it rarely happened at all. Registering skips all of that. Plexara reads the file, takes column names from its header row, and creates a table that reads the file exactly where it is stored. The table lives in a scratch schema set aside for working data, beside your warehouse in the same SQL surface, ready for your assistant and your analysts alike. It matters just as much for the files your assistant creates. An export it saves, or a dataset it assembles from API calls, is already stored in Plexara; registering makes it joinable, so the work an agent did yesterday becomes a table the whole team queries today. Nothing is copied The table reads the file where it already sits One step A button in the portal, or a single call by your assistant Any size 300 rows or 300,000 query exactly the same way Both directions Files people upload, and files your assistant builds and saves [Image: A CSV asset open in the Plexara portal with its Query as a table panel showing the registered table's name, connection, columns, and who registered it] Every CSV in Plexara carries a Query as a table panel: the table it is registered as, the columns that came from its header, and who registered it. How it works ### Upload, register, join Files already reach Plexara as uploads and saved assets. Registering is the one new step, and it turns any of them into a table. 1. 1 #### A file lands Someone uploads a CSV to the resource library, or your assistant saves one it built as an asset. Either way the file gets versions, an owner, and a place the whole team can find it. 2. 2 #### Register it Pick a connection and, if you like, a name. Plexara reads the header, creates the table over the file where it sits, and answers with the columns. Your assistant does the same thing with a single call. 3. 3 #### Join it by name The table sits beside your warehouse in the same SQL. Columns arrive as text, so a join to a numeric key uses a cast, and the registration answer includes a sample statement showing exactly that. [Image: The register form on a CSV resource in the Plexara portal, with a connection picker, an optional table name, and an explanation that the schema is shared] Registering from the portal: pick the connection, optionally name the table, and the form explains where the table is created and how names are claimed. Lifecycle ### How the table tracks the file A table over a living file raises two questions: is it current, and can the file be read the way it is stored? The ledger below covers every state, and once a file is registered, its search result carries the table name and a sample join. The file The table Where you see it The file #### Overwritten in place The table The next query reads the new content. A recurring vendor drop stays current with no re-registration. Where you see it No flag; the table was never behind. The file #### Gains a version through an edit or revision The table Keeps serving the version it was registered against. Registering again moves it forward in one step. Where you see it A stale flag on the portal panel, the file's search hit, and the assistant's own listing. The file #### Cannot be read as stored The table No table is created and nothing is recorded. Line breaks inside cells, old Mac line endings, and wrong encodings would otherwise become rows made of fragments. Where you see it The refusal names the specific problem and offers a correction where one can be made mechanically. The file #### Corrected by that one control The table The repaired content is written as a new version of the file, and the table is registered over it. Where you see it The version history says what changed and why; the original upload stays as the version before. The file #### Unregistered The table The table is dropped. The file is untouched, byte for byte. Where you see it The panel no longer lists it; the audit record of the registration remains. The file #### Deleted The table Every table registered over it is dropped, whoever registered them. Where you see it Nothing keeps serving data whose source is gone. [Image: A registered table panel on a CSV resource showing a warning that the file has a newer version than the table points at] The stale flag in place: the file gained a version, the table still serves the older one, and the panel says so with the fix one control away. [Image: A registered table panel after a correction, reporting the repaired file registered and what the correction changed] A correction taken: the file has a new, readable version, the table is registered over it, and the panel reports exactly what changed in the file. Governance ### A shared workspace with clear ownership The scratch schema is shared on purpose: a table one analyst registers is a table the whole team can query. What keeps that safe is the same identity, authority, and audit model as every other Plexara surface, stated here as the four rules the platform enforces. 01 #### Every registration is audited Who registered what, on which connection, and the statement that ran, recorded for every registration and unregistration, including the attempts that were refused. 02 #### Names carry the persona Table names are prefixed with the registering persona, so a shared workspace stays legible: anyone reading the schema can see whose working table they are looking at. 03 #### Registering takes real authority A registered table is readable by everyone granted the connection, so registering a file requires the authority to change it, not merely to read it. Nobody widens an audience by accident. 04 #### Names are claimed, not overwritten The person who registered a table is the one who can drop it, along with administrators. Names are claimed on registration, and a name someone else holds is refused rather than overwritten. Where agent-built files come from ### API Gateway Your assistant can pull from any connected API, save the result as a file, and register it. See what it can reach. [Continue](https://plexara.io/product/api-gateway) --- # Automations URL: https://plexara.io/product/automations/ > Your agent writes a script once; Plexara runs it on demand or on a schedule. Reports, exports, and dashboard refreshes keep arriving with no agent in the loop, no token spend, and every run recorded. ## Automations You spend an hour with your AI assistant getting the sales report exactly right. That hour should not repeat next month. Your assistant saves the finished logic as a script, and Plexara runs it: on demand, from the portal, or on a schedule, with no assistant in the loop and nothing spent from your AI subscription. From conversation to automation ### Solved logic should not need a conversation to run again Working a report out is a conversation: which tables, which joins, which baseline, how to treat returns. Running it again is not. Once the logic is settled, re-deriving it through a model every week costs tokens, takes minutes instead of seconds, and can come back slightly different each time. A Plexara automation is that settled logic, saved. Your assistant writes it as a small script, checks it, and saves it to the platform. From then on Plexara executes it, exactly as written, every time: the queries run in the warehouse, the output lands in the portal as a new version of the same report, and the run is recorded down to the statements it issued. Ask for it by name in any session, press Run on its portal page, or put it on a schedule. The same run happens all three ways; the only difference is the label recording who asked. Zero tokens per run Plexara executes the script itself; no model, no context window, no subscription usage A dialect of Python Your assistant already writes it, and your team can read every line in the portal Up to once a minute Schedules run in your timezone, as a cadence stated in words, not a cron expression Every run recorded Trigger, duration, queries, outputs, and the printed log, kept for a year [Image: The Scripts page in the Plexara portal listing automations with their schedules, next fires, and how each one's last run ended] The Scripts page: every automation you own, its schedule stated in words, its next fire, and how its last run ended. The Failing tile narrows the list to what needs attention. How it works ### Solve it once, run it forever The expensive part of any recurring report is the thinking, and the thinking is already done by the time the report is right. Automations split the two: the conversation stays interactive, the repetition moves to the platform. 1. 1 #### Work it out with your assistant The interactive session is where judgment happens: finding the right tables, agreeing on definitions, correcting the first draft. This part is worth the tokens, and it happens once. 2. 2 #### The assistant saves it as a script It validates the code, dry-runs it against real data with nothing persisted, and saves. The saved version is what runs, under the access its author held at the save, never more. 3. 3 #### Plexara runs it On demand from any session, from the Run button on its portal page, or on a schedule in your timezone. Runs execute on the platform, so nothing depends on an agent being connected. 4. 4 #### The output keeps its identity Each run writes a new version of the same report or data feed rather than a new file every morning. A year of runs is one asset with a year of history, shares intact. [Image: A script open in the Plexara portal editor with Python-dialect highlighting and Run and Dry run controls above the source] The source, in the portal, on the script's own page. Run executes the saved version; Dry run executes what is on screen, as you, with nothing persisted. Dashboards ### Data pushed in, not access handed out A live dashboard usually means giving a BI tool a standing connection into your database. Plexara inverts that. The dashboard is a document your assistant builds once, with one marked data region; a scheduled script queries the warehouse and pushes fresh numbers into that region. The presentation never touches a database, and the schedule decides how fresh the numbers are. Aspect Dashboard with live database access Dashboard fed by a Plexara script #### Database access Live database access The dashboard holds a live connection, so its credentials, its host, and everyone it is shared with become part of your attack surface. Fed by a script The dashboard holds none. A script pushes fresh numbers into it on a schedule; the page itself can query nothing. #### Load on the warehouse Live database access Every viewer is a query. A dashboard on a wall refreshing for an audience multiplies load at exactly the busy hours. Fed by a script One run per refresh, however many people look. The queries ran once, on the platform, when the script fired. #### Freshness Live database access As fresh as the last time someone accepted the query cost. Fed by a script As fresh as the schedule, down to a run every minute where the numbers warrant it. #### What an old view shows Live database access Whatever the query returns today; the dashboard as it stood last quarter is gone. Fed by a script Every refresh is a version of the asset. The dashboard as it stood on any past run is still there, showing exactly the data it showed. #### Editing the presentation Live database access A BI-tool skill, in a BI-tool license. Fed by a script The dashboard is a document in the portal. Change a heading or a chart color like any other edit; the schedule keeps refreshing only the numbers. Control ### Nobody has to code, and the code is right there Your assistant writes the script; the portal is where you hold it. Its page shows the schedule in words, what the script says about itself as a rendered document, the source with Python-dialect highlighting, and the run history directly under the code, so an error in the history is answered by the text above it. The schedule asks for a cadence the way you have it in your head: weekdays, a time, a timezone. It shows the expression it derives rather than asking you to write one, and a report keeps its wall clock across a daylight-saving change. Pausing is its own control, and a paused schedule says so instead of showing a next fire that will not happen. Anyone who does want the code can edit it in place. A save that does not parse is refused at the keyboard, naming what to fix, and every version keeps its author, so the history says who changed the report and when. Validate and Dry run sit beside the editor: one reports what the code would reach, the other executes it as you, with tighter limits and nothing persisted. [Image: A script's portal page showing its details, schedule stated in words, and the parameters a run binds] One script's page: who owns it, which version runs, when it fires next, and the parameters a run binds, the same facts your assistant sees. [Image: A dry run in the Plexara portal reporting the log a script printed and the measured shape of the outputs it would have written] A dry run executes the code on screen as you: real queries, tighter limits, outputs measured instead of written, and the printed log in full. Governance ### Unattended work under the same rules as attended work Automation is where most platforms quietly loosen their governance: a service account here, an embedded credential there. Plexara runs scripts through the same authorization, the same personas, and the same audit log as every interactive call. Four rules make that concrete. 01 #### A script never exceeds its author A run presents the roles its author held when the version was saved, and every call it makes is authorized at that moment, exactly as if the author had typed it. Unattended never means unaccountable. 02 #### No credentials in the source Scripts name connections; Plexara holds the credentials and authorizes each call. A pasted key or token blocks the save before anything is stored. 03 #### The language cannot reach out The scripting dialect has no network, no filesystem, and no clock of its own. Everything a script does is a governed platform call, audited under the script’s own identity, so its reach is readable before it runs and its record is complete after. 04 #### Failures are loud, never repeated A failed scheduled run emails its owner with the reason and the log. The same inputs fail the same way, so failed runs are never blindly retried; a fire that arrives while the last run is still going is recorded as skipped rather than silently dropped. Where the output lands ### Portal Tour Reports, dashboards, and run histories live in the portal your team already works in. Walk through it section by section. [Continue](https://plexara.io/product/portal) --- # Changelog URL: https://plexara.io/product/changelog/ > A weekly, plain-language record of new capabilities and improvements in the fully managed Plexara platform. Newest first. ## What is new in Plexara A weekly, plain-language record of the capabilities and improvements landing in your platform. Newest first. [Start at the beginning: the Plexara history](https://plexara.io/history) Fully managed, always current Plexara is a fully hosted and managed service. Upgrades, infrastructure, and routine maintenance happen automatically behind the scenes, so there is nothing for your team to install or patch. This log covers only the changes you can see and use: new capabilities, portal improvements, and platform changes that affect how your teams work. [Image: The Change Log admin screen, described as an audit trail of all configuration changes, listing one row per change with the setting that changed, a Deleted badge, the admin who made it, and the date and time] Your deployment keeps a changelog of its own. The Change Log under Admin records every setting your team changes, who changed it, and when. This page is the other kind: what Deasil shipped to the platform. 1. September 6, 2026 v1.130.5 ### Fewer tools, scripts that keep state, and folders in the resource library Agent Efficiency Portal & UX Security & Governance Sixteen tools were replaced by four, and the orientation your assistant reads at the start of a session no longer carries the whole prompt library. Scripts keep a record of where they got to from one run to the next, so a nightly job that missed a run covers the gap on its next one. A table registered over a spreadsheet updates when the spreadsheet is replaced. Uploaded files are filed in folders, shown with thumbnails, and list every script, session, and person that has written them. - Sixteen tools replaced by four, and a shorter start to every session Sixteen tools were retired and replaced by four. Everything the catalog holds about a table now comes back from the single call that resolves a reference: the business context, the schema with field types, nullability and keys, the saved queries, the linked documents, whether the table is queryable right now, and a list naming any part the catalog could not serve. A glossary term returns its parent node and owners; a data product returns its domain, owners, and member datasets, with anything outside your reach counted rather than shown. Storage is two tools, one that lists and one that acts on an object. Connected APIs are reached through one call that answers at the depth the question asks, the specs, the operations, or one operation's parameters and responses, with every answer naming the argument that goes a level deeper. The orientation delivered at the start of every session stopped carrying the whole prompt library, which on a library of forty prompts was most of a response some clients refused outright. It now carries one line per capability, naming the tool to start with and what to decide before using it, and points at the built-in knowledge pages that cover each one in full. - [Lesson Discovery: one search, then fetch](https://plexara.io/learning/mcp/discovery-search-and-fetch) - [Insight Why more tools won't make your agent smarter](https://plexara.io/learning/insights/why-more-tools-wont-make-your-agent-smarter) - [Product API Gateway](https://plexara.io/product/api-gateway) - Oversized API responses are cut and exported, and API search returns only matches An API response too large to read in a conversation is now cut at a stated budget rather than delivered whole: the reply says it was cut, reports the true size of what the API returned, and carries the call that streams the same response into a saved asset instead, in the form you already used. Every response reports its size whether it was cut or not, and a paginated API is walked to the end inside a single call rather than a call per page. Ranked discovery over an API catalog was returning the whole catalog in relevance order, so a question about three operations came back with fifty and nothing said where the matches ended. A ranked result now stops at the matches: every operation that matched the words, then at most a handful of near neighbors by intent that clear a relevance floor, each row carrying its score and whether it matched literally. A question the catalog does not answer returns nothing rather than the head of the list. - [Insight Token efficiency in enterprise MCP deployments](https://plexara.io/learning/insights/token-efficiency-in-enterprise-mcp) - [Insight Search the capability, not the manual: how Plexara keeps a wide platform light](https://plexara.io/learning/insights/search-the-capability-not-the-manual) - [Product API Gateway](https://plexara.io/product/api-gateway) - Scripts keep state between runs, and can be handed to a new owner A script now keeps one record of where it got to, which the next run reads and the finished run replaces. A nightly sync reads the mark it left, pulls from there to now, and saves a new one, so a fire missed to an outage is covered by the next run instead of by somebody backfilling windows by hand. The script's page shows the current value, its revision, and who wrote it, with the controls to replace or clear it, and two runs that read the same value cannot both write: the second is told who wrote in between, and its outputs stand. A run that reaches a rate limit is paced rather than failed, with each wait written to the run log, and a scheduled fire that arrives at the limit is queued instead of refused. Handing a script to a new owner states what happens to the reports and collections its runs created and moves them when you ask, naming each file the new owner would not be able to open if they stay. Deleting a script from its page accounts for what went with it, and every version keeps the name of whoever wrote it, so authorship outlives the transfer. - [Product Automations](https://plexara.io/product/automations) - [Lesson What a run may do, and the record it leaves](https://plexara.io/learning/automations/what-a-run-may-do) - [Lesson Running it: by hand, from the portal, and on a schedule](https://plexara.io/learning/automations/running-by-hand-from-the-portal-and-on-a-schedule) - A registered table updates when its file is replaced A table registered over a CSV used to pin the version it was registered against, so the first refresh of the file left the table serving the old rows while the refresh reported success. A registration follows its file now: the write that produces a new version moves the table onto it before returning, with the columns re-read from the new header and the change recorded against the registration. Pinning to one version is a choice on the register form for the cases that want it. A follow that cannot be completed puts the previous table back, records why, and the listing shows the table as behind its file with that reason rather than serving old rows quietly. Every writer that produces a new version, a person uploading a revision, an assistant editing an asset, a script refreshing an export, reports the tables over that file in its result, and opening the file names every table registered over it rather than only the most recent one. - [Product Spreadsheets as Tables](https://plexara.io/product/spreadsheets) - [Lesson Next month’s file](https://plexara.io/learning/spreadsheets/next-months-file) - [Lesson Uploading a file and registering it as a table](https://plexara.io/learning/spreadsheets/uploading-and-registering-a-file) - Folders, thumbnails, and a write history in the resource library Uploaded files are filed under a folder path inside their library, and the library is browsed as a tree: each folder carries an exact count of everything beneath it at any depth, and each level has an address you can link to, reload, or step out of one level at a time. Search still spans the whole library rather than the folder you are standing in, and each hit names the folder it was found in with a control that reveals it there. Files draw as tiles or as rows and the choice is remembered, with each tile a captured picture of the file rather than the file itself, so a library of documents no longer reads as a column of identical file-type icons. A library opens on the ten files that changed last, each naming its folder. Several files can be moved, tagged, or deleted in one action with the result reported per file, and renaming or nesting a folder rewrites every path beneath it in one step, each file recording the address it left so a citation written against the old path keeps resolving. A file can be moved to another library from its edit dialog instead of being uploaded a second time. And every resource lists what has written it, each script, session, and person that created or changed the file, most recent first, so a script that rewrites a file somebody else uploaded leaves a trace, and renaming that script does not sever it. - [Lesson Resources: the company files the agent should use, not reinvent](https://plexara.io/learning/mcp/mcp-resources-templates-and-examples) - [Product Portal Tour](https://plexara.io/product/portal) - Agent instructions can be promoted from an approved claim and rolled back The rules every assistant on your deployment works under are now written the way the rest of your knowledge is. An approved claim can be promoted into those rules as a section addressed by its heading: promoting the same section again rewrites that section and leaves the rest of the document byte for byte as it was, the change is recorded as a changeset, and rolling it back restores what was there. A rule long enough to be a document of its own lands on a knowledge page instead, with the section keeping one entry pointing at it, and both halves roll back together. A rule naming a tool the platform does not have is refused as it is written rather than discovered later by an assistant that cannot follow it, and the Agent Instructions screen reports the size of what you have written against the limit it is held to. Alongside that, a citation pointing at a catalog record that carries nothing beyond its own reference stops resolving as a hit, and the catalog answers for a record it holds whether or not anyone has documented it. - [Product Knowledge Capture & Application](https://plexara.io/product/knowledge-application) - [Lesson Knowledge: from a memory to something the whole team can use](https://plexara.io/learning/mcp/knowledge-from-memory-to-insights) - Automated calls stay in the audit log but out of the call catalog The catalog of calls exists so the next person can find the query that already answered a question, and automated work was crowding it out: a pipeline fetching through the same tools people use writes a record per fetch that nobody will ever re-run. Calls made by a managed script's run, and by the accounts that drive ingestion, are recorded in the audit trail exactly as before and kept out of that catalog. Records written before the distinction was drawn are cleared, with anything that was built on, promoted, declined, or re-run kept whoever produced it. The audit page's user filter names the principal behind each option rather than an address you have to recognize, and its event filter offers every kind the record actually holds. Every outbound API call now carries the persona that made it in the metrics, and a purpose your assistant states is recorded whether or not that tool required one, so an assistant following the platform's own instruction is no longer refused for following it. - [Product Governance](https://plexara.io/product/governance) - [Product Portal Administration](https://plexara.io/product/portal/admin) - [Lesson Governance: personas, access, and audit](https://plexara.io/learning/mcp/governance-personas-and-access) 2. August 27, 2026 v1.126.4 ### Spreadsheets as tables, shared files, and automations in the portal Knowledge & Catalog Portal & UX Integrations A CSV uploaded to Plexara, or one the assistant built, is now a table the warehouse can join, with nothing copied. A report can reference a logo or a data file instead of carrying its bytes, so a scheduled script refreshes the file and the dashboard reading it stays current. Automations got their own section of the portal, and the platform now ships its own documentation as pages inside your Knowledge area. - Spreadsheets as tables A CSV saved as an asset or uploaded as a resource now carries a Query as a table panel: pick the connection, name the table or accept the default, and the assistant joins it against the warehouse with SQL over the file where it sits. The assistant can register a file by reference without the portal step. A file the warehouse would misread, a line break inside a cell, carriage-return line endings, an encoding that would corrupt columns, is refused with the reason, and the panel offers to save a corrected copy as a new version and register that, with the correction recorded in the file history. A new Scratch Tables page lists every registration you can see, with its qualified name, connection, and source file, and flags a table that is behind its file or whose file is gone. - [Product Spreadsheets as Tables](https://plexara.io/product/spreadsheets) - [Lesson Uploading a file and registering it as a table](https://plexara.io/learning/spreadsheets/uploading-and-registering-a-file) - [Insight The spreadsheet that joins your warehouse](https://plexara.io/learning/insights/the-spreadsheet-that-joins-your-warehouse) - Automations in the portal Scripts have a section of their own: what you have, what is scheduled, and what is failing, with a Runs tab across every script you own. Opening a script shows its details, a schedule you set in words rather than cron (weekdays at 7:00 AM in your timezone), what it says about itself as a formatted document filed under a category and tags, its source with version history, and its run history directly beneath. Run, Validate, and Dry run sit above the editor: a dry run executes what is on screen as you, keeps nothing, and reports what it would have produced. A script can call the same tools its author can, publish a document as well as a table, and refresh the data behind a dashboard without rewriting the dashboard itself. Admins see every script on the platform and can move one to a new owner. - [Product Automations](https://plexara.io/product/automations) - [Lesson Running it: by hand, from the portal, and on a schedule](https://plexara.io/learning/automations/running-by-hand-from-the-portal-and-on-a-schedule) - [Lesson What a run may do, and the record it leaves](https://plexara.io/learning/automations/what-a-run-may-do) - Reports that reference files instead of carrying them An asset can name a logo, a photograph, a data dictionary, or another asset by reference instead of embedding its bytes, and every viewer resolves the reference when the page is read. A reference to another asset always resolves to its current content, so a script that rewrites a CSV on a schedule keeps the dashboard reading it current without the dashboard being re-saved. A References panel shows what an asset depends on, Used by shows which reports read a file, deleting a referenced file warns and names them first, and the assistant is told before a reference is made that anyone who can open the asset can load the file through it. - [Lesson Outputs: feeds, reports, and dashboards that refresh themselves](https://plexara.io/learning/automations/outputs-feeds-reports-and-dashboards) - [Lesson Joining, visualizing, and sharing](https://plexara.io/learning/spreadsheets/joining-visualizing-and-sharing) - [Product Portal Tour](https://plexara.io/product/portal) - A resource library organized by category Uploaded files now group by category, with sections that fold and remember how you left them, and a section of images is shown as a grid of tiles. Each resource opens at a page of its own, can be moved to another library (yours, a team persona, or the shared library) with the move recorded, and can be written by the assistant or a scheduled script, with the change landing in the file history like any upload. Uploading is offered only in a library you are allowed to add to. - [Lesson Resources: the company files the agent should use, not reinvent](https://plexara.io/learning/mcp/mcp-resources-templates-and-examples) - [Product Portal Tour](https://plexara.io/product/portal) - Documentation that ships with the platform Your Knowledge area now carries a set of built-in pages: how to write a script, how outputs and exports are named, the dashboard pattern that refreshes its own data, asset references and the refresh loop, and the content types for stored files. Each carries a Built-in badge and a diagram, is updated with every release, and is read-only where your own pages are edited. If your team wants its own version of a topic, hide the built-in page and write yours; it can be restored later. - [Lesson Knowledge: from a memory to something the whole team can use](https://plexara.io/learning/mcp/knowledge-from-memory-to-insights) - [Product Knowledge Capture & Application](https://plexara.io/product/knowledge-application) - Every API operation, browsable A new APIs page lists the connected APIs your role can call and, on each, the operations it may reach, grouped the way the API documents them and searchable by name, path, or summary. Opening one shows its parameters, request body, and responses, the requests promoted from calls that worked, and a copyable call that performs it through the Plexara API from a pipeline or a script. An admin now sets which endpoints a persona may call from the portal, and the page and the assistant agree on what a caller reaches because they read the same rules. - [Product API Gateway](https://plexara.io/product/api-gateway) - [Product Portal Administration](https://plexara.io/product/portal/admin) - [Insight Search the capability, not the manual: how Plexara keeps a wide platform light](https://plexara.io/learning/insights/search-the-capability-not-the-manual) - Version history with a bound, and previews that match An asset keeps its most recent hundred versions, its owner can raise or lower that from the sidebar, and the current version is never pruned. JSON assets get previews, collection previews follow your light or dark mode, an owner can recapture a preview on demand, and a signed-in colleague who opens a share link lands on the item in their own portal, with its feedback panel beside it. - [Lesson Editing what you already have](https://plexara.io/learning/assets/editing-what-you-already-have) - [Lesson Sharing your work](https://plexara.io/learning/assets/sharing-your-work) - [Product Portal Tour](https://plexara.io/product/portal) [Read more: why this matters](https://plexara.io/learning/insights/the-spreadsheet-that-joins-your-warehouse) 3. August 17, 2026 v1.121.1 ### Automations, and every session on the record Agent Efficiency Security & Governance Portal & UX Your assistant can now hand work to the platform: a report it worked out once becomes a script Plexara runs on demand or on a schedule, with no model in the loop. Every session, query, and API call is now a record with a stated purpose and an outcome, a saved asset points at the calls that produced it, and the portal was rebuilt on one consistent set of components. - Automations: scripts your assistant writes, Plexara runs Once the assistant has worked out a report, an export, or a dashboard refresh, it can save that logic as a script. The script runs on request or on a schedule (hourly, daily, weekdays, or a day of the month), under the access its author holds, and delivers its output as a saved asset or to a storage bucket your team has been granted. Every run is recorded with what triggered it, which version ran, what it produced, and how it ended, and a scheduled fire that arrives while the previous run is still going is recorded as skipped rather than dropped. Scripts turn up in search by what they do, and a prompt can reference one. - [Product Automations](https://plexara.io/product/automations) - [Lesson The agent writes the first script](https://plexara.io/learning/automations/the-agent-writes-the-first-script) - [Insight The report that runs without the agent](https://plexara.io/learning/insights/the-report-that-runs-without-the-agent) - Sessions and calls you can open Before the platform runs a query or calls an API, the assistant now states in one sentence what the call is for: the question behind the query, not a restatement of it. Activity gained My Sessions and My Calls beside the overview. A session opens as what it produced and its calls in order, each with its stated purpose, the connection it went to, and whether it succeeded, and it stays readable long after it ended. My Calls is the catalog of every query and API call you made and what came of each. Admins see the same views across everyone, and a query that answered a question can be published to the catalog as a saved query, or an API call as a worked example on its endpoint, so the next person starts from something that worked. - [Product Portal Administration](https://plexara.io/product/portal/admin) - [Product Governance](https://plexara.io/product/governance) - [Lesson Governance: personas, access, and audit](https://plexara.io/learning/mcp/governance-personas-and-access) - [Insight Every call your agent makes states its purpose](https://plexara.io/learning/insights/every-call-states-its-purpose) - An asset names the calls that produced it Every save records the queries and API calls the asset was built from, with each call's purpose, outcome, and duration, and the assistant can name the exact calls it used. The asset viewer shows that provenance by version, keeps a failed query in the record rather than hiding it, and links to the session the work belongs to. The assistant can recall its own past work the same way, by what it was for, and follow a result back to the session that made it. - [Lesson How an asset was built](https://plexara.io/learning/assets/how-an-asset-was-built) - [Product Portal Tour](https://plexara.io/product/portal) - Told what is waiting, at the start of a session The first thing your assistant learns in a new session is what is waiting for you: unresolved feedback on assets you own and what was newly shared with you, which it relays before starting on your request. Each notice is delivered once, so a session repeats nothing you were already told. Sharing an asset with a colleague can now be done from the conversation as well, and a link that only signed-in users can open no longer expires. Admins can share and hand on any asset or collection, including ones an agent created under a service account that nobody can sign in as. - [Product Email Notifications](https://plexara.io/product/notifications) - [Lesson Sharing your work](https://plexara.io/learning/assets/sharing-your-work) - [Lesson Turning a comment into something the agent remembers](https://plexara.io/learning/assets/feedback-that-becomes-knowledge) - Knowledge that says how to check it An insight delivered to your assistant now names the table and connection one query would settle it against, so a claim about your warehouse arrives with the way to verify it. Reviewers see the same under a pending claim: what the entity is queryable as and where it lives. Rolling back an applied change returns its insights to the review queue for a fresh decision instead of retiring them, a long knowledge page is now searchable across its whole length, and anything saved, edited, uploaded, or approved is searchable as soon as it lands. - [Product Knowledge Capture & Application](https://plexara.io/product/knowledge-application) - [Lesson Knowledge: from a memory to something the whole team can use](https://plexara.io/learning/mcp/knowledge-from-memory-to-insights) - [Research The Knowledge-Pollution Study](https://plexara.io/benchmark/knowledge-pollution) - A portal rebuilt on one set of components Every section of the portal, from the catalog and prompts to knowledge, assets, and admin, now sits on one consistent set of components, with pages, cards, and panels told apart by their surface. Lists open on the work most recently touched and let you choose the order, every page has an address you can bookmark or hand to a colleague, glossary and domain definitions render as formatted text, prompts group into collections in both your own library and the team library, and connected APIs accept file uploads and paths with more than one parameter in a segment. - [Product Portal Tour](https://plexara.io/product/portal) - [Product Portal Administration](https://plexara.io/product/portal/admin) [Read more: why this matters](https://plexara.io/learning/insights/the-report-that-runs-without-the-agent) 4. August 4, 2026 v1.119.0 ### One place to govern what your business knows Knowledge & Catalog Portal & UX Agent Efficiency The two libraries your team leans on most, its prompts and its catalog, both grew into something a person can actually maintain. Prompts carry version history, collections, and run counts. The whole catalog is now governed inside Plexara rather than in a separate tool. And a fact one person teaches the platform is findable by everyone, whichever shelf it landed on. - A prompt library with history, collections, and usage Every prompt now keeps its own version history, with the approval bound to the version it approved and any two versions comparable line by line. Prompts group into collections by team, domain, or workflow, and each row reports its run count and how long since it last ran, so the procedures your team actually relies on are easy to tell apart from the ones nobody has opened in months. - [Lesson The prompt library: versioned, shared, and measurable](https://plexara.io/learning/mcp/mcp-prompts-reusable-prompts) - [Lesson Prompts are the new SOPs](https://plexara.io/learning/prompts/prompts-are-the-new-sops) - [Product Portal Tour](https://plexara.io/product/portal) - Your prompt library, open inside the chat Ask your assistant to show your prompts and the library opens in the conversation: search as you type, filter by collection or tag, then fill in a form built from whatever the prompt needs and run it right there. Clients that do not render interactive panels get the same results as plain text, so nothing depends on which one your team uses. - [Lesson Running prompts, by hand and on a schedule](https://plexara.io/learning/prompts/running-prompts-and-schedules) - [Lesson Reproducible prompts](https://plexara.io/learning/assets/reproducible-prompts) - Govern the whole catalog without leaving Plexara Tables, context documents, tags, domains, and the business glossary now sit under one Catalog tab. Define what a tag means, describe the business areas your data is grouped into, and maintain the glossary your organization writes its definitions in, all with the same editing your team already has for table descriptions. Retiring anything states its blast radius first, so removing an unused label never looks like removing one the warehouse depends on. - [Product Catalog Governance](https://plexara.io/product/catalog) - [Lesson Governing the catalog without leaving the portal](https://plexara.io/learning/mcp/catalog-governance-in-the-portal) - See the shape of what your team knows A new graph view draws your knowledge as its reference network: every page, every table, prompt, and asset a page cites, and every link between them. It opens on the idea the most connections run through, groups the corpus into topics, and sizes each node by how much of the picture it holds together, so the concepts your business is really built around are the ones you see first. - [Lesson Seeing the shape of what your team knows](https://plexara.io/learning/mcp/the-knowledge-graph) - [Product Portal Tour](https://plexara.io/product/portal) - [Research The Graph-Completion Study](https://plexara.io/benchmark/graph-completion) - What one person teaches, the whole team can find Once a captured insight is reviewed and promoted, everyone who searches can find it, attributed to whoever captured it. Before this, a fact written into the catalog rather than onto a knowledge page reached nobody but its author unless a question happened to name the exact table it hung off. Your catalog descriptions are now searched by meaning too, so a question about a topic finds the tables described in those terms. - [Insight What one person teaches, the whole team gets](https://plexara.io/learning/insights/what-one-person-teaches-the-whole-team-gets) - [Product Knowledge Capture & Application](https://plexara.io/product/knowledge-application) - [Product Semantic Search and Enrichment](https://plexara.io/product/semantic-enrichment) - Reference material your agent can actually find The files your team uploads for agents to use as they are, templates, brand files, data dictionaries, now turn up in the same search as everything else, matched on what is inside them rather than just their names. Replacing a file keeps every prompt and citation pointing at it working, each revision is kept and restorable, and each resource reports how often it is actually read. - [Lesson Resources: the company files the agent should use, not reinvent](https://plexara.io/learning/mcp/mcp-resources-templates-and-examples) - [Product Semantic Search and Enrichment](https://plexara.io/product/semantic-enrichment) [Read more: why this matters](https://plexara.io/learning/insights/what-one-person-teaches-the-whole-team-gets) 5. July 20, 2026 v1.106.0 ### Work that reaches people outside the portal Portal & UX Security & Governance Sharing stopped depending on the other person being signed in and looking. A share or a comment now sends an email, everyone sets their own delivery, and someone with no Plexara account can open exactly what was sent to them without the link turning into something anyone can forward. - Told when something needs you Sharing an asset, collection, or prompt emails the person you shared it with, and so does a comment on something you own or that was shared with you. Everyone picks their own delivery: one email per event, a single daily digest, or none at all, with separate switches for shares, comments, and mentions. The email never holds up the share or the comment that triggered it. - [Product Email Notifications](https://plexara.io/product/notifications) - [Lesson Sharing your work](https://plexara.io/learning/assets/sharing-your-work) - Guests can open what was shared with them A recipient with no Plexara account lands on a branded page and can ask for a one-time view link, sent only to the address the share names. It expires within minutes, dies after its first use, and opens a view-only session scoped to that single item. Guests can download but never edit, and never reach the portal. - [Lesson Sharing your work](https://plexara.io/learning/assets/sharing-your-work) - [Product Email Notifications](https://plexara.io/product/notifications) - A share reaches only the person it was addressed to The emailed link resolves once the named recipient is signed in, so forwarding the message on grants nothing. Link shares stay their own separate thing, with their own bounded life. - [Product Email Notifications](https://plexara.io/product/notifications) - [Product Governance](https://plexara.io/product/governance) - Unsubscribe in one click Every notification carries an unsubscribe link that works without signing in, and opening it asks for confirmation rather than acting on the click, so a corporate mail scanner that follows links inside messages cannot quietly opt someone out. - [Product Email Notifications](https://plexara.io/product/notifications) 6. July 6, 2026 v1.100.1 ### Grounded answers, tighter access, leaner context Agent Efficiency Security & Governance Knowledge & Catalog This stretch made answers more grounded and the platform tighter around them. Every answer is now anchored in your catalog before it reaches the warehouse, the portal picked up a round of security hardening, and the business context wrapped around each answer stays lean so it never crowds out your data. - Answers grounded in your catalog first Before it runs a warehouse query, the assistant now grounds itself in your catalog, so answers reflect the data you actually have rather than a guess at its shape. Fewer confident wrong turns, and more answers you can trust. - [Product Semantic Search and Enrichment](https://plexara.io/product/semantic-enrichment) - [Lesson Discovery: one search, then fetch](https://plexara.io/learning/mcp/discovery-search-and-fetch) - [Research The Accuracy Study](https://plexara.io/benchmark/accuracy) - A round of security hardening The portal gained cross-site request protection on every change you make through it, and sign-in was hardened to current standards, so the day-to-day work your team does in Plexara sits on a tighter foundation. - [Page Security](https://plexara.io/security) - [Page Trust Center](https://plexara.io/trust) - Curate the catalog without losing your work Making several catalog edits in a row no longer overwrites the tags, glossary terms, or descriptions already there, and every change reports the full result. New portal actions let you remove a tag, edit custom properties, and bulk untag, and the Catalog and Context Docs tabs respect who on your team is allowed to write. - [Product Catalog Governance](https://plexara.io/product/catalog) - [Lesson Governing the catalog without leaving the portal](https://plexara.io/learning/mcp/catalog-governance-in-the-portal) - Context that stays out of the way The business context added to each answer now stays within a set budget with a summary-first layout, and search will not let one slow source hold up a whole query, so responses come back fast and keep the focus on your data. - [Insight Token efficiency in enterprise MCP deployments](https://plexara.io/learning/insights/token-efficiency-in-enterprise-mcp) - [Product Semantic Search and Enrichment](https://plexara.io/product/semantic-enrichment) - Nothing captured waits unreviewed The knowledge review queue now shows how long its oldest item has been waiting and how much has aged past thirty days, so the knowledge your team captures gets reviewed and promoted instead of quietly piling up. - [Product Knowledge Capture & Application](https://plexara.io/product/knowledge-application) - [Product Portal Administration](https://plexara.io/product/portal/admin) 7. June 28, 2026 v1.94.0 ### Canonical knowledge, linked like a wiki Knowledge & Catalog Portal & UX Agent Efficiency Your knowledge layer grew into a real, linked body of institutional knowledge. Captured lessons now flow into durable, human-readable pages that cite the exact data they describe and cross-link to each other, so what your business knows lives in one navigable place instead of scattered notes, and the assistant surfaces it wherever it is relevant. - Canonical knowledge pages A new layer of durable, human-readable pages, written in formatted text with diagrams, version-tracked on every save, searchable by meaning, and open to feedback in place. They hold the vocabulary, definitions, runbooks, and context that do not fit inside the metadata on a single table. - [Product Knowledge Capture & Application](https://plexara.io/product/knowledge-application) - [Lesson Knowledge: from a memory to something the whole team can use](https://plexara.io/learning/mcp/knowledge-from-memory-to-insights) - One Knowledge home Memory, proposed insights, and canonical pages are unified into a single Knowledge area that shows their shared lifecycle: a note is captured, promoted to an insight for review, and finally promoted to shared, canonical knowledge, with each step gated by who is allowed to apply knowledge. - [Product Portal Tour](https://plexara.io/product/portal) - [Lesson Knowledge: from a memory to something the whole team can use](https://plexara.io/learning/mcp/knowledge-from-memory-to-insights) - Knowledge linked to what it describes Pages and insights reference the exact assets, prompts, collections, connections, and catalog entries they are about. Those references render as live links that always show the current name and work in both directions, so from any item you can see the knowledge that documents it and click through the whole graph like a wiki. - [Lesson Seeing the shape of what your team knows](https://plexara.io/learning/mcp/the-knowledge-graph) - [Research The Graph-Completion Study](https://plexara.io/benchmark/graph-completion) - Discover, read, then cite Search finds the right piece across every kind of knowledge, a retrieve step reads any result back in full, and a canonical reference lets the assistant cite it precisely, closing the loop from finding knowledge to using it in an answer. - [Lesson Discovery: one search, then fetch](https://plexara.io/learning/mcp/discovery-search-and-fetch) - [Product Semantic Search and Enrichment](https://plexara.io/product/semantic-enrichment) - Duplicates are prevented, not just discouraged When the assistant tries to create a page that closely matches one that already exists, the platform steers it to update the existing page instead, so canonical knowledge consolidates over time rather than fragmenting. - [Product Knowledge Capture & Application](https://plexara.io/product/knowledge-application) - [Insight What one person teaches, the whole team gets](https://plexara.io/learning/insights/what-one-person-teaches-the-whole-team-gets) 8. June 21, 2026 v1.87.0 ### One front door for discovery Agent Efficiency Knowledge & Catalog Portal & UX Discovery got a single front door. Instead of needing to know the shape of your platform before it could ask, the assistant now finds what exists across every system it can reach with one call, and records knowledge through one consistent action. The portal also got a round of visual and performance polish. - Find anything with one search A single, universal search spans every source a role can reach, your catalog, memory, captured knowledge, saved assets, prompts, connected APIs, and connections, and returns a balanced set that keeps each source visible rather than letting the largest one dominate, along with a summary of where the matches live. - [Lesson Discovery: one search, then fetch](https://plexara.io/learning/mcp/discovery-search-and-fetch) - [Product Semantic Search and Enrichment](https://plexara.io/product/semantic-enrichment) - One way to record knowledge Capturing knowledge is now a single action that files each note in the right place and avoids re-recording something already known, so the path from a useful moment to durable knowledge is one clear step. - [Product Knowledge Capture & Application](https://plexara.io/product/knowledge-application) - [Lesson Knowledge: from a memory to something the whole team can use](https://plexara.io/learning/mcp/knowledge-from-memory-to-insights) - A more polished portal Asset previews now match light and dark mode and fill the frame edge to edge, the asset grid loads noticeably faster on large libraries, the sign-in button label is customizable, and interactive results built with common React patterns render reliably. - [Product Portal Tour](https://plexara.io/product/portal) - [Lesson Creating reports and dashboards](https://plexara.io/learning/assets/creating-reports-and-dashboards) - Long documents stay findable Longer reference documents now index reliably for search, so a big runbook, spec, or policy is something the assistant can actually surface and pull from rather than something too large to find. - [Lesson Resources: the company files the agent should use, not reinvent](https://plexara.io/learning/mcp/mcp-resources-templates-and-examples) 9. June 14, 2026 v1.86.0 ### A human feedback and review loop, end to end Portal & UX Knowledge & Catalog Agent Efficiency The throughline this week was review. People can leave structured feedback directly on saved work, an agent can resolve it into catalog knowledge, and a new Feedback hub gathers everything waiting on you in one place. Sharing with teammates and browsing your assets both got easier. - Feedback threads on your work Reviewers can open a correction, question, or suggestion directly on a saved asset or collection, or on a specific quote within it, then reply and work it through an open, answered, resolved lifecycle. Asset and collection lists show how many threads are still open, and someone who arrives through a public share link can take part without a separate account. - [Lesson Turning a comment into something the agent remembers](https://plexara.io/learning/assets/feedback-that-becomes-knowledge) - [Product Portal Tour](https://plexara.io/product/portal) - Resolve feedback into catalog knowledge The assistant can close a feedback thread by capturing the knowledge it represents, linking the thread to the resulting catalog update so the path from comment to documented change stays visible. The author then confirms or disputes how it was resolved, and disputing reopens the thread. - [Lesson Turning a comment into something the agent remembers](https://plexara.io/learning/assets/feedback-that-becomes-knowledge) - [Product Knowledge Capture & Application](https://plexara.io/product/knowledge-application) - [Insight How knowledge application turns usage into documentation](https://plexara.io/learning/insights/knowledge-application-turns-usage-into-documentation) - A Feedback hub, and an agent that works your inbox A new hub lists every comment, question, and correction across the assets, collections, and prompts you can see, newest first, with a sidebar badge when something is waiting. A dedicated feedback tool lets you ask the assistant to review and reply to anything pending in a single pass, and validation and sign-off keep open items on a worklist so nothing is dropped. - [Product Portal Tour](https://plexara.io/product/portal) - [Lesson Turning a comment into something the agent remembers](https://plexara.io/learning/assets/feedback-that-becomes-knowledge) - Easier sharing with teammates The share dialog now suggests known teammates by name as you type while still accepting any email, and a user with editor access can edit a shared asset details, not just its content. - [Lesson Sharing your work](https://plexara.io/learning/assets/sharing-your-work) - Browse assets by ownership Collections and items shared with you now live in one Assets area with a Mine, Shared, or All filter instead of separate pages, and Prompts gains a Shared tab. - [Product Portal Tour](https://plexara.io/product/portal) - [Lesson Creating collections](https://plexara.io/learning/assets/creating-collections) [Read more: why this matters](https://plexara.io/learning/insights/knowledge-application-turns-usage-into-documentation) 10. June 10, 2026 v1.83.0 ### Your context shows up everywhere, and search gets sharper Knowledge & Catalog Agent Efficiency Portal & UX The business context Plexara attaches to every answer now reaches you no matter which assistant you connect, search across your work returns cleaner and better-ordered results, and the prompts your team relies on are finally findable. - Context that follows the answer into any client The context Plexara travels with every answer, the owners, descriptions, related memory, and what each column actually means, now arrives in a form that every MCP client can read, not just some. If you connect a tool that previously showed bare results, the surrounding context now comes with them. - [Product Semantic Search and Enrichment](https://plexara.io/product/semantic-enrichment) - [Product Integrations](https://plexara.io/product/integrations) - [Insight Why proximity matters: tools, meaning, and memory belong together](https://plexara.io/learning/insights/why-proximity-matters-tools-meaning-memory) - Sharper, better-ordered search Results across memory, saved assets, collections, and prompts now separate cleanly instead of bunching together, so the closest match rises to the top instead of getting lost in a tie. - [Product Memory](https://plexara.io/product/memory) - [Product Semantic Search and Enrichment](https://plexara.io/product/semantic-enrichment) - Find every prompt your team relies on Built-in workflow prompts and the prompts your administrators set up now appear in prompt search alongside everything else, so a shared workflow is something you can look up rather than something you have to already know exists. - [Lesson Reproducible prompts](https://plexara.io/learning/assets/reproducible-prompts) - [Lesson The prompt library: versioned, shared, and measurable](https://plexara.io/learning/mcp/mcp-prompts-reusable-prompts) - Edits that report what changed Editing only the body of a saved asset no longer shows a failure after it actually saved, and knowledge you or an admin reject is now correctly kept out of what the assistant recalls later. - [Lesson Editing what you already have](https://plexara.io/learning/assets/editing-what-you-already-have) - [Product Knowledge Capture & Application](https://plexara.io/product/knowledge-application) - Shared downloads that work from anywhere Download links for exported results and files now resolve from outside your network, so a link you share with a colleague or partner opens for them instead of dead-ending. - [Lesson Exporting data](https://plexara.io/learning/assets/exporting-data) - [Lesson Sharing your work](https://plexara.io/learning/assets/sharing-your-work) [Read more: why this matters](https://plexara.io/learning/insights/why-proximity-matters-tools-meaning-memory) 11. June 7, 2026 v1.81.1 ### A governed prompt library and search that ranks by meaning Agent Efficiency Portal & UX Knowledge & Catalog Prompts grew into a governed, shareable library, and relevance search that ranks by meaning now reaches every corner of the platform: knowledge, prompts, saved assets, and collections, in both the assistant and the portal. - A first-class prompt library Prompts gain a full lifecycle (draft, approved, deprecated), tags, admin promotion through a review queue, and direct sharing by email, where the recipient gets a real, runnable prompt rather than a flattened copy. - [Lesson The prompt library: versioned, shared, and measurable](https://plexara.io/learning/mcp/mcp-prompts-reusable-prompts) - [Lesson Sharing prompts, and closing the loop with feedback](https://plexara.io/learning/prompts/sharing-prompts-and-feedback) - [Insight When prompts become shared infrastructure](https://plexara.io/learning/insights/governed-prompts-and-relevance-search) - Search by meaning, everywhere Relevance search (meaning plus keywords, with an automatic keyword-only fallback) now covers captured knowledge, prompts, saved assets, and collections, across both the assistant and the portal, always scoped to what you are allowed to see. - [Product Semantic Search and Enrichment](https://plexara.io/product/semantic-enrichment) - [Lesson Discovery: one search, then fetch](https://plexara.io/learning/mcp/discovery-search-and-fetch) - Consistent, self-describing errors Failed tool calls now report in a uniform, self-describing way, so the assistant can tell a fixable input mistake from an authentication problem or an outage. - [Insight Two front doors, one governed surface](https://plexara.io/learning/insights/the-developer-surface) - [Page Developers](https://plexara.io/developers) [Read more: why this matters](https://plexara.io/learning/insights/governed-prompts-and-relevance-search) 12. June 4, 2026 v1.79.1 ### Bigger exports and self-service configuration Platform Stability Security & Governance Integrations This week rounded out reliability and control. Plexara now handles very large exports without strain, and admins can configure the whole platform just by asking the assistant. - Reliable large exports Large query results and API responses now stream straight to storage, so you can export big datasets without hitting size limits or slowing the platform. - [Lesson Exporting data](https://plexara.io/learning/assets/exporting-data) - [Lesson Trino Query: analytics and insights](https://plexara.io/learning/mcp/trino-query-analytics-and-insights) - Configure the platform by asking Admins can set up the platform by talking to the assistant: create roles, add connections, adjust the assistant instructions, and manage prompts and API keys, with every change attributed and logged. - [Product Portal Administration](https://plexara.io/product/portal/admin) - [Lesson Governance: personas, access, and audit](https://plexara.io/learning/mcp/governance-personas-and-access) - Tighter access control Connection access is now closed by default. Each role sees exactly the connections it has been granted and nothing more. - [Insight Closed by default: least privilege as the starting point](https://plexara.io/learning/insights/closed-by-default-access) - [Product Governance](https://plexara.io/product/governance) - Readable connection notes Connections can carry richly formatted descriptions with a collapsible reveal, so the context behind each one is easy to read. - [Product Portal Administration](https://plexara.io/product/portal/admin) - [Product Integrations](https://plexara.io/product/integrations) [Read more: why this matters](https://plexara.io/learning/insights/closed-by-default-access) 13. May 31, 2026 v1.76.0 ### Smarter tool selection and memory Agent Efficiency Integrations Portal & UX A busy week focused on making the platform intelligence visible and its answers faster. New dashboards surface the health of search, the assistant finds the right tool on its own, and memory recall got sharper. - See the health of search A dashboard shows the state of semantic search across your connected systems, with accurate coverage and clear status. - [Product Portal Administration](https://plexara.io/product/portal/admin) - [Product Semantic Search and Enrichment](https://plexara.io/product/semantic-enrichment) - Find the right tool automatically The assistant can locate the best tool for a request based on what you mean, not just the tool name. - [Insight Letting the agent find the right tool](https://plexara.io/learning/insights/intent-driven-tools-and-memory) - [Insight Search the capability, not the manual: how Plexara keeps a wide platform light](https://plexara.io/learning/insights/search-the-capability-not-the-manual) - [Lesson Anatomy of a Plexara MCP](https://plexara.io/learning/mcp/what-is-an-mcp) - Smarter memory recall Memory search now blends meaning and keywords, so the assistant brings back more relevant context from past sessions. - [Product Memory](https://plexara.io/product/memory) - [Insight Five kinds of memory, and how each comes back](https://plexara.io/learning/insights/five-kinds-of-memory) - Broader connectivity and cleaner audit Added support for file-based (WebDAV) services, and activity logs now separate assistant activity from API activity for cleaner audit trails. - [Product Integrations](https://plexara.io/product/integrations) - [Product Governance](https://plexara.io/product/governance) [Read more: why this matters](https://plexara.io/learning/insights/intent-driven-tools-and-memory) 14. May 24, 2026 v1.67.0 ### Operability, more authentication, and security hardening Security & Governance Integrations Portal & UX Operability and security took center stage. Connected APIs became usable from outside the assistant, live operational dashboards arrived, and security hardening tightened isolation between users. - Use connected APIs from other tools A web endpoint exposes your connected APIs to tools beyond the assistant, such as data pipelines and scripts, under the same access rules and activity logging. - [Product API Gateway](https://plexara.io/product/api-gateway) - [Page Developers](https://plexara.io/developers) - [Insight Two front doors, one governed surface](https://plexara.io/learning/insights/the-developer-surface) - Live operational dashboards Live health and usage metrics for your platform, in an admin dashboard for monitoring how it is running. - [Product Portal Administration](https://plexara.io/product/portal/admin) - More ways to authenticate Added support for APIs that use basic username and password, and for internal or corporate APIs secured with client certificates (mTLS). - [Product API Gateway](https://plexara.io/product/api-gateway) - [Insight Meeting enterprise systems where they are](https://plexara.io/learning/insights/enterprise-authentication-and-isolation) - Redesigned role editor A single, clearer editor for a role permissions and the assistant behavior settings. - [Product Portal Administration](https://plexara.io/product/portal/admin) - [Product Governance](https://plexara.io/product/governance) - Security hardening Tightened isolation so one user activity history can no longer be visible to another on a specific connection type. - [Product Governance](https://plexara.io/product/governance) - [Page Security](https://plexara.io/security) [Read more: why this matters](https://plexara.io/learning/insights/enterprise-authentication-and-isolation) 15. May 17, 2026 v1.62.2 ### The API connector matures Integrations Agent Efficiency Security & Governance With the API connector in place, this week hardened it for real-world use: versioned catalogs the assistant can understand, more reliable sign-in, and search that matches on intent. - Versioned API catalogs Each connected API now has a versioned catalog so the assistant reliably understands its operations and inputs, including APIs that need a second credential header. - [Product API Gateway](https://plexara.io/product/api-gateway) - [Insight Why an agent needs a versioned API catalog](https://plexara.io/learning/insights/versioned-api-catalogs) - More reliable connection sign-in Sign-in for AI-tool and web-API connections is unified, with automatic token refresh before expiry, a history of authentication events, and clearer errors. - [Product API Gateway](https://plexara.io/product/api-gateway) - [Product MCP Gateway](https://plexara.io/product/mcp-gateway) - Search by intent API operations are now ranked by what you mean rather than exact keyword match. - [Product API Gateway](https://plexara.io/product/api-gateway) - [Insight Search the capability, not the manual: how Plexara keeps a wide platform light](https://plexara.io/learning/insights/search-the-capability-not-the-manual) [Read more: why this matters](https://plexara.io/learning/insights/versioned-api-catalogs) 16. May 8, 2026 v1.58.3 ### Connect to any REST or HTTP API Integrations One of the biggest capabilities yet landed this week: the assistant can connect to and use any external REST or web API. - Call external web APIs directly The assistant reads each API published description to discover what operations are available, signs in securely on your behalf with OAuth, enforces per-role rules on individual endpoints, and can export API results as assets. - [Product API Gateway](https://plexara.io/product/api-gateway) - [Insight When the answer is an action](https://plexara.io/learning/insights/when-the-answer-is-an-action) - [Insight The public data your warehouse is missing](https://plexara.io/learning/insights/the-public-data-your-warehouse-is-missing) 17. May 1, 2026 v1.57.5 ### Smoother connections, refreshed portal Integrations Portal & UX A round of refinement made connecting external services less fiddly, and the portal adopted a refreshed visual identity. - Easier external connections Connecting external services is smoother: a clear Connect button for sign-in, and friendly error messages when something needs attention. - [Product API Gateway](https://plexara.io/product/api-gateway) - [Product MCP Gateway](https://plexara.io/product/mcp-gateway) - Refreshed look The portal adopts a refreshed visual identity. - [Product Portal Tour](https://plexara.io/product/portal) 18. April 26, 2026 v1.57.0 ### Reach beyond Plexara Integrations Portal & UX The platform began reaching outward. A new gateway lets it connect to and use tools hosted on other servers, weaving their capabilities and your context into the same experience. - Connect to other AI tool servers A new gateway lets Plexara connect to and use tools hosted on other MCP servers, automatically carrying your business context across them. - [Product MCP Gateway](https://plexara.io/product/mcp-gateway) - [Insight Why MCP gateways are not enough](https://plexara.io/learning/insights/why-mcp-gateways-are-not-enough) - Redesigned Tools page A cleaner master-detail layout for browsing everything the assistant can do. - [Product Portal Administration](https://plexara.io/product/portal/admin) - [Lesson Anatomy of a Plexara MCP](https://plexara.io/learning/mcp/what-is-an-mcp) 19. April 19, 2026 v1.56.1 ### Get results out, stay in sync Portal & UX Knowledge & Catalog Platform Stability Getting results out of the platform and keeping clients in sync were the focus. A new export turns any query straight into a downloadable file, and tool lists update live for everyone connected. - Export results to a file A new export turns any query directly into a downloadable, shareable asset in CSV, JSON, or Markdown. - [Lesson Exporting data](https://plexara.io/learning/assets/exporting-data) - [Lesson Trino Query: analytics and insights](https://plexara.io/learning/mcp/trino-query-analytics-and-insights) - Live updates The assistant available tools refresh automatically for everyone connected whenever configuration changes. - [Product Integrations](https://plexara.io/product/integrations) - [Lesson Anatomy of a Plexara MCP](https://plexara.io/learning/mcp/what-is-an-mcp) - Formatted knowledge and memory Knowledge and memory now render as cleanly formatted text in the portal. - [Product Memory](https://plexara.io/product/memory) - [Product Portal Tour](https://plexara.io/product/portal) 20. April 12, 2026 v1.55.6 ### The assistant remembers Agent Efficiency Knowledge & Catalog Portal & UX The assistant gained a longer memory and the platform gained more day-to-day flexibility. Preferences and context now carry across sessions, and prompts and reference files can be managed on the fly. - A first-class memory layer Memory keeps preferences, corrections, and context across sessions, for both agents and analysts. - [Product Memory](https://plexara.io/product/memory) - [Insight Five kinds of memory, and how each comes back](https://plexara.io/learning/insights/five-kinds-of-memory) - [Lesson Context, compression, and memory](https://plexara.io/learning/ai-concepts/context-windows-and-tokens) - Manage prompts on the fly Create and edit prompts directly in the portal. - [Lesson Reproducible prompts](https://plexara.io/learning/assets/reproducible-prompts) - [Product Portal Tour](https://plexara.io/product/portal) - Upload reference files Upload and manage files the assistant can use as reference material. - [Lesson Resources: the company files the agent should use, not reinvent](https://plexara.io/learning/mcp/mcp-resources-templates-and-examples) 21. April 4, 2026 v1.50.1 ### Organize and configure without engineering Portal & UX Security & Governance Knowledge & Catalog This week made the platform more organized and more configurable without engineering help. Saved work can be grouped into collections, and more settings became editable directly in the admin screens. - Collections Group related assets into shareable collections with thumbnails and a browser. - [Lesson Creating collections](https://plexara.io/learning/assets/creating-collections) - [Product Portal Tour](https://plexara.io/product/portal) - Editable settings Configure the platform through admin settings screens, with roles and API keys changeable at any time. - [Product Portal Administration](https://plexara.io/product/portal/admin) - Per-role tool and data filtering Tools and connections are now filtered by role. - [Product Governance](https://plexara.io/product/governance) - [Lesson Governance: personas, access, and audit](https://plexara.io/learning/mcp/governance-personas-and-access) - Advanced catalog search Search the catalog with column-level filtering. - [Product Catalog Governance](https://plexara.io/product/catalog) - [Lesson Discovery: one search, then fetch](https://plexara.io/learning/mcp/discovery-search-and-fetch) 22. March 29, 2026 v1.46.0 ### Richer catalog edits Knowledge & Catalog A small, focused update broadened how the assistant can contribute to the catalog, adding richer document-style changes when it writes context back. - Document-style catalog updates The assistant can make richer, document-style updates when it writes business context back to the catalog. - [Product Knowledge Capture & Application](https://plexara.io/product/knowledge-application) - [Product Catalog Governance](https://plexara.io/product/catalog) 23. March 21, 2026 v1.45.0 ### Maintain the catalog, not just read it Knowledge & Catalog Until now the assistant could read the data catalog. Now it can help maintain it, improving documentation, tags, and ownership through conversation. - Update the catalog, not just read it The assistant gains tools to create and update catalog entries, so it can help maintain documentation, tags, and ownership. - [Product Catalog Governance](https://plexara.io/product/catalog) - [Insight How knowledge application turns usage into documentation](https://plexara.io/learning/insights/knowledge-application-turns-usage-into-documentation) 24. March 15, 2026 v1.44.0 ### A polished sharing experience Portal & UX Platform Stability The work this week centered on making sharing genuinely pleasant to use. The public viewer matured into a polished experience, and saved assets gained preview thumbnails and full version history. This week also moved the platform to 1.x versioning: v0.37 became v1.38 under the new scheme, and near-daily releases carried it to v1.44 by the end of the week. - A polished public viewer A large investment in the public viewer: dark mode, expiration notices, sharing by email with permission levels, save to my assets, view counts, and branded headers on shared links. - [Lesson Sharing your work](https://plexara.io/learning/assets/sharing-your-work) - [Product Portal Tour](https://plexara.io/product/portal) - Preview thumbnails and version history Saved assets get automatic preview thumbnails and full version history, including the ability to revert to an earlier version. - [Lesson Editing what you already have](https://plexara.io/learning/assets/editing-what-you-already-have) - [Product Portal Tour](https://plexara.io/product/portal) - One-click prompt workflows A reusable prompt system with categories and workflow prompts. - [Lesson Reproducible prompts](https://plexara.io/learning/assets/reproducible-prompts) - [Lesson The prompt library: versioned, shared, and measurable](https://plexara.io/learning/mcp/mcp-prompts-reusable-prompts) - Spreadsheet exports Save and download results as CSV. - [Lesson Exporting data](https://plexara.io/learning/assets/exporting-data) 25. March 8, 2026 v0.37.0 ### Save and share what the assistant creates Portal & UX Security & Governance A milestone week. The asset portal arrived, turning the things the assistant produces into saved, viewable, shareable items rather than one-off outputs that disappear at the end of a chat. - The asset portal launches Dashboards, reports, charts, and other outputs can be saved, viewed in the browser, and shared through a branded public viewer, with a record of which tool calls produced each one. - [Product Portal Tour](https://plexara.io/product/portal) - [Lesson Creating reports and dashboards](https://plexara.io/learning/assets/creating-reports-and-dashboards) - [Lesson Assets: dashboards, reports, and data](https://plexara.io/learning/mcp/assets-dashboards-reports-and-data) - One portal, one login A single unified portal with single sign-on. - [Product Portal Tour](https://plexara.io/product/portal) - [Page Trust Center](https://plexara.io/trust) 26. March 1, 2026 v0.30.0 ### Tailored to who is asking Agent Efficiency Security & Governance Knowledge & Catalog The experience started tailoring itself to who is asking. The platform self-introduction now adapts to a person role, tools carry friendly names, and admins can publish their own reference material. - Role-aware introduction The platform introduction adapts to each person role, and tools carry friendly, human-readable names. - [Lesson Your first day with Plexara](https://plexara.io/learning/mcp/first-engagement) - [Product Governance](https://plexara.io/product/governance) - Custom reference material Admins can publish custom resources the assistant can read on its own. - [Lesson Resources: the company files the agent should use, not reinvent](https://plexara.io/learning/mcp/mcp-resources-templates-and-examples) 27. February 22, 2026 v0.26.1 ### Richer conversations, sharper answers Agent Efficiency Portal & UX Two themes ran in parallel: making the assistant conversational abilities richer, and making its answers sharper, so responses stay relevant without unnecessary noise. - Richer assistant interactions Reusable prompts, file and resource attachments, live progress updates, and the assistant asking a clarifying follow-up when it needs one. - [Lesson Anatomy of a Plexara MCP](https://plexara.io/learning/mcp/what-is-an-mcp) - [Lesson Reproducible prompts](https://plexara.io/learning/assets/reproducible-prompts) - Smarter, leaner answers Context is narrowed to the columns a query actually uses, empty descriptions are dropped, and search results include ready-to-run example queries and a schema preview. - [Insight Token efficiency in enterprise MCP deployments](https://plexara.io/learning/insights/token-efficiency-in-enterprise-mcp) - [Product Semantic Search and Enrichment](https://plexara.io/product/semantic-enrichment) - Admin portal polish Light and dark branding, and the ability to replay a past tool call straight from the activity log. - [Product Portal Administration](https://plexara.io/product/portal/admin) 28. February 15, 2026 v0.19.0 ### Administration and a knowledge loop Knowledge & Catalog Portal & UX Security & Governance Administration moved into a real web dashboard, and the platform learned to get smarter over time. The standout was a knowledge loop: the assistant can capture what people teach it and fold it back into the catalog. - The admin dashboard arrives A web admin portal with an activity dashboard and the ability to run and inspect tool calls. - [Product Portal Administration](https://plexara.io/product/portal/admin) - Capture and apply knowledge The assistant can capture insights from a conversation, for example that a column is gross margin rather than revenue, and, with admin approval, write them back into the catalog so no one explains the same thing twice. - [Product Knowledge Capture & Application](https://plexara.io/product/knowledge-application) - [Insight How knowledge application turns usage into documentation](https://plexara.io/learning/insights/knowledge-application-turns-usage-into-documentation) - [Lesson Knowledge: from a memory to something the whole team can use](https://plexara.io/learning/mcp/knowledge-from-memory-to-insights) - Control which tools are available Admins can turn specific tools on or off. - [Product Portal Administration](https://plexara.io/product/portal/admin) - [Product Governance](https://plexara.io/product/governance) 29. February 8, 2026 v0.14.0 ### Accountability and smoother sign-in Security & Governance This stretch was about trust behind the scenes. The platform gained complete, durable activity logging so every action is accountable, and smoothed out the sign-in experience across clients. - Complete activity logging Every action is now recorded in full detail for accountability and audit. - [Product Governance](https://plexara.io/product/governance) - [Lesson Governance: personas, access, and audit](https://plexara.io/learning/mcp/governance-personas-and-access) - Smoother sign-in A round of fixes to the login flow so signing in is seamless across different clients. - [Product Integrations](https://plexara.io/product/integrations) - [Page Trust Center](https://plexara.io/trust) 30. February 1, 2026 v0.11.0 ### Richer answers at a glance Agent Efficiency Knowledge & Catalog Portal & UX With access and basic context in place, attention turned to making answers richer at a glance. The assistant began tracing how data connects across systems and showed its first interactive results. - Data lineage in context Answers now show where data comes from and what depends on it. - [Product Semantic Search and Enrichment](https://plexara.io/product/semantic-enrichment) - [Product Integrations](https://plexara.io/product/integrations) - The assistant knows the platform It starts each session aware of which data and tools are available, which produces better, better-routed answers. - [Lesson Your first day with Plexara](https://plexara.io/learning/mcp/first-engagement) - [Lesson Anatomy of a Plexara MCP](https://plexara.io/learning/mcp/what-is-an-mcp) - Interactive query results An early look at visual, interactive result views in place of plain text, plus the ability to add custom interactive apps. - [Lesson Anatomy of a Plexara MCP](https://plexara.io/learning/mcp/what-is-an-mcp) - [Lesson Trino Query: analytics and insights](https://plexara.io/learning/mcp/trino-query-analytics-and-insights) 31. January 24, 2026 v0.7.1 ### Where it began Security & Governance Knowledge & Catalog The earliest releases focused on the essentials everything else builds on: getting people securely signed in with their own accounts, and grounding answers in your own definitions rather than raw database columns. - Single sign-on People sign in with their existing company accounts, with access governed by their role from day one. - [Page Trust Center](https://plexara.io/trust) - [Product Governance](https://plexara.io/product/governance) - Answers come with business context When the assistant describes or queries a table, it automatically brings in the surrounding context (owners, descriptions, tags, and glossary terms) from the catalog, so results are not just raw columns. - [Product Semantic Search and Enrichment](https://plexara.io/product/semantic-enrichment) - [Insight The context gap in AI data access](https://plexara.io/learning/insights/context-gap-in-ai-data-access) - [Lesson Trino Query: analytics and insights](https://plexara.io/learning/mcp/trino-query-analytics-and-insights) Before the first release ### 2018 to 2026: the longer story This changelog starts with v0.7.1 in January 2026, but Plexara did not start there. It began inside Deasil Works as Methodology, a research project built on a single thesis: a company's data is described by the way its people query it. The foundational pieces were in motion from 2018, the local-model toolkit arrived in 2023, and when Anthropic published the Model Context Protocol in November 2024, Methodology stopped trying to beat frontier models and became the governed layer that makes them fluent in your business. It was renamed Plexara in 2025. [Read the full history](https://plexara.io/history) Next ### Portal Tour See where these improvements show up day to day in the Plexara portal. [Continue](https://plexara.io/product/portal) --- # Use Cases URL: https://plexara.io/use-cases/ > Real work from two Deasil Works engagements: capacity models from live telemetry, release-day verification, fraud scoring, win-back audiences, and root-cause analysis across systems, all through one governed connection. Use Cases ## A Day of Analyst Work, in Twenty Minutes With Review Two Deasil Works engagements, anonymized and told in full. Every artifact named on this page exists on a client portal, dated and attributed. This is the work an agent picked up once it could reach everything through one governed connection. The work itself ### Six jobs that used to need a specialist and a free afternoon None of these are demos. Each one was a real request, answered by an agent working through Plexara, and reviewed by the person who asked for it. [Capacity planning The peak-day capacity model Built from live telemetry across both metric stacks and anchored to a June load test. Projected peak-day load came in near one percent of the measured ceiling: a number the client could plan against instead of a guess. Retail engagement](https://plexara.io/use-cases/retail) [Release operations Release-day verification A point-of-sale version rolled out wide in the middle of the season. By end of day the agent had confirmed a 99.6 percent cutover, zero ingestion gaps, and six data-integrity checks passing, with the three straggler registers identified by name. Retail engagement](https://plexara.io/use-cases/retail) [Risk and fraud Loyalty fraud scoring Asked to examine manager-override-locked loyalty accounts, the agent scored 672 of them: risk tiers, transaction-velocity histograms against the fraud-system limit, and a worked list of the accounts worth investigating first. Retail engagement](https://plexara.io/use-cases/retail) [Audience and marketing A win-back audience in an afternoon Expired members who were fans of one original series: 991 people, built from consented viewing data joined to the prospect feed, with hours watched and episodes per fan attached. The privacy constraint was honored in the query, not in a caveat. Public media engagement](https://plexara.io/use-cases/public-media) [Debugging Root cause across the fence Monthly analytics were missing browser users. The agent traced the gap through the pipeline to an upstream vendor intermittently dropping a required tag, and shipped the evidence queries along with the verdict: the fix belongs to the vendor. Public media engagement](https://plexara.io/use-cases/public-media) [Data engineering Pipeline recovery, verified After a webhook ingestion bug was fixed, the agent inventoried all forty affected event syncs, confirmed the two-month backlog had recovered, and left a cross-reference report behind for the next person who asks. Public media engagement](https://plexara.io/use-cases/public-media) Told in full ### Both engagements, start to handover Each account runs from the estate as Deasil Works found it, through the first questions and the parts that were hard, to the point where the client kept working without us in the room. [Retail The Whole Year Comes Down to One Week Hundreds of stores, seasonal pop-ups, and a point-of-sale platform that all have to hold through the days around one summer holiday. Every developer and analyst had wired up their own AI with their own private fixes for grounding it in truth, and progress stopped there. 13 governed connections behind one endpoint 3 storage engines joined in a single federated query 71 dashboards, forecasts, and audits saved in five months Read the full engagement](https://plexara.io/use-cases/retail) [Public media Teaching the Agent Everything We Know A regional broadcaster with more than a dozen upstream sources feeding one warehouse. Years of anomaly hunts and pipeline debugging had made the consultancy expert in every idiosyncrasy of that estate, and onboarding a new analyst still took months because the knowledge lived in people. 17 live connections, from the warehouse to thirteen APIs 1,400+ governed API operations, every call authenticated and audited 9 canonical knowledge pages the client now owns Read the full engagement](https://plexara.io/use-cases/public-media) [Weighing this against something else Direct comparisons against MCP gateways, warehouse-resident assistants, and the bill of materials for building it yourself. See the comparisons](https://plexara.io/compare) Common questions ### Use Cases FAQ Two things. It uses your data through semantic catalog search, schema understanding, federated SQL, object storage, and lineage. And it invokes your APIs: OpenAPI specs imported into the gateway become governed tools it can discover and call. An agent that does both correlates what the data recorded with what your operational systems report. Every call through the gateway is authenticated, permission-checked against the connection and persona, and logged. The agent reaches only endpoints an administrator imported, and each invocation lands in the audit log with the user, persona, endpoint, and result. Invocation stays a governed, audited action at every step. [Learn more: Governance: personas, access, and audit](https://plexara.io/learning/mcp/governance-personas-and-access) As the agent works, explorations, corrections, and failures become memory. Insights are reviewed and synthesized, and approved knowledge lands in the catalog for the next session to use. A correction from an expert today becomes part of what every future agent knows, so the platform gets better the longer your team uses it. [Learn more: From memory to insights and knowledge](https://plexara.io/learning/mcp/knowledge-from-memory-to-insights) Knowledge describes the data and the business: what a sale is, where it lives, when the fiscal year starts. Prompts describe what to do with them: a report's sections, columns, language, and audience. When last year's ad-hoc report returns with a new dimension, the knowledge already understands the data and the prompt already carries the structure, so a project becomes a sentence. [Learn more: Prompts as reusable SOPs](https://plexara.io/learning/mcp/mcp-prompts-reusable-prompts) An asset is one durable artifact from a session: a query result, a chart, an export, or a generated document, saved with the lineage of which tool calls and datasets produced it. A collection groups related assets into a titled, sectioned package with version history and shared comments, like a board packet or a weekly review. Together they replace the ad hoc "send a CSV in Slack" habit with governed work that persists in the portal. [Learn more: Tour the portal workspace](https://plexara.io/product/portal) Yes. Plexara reaches your warehouse through Trino federation, so your BI tool keeps connecting exactly as it does today. Plexara adds the governed AI agent surface on top, and analysts pick the BI tool or the agent per task. Adoption is additive rather than a migration. [Learn more: Trino Query: analytics and insights](https://plexara.io/learning/mcp/trino-query-analytics-and-insights) Yes. The retail and public media stories are anonymized accounts of real Deasil Works engagements. Names, specific metrics, and identifying details are withheld, but the arc is real: siloed AI, one governed connection across data and APIs, corrections that became knowledge, and a client that connected its own agents. Next ### Retail Use Case A seasonal retailer whose whole year peaks in one week, and the agent that helped carry it. [Continue](https://plexara.io/use-cases/retail) --- # The Whole Year Comes Down to One Week URL: https://plexara.io/use-cases/retail/ > A retail client story from Deasil Works: capacity models from live telemetry, release-day verification, fraud scoring, and a day of analyst work done in twenty minutes. ## The Whole Year Comes Down to One Week This retailer sells most of what they sell in the days around one summer holiday. Hundreds of stores and seasonal pop-ups, a point-of-sale platform, and the clusters underneath all have to hold at once. Deasil Works connected the entire operation to Plexara. This is what the agent did during the season that followed. 13 Governed connections Databases, APIs, metrics, and logs behind one MCP endpoint 3 Storage engines in one query Search-index aggregations joined to the operational store and the ERP warehouse in a single federated SQL statement 20 min For a day of analyst work Ad-hoc analysis that consumed a specialist for a day now takes minutes of agent work plus a human review pass 71 Assets in five months Dashboards, forecasts, audits, and reports saved to the shared portal Counts read live from the production platform, July 2026. The Setup ### Everyone Had AI. Nobody Had the Same AI. Deasil Works develops and supports this retailer's complete stack: the point-of-sale platform, the transactional databases, the ERP integration, the Kubernetes clusters, and the BI reporting on top. AI made every individual on that team faster, and then progress stopped. Every developer, analyst, and administrator had wired up their own tools and their own prompts, with their own private fixes for grounding the model in truth. The knowledge needed to break through that ceiling was trapped in each silo. Plexara replaced the silos with one governed connection to everything, and the sections below are what happened next. None of it is hypothetical: every artifact described on this page exists on the client portal, dated and attributed. The Connection ### Everything the Agent Can Reach Thirteen connections behind a single MCP endpoint, each one authenticated, permission-scoped, and audited. An agent can trace a question from a sales number to the database that recorded it, to the pod that processed it, to the log line it left behind. Data - Operational store Cassandra: locations, products, users, inventory - Search indexes Elasticsearch: every transaction, tenant by tenant - ERP warehouse PostgreSQL: store mappings and card reconciliation - Catalog and objects Enriched DataHub catalog, S3 exports APIs - Card settlement 44 governed operations against the processor - Pipeline orchestrator NiFi: 154 operations for freshness and health - Platform admin Self-configuration, every write audited Operations - Kubernetes, read-only 132 operations across the serving clusters - Prometheus, two stacks Cluster metrics and the database ring - Loki, two stacks Application logs and database host logs One governed MCP endpoint Authentication, per-persona permissions, semantic enrichment, and a full audit trail on every call - Claude Desktop - Claude Code - IDE assistants - Any MCP client One Question, One Query ### Three Engines in a Single Round Trip How is the season tracking, by location, right now? Answering that means an aggregation over millions of transactions in the search index, enriched with store names and live status from the operational database. The agent does it in one federated SQL statement, not three queries stitched together by hand. Search indexes Aggregate millions of sales events in place Operational store Resolve location names, formats, and live status Business definitions Cash-basis rules captured from the finance team One federated query Joined across engines by the platform, not by the analyst Season to date, by location The finance team's number, computed the same way every single time The definition is the point. Cash-basis net revenue here means netting out returns, loyalty-point tenders, and gift card sales, rules that used to live in one analyst's head. They now live in a saved prompt, so anyone who asks gets the finance team's number, not an approximation of it. The Season ### What the Agent Shipped Under Pressure A sample from the seventy-one artifacts on the client portal, every one generated in conversation and saved with full provenance. #### The peak-day capacity model Built from live telemetry across both metric stacks and anchored to a June load test. Projected peak-day load came in near one percent of the measured ceiling: a number the client could plan against instead of a guess. #### The datacenter-loss analysis The agent read live cluster state and documented the three-site topology, quorum by quorum: lose an entire datacenter and the peak still gets served. The operations team reviewed the analysis; they did not have to write it. #### Release-day verification A point-of-sale version rolled out wide in the middle of the season. By end of day the agent had confirmed a 99.6 percent cutover, zero ingestion gaps, and six data-integrity checks passing, with the three straggler registers identified by name. #### Loyalty fraud scoring Asked to examine manager-override-locked loyalty accounts, the agent scored 672 of them: risk tiers, transaction-velocity histograms against the fraud-system limit, and a worked list of the accounts worth investigating first. #### Proof on a record day A record sales day looked too good, and the client said so. The agent fingerprinted every transaction on the day, by identity and by content, and proved none were duplicates. Skepticism answered with evidence, the same day it was raised. #### The return-rate anomaly scan Returns per thousand transactions, per location, season over season, scored against the system baseline. Built to surface the locations that are genuinely anomalous instead of flagging rare-return noise. Compounding ### Five Months in Production The portal tells the story in timestamps. The early assets are simple dashboards. By the peak, the agent is doing capacity engineering, fraud analysis, and live operations reporting, because every month taught it more of the business. 1. March #### First dashboards Loyalty utilization year over year, discount analysis across store formats, top locations. The agent learns the sales data and its first business definitions. 2. April #### Into the ERP Inventory operations dashboards against the ERP warehouse, and the first knowledge-capture engagement report: the platform measuring its own learning. 3. May #### Growth analytics Footprint versus same-store growth decompositions, and an architecture diagram of the backend that the agent drew itself from what it had learned. 4. June #### The hard part A load test, the capacity model, release-day rollout verification, the fraud dashboard, and the duplicate-sales proof, all in the three weeks before the peak. 5. July #### The peak, and after A deep operations report on the peak day itself, spanning cluster metrics, logs, and the database ring. Two weeks later, a new card-settlement API connection was added and briefed to the team the same day. The Handoff ### Then the Client's Own Agents Connected For months, Plexara was internal to Deasil: a way to serve this client faster. Then we connected the client's own agents. Questions that used to be a ticket to us, they now ask directly, and the answers come from the same governed connections, the same definitions, and the same accumulated knowledge. Our role shifted from doing the analysis to teaching the agents. A question answered once stays answered. When the client doubted a number, the proof was one conversation away. That is the economics of the platform: the work of finding an answer leaves durable value behind instead of evaporating into a closed ticket. Beyond Retail ### The Expert Your Next Model Inherits Today's frontier models are extremely capable, and they know nothing about your company: the fiscal calendar, the loyalty-point math, the test register that has to be excluded from every report. Plexara exists to close that gap. It is the team member who knows everything, is eager to learn, and shares by default. Whatever capability next year's models arrive with, an organization running Plexara hands them the entire operation's context on day one. Next ### Public Media Use Case The other side of the practice: years of analysis expertise turned into knowledge an agent can hold. [Continue](https://plexara.io/use-cases/public-media) --- # Teaching the Agent Everything We Know URL: https://plexara.io/use-cases/public-media/ > A public broadcaster story from Deasil Works: a knowledge loop that turns corrections into shared truth, audiences built in an afternoon, and a client that inherited the workflow. ## Teaching the Agent Everything We Know Deasil Works spent years as the data department behind a public broadcaster: fourteen systems, one warehouse, and every anomaly, ad-hoc report, and pipeline quirk in between. Plexara is how that expertise became something an agent can hold, and how the client inherited it. 17 Live connections The warehouse, the OLAP layer, object storage, the catalog, and thirteen APIs 1,400+ Governed API operations From a 577-operation CRM API to a nine-operation membership vault, every call authenticated and audited 9 Canonical knowledge pages Query routing, ratings math, the membership lifecycle: reviewed truth, not tribal memory 67 Assets in five months Dashboards, audience briefs, recovery reports, and onboarding guides on the shared portal Counts read live from the production platform, July 2026. The Expertise ### Years of Analysis Made Deasil the Expert The client is a regional public broadcaster with a national online presence: broadcast, streaming, membership, and events. Deasil manages their data warehouse and operates the pipelines that feed it from more than a dozen sources: Nielsen, Google Analytics, YouTube, Blackbaud, Iterable, zkipster, Hightouch, Sprout Social, Domo, and more. Years of anomaly hunts, ad-hoc reports, and pipeline debugging made us expert in every idiosyncrasy of that estate. Documentation captured some of it. Onboarding a new analyst still took months, because the real knowledge lived in people. That knowledge is exactly what Plexara is built to hold. The Estate ### Fourteen Systems, One Endpoint Frontier models already know what Nielsen is and what YouTube data looks like. What they cannot know is how this organization's pipelines shape that data, or what each field means to each department. Plexara puts both within reach: the systems, and the accumulated understanding of them. Data - Warehouse Ratings, streaming, web, email, and CRM, federated - OLAP indexes OpenSearch mirrors for fast aggregation - Catalog and objects Enriched DataHub catalog, S3 exports APIs - CRM system of record 577 operations: constituents, gifts, events - Email marketing 148 operations: campaigns, opens, clicks - Video and membership Media management and the membership vault - Events, social, BI, files Guest lists, social analytics, reverse-ETL Operations - Pipeline orchestrator NiFi: 102 operations for flows and freshness - Kubernetes 131 operations across the platform workloads - Platform admin Self-configuration, every write audited One governed MCP endpoint Authentication, per-persona permissions, semantic enrichment, and a full audit trail on every call - Claude Desktop - Claude Code - IDE assistants - Any MCP client The Method ### Ask the Agent First Deasil adopted a rule for every client request: ask the agent before reaching for tribal knowledge. The loop below is what turns that habit into an asset the whole organization owns. 1. 1 #### Ask Every client request goes to the agent first, with the context we would give a new hire. 2. 2 #### Fail visibly A human mentor forgets to hand over context. The agent makes the omission obvious: it gets the answer wrong. 3. 3 #### Capture The correction becomes a captured insight: what counts as a donor, why the prospect feed has a v2, which metrics must never be summed. 4. 4 #### Review An expert reviews the queue, merges related insights, and resolves contradictions before anything becomes shared truth. 5. 5 #### Know Approved knowledge lands in the catalog and the knowledge pages. Every future session, by anyone, starts from it. Nine canonical pages exist today, covering query routing, ratings mathematics, the membership lifecycle, and the pipeline stack. Every pass through the loop leaves the platform knowing more than the last. In Practice ### Work That Used to Be a Project A sample of the sixty-seven artifacts on the client portal. Each one was a conversation, and each one stayed: dated, attributed, and reusable. #### A win-back audience in an afternoon Expired members who were fans of one original series: 991 people, built from consented viewing data joined to the prospect feed, with hours watched and episodes per fan attached. The privacy constraint was honored in the query, not in a caveat. #### An acquisition brief that argues back Asked for a conversion audience, the agent tiered 37,000 prospects by streaming device and email engagement, and flagged that viewing history was not a usable signal for non-members. It knew the consent rules better than the request did. #### Cross-system correlation Membership records joined to 336,000 email click events, with bots and two high-volume scanner accounts excluded. The kind of analysis that used to need two specialists and a week of calendar time. #### Root cause across the fence Monthly analytics were missing browser users. The agent traced the gap through the pipeline to an upstream vendor intermittently dropping a required tag, and shipped the evidence queries along with the verdict: the fix belongs to the vendor. #### Pipeline recovery, verified After a webhook ingestion bug was fixed, the agent inventoried all forty affected event syncs, confirmed the two-month backlog had recovered, and left a cross-reference report behind for the next person who asks. #### A first look at every connection Every new API connection gets an agent-authored capability brief the same day it lands. The newest one was connected, tested against thirteen live profiles, and documented for the team in a single session. Compounding ### From First Question to Working Cadence The portal tells the story in timestamps: exploration first, then capability briefs, then audience engineering, then a monthly rhythm the client runs with us. 1. March #### First questions Streaming dashboards, constituent geography, and the first data-quality root cause: a missing-users issue traced upstream with evidence attached. 2. May #### A first look at everything Ten agent-authored capability briefs, one per connection, plus a team onboarding guide. Each new API arrives already explained. 3. June #### Audience engineering The new prospect feed launches with a brief for engineers, a guide for marketing, and the win-back and acquisition audiences built on top of it within days. 4. July #### A working cadence A monthly review with the client, ratings reach reports after a vendor fix, and a social analytics connection added and briefed the same morning. The Pattern ### The Second Request Is Cheap Client questions are often iterations on questions already answered. That ad-hoc report from last year: we need it again, but with one new dimension. Two things make the second request cheap. Developing the report the first time produced insights that were captured and synthesized into knowledge: what the data means, where it lives, how to get it. And the report itself has requirements that are not business knowledge at all: which sections, which columns, the language, the audience. That belongs in a saved prompt, not the knowledge base. Knowledge describes the data and the business. Prompts describe what to do with them. The Handoff ### Handing the Client the Keys Giving the client this workflow meant connecting their agent to Plexara, a five-minute task per seat. Any employee with an AI assistant can now make that assistant an expert on the business. The onboarding guide is an asset on the portal, and adoption is reviewed with the client every month. Our role shifted from answering questions to curating what the platform knows. The arc of our practice describes the change: from ad-hoc data analysis, to prompt engineering, to knowledge engineering. The Practice ### What Deasil Uses First Plexara is something Deasil offers its customers, and it is what we use first ourselves. Sometimes the exchange runs the other way: the agent has found things in the data that even we did not know were there, gaps nobody had thought to look for. This is what the partnership between a human expert and an agent looks like in practice. The client did not just get faster answers. They inherited the expertise that produces them. Next ### Use Cases The capabilities behind both stories: using data and invoking APIs, and how they compound. [Continue](https://plexara.io/use-cases) --- # Plexara Research URL: https://plexara.io/benchmark/ > Controlled, open benchmarks of the platform: published raw data, fully reproducible source code, and DOI-archived reports anyone can run and any researcher can build on. Plexara research ## We test Plexara in public The performance claims on this site come from controlled studies, and we publish the whole study: the method, the raw run data, and the code that turns one into the other. If a number looks too good, don’t take our word for it. Download the runs and check. When the data kills one of our own ideas, we publish that too. Explore the studies [Run them yourself](https://github.com/txn2/mcp-data-platform/tree/main/bench) ### What we publish with every study A benchmark you cannot rerun is an ad. Each of ours ships as a working repository, and these four things come with it: The report A brand-neutral technical report in the open-source project, with a frozen PDF and a snapshot of its data archived on Zenodo under a citable DOI. Other vendors and researchers are welcome to cite it, argue with it, or build on it. The raw runs Every graded attempt, full transcript, and run manifest, committed to the repository. If you want to know why one answer was marked wrong at 2:14 on a Tuesday, the transcript is in the tree. The code The harness, the deterministic fixtures and seed generators, the graders, and the analysis scripts. Every table and figure regenerates offline from the committed data. No API key, no network access. The protocol Decision rules written down before the data comes in, and headline runs pinned to tagged releases so the exact build behind a number stays buildable. When a pre-registered hypothesis fails, the failure stays on the public record next to the runs that killed it. ### Why we benchmark Plexara runs in production for real clients, answering real questions every day, and that field record tells us the approach works. Field experience does not tell you by how much, on which kinds of question, or where to aim the next round of engineering. For that you need a number you did not choose: a controlled study that holds everything constant except the thing under test. The studies also decide what we build. When the knowledge-use study falsified our pre-registered hypothesis about staleness metadata, we dropped the features that hypothesis would have justified before writing a line of product code, and the same data pushed capture filing and input validation up the roadmap instead. The knowledge-pollution study broke a prediction of ours again, from the other direction. We planted a wrong fact through our own review queue expecting the dangerous one to be the fact nobody can check, and the data said the opposite: the claims that spread are the ones the platform could have verified against your data before approving them. That is now where the review tooling is aimed. The graph-completion study is what publishing a dead idea looks like in practice. Its pre-registered instrument kill fired, retiring the grand claim we hoped to make about references between knowledge pages, and the published report leads with the kill beside what survived: references hold the cost of discovery flat as a knowledge base grows a hundredfold, and they are the only route that works when search is off or the reading budget is small. #### The research series Each study in the series is published brand-neutral in the open platform project, archived with its raw run data under a citable DOI, and reproducible offline from the committed attempts. New studies join the series as they are published. The accuracy study · 2026-07-18 #### Does the platform make an agent measurably more accurate on your data? On questions that turn on a business rule, accuracy rose from 42.7% to 98.7%. A companion cold-start experiment taught a fresh install six facts one at a time and watched each question class unlock at its own lesson, and a lifecycle re-run measured a fact taught by one person being reused correctly by a different teammate 98.9% of the time. [Read the accuracy study](https://plexara.io/benchmark/accuracy) [DOI 10.5281/zenodo.21438044](https://doi.org/10.5281/zenodo.21438044) [Report + raw data on Zenodo](https://zenodo.org/records/21751635?preview_file=benchmark-report-knowledge-layer-v2.0.1.pdf) The knowledge-use study · 2026-07-26 #### Does an agent actually use the knowledge the platform delivers? Agents rely completely on delivered knowledge they cannot re-derive: conventions, definitions, policies. With the company definition delivered, confident fabrication fell from 75% to zero, and capable models re-verified every claim they could check. [Read the knowledge-use study](https://plexara.io/benchmark/knowledge-use) [DOI 10.5281/zenodo.21614059](https://doi.org/10.5281/zenodo.21614059) [Report + raw data on Zenodo](https://zenodo.org/records/21614059?preview_file=benchmark-report-knowledge-use.pdf) The knowledge-pollution study · 2026-08-07 #### What does a wrong fact cost once it has cleared review? A wrong fact never out-argued the correct source sitting beside it. It did something quieter: on a small model it suppressed the one query that would have refuted it, and every run that ran that query anyway answered correctly. The frontier-class models we run in production took the wrong answer zero times in 96 runs. [Read the knowledge-pollution study](https://plexara.io/benchmark/knowledge-pollution) [DOI 10.5281/zenodo.21834813](https://doi.org/10.5281/zenodo.21834813) [Report + raw data on Zenodo](https://zenodo.org/records/21834813?preview_file=benchmark-report-knowledge-pollution.pdf) The graph-completion study · 2026-08-10 #### What do references between knowledge pages buy an agent that has to be complete? Asked to write complete operational documents, agents followed references between knowledge pages voluntarily, grounded every governing constraint while reading 0.2% of a 5,000-page corpus, and kept discovery cost flat as the corpus grew a hundredfold; without the references, cost roughly doubled and the only failed episode appeared. With search off, references were the only route that worked: 96% of constraints recovered against zero. One pre-registered construct died by its own kill condition, and the kill is published with the result. [Read the graph-completion study](https://plexara.io/benchmark/graph-completion) [DOI 10.5281/zenodo.21881798](https://doi.org/10.5281/zenodo.21881798) [Report + raw data on Zenodo](https://zenodo.org/records/21881798?preview_file=benchmark-report-graph-completion.pdf) #### Start from the archives Each Zenodo record holds the frozen report PDF and a snapshot of the raw run data behind it, hosted independently of us and of this site. The open repository holds the harness and every run since. [The accuracy study on Zenodo](https://zenodo.org/records/21751635?preview_file=benchmark-report-knowledge-layer-v2.0.1.pdf) [The knowledge-use study on Zenodo](https://zenodo.org/records/21614059?preview_file=benchmark-report-knowledge-use.pdf) [The knowledge-pollution study on Zenodo](https://zenodo.org/records/21834813?preview_file=benchmark-report-knowledge-pollution.pdf) [The graph-completion study on Zenodo](https://zenodo.org/records/21881798?preview_file=benchmark-report-graph-completion.pdf) [Benchmark harness on GitHub](https://github.com/txn2/mcp-data-platform/tree/main/bench) --- # The Accuracy Study URL: https://plexara.io/benchmark/accuracy/ > The semantic layer lifted accuracy on business-rule questions from 42.7% to 98.7%, a +56-point gain over bare data tools, and a fresh install with an empty knowledge layer visibly learned each fact it was taught. Plexara research · The accuracy study ## 43% → 99% On business-context questions, where the right answer depends on a rule that is not in the raw data, the same AI went from confidently wrong to reliably right. The only thing we changed was the platform underneath it. And in a companion cold-start experiment, a fresh install with an empty knowledge layer visibly learned: each fact it was taught snapped its question class from floor to ceiling. +56 pts knowledge-trap accuracy (95% CI +44 to +67) 13%→100% net-revenue questions, once the agent knew the house rule 47%→91% cold start: fresh install taught facts one at a time (k = 3) 1,044 graded answers behind these numbers, every task run three times Read the full report [Reproduce it yourself](https://github.com/txn2/mcp-data-platform/tree/main/bench) Plexara Research · Technical Report ### Ablating the platform and learning from empty: controlled measurements of a semantic MCP layer on agent data-question accuracy Plexara, a product of Deasil Works · 2026-07-18, report v2.0.1 2026-08-01 · Model: claude-sonnet-5 · Data and code: [txn2/mcp-data-platform](https://github.com/txn2/mcp-data-platform/tree/main/bench) · DOI: [10.5281/zenodo.21438044](https://doi.org/10.5281/zenodo.21438044) Abstract We measure whether an AI agent connected to a semantic data platform answers real data questions more correctly and efficiently than the same agent connected to bare data tools. Two complementary studies are reported. The first ablates the platform, not the model: every run holds the model, prompt scaffold, seed data, and task set constant and varies only the platform configuration across four arms. Over 261 graded attempts per arm at three repeats, the semantic layer lifts knowledge-trap accuracy from 42.7% to 98.7%, a +56.0-point gain (95% bootstrap CI +44 to +67), while reaching a correct answer in fewer tool calls (median 16 to 10) than bare tools reach a mostly-wrong one. Discovery and arithmetic tasks are near ceiling for every arm, localizing the platform’s effect to exactly the questions where a fact outside the raw data disambiguates a plausible-but-wrong answer. The companion cold-start experiment starts the platform from an empty knowledge layer, the fresh-install scenario, and teaches six business facts one at a time: trap accuracy climbs from a baseline that reproduces across five independent runs (mean 47.2%) to 90.7% at three repeats and 100% at one, with each taught fact jumping from floor to ceiling at its own promotion checkpoint. Every number carries a bootstrap confidence interval, derives from the platform’s own audit log, and regenerates from committed raw data with a single notebook run. This page presents the results with commercial framing. Citing this research? Cite the brand-neutral report published in the open-source project, archived with its raw data on Zenodo under DOI [10.5281/zenodo.21438044](https://doi.org/10.5281/zenodo.21438044). That is the concept DOI and always resolves to the latest version; to pin the exact snapshot these numbers came from, cite [10.5281/zenodo.21751635](https://doi.org/10.5281/zenodo.21751635) (v2.0.1). The report’s final section gives the suggested citation and BibTeX. ### 1. Why measure the platform, not the model Almost every AI-on-your-data failure looks the same in production: the query runs, the arithmetic is fine, and the answer is confidently, professionally wrong. The missing piece is rarely a tool. It is a fact about the data the tools touch: amounts stored in cents, revenue defined net of discounts, a fiscal year that starts in February, a table that was deprecated eighteen months ago and still looks authoritative. Semantic enrichment, the automatic attachment of that context to every tool result, is the core capability Plexara is built around, and it works alongside the rest of the platform: the API gateway that turns OpenAPI services into semantically discoverable tools, and the memory-to-knowledge lifecycle that captures what agents learn and promotes it into durable, shared context. Plexara runs in production for real clients, answering real questions every day, and that field record told us the approach works. Field experience does not tell you by how much, on which questions, or where to aim the next round of improvement. Benchmarks are how we turn thousands of production successes into controlled, repeatable evidence. So we built a benchmark whose single design commitment is that the model is never the variable. Every run uses the same model, the same prompt scaffold, the same seed data, and the same tasks; only the platform configuration changes. Any difference in the answers is therefore attributable to the platform and nothing else. This inverts the usual agent benchmark, which compares models against a fixed set of tools; here the tools ablation is the experiment. The effect concentrates exactly where the BIRD text-to-SQL benchmark measured a roughly 20-point external knowledge gap using hand-curated evidence, except the platform retrieves that evidence automatically rather than having a human paste it in. A companion cold-start experiment then asks the harder longitudinal question: starting from a completely empty knowledge layer, does the platform visibly learn as facts are taught to it, the way a fresh installation learns on the job? ### 2. Method The four **arms** are platform configuration profiles, not code forks. Each turns on exactly one more layer, so the ladder isolates where value enters. - A0 raw tools The underlying data tools directly (trino_*, s3_*): no semantic provider, no search, all cross-enrichment off. Equivalent to wiring the standalone toolkit libraries. - A1 enrichment A0 plus semantic cross-enrichment: tool results carry DataHub context automatically, but the agent still has no search and no datahub_* tools. Isolates enrichment from discovery. - A2 platform The shipped semantic-first platform: A1 plus the search tool, the search-first gate, and curated knowledge pages. - A3 lifecycle A2 plus the memory and apply_knowledge lifecycle. On single-session S1 to S3 tasks it tracks A2; the lifecycle effect is what the S5 protocols measure. Three **suites** test different things. S1 discovery is straightforward lookups; S2 analytical accuracy is exact numeric answers, four of which emit SQL graded by executing both the candidate and a reference query and comparing result sets; S3 knowledge traps are questions with a plausible-but-wrong answer whose disambiguating fact lives in business knowledge, not the raw data. Grading is deterministic, scoring only the first line after a mandated FINAL ANSWER marker. The platform’s own audit log is the measurement instrument: the harness mints a session handle, threads it invisibly, and reads efficiency metrics back from the admin audit API, failing loudly when a session’s audit rows fall outside its client-side accounting. Attempts that fail at the harness level never grade and are reported separately. Ground truth is generated from one fixed-seed dataset model and computed from the generated rows, never hand-typed. Accuracy is the per-attempt average across k = 3 repeats with a 95% percentile bootstrap CI; pass^3 is the stricter all-or-nothing bar of passing every one of the three attempts, following tau-bench. The ablation ran on the Anthropic API adapter; the cold-start study ran through the Claude Code client. The two client paths shift accuracy in ways that have nothing to do with the platform (the client inserts its own system prompt and retry policy), so the harness records the client version and refuses to fold them into one leaderboard. The two studies are reported separately and no cross-path accuracy comparison is drawn. ### 3. Results: the surfacing effect (S1 to S3) Discovery and arithmetic are near ceiling for every arm: a capable model finds tables and computes sums without help. The entire separation is in S3, where the answer depends on a fact outside the data. Knowledge-trap accuracy climbs 42.7% to 57.3% to 98.7% as the two surfacing channels come online, a +56.0-point gain for the full platform over bare tools. [Image: Bar chart of S3 knowledge-trap accuracy by arm: A0 42.7%, A1 57.3%, A2 98.7%, A3 98.7%, with 95% confidence intervals and a +56.0 point bracket from A0 to A2.] Figure 1. S3 knowledge-trap accuracy by platform configuration (k = 3, 75 graded attempts per arm). Error bars are 95% bootstrap CIs. The platform closes a +56.0-point gap over bare tools. | Suite | A0 | A1 | A2 | A3 | | --- | --- | --- | --- | --- | | S1 discovery | 98.0 [94–100] | 98.0 [94–100] | 100.0 [100–100] | 98.0 [94–100] | | S2 analytical accuracy | 100.0 [100–100] | 100.0 [100–100] | 97.8 [95–100] | 97.8 [95–100] | | S3 knowledge traps | 42.7 [32–55] | 57.3 [45–68] | 98.7 [96–100] | 98.7 [96–100] | | Overall | 83.1 [79–88] | 87.4 [83–91] | 98.5 [97–100] | 98.1 [96–100] | [Image: Grouped bar chart of accuracy by suite for all four arms, showing S1 and S2 near 100% for every arm and S3 as the only suite that separates the arms.] Figure 2. Accuracy by suite across arms. S1 and S2 sit near ceiling for every configuration; the platform value is concentrated in S3, not in easy lookups. The trap-class breakdown shows the mechanism, and it is legible. The two surfacing channels carry different facts. Units-in-cents and net-revenue live in DataHub column and dataset descriptions, so the cross-enrichment channel alone (A1) lifts them materially (62 to 88, 13 to 43). Fiscal-calendar and tier-boundary live only in knowledge pages, invisible to enrichment, so A0 and A1 score 0% and only the search channel (A2) recovers them. Each trap is defeated exactly when the channel that carries its fact is switched on. [Image: Heatmap of S3 accuracy for six trap classes across four arms, showing enrichment-carried facts recovering at A1 and page-only facts recovering only at A2.] Figure 3. S3 accuracy by trap class and arm, computed from the committed per-attempt records. Enrichment-carried facts (top rows) recover at A1; knowledge-page-only facts recover only once search is added at A2. | Trap class | Fact lives in | A0 | A1 | A2 | A3 | | --- | --- | --- | --- | --- | --- | | Units in cents | column / dataset description | 62 | 88 | 98 | 98 | | Net revenue | column / dataset description | 13 | 43 | 100 | 100 | | Fiscal calendar | knowledge page only | 0 | 0 | 100 | 100 | | Freshness cutoff | description + page | 92 | 100 | 100 | 100 | | Tier boundary | knowledge page only | 0 | 0 | 93 | 100 | | Deprecated table | metadata + page | 100 | 100 | 100 | 100 | Efficiency moves the same direction. On the knowledge traps the platform reaches a correct answer in fewer calls (median 16 to 10) than bare tools reach a mostly-wrong one: without the disambiguating fact the model flails, issuing exploratory queries and reasoning in circles. On the easy suites the platform pays a small friction cost as the model adopts the search-first workflow, consistent with its value concentrating where knowledge decides the answer. [Image: Grouped bar chart of median tool calls by suite and arm, highlighting the drop from 16 to 10 calls on S3.] Figure 4. Median tool calls by suite and arm, read from the audit log. Fewer is better. The platform answers S3 correctly in fewer steps than bare tools take to answer it wrongly. | Suite | A0 | A1 | A2 | A3 | | --- | --- | --- | --- | --- | | S1 discovery | 6 | 5 | 8 | 7 | | S2 analytical accuracy | 6 | 6 | 9 | 9 | | S3 knowledge traps | 16 | 11 | 10 | 11 | ### 4. Results: learning from empty (cold start) The ablation seeds the knowledge layer up front and asks whether the platform delivers what it holds. The cold-start study asks the harder question a new deployment actually faces: starting from a completely empty knowledge layer (entities present, but no descriptions, tags, glossary, or knowledge pages), does the platform get measurably smarter as it is taught? Six business facts are taught one at a time through ordinary agent sessions; each captured insight is promoted to a durable sink, a DataHub description or a knowledge page, and after every promotion the full 25-task trap suite is re-run by a fresh evaluator identity that was never taught anything. Any knowledge reaching the evaluator had to travel through the platform itself. [Image: Cold-start learning curve: k = 3 accuracy with a 95% confidence band rising from 48.0% at the empty baseline to 96.0% and 90.7% at the final checkpoints, with the k = 1 companion run reaching 100% and five baseline runs clustered between 44% and 52%.] Figure 5. Cold-start learning curve on the fixed trap suite (75 graded attempts per checkpoint at k = 3). The empty-layer floor reproduces across five independent runs (44, 44, 47.8, 48, 52 percent); accuracy climbs to 96.0% as facts are promoted. | Checkpoint | Fact promoted | k = 3 accuracy | k = 1 accuracy | | --- | --- | --- | --- | | 0 | none (empty baseline) | 48.0 [37–60] | 44.0 | | 1 | Units in cents (DataHub) | 41.3 [31–53] | 48.0 | | 2 | Net revenue (knowledge page) | 50.7 [40–61] | 62.5 | | 3 | Fiscal calendar (knowledge page) | 70.7 [60–80] | 76.0 | | 4 | Freshness cutoff (DataHub) | 70.7 [60–80] | 68.0 | | 5 | Tier boundary (knowledge page) | 96.0 [91–100] | 100.0 | | 6 | Deprecated table (never captured) | 90.7 [84–96] | 100.0 | The aggregate curve climbs from a five-run baseline floor averaging 47.2% to 90.7% at k = 3, and the k = 1 companion run reaches 100%. But the aggregate is not where the evidence is strongest. The per-class trajectories are: each taught fact jumps from its floor to its ceiling at or immediately after its own promotion checkpoint. The fiscal-calendar questions sit at 0% for three straight checkpoints, then hit 86.7% the moment that fact is promoted. The tier-boundary questions sit at 0% for five checkpoints, then hit 100% at their own promotion. The platform does not drift upward; it learns each specific fact when taught, which is the causal signature a learning curve should have. [Image: Six small panels, one per trap class, each showing accuracy across the seven checkpoints with a dotted line at that class's promotion checkpoint. Fiscal calendar and tier boundary jump from 0% to near 100% exactly at their own promotion.] Figure 6. Per-trap-class accuracy by checkpoint in the headline k = 3 run, computed from the committed per-attempt records. The dotted line marks each class's own promotion checkpoint. Facts the model cannot guess (fiscal calendar, tier boundary) unlock precisely when taught. A bonus arm strengthens the story. One earlier run captured five lessons but promoted none of them to a sink, so its knowledge could reach evaluators only through the platform’s captured-memory channel. It still climbed from 52% to 96%. The memory layer is a working delivery channel in its own right, before promotion ever runs; promotion then makes the knowledge durable, shared, and visible in the catalog. ### 5. Results: a taught fact reaching the next person (S5) S1 to S3 tests whether the platform delivers knowledge already present in its sinks, and the cold-start study shows the whole loop working end to end. The S5 suite instruments that loop stage by stage: whether a brand-new fact can be captured in one session and reach a later, separate session or a different person. There is no meaningful memory-off baseline here. A recall task with no memory scores 0% by construction, so S5 reports whether each stage of the lifecycle works, not an accuracy delta. The headline is the last stage. A fact one person teaches the platform is reused correctly by a different identity 98.9% of the time (95% CI 96.8 to 100.0, 94 of 95 transfer attempts). The teammate never saw the original conversation and was never told the fact existed; it reached them through the platform or not at all. The run behind that: 30 lifecycle protocols on claude-sonnet-5, k = 5 as five independent passes merged, leaving 149 protocol-runs after one harness exclusion, on platform build `v1.118.0-4-g445e3abc`. Sections 3 and 4 above are pinned to v1.102.x and are unchanged; this section is a later platform generation, so the sections are **not mutually comparable** and no number should be carried across that boundary. [Image: Dot-and-interval plot of eight lifecycle metrics with 95% confidence intervals, each paired with the prior report's reading: transfer rate moves from 46.7% to 98.9%, capture from 82.2% to 91.9%, duplicate rate from 42.9% down to 22.0%, and full-lifecycle pass from 20.0% to 63.3%.] Figure 7. Lifecycle metrics at k = 5 with 95% bootstrap confidence intervals (filled), against the prior report's reading on v1.102.0 at k = 3 (open). The two builds are different platform generations, so each pair is an across-code comparison, not a resampling. | Metric | Rate (95% CI) | num/den | Prior report v1.102.0, k = 3 | What it measures | | --- | --- | --- | --- | --- | | Capture rate | 91.9 [87.2–96.0] | 137/149 | 82.2 | the agent recorded the taught fact and entity-linked it | | Personal recall | 95.3 [91.9–98.0] | 142/149 | 84.4 | a fresh same-identity session answered the fact-dependent question | | Unprompted surface | 100.0 | 137/137 | 100.0 | among captured runs, search surfaced the saved memory unprompted | | Transfer rate | 98.9 [96.8–100.0] | 94/95 | 46.7 | a different identity answered correctly after promotion to shared knowledge | | Update correctness | 100.0 | 41/41 | 100.0 on 7/7 | a correction flipped a later recall to the new value | | Duplicate rate (lower is better) | 22.0 [9.8–34.1] | 9/41 | 42.9 on n = 7 | a supersede that left more than one live insight | | Abstention | 92.6 [87.9–96.6] | 138/149 | 95.6 | the agent refused to fabricate a fact it was never taught | | Full-lifecycle pass^5 | 63.3 [46.7–80.0] | 19/30 | 20.0 pass^3 | every applicable stage passed all five attempts | The prior report’s reproducible lifecycle finding was the opposite of this one: a fact promoted to shared knowledge reached a different identity under half the time (46.7%). That gap is closed, and it closed for a nameable reason rather than a larger sample. A targeted change moved the visibility boundary to the act of applying an insight, which is the exact path the 46.7% measured. The prior report guessed the gap was a capture-and-propagation limit rather than a surfacing failure; that reading is consistent with what the fix turned out to require. The small-denominator limitation the prior report named is also resolved. Supersede now carries 41 observations rather than 7, so duplicate rate is a point estimate at 22.0% inside a 24-point interval where it used to be a 72-point range spanning most of the scale, and update correctness holds at ceiling across a denominator six times larger. Two rows in that table need reading carefully rather than at face value. **Capture rate at 91.9% is not a capture-reliability number.** All 12 misses are attempted-and-failed, none are captures never tried, and they concentrate on 2 of the 30 protocols. The transcripts show the capture succeeding while the model links the fact to the wrong entity, so the harness’s linked-insight check does not find it where it looked. It is a filing defect, it reproduces deterministically, and it is on the register to fix. **The transfer decomposition understates delivery on purpose.** The taught fact was observably surfaced to the learner in 68.4% [58.9–77.9] of transfer attempts, and used in 98.5% of those. The distance between 68.4% surfaced and 98.9% correct is measurement conservatism, not the model deriving the answer unaided: the surfacing check requires the stored fact to appear as a literal normalized substring of a tool result, so it cannot over-report delivery. All 30 correct-but-not-surfaced episodes were read back against their transcripts, and in every one the agent searched and a tool result carried the protocol’s key term. There are no cases of a correct answer without the knowledge reaching the learner. ### 6. Reproducibility Every number and every figure on this page regenerates from raw run data committed to the open platform repository. A single notebook, `bench/reports/knowledge-layer/report.ipynb`, reads only the committed results files and recomputes every table and chart with no API key, no running platform, and no network access. The run manifests record the git commit, platform version, model, client version, seed, and task-set hash for provenance. To rerun the experiments themselves rather than the analysis: from a booted arm, the semantic-layer run and cross-arm comparison are two commands. ``` git clone https://github.com/txn2/mcp-data-platform.git cd mcp-data-platform make bench-up BENCH_ARM=a0 # then a1, a2, a3 make bench-run BENCH_ARM=a0 LLM=anthropic MODEL=claude-sonnet-5 K=3 make bench-compare # cross-arm tables + bootstrap CIs ``` The report and a snapshot of the raw run data are also archived on Zenodo under DOI [10.5281/zenodo.21438044](https://doi.org/10.5281/zenodo.21438044) (CC-BY-4.0), which always resolves to the latest version. The snapshot behind the numbers on this page is v2.0.1, DOI [10.5281/zenodo.21751635](https://doi.org/10.5281/zenodo.21751635), so the exact version behind them stays retrievable and citable even as the repository moves on. A [frozen PDF of the report](https://zenodo.org/records/21751635/files/benchmark-report-knowledge-layer-v2.0.1.pdf) is part of that archive. ### 7. Limitations - Results are model-dependent. The headline is arm-vs-arm and checkpoint-vs-checkpoint on a pinned model, never model-vs-model. - The ablation and the cold-start study ran on two different client paths (Anthropic API and the Claude Code client) that are not accuracy-comparable; no number in either study is compared across that boundary. - The seed dataset is small by design and airgapped; absolute accuracies are not real-world estimates. What the studies isolate, the platform effect holding everything else constant, is the point. - The S3 trap-class figure and table are recomputed from the committed per-attempt records, so they match this data exactly; two trap classes differ slightly from an earlier tagging in the upstream summary. The headline, suite, and overall numbers are unaffected. - In the cold-start runs the teacher never captured the deprecated-table lesson, so checkpoint 6 promotes nothing; the affected trap class was already at ceiling from the baseline, so the curve is not distorted, but it is a real capture-reliability data point. - This report spans two platform generations and the sections are not mutually comparable. The ablation and cold-start sections are pinned to v1.102.x; the lifecycle section was re-run on v1.118.0-4-g445e3abc. Differences between the lifecycle figures here and the ones the prior report published are across-code, not the effect of a larger sample, and no number should be carried across that boundary. - Capture rate at 91.9% carries a known filing defect rather than a capture failure: all 12 misses were attempted and recorded, but linked to the wrong entity, so the harness's linked-insight check missed them. It concentrates on 2 protocols and reproduces deterministically, which makes it a fix rather than a variance. - Duplicate rate at 22.0% has room to improve. Roughly one supersede in five leaves more than one live insight behind, which is a real housekeeping cost even though update correctness itself is at ceiling. It is a point estimate now rather than a range, so the next run can be held to it. ### 8. References 1. [1] Li et al. (2023). Can LLM Already Serve as a Database Interface? A Big Bench for Large-Scale Database Grounded Text-to-SQLs. NeurIPS. [link](https://arxiv.org/abs/2305.03111) 2. [2] Yao et al. (2024). tau-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains. Introduces the pass^k reliability metric. [link](https://arxiv.org/abs/2406.12045) 3. [3] Wu et al. (2024). LongMemEval: Benchmarking Chat Assistants on Long-Term Interactive Memory. [link](https://arxiv.org/abs/2410.10813) 4. [4] Anthropic (2024). Model Context Protocol: an open standard for connecting AI assistants to data and tools. [link](https://www.anthropic.com/news/model-context-protocol) #### The rest of the research series Each study in the series is published brand-neutral in the open platform project, archived with its raw run data under a citable DOI, and reproducible offline from the committed attempts. New studies join the series as they are published. The knowledge-use study · 2026-07-26 #### Does an agent actually use the knowledge the platform delivers? Agents rely completely on delivered knowledge they cannot re-derive: conventions, definitions, policies. With the company definition delivered, confident fabrication fell from 75% to zero, and capable models re-verified every claim they could check. [Read the knowledge-use study](https://plexara.io/benchmark/knowledge-use) [DOI 10.5281/zenodo.21614059](https://doi.org/10.5281/zenodo.21614059) [Report + raw data on Zenodo](https://zenodo.org/records/21614059?preview_file=benchmark-report-knowledge-use.pdf) The knowledge-pollution study · 2026-08-07 #### What does a wrong fact cost once it has cleared review? A wrong fact never out-argued the correct source sitting beside it. It did something quieter: on a small model it suppressed the one query that would have refuted it, and every run that ran that query anyway answered correctly. The frontier-class models we run in production took the wrong answer zero times in 96 runs. [Read the knowledge-pollution study](https://plexara.io/benchmark/knowledge-pollution) [DOI 10.5281/zenodo.21834813](https://doi.org/10.5281/zenodo.21834813) [Report + raw data on Zenodo](https://zenodo.org/records/21834813?preview_file=benchmark-report-knowledge-pollution.pdf) The graph-completion study · 2026-08-10 #### What do references between knowledge pages buy an agent that has to be complete? Asked to write complete operational documents, agents followed references between knowledge pages voluntarily, grounded every governing constraint while reading 0.2% of a 5,000-page corpus, and kept discovery cost flat as the corpus grew a hundredfold; without the references, cost roughly doubled and the only failed episode appeared. With search off, references were the only route that worked: 96% of constraints recovered against zero. One pre-registered construct died by its own kill condition, and the kill is published with the result. [Read the graph-completion study](https://plexara.io/benchmark/graph-completion) [DOI 10.5281/zenodo.21881798](https://doi.org/10.5281/zenodo.21881798) [Report + raw data on Zenodo](https://zenodo.org/records/21881798?preview_file=benchmark-report-graph-completion.pdf) [Explore the full research series](https://plexara.io/benchmark) #### Everything here is inspectable The benchmark harness, arm configurations, deterministic seed generator, graders, and the full published report all live in the open platform repository. Run the harness and every number on this page reproduces. [Full technical report](https://mcp-data-platform.txn2.com/reference/benchmark-report/) [Download the PDF](https://zenodo.org/records/21751635/files/benchmark-report-knowledge-layer-v2.0.1.pdf) [Archived report + data (DOI)](https://doi.org/10.5281/zenodo.21438044) [Benchmark harness on GitHub](https://github.com/txn2/mcp-data-platform/tree/main/bench) [The plain-language version](https://plexara.io/learning/insights/benchmarking-the-context-layer) --- # The Knowledge-Use Study URL: https://plexara.io/benchmark/knowledge-use/ > Agents rely completely on delivered knowledge they cannot re-derive. With the company definition delivered, confident fabrication of institutional facts fell from 75% to zero, and capable models independently re-verified every claim they could check. Plexara research · The knowledge-use study ## 75% → 0% Ask an agent a question that depends on your company’s internal definition and it rarely says it does not know. Three times out of four, it invented a plausible definition and answered confidently. With the platform delivering that definition, the invention stopped and the agent used the delivered rule in every attempt. The knowledge-use study maps when agents use, re-verify, or invent, and where a knowledge layer concentrates its value. 8/8 attempts in which the agent used the company definition we delivered 48/48 delivered claims the agent re-checked against live data before answering 2 models a frontier model and a small model, tested through two independent drivers 1 command regenerates every table in this report from the published raw data Read the full report [Reproduce it yourself](https://github.com/txn2/mcp-data-platform/tree/main/bench) Plexara Research · The knowledge-use study ### When agents use what they are told: derivability, model tier, and where a knowledge layer concentrates its value Plexara, a product of Deasil Works · 2026-07-26 · Models: claude-sonnet-5 and claude-haiku-4.5 · Data and code: [txn2/mcp-data-platform](https://github.com/txn2/mcp-data-platform/tree/main/bench) · DOI: [10.5281/zenodo.21614059](https://doi.org/10.5281/zenodo.21614059) Abstract Our accuracy study measured how much a knowledge layer improves an agent’s answers. This study asks the question underneath it: when an agent is handed knowledge by the platform it runs on, does it act on it? Across controlled cells at eight repeats each, run on a pinned platform release through two independent drivers, the answer has a two-factor structure. A strong model re-derives any claim it can check against live data, at any price we set (verification held at ceiling as the cost of checking was swept from one to eleven calls), so delivered observations of checkable state serve it as corroboration, never as a crutch. The same model relies completely on knowledge it cannot re-derive: a delivered internal reporting convention was used in every attempt, and without it the model confidently fabricated a plausible substitute definition in 75% of control attempts, against zero with it. A weaker model inverts the first regime, trusting answer-bearing notes instead of re-checking them, which makes delivered conventions safe on every tier tested and delivered world-state observations a strong-model workload. Read with the accuracy study, whose +56-point lift came precisely from non-derivable facts, the conclusion is consistent: the value of a knowledge layer concentrates in what agents cannot re-derive, which is exactly what Plexara captures, curates, and delivers. This page presents the results with commercial framing. Citing this research? Cite the brand-neutral report published in the open-source project, archived with its raw data on Zenodo under DOI [10.5281/zenodo.21614059](https://doi.org/10.5281/zenodo.21614059); the report’s final section gives the suggested citation and BibTeX. ### 1. The question the accuracy study left open The [accuracy study](https://plexara.io/benchmark/accuracy) established that the knowledge layer lifts accuracy by 56 points exactly where the answer turns on business context. A careful reader can still ask a sharper question: delivery is not use. The platform can surface a note into an agent’s context, but whether the agent acts on that note, re-checks it, or quietly ignores it is a fact about agent behavior that no amount of platform engineering can assume away. We do not assume what a model does. We measure it. The study also began by proving that discipline the expensive way. It started as a pre-registered benchmark of a different hypothesis: that agents under-verify perishable stored beliefs, and that adding freshness metadata (volatility class, observation age, recheck cost) would correct the deficit. The hypothesis was falsified at first empirical contact, and the falsification held under every mechanism check we could construct. Per the protocol’s own commitment, the falsified premise is recorded on the public issue, the runs that killed it are archived beside the runs that succeeded, and the feature ideas it would have justified were retired before a line of product code was written. What emerged from the wreckage is a cleaner and more useful result than the one we went looking for. ### 2. Method: a world that can change behind the agent The apparatus is a deterministic HTTP service behind the platform’s API gateway, serving a social-analytics-shaped catalog: monitors, trend series, profile metrics, a workspace structure. A harness-only control plane changes the account’s **world** between sessions, so a belief planted in one world can be queried in another, and the service’s access log spans the change: a recheck after the world moved is detectable as a decision, not inferred from the transcript. The cost of re-establishing the state is a world property, from one call on an unscoped account to eleven on a workspace-scoped one. Beliefs are frozen, committed strings planted through the platform’s real capture tool, as the same identity that will later be asked. A cell pairs a question, a belief (or none), and a query world; its correct behavior is derived from two computed facts (is the question answerable in this world; is the belief true in it), never hand-assigned. Grading is deterministic: verification is read off the fixture access log under a definition fixed before any data, refusals key on a prescribed sentinel, and numeric answers grade against ground truth computed from the same data the service serves. Episodes run as fresh platform identities over MCP through two drivers: the Claude Code client, and an in-process tool loop against the raw model API with no agent client, added specifically to strip client behavior from the headline results. Models are Sonnet 5 (both drivers) and Haiku 4.5, at k = 8 per cell with Wilson 95% intervals. Every headline table was rerun on a platform binary built from release tag v1.116.0 and replicated exactly; every run archives its manifest, per-attempt records, and full transcripts. All findings are exploratory, with decision rules stated before each run, and the report says so plainly. ### 3. Results: the strong model verifies everything Delivered a true note about checkable world state, Sonnet 5 re-checked it against the live service in every attempt, and no lever we pulled changed that. Sweeping the price of checking from one call to eleven moved nothing: verification held at 8/8 at every cost level, and the agent paid the full price rather than sampling, enumerating all ten workspaces at the top of the range. | Cost to re-establish the state | World | Verified | Median calls made | | --- | --- | --- | --- | | 1 calls | unscoped account | 8/8 | 1 | | 3 calls | scoped, 2 workspaces | 8/8 | 4 | | 6 calls | scoped, 5 workspaces | 8/8 | 7 | | 11 calls | scoped, 10 workspaces | 8/8 | 12 | Even a note that states the answer outright changes nothing. With the note, Sonnet 5 verified 32/32 and trusted 0/32; matched no-knowledge controls verified 16/16; the median effort difference between being handed the answer and being handed nothing was exactly zero calls. The note is not missed: it appears in the transcripts and is cited in most final answers, as corroboration of a result the agent had already re-derived. The raw-API runs, with no agent client in the loop, reproduce this exactly, 48/48 verified. [Image: Line chart of verification rate versus the cost of checking, one to eleven calls: Sonnet 5 holds at 100% at every cost level while Haiku 4.5 stays near zero.] Figure 1. Verification of a delivered, checkable note versus the cost of checking, by model tier (answer sweep, k = 8 per cell, release-tagged runs). The strong tier is insensitive to cost; the weak tier rarely re-checks. | Driver | Condition | n | Verified | Trusted | | --- | --- | --- | --- | --- | | Sonnet 5, Claude Code client | note delivered | 32 | 32/32 [89–100] | 0/32 [0–11] | | Sonnet 5, Claude Code client | no note (control) | 16 | 16/16 [81–100] | 0/16 [0–19] | | Sonnet 5, raw API (no client) | note delivered | 32 | 32/32 [89–100] | 0/32 [0–11] | | Sonnet 5, raw API (no client) | no note (control) | 16 | 16/16 [81–100] | 0/16 [0–19] | | Haiku 4.5, Claude Code client | note delivered | 32 | 3/32 [3–24] | 29/32 [76–97] | | Haiku 4.5, Claude Code client | no note (control) | 16 | 16/16 [81–100] | 0/16 [0–19] | For a buyer evaluating a knowledge layer, this null result is substantial good news: on a capable model, delivered knowledge never becomes blind trust. The agent treats the platform’s notes about the current state of the world the way a good analyst treats a colleague’s recollection, worth citing, worth confirming, never a substitute for looking. ### 4. Results: the knowledge only a platform can deliver The null above admits a deflationary reading: perhaps this model ignores delivered notes entirely. The bridge experiment tests that with a belief whose content cannot be re-derived from any endpoint: an internal reporting convention stating that a monitor day counts as positive coverage when its sentiment score is 70 or higher, paired with a question that requires real analytical work plus the convention. Thresholds from 50 through 80 all yield distinct day counts, so any stated answer betrays the threshold that produced it, and the no-note control doubles as a leakage check. With the note, Sonnet 5 used it in 8 of 8 attempts: every attempt fetched the trend series and counted days at threshold 70. Without it, no control attempt ever produced the note-only answer (zero leakage), two declined, and six **fabricated a definition**, adopting a threshold of 50 as a “neutral midpoint” and answering confidently. A delivered convention therefore does double duty: it is used, and it suppresses confident invention of institutional facts, 75% fabrication without it, zero with it. [Image: Grouped bar chart of reliance on the delivered note by derivability and model tier: near zero trust in derivable world-state notes for Sonnet 5 versus 91% for Haiku 4.5, and complete use of the non-derivable convention on both tiers.] Figure 2. Reliance on the delivered note by derivability and tier (k = 8 per cell). The same strong model that re-derives every checkable claim relies completely on knowledge it cannot re-derive. | Driver | Convention used | Control fabricated | Leakage | | --- | --- | --- | --- | | Sonnet 5, Claude Code client | 8/8 [68–100] | 6/8 [41–93] | 0 | | Sonnet 5, raw API (no client) | 8/8 [68–100] | 4/8 [22–78] | 0 | | Haiku 4.5, Claude Code client (four episodes lost to API 529s, recorded as failures) | 5/6 [44–97] | 6/6 [61–100] | 0 | This is the study’s center of gravity. Conventions, definitions, policies, fiscal calendars, deprecations: facts with no endpoint to consult are exactly the facts an agent cannot recover on its own, and exactly the facts it will invent plausibly when missing. They are also exactly what Plexara’s memory-to-knowledge lifecycle captures from real sessions, curates, and delivers. The weak tier agrees: Haiku 4.5 used the convention in 5 of 6 clean attempts, and its controls fabricated in 6 of 6. ### 5. Results: model tier changes the deployment math On the identical cells, the weaker tier inverts the world-state result: Haiku 4.5 trusted the delivered answer-bearing note in 29 of 32 attempts, verifying in 3, while its no-knowledge controls probed 16 of 16. The trust is shaped rather than blanket. A stale note that offers no answer to adopt still gets probed; the exposure is answer-bearing notes, and the stale-answer cell prices it directly. The note says three monitors, the account has been emptied, the truthful answer is zero: | Model | Condition | Verified | Trusted | Correct | | --- | --- | --- | --- | --- | | Sonnet 5 | stale note | 8/8 | 0/8 | 8/8 [68–100] | | Sonnet 5 | no note | 8/8 | 0/8 | 8/8 [68–100] | | Haiku 4.5 | stale note | 2/8 | 6/8 | 0/8 [0–32] | | Haiku 4.5 | no note | 8/8 | 0/8 | 8/8 [68–100] | [Image: Grouped bar chart of accuracy with a stale note versus no note by tier: Sonnet 5 at 100% in both conditions, Haiku 4.5 at 0% with the stale note and 100% without it.] Figure 3. Accuracy with and without the stale note, by tier (stale-answer cell, k = 8, release-tagged runs). The strong tier re-derives and is unaffected; on the weak tier a stale answer-bearing note is strictly worse than no note. Measured against its own perfect no-note control, the stale note took Haiku 4.5 from 8/8 to 0/8. The strong tier’s re-derivation habit makes it staleness-immune on the same cell, 8/8 in both conditions. The deployment guidance falls straight out of the data, and we give it to customers as measured fact rather than folklore: delivered conventions and definitions are safe and valuable on every tier tested; delivered observations of world state pair best with capable models, which treat them as corroboration and re-verify them for free. That is also how we run Plexara in production, with frontier-class models doing the analytical work. ### 6. Two studies, one mechanism The results form a two-factor structure, derivability crossed with model tier: | Regime | Strong tier (Sonnet 5) | Weak tier (Haiku 4.5) | | --- | --- | --- | | Derivable delivered knowledge (checkable world state) | Re-derived at any cost; delivery redundant; staleness-immune | Trusted when it answers the question; delivery efficient; staleness-exposed | | Non-derivable delivered knowledge (conventions, definitions) | Used; suppresses fabrication | Used; suppresses fabrication | | No knowledge delivered | Probes; on convention questions, mostly fabricates | Probes; on convention questions, always fabricates | Read together with the accuracy study, the picture is consistent, and each study independently explains the other. The accuracy study’s +56-point knowledge-trap lift came precisely from non-derivable facts: unit conventions, net-revenue policy, fiscal calendars, deprecations. This study shows why those facts and not others carry the lift: they are the knowledge an agent relies on completely because no query can reconstruct them, and the knowledge it fabricates most confidently when missing. **The value of a knowledge layer concentrates in what agents cannot re-derive.** Two studies, two methods, two model tiers, one conclusion. The findings also drove platform decisions, in both directions. Retired, with the evidence above: volatility and valid-until schema fields, freshness-and-recheck-cost enrichment, and capture steering toward dated observations, features the falsified hypothesis would have justified. Sharpened, with new evidence: capture filing, where a companion lifecycle probe found the supersede mechanism at ceiling and located the real loss stages upstream in entity linking, and strict input validation at tool boundaries, surfaced by an agent burning calls on a silently ignored misnamed field. The benchmark series is how we decide what to build: the numbers retire features as readily as they justify them. ### 7. Reproducibility Every table in the published report regenerates from raw run data committed to the open platform repository, offline, with no API key and no network access. Run manifests pin the commit, platform build, model, driver, client version, seed-set hash, and k. The release-tagged rerun means the headline numbers are tied to a build anyone can produce from the tag. ``` git clone https://github.com/txn2/mcp-data-platform.git cd mcp-data-platform python3 bench/reports/knowledge-use/pk_tables.py # every table, from committed raw data python3 bench/reports/knowledge-use/figures.py # every figure ``` The report and a snapshot of the raw run data are archived on Zenodo under DOI [10.5281/zenodo.21614059](https://doi.org/10.5281/zenodo.21614059), with a [frozen PDF](https://zenodo.org/records/21614059/files/benchmark-report-knowledge-use.pdf) as part of the archive. ### 8. Limitations - Two models, one family, one pair per tier: the capability axis is a two-point contrast, and "tier" is confounded with everything else that differs between Sonnet 5 and Haiku 4.5. The claims are about these models, not about capability in general. - The headline cells rest on a handful of questions over one fixture family. The derivability contrast is controlled within that fixture; breadth is the price of the controls. - The reporting convention in the bridge is study-authored and declared as such; its leakage control is structural (distinct answers per threshold), but its phrasing is ours. - Every finding is exploratory. Decision rules were fixed before each run, but hypotheses were revised between runs as premises fell, so intervals are per-rate Wilson bounds, not a corrected confirmatory family. - The raw-API replication covers the strong-tier headlines but not Haiku, whose results are client-path only; four Haiku bridge episodes were lost to API errors and are excluded as failures, not graded. - The release-tagged rerun replicated every headline; two secondary rates moved within noise and toward the conclusions (control fabrication 6/8 to 8/8, weak-tier outright trust of the stale note 6/8 to 8/8). ### 9. References 1. [1] Johnston, C. (2026). Does a Semantic Knowledge Layer Make an Agent Measurably Better? A Reproducible Benchmark. mcp-data-platform benchmark report series. [link](https://doi.org/10.5281/zenodo.21438044) 2. [2] Zep: temporal validity ledgers (valid-at / expired-at / invalid-at edges) for agent memory graphs. [link](https://arxiv.org/abs/2501.13956) 3. [3] MemStrata: deterministic supersession of agent memory by subject-relation-object. [link](https://arxiv.org/abs/2606.26511) 4. [4] FAMA: forgetting-aware memory accuracy, penalizing reliance on obsolete memory. [link](https://arxiv.org/abs/2604.20006) 5. [5] STALE: staleness detection in purely conversational agent memory, where no verification action exists. [link](https://arxiv.org/abs/2605.06527) 6. [6] DRNoise: falsifiable misleading evidence for document-research agents, without an operational world state. [link](https://arxiv.org/abs/2607.17291) #### The rest of the research series Each study in the series is published brand-neutral in the open platform project, archived with its raw run data under a citable DOI, and reproducible offline from the committed attempts. New studies join the series as they are published. The accuracy study · 2026-07-18 #### Does the platform make an agent measurably more accurate on your data? On questions that turn on a business rule, accuracy rose from 42.7% to 98.7%. A companion cold-start experiment taught a fresh install six facts one at a time and watched each question class unlock at its own lesson, and a lifecycle re-run measured a fact taught by one person being reused correctly by a different teammate 98.9% of the time. [Read the accuracy study](https://plexara.io/benchmark/accuracy) [DOI 10.5281/zenodo.21438044](https://doi.org/10.5281/zenodo.21438044) [Report + raw data on Zenodo](https://zenodo.org/records/21751635?preview_file=benchmark-report-knowledge-layer-v2.0.1.pdf) The knowledge-pollution study · 2026-08-07 #### What does a wrong fact cost once it has cleared review? A wrong fact never out-argued the correct source sitting beside it. It did something quieter: on a small model it suppressed the one query that would have refuted it, and every run that ran that query anyway answered correctly. The frontier-class models we run in production took the wrong answer zero times in 96 runs. [Read the knowledge-pollution study](https://plexara.io/benchmark/knowledge-pollution) [DOI 10.5281/zenodo.21834813](https://doi.org/10.5281/zenodo.21834813) [Report + raw data on Zenodo](https://zenodo.org/records/21834813?preview_file=benchmark-report-knowledge-pollution.pdf) The graph-completion study · 2026-08-10 #### What do references between knowledge pages buy an agent that has to be complete? Asked to write complete operational documents, agents followed references between knowledge pages voluntarily, grounded every governing constraint while reading 0.2% of a 5,000-page corpus, and kept discovery cost flat as the corpus grew a hundredfold; without the references, cost roughly doubled and the only failed episode appeared. With search off, references were the only route that worked: 96% of constraints recovered against zero. One pre-registered construct died by its own kill condition, and the kill is published with the result. [Read the graph-completion study](https://plexara.io/benchmark/graph-completion) [DOI 10.5281/zenodo.21881798](https://doi.org/10.5281/zenodo.21881798) [Report + raw data on Zenodo](https://zenodo.org/records/21881798?preview_file=benchmark-report-graph-completion.pdf) [Explore the full research series](https://plexara.io/benchmark) #### Everything here is inspectable The fixture, the world registry, the frozen beliefs, the graders, the run manifests, and the full published report all live in the open platform repository, with every transcript archived. Rerun the analysis scripts and every number on this page reproduces. [Full technical report](https://mcp-data-platform.txn2.com/reference/benchmark-report-knowledge-use/) [Download the PDF](https://zenodo.org/records/21614059/files/benchmark-report-knowledge-use.pdf) [Archived report + data (DOI)](https://doi.org/10.5281/zenodo.21614059) [Benchmark harness on GitHub](https://github.com/txn2/mcp-data-platform/tree/main/bench) [The plain-language version](https://plexara.io/learning/insights/when-agents-use-what-you-teach) --- # The Knowledge-Pollution Study URL: https://plexara.io/benchmark/knowledge-pollution/ > We planted a wrong fact through our own review queue and measured what agents did with it. A wrong claim does not out-argue the correct source, it suppresses the check that would refute it, and the exposure sits entirely on cheap model tiers. Plexara research · The knowledge-pollution study ## 120 of 120 We planted a wrong fact through our own review queue, left the correct source sitting beside it, and watched what agents did next. Across 120 runs the outcome came down to a single act: whether the agent ran the one query that settles the question. Every run that ran it answered correctly. Every run that skipped it took the wrong number. The wrong fact never out-argued the correct one. On a cheap model, it removed the impulse to look. 0 of 96 runs in which a frontier-class model preferred the wrong fact to the correct source 16 of 24 runs in which a small model preferred it, on the one kind of claim that traveled 432 runs graded on the exact value answered, with no judge anywhere in the loop 1 command regenerates every table in this report from the published raw data Read the full report [Reproduce it yourself](https://github.com/txn2/mcp-data-platform/tree/main/bench) Plexara Research · The knowledge-pollution study ### What a wrong fact costs once it clears review: verification displacement, model tier, and the price of a curation gate Plexara, a product of Deasil Works · 2026-08-07 · Models: claude-haiku-4.5, claude-sonnet-5 and claude-opus-5 · Data and code: [txn2/mcp-data-platform](https://github.com/txn2/mcp-data-platform/tree/main/bench) · DOI: [10.5281/zenodo.21834813](https://doi.org/10.5281/zenodo.21834813) Abstract Our first two studies measured what a knowledge layer is worth when the knowledge is right. This one measures what it costs when a piece of it is wrong. A wrong fact, of the kind a competent agent could capture by mistake, went through the real path: captured in a session, approved in the review queue, promoted to the shared knowledge every teammate reads. The correct source stayed where it was, beside it. The result inverted our own pre-registered prediction. We expected the dangerous claim to be the one nothing can check, and it was refused at every model tier. The claim that traveled was the one a single query settles, and it traveled only on a small, cheap model. The mechanism is exact: an agent’s answer was decided entirely by whether it ran that query, with no exception in 120 runs, and with nothing planted the same small model ran the query every time. The wrong fact did not win an argument. It removed the reason to check. Two design consequences follow, and we have acted on both: the claims most worth scrutiny at review time are precisely the ones the platform can verify against your own data, and the exposure sits on the cheap model tier, which is why Plexara runs frontier-class models in production. This page presents the results with commercial framing. Citing this research? Cite the brand-neutral report published in the open-source project, archived with its raw data on Zenodo under DOI [10.5281/zenodo.21834813](https://doi.org/10.5281/zenodo.21834813); the report’s citation section gives the suggested citation and BibTeX. ### 1. The question the first two studies left open The [accuracy study](https://plexara.io/benchmark/accuracy) measured what a knowledge layer is worth: 56 points of accuracy on the questions that turn on a business rule. The [knowledge-use study](https://plexara.io/benchmark/knowledge-use) located where that worth sits: agents rely on what they cannot work out for themselves and re-derive what they can. Both measured correct knowledge. A buyer is entitled to ask the other half of the question, and it is the question we would ask: a review queue is run by people, people approve things, and sooner or later one of those things is wrong. What does that cost? Not in theory. In graded runs, with the wrong fact promoted by the same machinery that promotes the right ones, and the correct source still sitting beside it. This is not a security study and it does not posit an attacker. The wrong facts here are the kind a careful analyst’s agent could produce by good-faith mistake: a fiscal year that starts in the wrong month, a record count that was true last quarter. That is the failure mode a real deployment actually meets. ### 2. Method: a wrong fact, promoted by our own review queue Every wrong fact in this study earned its standing legitimately. An agent captured it in a session, an administrator approved it in the review queue, and it was promoted into the shared knowledge tier and written to its home, either a catalog entry or a knowledge page. A separate identity then confirmed by read-back that the claim was reachable in search and present where it had been filed, before a single graded run started. Nothing was slipped past the gate; the gate let it through, which is the whole point. Two kinds of wrong fact, chosen for how they relate to the world rather than by label. One is a reporting convention that nothing in the data can confirm or refute, a fiscal-year boundary. The other is a claim about state that one query settles, a record count, where the question the agent is asked is that count. Beside each of them sits the correct source: a curated page stating the real boundary, or the warehouse itself holding the real number. Every run is therefore a conflict, not a delivery test. Three model tiers, three arms per cell (nothing planted, a correct fact planted, the wrong fact planted), and 24 runs per cell so the two claim kinds carry the same denominator. Each run is a fresh identity on a fresh database. Grading is deterministic to the exact value: the correct answer, the value only the wrong fact leads to, and the pre-existing wrong answers the question already invites are all computed from the fixture before anything runs, and no two can collide inside grader tolerance. No judge is involved anywhere. Hypotheses, decision rules and falsifiers were fixed in a pre-registration before the confirmatory data, and the prediction they encode is the one the data broke. ### 3. Results: only one kind of claim traveled We expected the convention to be the dangerous one. It is the class the knowledge-use study showed agents rely on completely, precisely because no query can reconstruct it. The opposite happened. The wrong convention was refused at every tier. The claim that traveled was the one a single query settles, and it traveled only on the small model. | The wrong fact we planted | Haiku 4.5 | Sonnet 5 | Opus 5 | | --- | --- | --- | --- | | A convention nothing in the data can settle (a fiscal-year boundary) | 0/24 [0–13.8] | 0/24 [0–13.8] | 0/24 [0–13.8] | | A fact one query settles (a record count) | 16/24 [46.7–82] | 0/24 [0–13.8] | 0/24 [0–13.8] | [Image: Dot-and-interval chart of adoption of the wrong claim by claim kind and model tier: 16 of 24 for the checkable claim on Haiku 4.5, zero of 24 in every other cell, with Wilson 95% intervals.] Figure 1. Adoption of the planted wrong claim by claim kind and model tier (24 runs per cell, Wilson 95% intervals). The kind of claim we predicted would propagate was refused everywhere; the kind we predicted would be re-derived away is the only one that moved. Delivery is not what varies here. On every arm the read-back confirmed the wrong fact was reachable, the planted text appears in all 24 transcripts, and on the convention cells the correct source appears beside it in all 24. Those zeros are refusals of a delivered claim, not claims that failed to arrive. One floor is noisy and the controls are what expose it: with nothing planted at all, the small model answers the convention questions correctly 9 times in 24, so its convention zero is a statement about what it declined to adopt rather than a clean rate against a stable baseline. The checkable floor is clean at every tier, which is what makes the next section readable. ### 4. Results: it did not argue, it removed the check On the checkable claim, one thing separates the outcomes completely: whether the run observed the result of a count against the table in question. | Model | Condition | Ran the check | Took the wrong value | Answered correctly | | --- | --- | --- | --- | --- | | Haiku 4.5 | wrong fact planted | 8/24 | 16/24 | 8/24 | | Haiku 4.5 | nothing planted (control) | 24/24 | 0/24 | 24/24 | | Sonnet 5 | wrong fact planted | 24/24 | 0/24 | 24/24 | | Opus 5 | wrong fact planted | 24/24 | 0/24 | 24/24 | [Image: Stacked bar chart of the four checkable arms, 24 runs each, split by whether the refuting count came back: every observing run answered correctly, every non-observing run took the wrong value.] Figure 2. Every run split by whether the refuting count came back (24 runs per arm). Each bar is a clean partition: the runs that observed the count were correct, the runs that did not took the planted value. With nothing planted, the same small model ran the query 24 times in 24. Every run that observed the count answered correctly. Every run that did not took the planted value. There is no exception in either direction, here or in the 120 runs this cell accumulated across the follow-up conditions below. The control row is what makes it legible: with nothing planted, the small model runs the query 24/24 times and is right 24/24 times. It is entirely capable of settling the question. The claim’s presence is what stopped it asking. **The planted fact did not out-argue the world. It removed the impulse to consult it.** That is a different failure from the one most people picture when they imagine bad data in a knowledge layer, and it has a different fix. Persuasion would be answered with better ranking or stronger provenance signals. Displaced verification is answered by checking the claim before it is promoted, and by which model is doing the work. ### 5. Results: not the phrasing, not the filing cabinet The planted fact was written the way this platform’s capture path actually writes facts, which includes telling the next reader what to do. That raises a fair objection: was the small model adopting a belief, or just following an instruction? The pre-registered answer plants the same false count at three strengths of phrasing. | How the fact was phrased | Took the wrong value | Ran the check | | --- | --- | --- | | Bare (states the count and asks nothing) | 18/24 [55.1–88] | 6/24 | | Plain (marks the count as the relevant one) | 17/24 [50.8–85.1] | 7/24 | | Imperative (instructs the reader to report the count) | 18/24 [55.1–88] | 6/24 | A bare statement that asks nothing of the reader is taken as often as an explicit instruction. The effect is adoption, not compliance, and the rate at which the check gets run barely moves across the ladder. It is the presence of a stored answer that suppresses verification, not the force with which it is worded. Two more decompositions take the effect apart. Moving the identical claim from the catalog entry onto a knowledge page changes nothing except to sharpen it, and planting an equivalent claim in a completely different fixture, with a different world, a different question and a different tool, reproduces it against a clean control floor. | Condition | Model | Took the wrong value | Answered correctly | | --- | --- | --- | --- | | Stored on the catalog entity the confirmatory arm, for reference | Haiku 4.5 | 16/24 [46.7–82] | 8/24 | | Stored on a knowledge page instead same claim, same phrasing, same question | Haiku 4.5 | 24/24 [86.2–100] | 0/24 | | A second fixture, nothing planted the floor the next two rows are measured against | Haiku 4.5 | 0/24 [0–13.8] | 24/24 | | A second fixture, wrong fact planted different world, different question, different tool | Haiku 4.5 | 24/24 [86.2–100] | 0/24 | | A second fixture, wrong fact planted the same arm, one tier up | Sonnet 5 | 0/24 [0–13.8] | 24/24 | [Image: Dot-and-interval chart of adoption across seven robustness conditions, weak tier against strong tier: the weak tier ranges from 16 of 24 to 24 of 24 while the strong tier is zero in every condition measured.] Figure 3. Adoption of the wrong checkable claim across every pre-registered robustness condition, by tier. The weak tier holds between 67% and 100% whatever we vary; where the strong tier was measured alongside it, the strong tier is at zero. The storage location result is the practically useful one. A claim carried into an answer by search alone is just as effective as one written onto the very record the question is about, so the surface worth guarding is the search channel and the review that admits a claim to it, not the filing cabinet it lands in. ### 6. Results: what the replication corrected Every arm above runs through one agent client, so the pre-registered replication reruns the headline cells against the raw model API with no agent framework in the path. It exists to separate what is true of the platform and the models from what is true of one client, and it earned its budget by finding a correction. | The wrong fact we planted | Model | Through the agent client | Raw model API | | --- | --- | --- | --- | | Checkable | Haiku 4.5 | 16-24 of 24 | 8/8 [67.6–100] | | Checkable | Sonnet 5 | 0/24 | 0/8 [0–32.4] | | Checkable | Opus 5 | 0/24 | arm invalidated and reported, not analyzed | | Convention | Haiku 4.5 | 0/24 | 4/8 [21.5–78.5] | | Convention | Sonnet 5 | 0/24 | 1/8 [2.2–47.1] | | Convention | Opus 5 | 0/24 | 0/8 [0–32.4] | The headline replicates: the checkable claim propagates to the small model and to neither frontier-class model, with no agent client involved. The convention result does not. On the raw API the small model took the false fiscal boundary in half its runs, and the middle tier took it once. So the refusal of a wrong convention is a property of the agent scaffolding, not of the platform, and this page claims it only for agents running inside such a scaffold. That is exactly the risk the replication was budgeted to catch, and it caught it. A second narrowing surfaced during the recompute, and it is an instrument defect of our own making. The promotion path records a reviewer note on the promoted record, and the harness wrote that note in a form that named the claim as a study plant. Any run that opened the full record read an explicit disclosure. Opening the record turned out to be capability-graded: on the contested convention cells the frontier-class models opened it in 18 to 24 runs of 24, the small model in 9 of 24. The Opus refusals on that cell therefore cannot be separated from the disclosure and are reported as confounded; the other two tiers hold their refusal among the runs that never saw it, and the checkable headline is essentially untouched, since the handful of exposed runs adopted anyway. The substantive lesson survives the defect, and it is one we have taken to heart in the product. The provenance surface is a working defense. The tier that reads the full record, its status, who captured it, what the reviewer said, is the tier that resists a conflict. The tier that never opens it is not protected by it. ### 7. Results: three different answers to one wrong fact The store snapshots record what each identity wrote back, and the three tiers behaved in three qualitatively different ways when handed the same wrong claim. | Model | What it did with the wrong fact | What it wrote back | | --- | --- | --- | | Haiku 4.5 | Took the claim on the checkable cell and stopped checking | filed nothing corrective | | Sonnet 5 | Re-derived the answer and declined the claim, silently | filed nothing at all | | Opus 5 | Re-derived the answer, declined the claim, and filed a correction | 30 corrections proposed for review | The corrections Opus filed are proposals sitting in the review queue, not self-repair; each one cites the record it disputes and states that it verified the real number by direct query. That is the shape of a working system: the strongest model in the loop treats a conflicting stored claim as something to check and then to flag for a person, and the flag lands where a person will see it. ### 8. What we changed because of it - **Review scrutiny follows derivability.** The claims that propagate are exactly the claims the platform can check against your own data. A claim that names a number a query would settle is the one worth putting the observed value next to before a reviewer approves it, and that is where our review tooling is aimed. - **Frontier-class models do the analytical work.** The exposure sits on the cheap tier, between 67% and 100% across four independent conditions, and it adopts straight through an explicit disclosure sitting in the record. That is how we run Plexara in production, and this study is the measurement behind the choice rather than a preference. - **Provenance stays rich on the record.** Status, capturer, and reviewer history on the full record are not decoration. They are the surface a capable agent actually uses to arbitrate a conflict, and the study shows the arbitration happening there. - **What we did not learn.** Whether a belief recovers after a claim is retracted never ran. We have no data on it, we claim none, and the follow-up is scoped to the one cell that qualifies. The instrument lesson is on the record too: a study plant’s reviewer note must never name it as a plant. ### 9. Reproducibility Every table on this page regenerates from raw run data committed to the open platform repository, offline, with no API key and no network access. Each arm archives its manifest, every graded attempt, the full transcripts, the plant record with its read-back flags, and the store snapshots taken before and after. Arms invalidated mid-study are archived beside the ones that counted, with a suffix naming what invalidated them. ``` git clone https://github.com/txn2/mcp-data-platform.git cd mcp-data-platform python3 bench/reports/knowledge-pollution/pollution_tables.py # every table python3 bench/reports/knowledge-pollution/figures.py # every figure ``` The recompute is a build gate rather than a convenience: the project’s own verify step re-derives the headline numbers from the archives and fails on any drift from what the report prints. The report and a snapshot of the raw run data are archived on Zenodo under DOI [10.5281/zenodo.21834813](https://doi.org/10.5281/zenodo.21834813), with a [frozen PDF](https://zenodo.org/records/21834813/files/benchmark-report-knowledge-pollution.pdf) as part of the archive. ### 10. Limitations - Three models, one family. "Model tier" here is three models from one vendor, so the defensible statement is that the cheap tier does this and the expensive ones do not, not that capability in general causes it. - Two fixtures, both benchmark fixtures. The second fixture removes the first one as an explanation, and a storage-location control separates where a claim lives from which world it lives in, but neither fixture is a production system. - Twenty-four runs per cell resolves near-zero against near-ceiling, which is what these contrasts are. It cannot separate two small rates, and nothing here claims finer resolution. The raw-API arms, at eight runs, are coarser still. - The reviewer note on the planted record disclosed the plant to any run that opened it. Exposure was graded by model tier and by claim kind; the Opus convention refusal is confounded by it, the other two tiers hold among unexposed runs, and the checkable results are essentially untouched. - A run that noticed the conflict and declined to answer lands in the same bucket as a run that failed for any other reason. Separating them would need a judged pass, which the protocol forbids by design. - Whether belief recovers after retraction has no data. Two of the five pre-registered hypotheses were never tested, and the report says so rather than quietly dropping them. - No headline was rerun on a tagged release build. The confirmatory arms are pinned to one commit, and the follow-up arms ran a later state whose agreement with the first was measured rather than assumed. ### 11. References 1. [1] Johnston, C. (2026). Does a Semantic Knowledge Layer Make an Agent Measurably Better? A Reproducible Benchmark. mcp-data-platform benchmark report series. [link](https://doi.org/10.5281/zenodo.21438044) 2. [2] Johnston, C. (2026). When Do Agents Use Stored Knowledge? Derivability, Capability, and the Limits of a Knowledge Layer. mcp-data-platform benchmark report series. [link](https://doi.org/10.5281/zenodo.21614059) 3. [3] The closest organic work on cross-user contamination of shared agent memory, reporting 57 to 71 percent contamination without derivability or capability moderators and without a co-present correct source. [link](https://arxiv.org/abs/2604.01350) 4. [4] Governed agent memory: provenance and curation plumbing validated without measuring what anyone ends up believing. [link](https://arxiv.org/abs/2606.18829) 5. [5] Curation and provenance machinery for multi-agent shared memory, again measured at the plumbing rather than the answer. [link](https://arxiv.org/abs/2607.16211) 6. [6] Representative of the attacker-framed memory-integrity literature, which studies deliberate corruption as a capability an adversary optimizes for. This study measures the good-faith-mistake base rate underneath it. [link](https://arxiv.org/abs/2407.12784) #### The rest of the research series Each study in the series is published brand-neutral in the open platform project, archived with its raw run data under a citable DOI, and reproducible offline from the committed attempts. New studies join the series as they are published. The accuracy study · 2026-07-18 #### Does the platform make an agent measurably more accurate on your data? On questions that turn on a business rule, accuracy rose from 42.7% to 98.7%. A companion cold-start experiment taught a fresh install six facts one at a time and watched each question class unlock at its own lesson, and a lifecycle re-run measured a fact taught by one person being reused correctly by a different teammate 98.9% of the time. [Read the accuracy study](https://plexara.io/benchmark/accuracy) [DOI 10.5281/zenodo.21438044](https://doi.org/10.5281/zenodo.21438044) [Report + raw data on Zenodo](https://zenodo.org/records/21751635?preview_file=benchmark-report-knowledge-layer-v2.0.1.pdf) The knowledge-use study · 2026-07-26 #### Does an agent actually use the knowledge the platform delivers? Agents rely completely on delivered knowledge they cannot re-derive: conventions, definitions, policies. With the company definition delivered, confident fabrication fell from 75% to zero, and capable models re-verified every claim they could check. [Read the knowledge-use study](https://plexara.io/benchmark/knowledge-use) [DOI 10.5281/zenodo.21614059](https://doi.org/10.5281/zenodo.21614059) [Report + raw data on Zenodo](https://zenodo.org/records/21614059?preview_file=benchmark-report-knowledge-use.pdf) The graph-completion study · 2026-08-10 #### What do references between knowledge pages buy an agent that has to be complete? Asked to write complete operational documents, agents followed references between knowledge pages voluntarily, grounded every governing constraint while reading 0.2% of a 5,000-page corpus, and kept discovery cost flat as the corpus grew a hundredfold; without the references, cost roughly doubled and the only failed episode appeared. With search off, references were the only route that worked: 96% of constraints recovered against zero. One pre-registered construct died by its own kill condition, and the kill is published with the result. [Read the graph-completion study](https://plexara.io/benchmark/graph-completion) [DOI 10.5281/zenodo.21881798](https://doi.org/10.5281/zenodo.21881798) [Report + raw data on Zenodo](https://zenodo.org/records/21881798?preview_file=benchmark-report-graph-completion.pdf) [Explore the full research series](https://plexara.io/benchmark) #### Everything here is inspectable The pre-registration written before the data, the harness that plants and retracts a claim, the graders, the run manifests, every transcript, and the full published report all live in the open platform repository. Rerun the analysis scripts and every number on this page reproduces. [Full technical report](https://mcp-data-platform.txn2.com/reference/benchmark-report-knowledge-pollution/) [Download the PDF](https://zenodo.org/records/21834813/files/benchmark-report-knowledge-pollution.pdf) [Archived report + data (DOI)](https://doi.org/10.5281/zenodo.21834813) [Benchmark harness on GitHub](https://github.com/txn2/mcp-data-platform/tree/main/bench) --- # The Graph-Completion Study URL: https://plexara.io/benchmark/graph-completion/ > Agents asked to write complete operational documents follow references between knowledge pages voluntarily, ground every constraint while reading 0.2% of a 5,000-page corpus, and keep discovery cost flat as the corpus grows a hundredfold. With search off, references are the only route that works. Plexara research · The graph-completion study ## 96% vs 0% We asked agents to write the complete plan, a schema change, an incident write-up, a new data feed, with the governing constraints spread across an operations wiki. When the pages were connected the way Plexara connects knowledge pages, and search was turned off, agents recovered 96% of the constraints by following references alone. Strip the references and they recovered none. Turn search back on and the references change what discovery costs instead: flat effort per constraint as the corpus grew a hundredfold, against effort that roughly doubled and produced the only failed episode in the matrix without them. 100% of governing constraints grounded on the connected corpus, at every tested size from 50 to 5,000 pages 0.2% of a 5,000-page corpus an agent actually read while grounding every constraint 2.3x the search effort per constraint once the references were stripped at 5,000 pages, and climbing with scale 1 command per run family regenerates every number on this page from the committed raw archives, offline Read the full report [Reproduce it yourself](https://github.com/txn2/mcp-data-platform/tree/main/bench) Plexara Research · The graph-completion study ### What connected knowledge buys the agent that has to be complete: voluntary traversal, flat discovery cost, and a pre-registered kill on the public record Plexara, a product of Deasil Works · 2026-08-10 · Client: Claude Code 2.1.225 and 2.1.226 · Data and code: [txn2/mcp-data-platform](https://github.com/txn2/mcp-data-platform/tree/main/bench) · Frozen design: [pre-registered before any episode ran](https://github.com/txn2/mcp-data-platform/blob/main/bench/docs/graph-completion-study-design.md) · DOI: [10.5281/zenodo.21881798](https://doi.org/10.5281/zenodo.21881798) Abstract Plexara’s knowledge pages reference the pages that govern them, and this study measures what those references are worth to an agent that has to produce a complete document rather than answer a question. Across a premise probe and a confirmatory matrix that grew the corpus from 50 to 5,000 pages around byte-identical tasks, agents on the connected corpus grounded every constraint in every condition, reading as little as 0.2% of the largest corpus. The references did not change what the finished document contained; competent search reached the same content. They changed what it cost, holding search effort per constraint flat across two orders of magnitude of corpus while the stripped arm’s effort roughly doubled and produced the matrix’s only failed episode, and they were the only route that worked when search was off or the reading budget was small. One pre-registered construct, semantic discontinuity, died by its own kill condition: prose that preserves a page’s meaning hands a competent searcher the vocabulary to find it, so the certified unreachability the construct required cannot be authored. We publish the kill with the result. This page presents the results with commercial framing. Citing this research? Cite the brand-neutral report published in the open-source project, archived with its raw data on Zenodo under DOI [10.5281/zenodo.21881798](https://doi.org/10.5281/zenodo.21881798); the report’s citation section gives the suggested citation and BibTeX. ### 1. The question a ranked result list cannot answer The [accuracy study](https://plexara.io/benchmark/accuracy) measured what a knowledge layer is worth on questions, and the [knowledge-use](https://plexara.io/benchmark/knowledge-use) and [knowledge-pollution](https://plexara.io/benchmark/knowledge-pollution) studies measured whether agents act on delivered facts and what a wrong one costs. A question has an answer. A change plan does not; it has a completeness bar. It is done when every governing constraint is in it, and missing one is not a lower score, it is a freeze window nobody observed. Search is the wrong shape for that bar. A ranked list returns some relevant pages and certifies nothing about the ones it did not return. Plexara’s knowledge layer is connected: pages reference the runbooks, calendars and registers that govern them, so there is a second discovery structure available, following the references. This study measures what that structure buys, on tasks where being almost complete is failing. ### 2. Method: completion tasks over a generated wiki Three completion cells, each a document an operations team actually writes: a schema change plan for a governed data stream, an incident-handling write-up, and the onboarding of a new nightly data feed. Each cell’s governing constraints live on 5 to 8 pages spread through an operations wiki, up to four references deep from the entry page the agent is handed. Every constraint carries a hard token that exists only on its source page, so grading is deterministic: a constraint counts as **grounded** only when its token is in the final document and the source page was actually fetched during the episode. A token in the document with no read behind it is counted separately, as fabrication. Two corpora with the same prose meaning: a connected arm, where pages reference each other the way Plexara knowledge pages do, and a stripped arm, where each reference is rendered as its plain-prose fallback sentence instead of a link. Crossed with search on or off, and run at three corpus sizes, 50, 500 and 5,000 pages, generated deterministically from a recorded spec so any reader can regenerate the exact corpus. The three cells and their 27 core pages are byte-identical at every size; only the haystack grows. The matrix, the dependent variables and the kill conditions were frozen in a design document before any episode ran. The premise probe ran 72 episodes on a 42-page corpus at two reading budgets. The confirmatory matrix ran 99 pre-registered episodes across the three sizes with one agent configuration, moving the ratio of reading budget to corpus size two orders of magnitude. One episode died to a harness error and is archived as such, not graded. ### 3. Results: agents follow references unprompted Hand an agent one entry page, no search tool, and a task whose constraints sit up to four references away, and it walks. On the large reading budget the agent recovered 96% of the spread constraints by pure reference-following, at zero queries, reaching the deepest page of every cell in all nine episodes. The small budget recovered 42%, and its failures were stopping early, not failing to start. On the stripped corpus the same agents recovered nothing, because nothing gave them a route. | Corpus | Search | Reading budget | Grounded coverage | Fabricated slots | Reads per episode | Searches per grounded constraint | | --- | --- | --- | --- | --- | --- | --- | | connected | off | large (opus alias) | 0.96 | 0 | 9.0 | no searches | | connected | off | small (haiku alias) | 0.42 | 0 | 4.6 | no searches | | stripped | off | large (opus alias) | 0.00 | 13 | 6.0 | no route | | stripped | off | small (haiku alias) | 0.00 | 1 | 0.7 | no route | | connected | on | large (opus alias) | 0.99 | 0 | 19.0 | 0.57 | | connected | on | small (haiku alias) | 0.29 | 4 | 2.4 | 2.30 | | stripped | on | large (opus alias) | 1.00 | 0 | 21.1 | 0.64 | | stripped | on | small (haiku alias) | 0.10 | 3 | 1.0 | 8.00 | [Image: Bar chart of grounded off-entry coverage with search off: 0.96 and 0.42 on the connected corpus at two reading budgets, 0.00 on the stripped corpus at both budgets.] Figure 1. Grounded coverage with search turned off, probe corpus, 9 episodes per bar. References are the only route that exists: agents walk them to full depth voluntarily, and recovery without them is zero. The walk survives scale. In the confirmatory matrix’s no-search condition at 5,000 pages, every episode was a full-depth pure-reference walk: 9 reads per episode, which is the size of the reference closure itself, every constraint grounded, all nine episodes. Voluntary traversal is not an artifact of a small corpus. ### 4. Results: at scale, references change the cost, not the content With search on, both corpora reach the same place: grounded coverage is at ceiling in every cell of the matrix. At 5,000 pages an episode makes about 11 reads, roughly 0.2% of the corpus, and still grounds every constraint. Discovery is not enumeration; targeted search plus the vocabulary an agent picks up from the pages it reads collapses a 5,000-page haystack as effectively as a 50-page one. What scale moves is the cost. | Pages | Corpus | Search | Episodes | Grounded coverage (SD) | Reads per episode | Searches per grounded constraint | Reads found via references | | --- | --- | --- | --- | --- | --- | --- | --- | | 50 | connected | on | 15 | 1.00 (0.00) | 15.3 | 0.59 | 0.09 | | 50 | stripped | on | 15 | 1.00 (0.00) | 16.1 | 0.73 | 0.00 | | 500 | connected | on | 15 | 1.00 (0.00) | 12.3 | 0.67 | 0.28 | | 500 | stripped | on | 15 | 1.00 (0.00) | 13.3 | 1.02 | 0.00 | | 5000 | connected | off | 9 | 1.00 (0.00) | 9.0 | no searches | 0.89 | | 5000 | connected | on | 15 | 1.00 (0.00) | 10.7 | 0.63 | 0.34 | | 5000 | stripped | on | 14 (+1 failed) | 0.95 (0.19) | 11.2 | 1.44 | 0.00 | [Image: Line chart of searches per grounded constraint against corpus size on a log axis: the connected corpus holds flat at 0.59 to 0.63 from 50 to 5,000 pages while the stripped corpus climbs from 0.73 through 1.02 to 1.44.] Figure 2. Search effort per grounded constraint as the corpus grows a hundredfold. The connected corpus is flat; the stripped corpus roughly doubles, and its 5,000-page cell holds the matrix's only failed episode and its only below-ceiling coverage. On the connected corpus the effort curve is flat: 0.59, 0.67, 0.63 searches per grounded constraint across two orders of magnitude. Stripped, it climbs: 0.73, 1.02, 1.44, plus the only failed episode and the only below-ceiling coverage in the matrix, both in the 5,000-page cell. And agents lean on the references more as the haystack grows: the share of reads discovered through a reference on a fetched page rises from 0.09 at 50 pages to 0.34 at 5,000, while the stripped arm stays pinned to search for every single read. The 50-page cells are the built-in control: at a size where a raised search limit can enumerate the corpus, the design predicted no separation, and both arms sat at identical ceiling with a coverage delta of exactly zero. The separation that appears at scale is a scale effect, not a haystack artifact. ### 5. Results: under a small reading budget, references change the outcome The probe’s small-budget arm is where references stop being an efficiency and start being the difference between a grounded document and a thin one. With search on, the connected corpus nearly tripled grounded coverage, 0.29 against 0.10, and cut the searches spent per grounded constraint from 8.0 to 2.3. The characteristic small-budget failure was searching without reading: in two thirds of its search episodes the agent issued queries, fetched nothing, and wrote the document from result snippets. The durable variable is not the model, it is the ratio of reading budget to corpus size. The probe’s large budget could afford to read half of a 42-page corpus and hit ceiling with or without references; nothing can read half of a real knowledge base. As the corpus grows, every agent becomes the constrained one, which is exactly the regime the confirmatory matrix measured, and where the cost separation lives. ### 6. Results: coverage without reading is fabrication The stripped no-search arm has a floor of zero by construction: the off-entry pages are unreachable. The large-budget agent still produced constraint tokens for 19% of the slots it had no way to read, 13 slots across nine episodes, stating plausible values inside otherwise accurate documents. [Image: Paired bar chart for the stripped no-search arm at the large reading budget: raw coverage 0.19 against grounded coverage 0.00, the gap labeled as fabricated slots.] Figure 3. Raw coverage against grounded coverage where no route to the source pages exists. Every point of the raw bar is a value the agent could not have read: plausible, confident, and wrong to trust. This is the completion-task face of the result the [knowledge-use study](https://plexara.io/benchmark/knowledge-use) measured on questions: starve an agent of a source and a confident value appears anyway. It is why every headline on this page is grounded coverage, token in the document and source page read, and why read provenance, not text overlap, is the only defensible way to grade a completion instrument. ### 7. The kill we published: prose is a search route The confirmatory design pre-registered a stronger construct than cost. Six constraints were authored as semantic discontinuities, institutional obligations like a finance close calendar governing when a schema change may ship, written entirely in their own department’s vocabulary, never naming the task’s systems. Twice per corpus size, an offline embedding scan and a live sweep gate certified that no task-derived query ranked those pages. The claim under test: an authored reference crosses in one hop a gap that search cannot cross at all. The stripped arms grounded those constraints anyway, at 1.00 coverage at 500 pages and 0.93 at 5,000. The design names any stripped-arm discontinuity grounding an instrument kill, so the kill fired and no confirmatory conclusion is read from those cells. What happened is worth more than the construct: the stripped corpus renders each reference as a meaning-preserving prose sentence, the agent reads that sentence on an ordinary page it found through search, and then searches again in the institution’s own vocabulary. It runs the traversal in query space, two hops instead of one. The certifications were sound for what they measured; they measured queries derived from the task, and the defeating queries were derived from corpus text the agent had already read. Prose that preserves a page’s meaning necessarily names the institution, and naming the institution hands a competent searcher the vocabulary that closes the gap. An arm contrast that removed the mention would change what the page says and grade two different documents, which the design refused by construction. So the construct is not just unmeasured, it is unauthorable under a meaning-constant contrast, and we retired it rather than weakening the contrast to save it. ### 8. What this settles, and what it retires - **References do real work.** Agents use them voluntarily, lean on them more as the knowledge base grows, and depend on them entirely when search is off or the reading budget is small. Connecting a knowledge page to the pages that govern it is not decoration; it is what keeps discovery affordable at the sizes real knowledge bases reach. - **The claim we make is the measured one.** For an agent that searches competently, references did not change what the finished document contained at any tested size; they changed what it cost and how it degraded. We say that, rather than the grander completeness claim the kill took off the table. - **Grounded coverage is the reading that counts.** The fabrication channel is real and measurable, so any completion claim, ours or a vendor’s, should be graded on read provenance, not on whether the right words appear in the output. - **What we did not learn.** Whether agents know when they are done is unmeasured: no episode in 98 ever claimed completeness, so the overclaim channel never separated anything. And whether some constraint can be truly unreachable to read-informed search is a question our instrument cannot pose, for the reason the kill section states. ### 9. Reproducibility Both run families are committed whole to the open platform repository: every manifest, graded attempt, transcript, gate reading and plant record, beside the frozen design document. Each family carries a stdlib-only analyzer that recomputes every number on this page offline, with no API key and no network. The corpora themselves are not stored; each archive records a spec and fingerprint from which the exact corpus regenerates, and the harness refuses on mismatch. ``` git clone https://github.com/txn2/mcp-data-platform.git cd mcp-data-platform python3 bench/reports/graph-completion/graph_tables.py # every table python3 bench/reports/graph-completion/figures.py # every figure ``` The recompute is a build gate rather than a convenience: the project’s own verify step re-derives the headline numbers from the archives and fails on any drift from what the report prints, including the presence of the instrument kill and the archived analyzer’s deliberate non-zero exit. The analyzer exits non-zero by design: the pre-registered kill is present in the archives, and it refuses to bless kill-affected cells as confirmatory findings. That refusal is itself part of the published record, and this page reports those cells the same way. The report and a snapshot of the raw run data are archived on Zenodo under DOI [10.5281/zenodo.21881798](https://doi.org/10.5281/zenodo.21881798), with a [frozen PDF](https://zenodo.org/records/21881798/files/benchmark-report-graph-completion.pdf) as part of the archive. ### 10. Limitations - One agent client, and model aliases rather than resolved model identifiers: the archives record what the client was asked for (its small and large aliases), not a pinned model build. Budget-to-corpus ratio, not model identity, is the variable the design treats as durable. - One authored corpus genre. Three hand-written completion cells inside a generated operations wiki, deterministic by construction; other document kinds and messier corpora are untested. - Fifteen episodes per confirmatory cell resolves ceiling against collapse and a doubling of cost; it cannot resolve small differences, and nothing here claims finer resolution. - The completeness-closure question is unmeasured, not answered: no episode ever claimed its document was complete, so the overclaim reading never separated the arms in either direction. - The semantic-discontinuity cells are invalid by the pre-registered instrument kill and are reported as such; no conclusion about unreachable-to-search constraints is drawn anywhere on this page. - The largest tested corpus is 5,000 pages. The cost curves justify no extrapolation beyond it. - The tasks are posed and the corpus is authored; production agents on production knowledge bases are a separate instrument, not this one. - Runs are pinned to recorded development commits of the platform, not a tagged release build, and the archives record the exact commit of each run. ### 11. References 1. [1] Johnston, C. (2026). Does a Semantic Knowledge Layer Make an Agent Measurably Better? A Reproducible Benchmark. mcp-data-platform benchmark report series. [link](https://doi.org/10.5281/zenodo.21438044) 2. [2] Johnston, C. (2026). When Do Agents Use Stored Knowledge? Derivability, Capability, and the Limits of a Knowledge Layer. mcp-data-platform benchmark report series. [link](https://doi.org/10.5281/zenodo.21614059) 3. [3] Johnston, C. (2026). Knowledge Pollution: Verification Displacement, Capability, and the Price of a Curation Gate. mcp-data-platform benchmark report series. [link](https://doi.org/10.5281/zenodo.21834813) 4. [4] Graph-structured retrieval for query-focused summarization: builds the graph from the corpus rather than measuring authored references, and evaluates answer quality rather than grounded completeness. [link](https://arxiv.org/abs/2404.16130) 5. [5] Knowledge-graph-indexed retrieval motivated by long-term memory consolidation; the retrieval structure is derived, and single-answer recall is the metric rather than document completeness. [link](https://arxiv.org/abs/2405.14831) #### The rest of the research series Each study in the series is published brand-neutral in the open platform project, archived with its raw run data under a citable DOI, and reproducible offline from the committed attempts. New studies join the series as they are published. The accuracy study · 2026-07-18 #### Does the platform make an agent measurably more accurate on your data? On questions that turn on a business rule, accuracy rose from 42.7% to 98.7%. A companion cold-start experiment taught a fresh install six facts one at a time and watched each question class unlock at its own lesson, and a lifecycle re-run measured a fact taught by one person being reused correctly by a different teammate 98.9% of the time. [Read the accuracy study](https://plexara.io/benchmark/accuracy) [DOI 10.5281/zenodo.21438044](https://doi.org/10.5281/zenodo.21438044) [Report + raw data on Zenodo](https://zenodo.org/records/21751635?preview_file=benchmark-report-knowledge-layer-v2.0.1.pdf) The knowledge-use study · 2026-07-26 #### Does an agent actually use the knowledge the platform delivers? Agents rely completely on delivered knowledge they cannot re-derive: conventions, definitions, policies. With the company definition delivered, confident fabrication fell from 75% to zero, and capable models re-verified every claim they could check. [Read the knowledge-use study](https://plexara.io/benchmark/knowledge-use) [DOI 10.5281/zenodo.21614059](https://doi.org/10.5281/zenodo.21614059) [Report + raw data on Zenodo](https://zenodo.org/records/21614059?preview_file=benchmark-report-knowledge-use.pdf) The knowledge-pollution study · 2026-08-07 #### What does a wrong fact cost once it has cleared review? A wrong fact never out-argued the correct source sitting beside it. It did something quieter: on a small model it suppressed the one query that would have refuted it, and every run that ran that query anyway answered correctly. The frontier-class models we run in production took the wrong answer zero times in 96 runs. [Read the knowledge-pollution study](https://plexara.io/benchmark/knowledge-pollution) [DOI 10.5281/zenodo.21834813](https://doi.org/10.5281/zenodo.21834813) [Report + raw data on Zenodo](https://zenodo.org/records/21834813?preview_file=benchmark-report-knowledge-pollution.pdf) [Explore the full research series](https://plexara.io/benchmark) #### Everything here is inspectable The design frozen before any episode ran, both run families with every transcript and gate reading, the corpus generator, and the analyzers that reproduce every number on this page all live in the open platform repository, including the instrument kill the analyzers refuse to gloss over. [Full technical report](https://mcp-data-platform.txn2.com/reference/benchmark-report-graph-completion/) [Download the PDF](https://zenodo.org/records/21881798/files/benchmark-report-graph-completion.pdf) [Archived report + data (DOI)](https://doi.org/10.5281/zenodo.21881798) [Probe run archives](https://github.com/txn2/mcp-data-platform/tree/main/bench/results/graph-completion-probe) [Confirmatory run archives](https://github.com/txn2/mcp-data-platform/tree/main/bench/results/graph-completion-confirmatory) [Benchmark harness on GitHub](https://github.com/txn2/mcp-data-platform/tree/main/bench) --- # MCP Data Platforms vs MCP Gateways URL: https://plexara.io/compare/ > Two categories share the MCP label: gateways govern traffic, data platforms serve data. How to grade any vendor, and how Plexara compares to Snowflake managed MCP, Starburst AIDA, gateways, and building it yourself. Compare ## MCP Data Platforms vs MCP Gateways Two categories share the MCP label and solve different problems. A gateway governs traffic: who may call which tool, over which connection, with what audit trail. A data platform serves data: it runs the query, attaches what the result means, and remembers what your team learned. Plexara is the managed MCP data platform. This page defines the categories so you can grade any vendor, including us. The category line ### What governs traffic vs what serves data The quickest test: look at what the agent receives back. A gateway hands your agent a connection. A data platform hands your agent an answer that already carries its meaning. | | MCP gateway | MCP data platform | | --- | --- | --- | | Core job | Route, authenticate, and observe MCP tool calls | Execute queries and return governed, context-rich results | | What the agent receives | Whatever the backend server returned, relayed as-is | Results enriched with ownership, definitions, and lineage from the catalog | | Knowledge across tools | None: each connected server keeps its own state | Memory and insights captured once surface on every relevant response | | Search | A registry of servers and tools | One semantic search across data, metadata, knowledge, and API operations | | Governance point | At the connection: which tools are reachable | At execution: what each persona sees inside every result | | Representative vendors | Arcade, MintMCP, Kong, Composio | Plexara, warehouse-native MCP servers | The categories are complementary, and large deployments often run both: a gateway as the front door for the tool sprawl an enterprise accumulates, and a data platform behind it doing the data work. What a gateway cannot do, no matter how many servers it fronts, is make independent servers behave like one platform. Each server stays blind to the others. Head to head ### The comparisons in detail [Plexara vs MCP gateways Why connecting many independent MCP servers through a control plane still leaves your agent assembling context by hand. Read the comparison](https://plexara.io/compare/mcp-gateways) [Plexara vs building it yourself The same open foundations are available to any team. What the build actually costs, and what you get by skipping it. Read the comparison](https://plexara.io/compare/build-vs-buy) [Plexara vs Snowflake managed MCP Snowflake ships a capable MCP server for Snowflake-resident data. The comparison starts where your data stops being in one warehouse. Read the comparison](https://plexara.io/compare/snowflake-managed-mcp) [Plexara vs Starburst AIDA AIDA is an assistant inside Starburst. Plexara makes the agents you already use experts on your data. Different answers to different questions. Read the comparison](https://plexara.io/compare/starburst-aida) Grade any vendor ### Five questions that sort the category Ask these of any product wearing the MCP label, ours included. Does a query result arrive with the business meaning of its columns attached, or does the agent get raw rows? Can something learned in one tool surface in another, or does each connection keep its own state? Is there one search across data, metadata, and accumulated knowledge, or one registry of tools? Is access decided per persona at execution time, or per connection at setup time? And when you leave, is what your team authored readable without the product? Plexara answers all five as a data platform: enrichment on every response, memory and knowledge shared across every surface, one semantic search, personas enforced on each tool call, and metadata stored in DataHub in open formats. The [benchmark report](https://plexara.io/benchmark/accuracy) measures what that context layer is worth: the same agent went from 42.7% to 98.7% correct on business-context questions when the platform was turned on. Next ### See the numbers behind the claims A controlled benchmark isolating what the platform contributes, with reproduction commands. [Continue](https://plexara.io/benchmark) --- # Plexara vs MCP Gateways URL: https://plexara.io/compare/mcp-gateways/ > MCP gateways route and authenticate tool calls. Plexara executes queries and returns enriched, governed results. Why connecting independent MCP servers does not add up to a data platform. ## Plexara vs MCP Gateways Gateways like Arcade, MintMCP, Kong, and Composio are control planes: they authenticate, route, and observe MCP traffic, and they do it well. Plexara is a data engine behind a single MCP surface. The difference shows up in every response your agent receives. Credit where due ### What gateways do well An enterprise that adopts MCP seriously ends up with dozens of servers: SaaS connectors, internal tools, vendor products. Somebody has to decide who may reach which of them, hold the credentials, and log the traffic. That is the gateway job. Arcade brings per-user OAuth and a large connector runtime. MintMCP leads with SSO, RBAC, and compliance-grade audit. Kong folds MCP into the same control plane as its API gateway. Composio ships hundreds of managed integrations. If your problem is tool sprawl, a gateway is the right purchase, and Plexara sits behind one comfortably. Plexara even includes [its own API gateway](https://plexara.io/product/api-gateway) for REST backends, so we are not arguing against the pattern. We are drawing the line around what routing can and cannot produce. The structural gap ### What routing cannot produce The tempting move is to skip the platform: connect a warehouse MCP server, a catalog MCP server, and a storage MCP server through one gateway and call it a data platform. It is not one, for five structural reasons. #### Responses arrive as raw as the source sent them A gateway relays. When your agent queries the warehouse through a gateway, the rows come back without ownership, definitions, or deprecation warnings, because the warehouse server does not know your catalog exists. Plexara enriches every response at the protocol level: the query result carries the catalog context that explains it, in the same envelope. #### Each server is blind to the others Connect a warehouse MCP, a catalog MCP, and a storage MCP through one gateway and you have three tools that share credentials handling but nothing else. A correction captured while querying cannot surface when the agent browses the catalog. In Plexara, query, catalog, storage, and API access are layers of one platform, so knowledge stored against a table appears wherever that table shows up. #### No unified search A gateway can list its servers and tools. It cannot answer "where do we keep verified revenue numbers?" because that answer spans data, metadata, and accumulated team knowledge. Plexara runs one semantic search across all of it, including the operations of connected REST APIs. #### Context assembly falls on the agent, every session With independent servers, a well-prompted agent can orchestrate them: query here, look up meaning there, cross-reference by hand. That burns tokens and latency on every question, and the assembled context evaporates when the session ends. Plexara does the assembly once, server-side, and persists what the team learns. #### Governance stops at the connection A gateway decides which tools a user may call. It cannot see inside the result to apply column-level or row-level policy, because the payload is opaque to it. Plexara enforces personas at execution time, inside the platform, where the data is visible. ### Side by side | | MCP gateway | Plexara | | --- | --- | --- | | Authentication and routing | Core strength: SSO, RBAC, per-user OAuth | Built in, scoped to the platform surface | | Query execution | Delegated to whatever server is connected | Federated SQL over 40+ Trino connectors | | Semantic enrichment | None | Catalog context attached to every response | | Memory and knowledge | None shared across servers | Captured once, surfaced on every relevant call | | Search | Server and tool registry | Semantic search across data, metadata, knowledge, and API operations | | Result-level governance | Opaque payloads: cannot see inside results | Personas applied at execution time | | Best deployed as | Front door for MCP tool sprawl | The data engine behind that front door | Choose a gateway when the problem is governing many independent tools. Choose Plexara when the problem is making agents accurate on enterprise data. Run both when you have both problems: the gateway fronts the fleet, and Plexara is the member of the fleet that answers data questions with context attached. The full argument is in [why MCP gateways are not enough](https://plexara.io/learning/insights/why-mcp-gateways-are-not-enough). Next comparison ### Plexara vs building it yourself The same open foundations are available to any team. What the build actually costs. [Continue](https://plexara.io/compare/build-vs-buy) --- # Plexara vs Building It Yourself URL: https://plexara.io/compare/build-vs-buy/ > What a self-built MCP data platform actually contains: federation, enrichment, personas, memory, audit, and a permanent operations tail. When building is right, and what Plexara replaces. ## Plexara vs Building It Yourself Trino, DataHub, and the MCP specification are open. A strong platform team can assemble the same foundations we did. This page lays out what that build actually contains, where teams underestimate it, and what you get by letting us run it instead. The bill of materials ### What the build contains The demo version of this project takes a sprint: stand up an MCP server, point it at a database, watch an agent answer questions. The production version is six systems that must behave as one. #### The MCP server itself A production server that speaks the protocol correctly, streams results, handles per-user sessions, and keeps pace with a specification that is still evolving quarter over quarter. #### Federation Trino deployment, connector configuration for every source, pushdown tuning, and capacity management. The engine is open; running it well against a dozen live systems is a discipline. #### The semantic layer DataHub deployment plus the part nobody ships: the pipeline that attaches catalog context to query results at response time, so the agent receives meaning with the data instead of hunting for it. #### Identity, personas, and audit Per-user authentication into shared infrastructure, closed-by-default access mapped to roles, and an audit log that ties every tool call to a human. Security review will not waive any of it. #### Memory and knowledge capture A store for what agents and analysts learn, semantic recall over it, a review pipeline that turns raw captures into governed knowledge, and surfacing logic so it reappears in the right context. #### The operations tail Upgrades across every component, embedding models for semantic search, monitoring, incident response, and the integration glue between all of the above, forever. The case for building ### When building is the right call Some organizations should build. If a platform team already runs Trino and DataHub in production, already owns identity infrastructure, and treats the agent data layer as a durable competitive investment worth permanent headcount, the open foundations will serve them the way they served us. The trap is the middle path: a team that builds the demo, ships it to one department, and discovers the remaining systems on the list above one incident at a time. Industry estimates put 20 to 40 percent of data engineering capacity into integration maintenance in multi-vendor stacks, and a hand-rolled agent platform joins that queue the day it ships. The question is less whether your team can build it and more whether that is the work you want your best engineers doing next year. ### Side by side | | Build it yourself | Plexara | | --- | --- | --- | | Time to first governed answer | Months: assemble, integrate, harden | A phased rollout that starts with two or three sources | | Enrichment pipeline | Custom code you design and maintain | Built into every response | | Spec churn | Your team tracks MCP changes | Absorbed by the platform | | Operations | Your on-call, every layer | Fully managed on infrastructure we own | | Metadata portability | Yours by construction | Yours by construction: DataHub, open formats | | Engineering focus | Platform plumbing | Your data products | One thing does not change between the columns: because Plexara stores semantic metadata in DataHub in standard formats, choosing the platform now does not foreclose building later. Everything your team authors [leaves with you](https://plexara.io/learning/insights/what-you-keep-if-you-leave). Next comparison ### Plexara vs Snowflake managed MCP A capable MCP server for Snowflake-resident data. The comparison starts where your data stops being in one warehouse. [Continue](https://plexara.io/compare/snowflake-managed-mcp) --- # Plexara vs Snowflake Managed MCP URL: https://plexara.io/compare/snowflake-managed-mcp/ > Snowflake's managed MCP server reaches Snowflake-resident data. Plexara federates across warehouses, databases, S3, and APIs, enriches every response, and stores your semantics in open formats. ## Plexara vs Snowflake Managed MCP Snowflake's managed MCP server gives agents governed access to Snowflake. Plexara gives agents governed access to your data estate: Snowflake included, alongside everything that never moved there. The comparison is about reach, what travels with each response, and where your semantic investment ends up living. The facts first ### What Snowflake's managed MCP server is Generally available since November 2025, it is a Snowflake-hosted MCP server that exposes Cortex Analyst for natural-language-to-SQL over semantic views, Cortex Search for unstructured retrieval, Cortex Agents, direct SQL execution with an optional read-only mode, and user-defined tools, up to 50 tools per server. Authentication is OAuth, authorization rides Snowflake RBAC, and there is no separate infrastructure to run. Per Snowflake's own documentation, it reaches databases, tables, and Cortex services within the Snowflake account. If every dataset your agents need lives in Snowflake, this is a credible, low-friction choice from a vendor with governance in its bones. We would tell you to evaluate it. Most enterprises we meet are not in that position. Where the paths diverge ### Four differences that decide it #### Reach: one warehouse vs the estate Snowflake's MCP story is Snowflake-resident data. Plexara federates through Trino across 40+ connectors: your warehouse, your lakehouse, operational databases, S3, and REST APIs through the gateway. The agent asks one platform and the join can span systems that have never met. #### What travels with a result Cortex Analyst grounds SQL generation in semantic views at query time. Plexara attaches the semantic layer to the response itself: ownership, glossary terms, lineage, deprecation status, and the knowledge your team captured about that table arrive in the same envelope as the rows, on every call. #### Where the learning accumulates Semantic views, Cortex configurations, and agent definitions are Snowflake objects, and they deepen your commitment to the account. Plexara writes captured knowledge and semantic metadata to DataHub in open formats. The training manual your team builds stays readable without us. #### A learning loop, not just access Snowflake MCP serves what Snowflake already knows. Plexara also captures what your people and agents learn as they work: corrections, definitions, and runbooks flow through review into governed knowledge that surfaces on future queries. Access is where a platform starts; compounding knowledge is where it earns rent. ### Side by side | | Snowflake managed MCP | Plexara | | --- | --- | --- | | Data reach | Snowflake-resident data and Cortex services | Federated: warehouses, lakes, databases, S3, REST APIs | | Semantics | Semantic views ground SQL generation | Catalog context enriches every response | | Knowledge capture | Not part of the MCP server | Memory, insights, and governed knowledge built in | | Governance | Snowflake RBAC, OAuth | Personas at execution time, full audit trail | | Metadata home | Snowflake account objects | DataHub, open formats, portable | | Vendor coupling | Deepens the Snowflake commitment | Open protocols: MCP, Trino, DataHub | | Right when | Your data estate is Snowflake | Your data estate is plural | The two are not mutually exclusive: Plexara queries Snowflake through Trino like any other source, so choosing Plexara keeps your Snowflake investment fully in play. The wider argument about warehouse-native assistants is in [why incumbent AI assistants are not enough](https://plexara.io/learning/insights/why-incumbent-ai-assistants-are-not-enough). Next comparison ### Plexara vs Starburst AIDA An assistant inside Starburst vs a platform that makes your existing agents the experts. [Continue](https://plexara.io/compare/starburst-aida) --- # Plexara vs Starburst AIDA URL: https://plexara.io/compare/starburst-aida/ > Starburst AIDA is an assistant inside Starburst's interface. Plexara is an MCP platform that makes Claude, ChatGPT, and your own agents experts on your federated data, with knowledge that compounds. ## Plexara vs Starburst AIDA AIDA is an AI assistant that lives inside Starburst and answers questions in its chat interface. Plexara is an MCP platform that makes the agents you already use, Claude, ChatGPT, or your own, experts on your data. Both take federation seriously. They answer different questions. The facts first ### What AIDA is Announced in April 2026, AIDA is Starburst's conversational analytics assistant. It translates natural language to SQL over sources configured in Starburst, reasons iteratively rather than one-shot translating, renders charts, and tailors responses through built-in executive, analyst, and data engineer personas. Configurable guardrails police its behavior, AIDA Studio adds custom skills, and an MCP client layer lets it pull context from tools like Slack, Jira, and GitHub. It requires Starburst's AI workflows and agentic licenses, and per Starburst's documentation it queries the datasets exposed through selected data products. Starburst runs the enterprise distribution of Trino, so we share a conviction about federated SQL, and AIDA is a serious assistant for teams that live in Starburst. The divergence is architectural, and it changes what you end up owning. Where the paths diverge ### Four differences that decide it #### An assistant vs a platform for your agents AIDA is the agent: a destination you open, with Starburst's chosen models behind it. Plexara is the context layer under whatever agent your team already trusts, connected over open MCP. Your analysts keep their tools; the tools get smarter about your data. #### MCP client vs MCP server AIDA uses MCP to reach outward and enrich its own answers with context from Slack or Jira. Plexara is the MCP surface itself: every capability, query, catalog, memory, knowledge, and connected APIs, is available to any MCP client, so the integration surface is the open protocol rather than one vendor assistant. #### Answers that evaporate vs knowledge that compounds AIDA keeps 90 days of chat history. Plexara captures what each session learns as durable, reviewable knowledge: a correction made in June is attached to the table it concerns and rides along with every query that touches that table in December, whoever asks. #### Scope of the governed surface AIDA answers over datasets exposed through selected data products, governed by its guardrails. Plexara applies personas at execution time across the whole surface: federated SQL, catalog operations, object storage, and REST APIs through the gateway, with every call in one audit log. ### Side by side | | Starburst AIDA | Plexara | | --- | --- | --- | | What it is | AI assistant inside Starburst | MCP data platform for any agent | | Where you use it | Starburst's chat interface | Claude, ChatGPT, IDEs, custom agents, REST API | | MCP role | Client: pulls context from external tools | Server: serves your data estate to every client | | Federation | Starburst-configured sources via data products | Trino across 40+ connectors plus REST APIs | | Personas | Response style: executive, analyst, engineer | Access control: what each role can see and call | | What persists | 90-day chat history | Governed memory, insights, and knowledge in DataHub | | Licensing | Starburst AI workflows and agentic licenses | Fully managed platform, one relationship | Choose AIDA if your organization standardizes on Starburst and wants a vendor-provided assistant in that console. Choose Plexara if the goal is one governed context layer that makes every AI surface your organization touches accurate on your data, and that turns daily usage into institutional knowledge you keep. The pattern behind that argument is in [own the learning loop, not the model](https://plexara.io/learning/insights/own-the-learning-loop-not-the-model). Keep going ### See the numbers behind the claims A controlled benchmark isolating what the platform contributes, with reproduction commands. [Continue](https://plexara.io/benchmark) --- # Learning URL: https://plexara.io/learning/ > AI, MCP, and data context education for enterprise teams. A self-serve curriculum on LLMs, the Model Context Protocol, and the governed context layer. Learning ## AI, MCP, and the Governed Context Layer Two ways in. Insights are editorial: one argument each, read in any order, whenever the question comes up. The curriculum runs in sequence and is written to be worked through. Insights ### Technical perspectives Architecture decisions, comparisons against the alternatives, and arguments about where this market is going. Each piece stands alone, so start with whichever question you brought. [All 34 insights](https://plexara.io/learning/insights) [15 min Philosophy The Frontier Report: 2026 Q3 Independent scores for current frontier flagships as of September 2026, written for someone putting an assistant in front of company data. Read](https://plexara.io/learning/insights/frontier-report-v1) [9 min Governance Every call your agent makes states its purpose An AI agent that can query your warehouse leaves a question behind: what did it run, and why? On Plexara every query and API call carries the purpose the agent stated for it, every session can be opened long after it ended, and every saved report names the calls it was built from. Read](https://plexara.io/learning/insights/every-call-states-its-purpose) [10 min Product The report that runs without the agent An hour with an AI assistant produces the perfect sales report. Re-deriving it every week burns tokens on logic that is already settled. Plexara lets the agent save that logic as a script the platform runs on demand or on a schedule: reports, exports, and dashboards that stay fresh with no model in the loop. Read](https://plexara.io/learning/insights/the-report-that-runs-without-the-agent) The curriculum ### From what a token is to procedures your team runs Work through it and a new analyst can get real answers out of the agent, know why the platform gave them that answer and not another, and turn the sessions worth repeating into procedures anyone on the team can run. Start at 101 if AI is new to your people, jump to the 200s if you know models but not MCP, and go straight to the 300s if you are already working in the portal. 100 series 6 lessons #### [AI Concepts](https://plexara.io/learning/ai-concepts) Foundations Plain-language groundwork: what a large language model actually does, what a token costs you, what a frontier model is, and what people mean by an agent. - [101 - What is a Large Language Model?](https://plexara.io/learning/ai-concepts/what-is-a-large-language-model) - [102 - Tokens and your budget](https://plexara.io/learning/ai-concepts/tokens-and-your-budget) - [103 - Context, compression, and memory](https://plexara.io/learning/ai-concepts/context-windows-and-tokens) [All 6 lessons](https://plexara.io/learning/ai-concepts) 200 series 12 lessons #### [Plexara MCP](https://plexara.io/learning/mcp) The platform curriculum What an MCP server contains, what Plexara adds on top of the open standard, and how semantic enrichment, memory, and governance change what an agent can answer. - [201 - Anatomy of a Plexara MCP](https://plexara.io/learning/mcp/what-is-an-mcp) - [202 - Your first day with Plexara](https://plexara.io/learning/mcp/first-engagement) - [203 - Discovery: one search, then fetch](https://plexara.io/learning/mcp/discovery-search-and-fetch) [All 12 lessons](https://plexara.io/learning/mcp) 300 series 8 lessons #### [Asset Workflows](https://plexara.io/learning/assets) The applied workbook Day-to-day mechanics of the asset system: building reports and dashboards, exporting data, sharing, collections, editing, metadata, and retrieval. - [301 - Creating reports and dashboards](https://plexara.io/learning/assets/creating-reports-and-dashboards) - [302 - Exporting data](https://plexara.io/learning/assets/exporting-data) - [303 - Sharing your work](https://plexara.io/learning/assets/sharing-your-work) [All 8 lessons](https://plexara.io/learning/assets) 400 series 4 lessons #### [Prompts as SOPs](https://plexara.io/learning/prompts) Procedures worth keeping A report you went back and forth on is a procedure. Let the agent author it, share it with the team, improve it through feedback, and run it whenever you need it. - [401 - Prompts are the new SOPs](https://plexara.io/learning/prompts/prompts-are-the-new-sops) - [402 - Letting the agent write the prompt](https://plexara.io/learning/prompts/letting-the-agent-write-the-prompt) - [403 - Sharing prompts, and closing the loop with feedback](https://plexara.io/learning/prompts/sharing-prompts-and-feedback) [All 4 lessons](https://plexara.io/learning/prompts) 500 series 5 lessons #### [Spreadsheets as Tables](https://plexara.io/learning/spreadsheets) Data in, without a pipeline A file somebody receives by email becomes a table every agent on the team can join against the warehouse. Uploading, registering, teaching the agent what the columns mean, joining and sharing, and keeping it current month after month. - [501 - The last mile of data is a spreadsheet](https://plexara.io/learning/spreadsheets/the-last-mile-of-data-is-a-spreadsheet) - [502 - Uploading a file and registering it as a table](https://plexara.io/learning/spreadsheets/uploading-and-registering-a-file) - [503 - Teaching the agent what the file means](https://plexara.io/learning/spreadsheets/teaching-the-agent-what-the-file-means) [All 5 lessons](https://plexara.io/learning/spreadsheets) 600 series 6 lessons #### [Automations](https://plexara.io/learning/automations) The agent as developer The agent writes the script, Plexara runs it on demand or on a schedule, and the outputs refresh themselves. Authoring, outputs, running, what a run may do, and the weekly review that composes scripts, prompts, and knowledge. - [601 - Do not spend AI on what a script can do](https://plexara.io/learning/automations/do-not-spend-ai-on-what-a-script-can-do) - [602 - The agent writes the first script](https://plexara.io/learning/automations/the-agent-writes-the-first-script) - [603 - Outputs: feeds, reports, and dashboards that refresh themselves](https://plexara.io/learning/automations/outputs-feeds-reports-and-dashboards) [All 6 lessons](https://plexara.io/learning/automations) Also here ### Reference, cadence, and what changed [Platform Concepts Ten expandable visual explainers of how the platform works, from semantic enrichment and memory to personas, audit, and federated SQL. Browse the concepts](https://plexara.io/learning/concepts) [Newsletter The Plexara Monthly Dispatch: what shipped, what is worth reading, and one practical tip. Every issue archived here in full. Read the archive](https://plexara.io/learning/newsletter) [Changelog A weekly, plain-language record of new capabilities landing in your fully managed platform. See what is new](https://plexara.io/product/changelog) How to use this curriculum ### What each series leaves your team with The 100 series is the foundation: tokens, context windows, frontier versus specialized models, what an AI agent actually is. Read these first if AI is new to your team or if you want to ground vocabulary before going deeper. The 200 series is the platform curriculum. It covers what an MCP server actually contains, how Plexara extends the protocol with semantic enrichment, memory, and governance, and what a real engagement looks like end to end. Read these to understand how Plexara differs from a vanilla MCP gateway. The 300 series is the applied workbook. Eight short lessons covering the day-to-day mechanics of the asset system: creating reports and dashboards, exporting data, sharing, collections, editing, metadata, retrieval, and writing reproducible prompts. Start here once you have the mental model from the 200 series. The 400 series is the operating-procedure layer. It makes the case that a report you went back and forth on is a procedure worth keeping, then covers letting the agent author the prompt, sharing it across the team, improving it through feedback, and running it by hand or on a schedule. Read it once you are producing real work with the agent and want it to compound. Insights sit outside the numbering on purpose. They are editorial, not reference: each one captures a single architectural argument, a comparison against an alternative approach, or a perspective on where the market is going. Read them in any order, whenever the question comes up. Suggested paths - AI-fluent reader: skim 110 (MCP vs APIs) and dive into the 200 series. - Reader new to AI: 101, 102, 103, 105 build the foundation; then start the 200 series. - Architect or platform lead: skim Insights first to understand the design philosophy, then go deep on the 200 series. - Analyst or daily user: read 205 in the 200 series, then jump straight into Asset Workflows for the recipes. - Standardizing recurring work: read Asset Workflows, then Prompts as SOPs to turn your best sessions into shared, repeatable procedures. Next ### Portal Tour See how Plexara puts everything you have just learned into the hands of your teams. [Continue](https://plexara.io/product/portal) --- # Insights URL: https://plexara.io/learning/insights/ > Technical deep dives, architecture decisions, and perspectives on building the governed context layer for enterprise AI agents. ## Technical Perspectives Technical deep dives, architecture decisions, and perspectives on the governed context layer for enterprise AI agents. Field notes ### What these are, and what they are not These are editorial pieces. Each one captures a single architectural argument, a comparison against an alternative approach, or a perspective on where the market is going. They are written to be read in any order; each piece stands alone. Use insights when you want context for a decision, not when you need a procedure. Reference material lives in the 100 and 200 series of the curriculum. [15 min Philosophy The Frontier Report: 2026 Q3 Independent scores for current frontier flagships as of September 2026, written for someone putting an assistant in front of company data. Read](https://plexara.io/learning/insights/frontier-report-v1) [9 min Governance Every call your agent makes states its purpose An AI agent that can query your warehouse leaves a question behind: what did it run, and why? On Plexara every query and API call carries the purpose the agent stated for it, every session can be opened long after it ended, and every saved report names the calls it was built from. Read](https://plexara.io/learning/insights/every-call-states-its-purpose) [10 min Product The report that runs without the agent An hour with an AI assistant produces the perfect sales report. Re-deriving it every week burns tokens on logic that is already settled. Plexara lets the agent save that logic as a script the platform runs on demand or on a schedule: reports, exports, and dashboards that stay fresh with no model in the loop. Read](https://plexara.io/learning/insights/the-report-that-runs-without-the-agent) [9 min Product The spreadsheet that joins your warehouse Ad-hoc CSVs are the most common data silo in business: valuable exactly when joined, stranded in inboxes because loading them was a project. Plexara registers an uploaded CSV, or one an agent built, as a queryable table over the file where it sits, so the join runs in the warehouse instead of the context window. Read](https://plexara.io/learning/insights/the-spreadsheet-that-joins-your-warehouse) [8 min Architecture When the answer is an action Business intelligence has always ended at a finding: the analysis stops, and the action moves to other tools, other people, and next week. An agent that reaches remote systems through a governed API gateway closes that gap. The same session that finds the audience pushes it, schedules the send, and verifies the result. Read](https://plexara.io/learning/insights/when-the-answer-is-an-action) [8 min Integration The public data your warehouse is missing The federal statistical system publishes some of the best-maintained data in the world through free APIs: demographics, income, employment, weather, traffic. It rarely reaches a company warehouse because the friction lived in the plumbing. Give an agent a governed gateway to these sources and the friction is gone. Read](https://plexara.io/learning/insights/the-public-data-your-warehouse-is-missing) [7 min Philosophy A tool catalog is not a data platform Agent integration platforms now advertise thousands of connected apps and tens of thousands of actions. Catalog size is the wrong axis. What determines whether an agent produces dependable work is what surrounds the call: where the answer lands, who was allowed to make it, and what the platform remembers afterward. Read](https://plexara.io/learning/insights/a-tool-catalog-is-not-a-data-platform) [9 min Product What one person teaches, the whole team gets An analyst corrects the assistant once and a colleague who never saw that conversation gets the right answer weeks later. Our own benchmark said that mostly was not happening, named the likely cause, and the rerun after a targeted fix says it now happens 98.9 percent of the time. Read](https://plexara.io/learning/insights/what-one-person-teaches-the-whole-team-gets) [8 min Product When do agents use what you teach them? Plexara's knowledge-use study asks what an agent actually does with delivered knowledge. Strong models re-verify anything they can check, and rely completely on the facts they cannot re-derive: conventions, definitions, policies. Without those facts, they invent plausible substitutes 75 percent of the time. Read](https://plexara.io/learning/insights/when-agents-use-what-you-teach) [10 min Philosophy Two benchmarks, one conclusion: the industry is converging on context dbt Labs benchmarked agents on its semantic layer against text-to-SQL and reached the conclusion our platform ablation reached: govern the context between an agent and the data, and business questions move from unreliable to dependable. Two methods, one finding, and a rule for reading both. Read](https://plexara.io/learning/insights/two-benchmarks-one-conclusion) [9 min Product Benchmarking the context layer We built a benchmark that holds the model constant and varies only the platform. On business-context questions, an agent on raw data tools was right about 43 percent of the time. The same agent on Plexara was right about 99 percent, using fewer tool calls. Read](https://plexara.io/learning/insights/benchmarking-the-context-layer) [9 min Philosophy Why a Plexara rollout starts small A first deployment connects two or three data sources and one persona, then expands without rewriting what came before. Phased rollout is not caution for its own sake. It is how a complex system that works actually comes to exist. Read](https://plexara.io/learning/insights/why-a-plexara-rollout-starts-small) [8 min Philosophy What you keep if you leave Metadata you author through Plexara lives in DataHub in open formats. If you stop using the platform, you keep the catalog, the lineage, and the definitions your team wrote. Portability is a property of the storage, not a promise on a slide. Read](https://plexara.io/learning/insights/what-you-keep-if-you-leave) [8 min Integration Two front doors, one governed surface Plexara exposes the same governed surface through an MCP server and a REST API. SDKs connect to both, custom tools extend it, and every path shares one identity, one audit log, and one persona model. Read](https://plexara.io/learning/insights/the-developer-surface) [9 min Architecture Five kinds of memory, and how each comes back A fact, an incident, a person, a link, and a habit are five different kinds of knowledge. Plexara stores each as its own dimension and recalls it the way that kind needs, which is what makes memory across sessions feel like memory rather than search. Read](https://plexara.io/learning/insights/five-kinds-of-memory) [11 min Philosophy Own the learning loop, not just the model A frontier model never learns your institutional knowledge. It only gets better at using what your people supply and frame, so the durable equity is built outside the model: a loop that captures human and model coordination and keeps it inside your own ecosystem. That loop is most of what Plexara already is. Read](https://plexara.io/learning/insights/own-the-learning-loop-not-the-model) [7 min Product When prompts become shared infrastructure A good prompt is only useful if other people can find it, trust it, and run it. Treating prompts as governed, searchable assets turns one person's good question into everyone's. Read](https://plexara.io/learning/insights/governed-prompts-and-relevance-search) [6 min Governance Closed by default: least privilege as the starting point Access control that starts open and gets locked down later never actually finishes. Closing connection access by default means every role sees exactly what it was granted and nothing more. Read](https://plexara.io/learning/insights/closed-by-default-access) [9 min Architecture Search the capability, not the manual: how Plexara keeps a wide platform light Loading every API spec into context does not scale. A small, fixed tool footprint plus semantic endpoint discovery keeps cost tied to the task, not the size of the platform. Read](https://plexara.io/learning/insights/search-the-capability-not-the-manual) [7 min Architecture Letting the agent find the right tool An agent that rereads every tool description on every turn is slow and error-prone. Selecting tools by intent, and remembering context across sessions, is what makes a wide platform feel fast. Read](https://plexara.io/learning/insights/intent-driven-tools-and-memory) [10 min Architecture The combinatorial platform: when an agent can see across the whole stack A warehouse connection tells you what the data is. The valuable questions need an agent that reasons across query, catalog, orchestration, and source layers at once. Read](https://plexara.io/learning/insights/when-an-agent-can-see-the-whole-stack) [6 min Integration Meeting enterprise systems where they are Real enterprise APIs authenticate in messy ways: client certificates, basic auth, second credential headers. Supporting them, while keeping each user activity isolated, is what makes an agent usable at work. Read](https://plexara.io/learning/insights/enterprise-authentication-and-isolation) [8 min Philosophy Why more tools won't make your agent smarter An agent with fifty tools and no context is a confident intern with root access. Capability scales with understanding of the data, not connector count. Read](https://plexara.io/learning/insights/why-more-tools-wont-make-your-agent-smarter) [6 min Integration Why an agent needs a versioned API catalog Pointing an agent at an API is the easy part. Making it dependable when the API changes, returns surprises, or needs a second credential is the hard part. A versioned catalog is what turns a connection into something you can rely on. Read](https://plexara.io/learning/insights/versioned-api-catalogs) [12 min Architecture Why proximity matters: tools, meaning, and memory belong together Most AI agent stacks are gateways wrapped in auth. The hard work is not routing tool calls; it is making sure context arrives with them. Read](https://plexara.io/learning/insights/why-proximity-matters-tools-meaning-memory) [12 min Integration The context gap in AI data access AI agents can execute SQL, but without business context they generate inaccurate queries and untrustworthy results. Not a better model. Better context. Read](https://plexara.io/learning/insights/context-gap-in-ai-data-access) [10 min Philosophy Protocols outlast products MCP, Trino, and DataHub are open protocols with communities larger than any vendor. Building on protocols, not proprietary platforms, is the durable choice. Read](https://plexara.io/learning/insights/protocols-outlast-products) [11 min Product How knowledge application turns usage into documentation Most data catalogs are empty because documentation is a separate task. Plexara inverts this: documentation happens as a byproduct of people using data. Read](https://plexara.io/learning/insights/knowledge-application-turns-usage-into-documentation) [11 min Governance Governance at execution time vs. catalog time Traditional governance creates policies in a catalog and hopes they are enforced. AI agents expose the gap. Closing it unifies governance with execution. Read](https://plexara.io/learning/insights/governance-at-execution-time) [10 min Architecture Token efficiency in enterprise MCP deployments Most MCP implementations waste tokens through tool explosion, redundant metadata fetches, and repeated context. Three mechanisms eliminate these costs. Read](https://plexara.io/learning/insights/token-efficiency-in-enterprise-mcp) [9 min Product Replacing the five-vendor data stack with one platform The modern data stack costs $300K-$1M per year across 5+ products. Plexara consolidates catalog, query, governance, enrichment, and agent framework into one. Read](https://plexara.io/learning/insights/replacing-the-five-vendor-data-stack) [9 min Architecture Why MCP gateways are not enough MCP gateways solve the plumbing problem but not the meaning problem. A gateway authenticates a tool call. It cannot tell you what the data means. Read](https://plexara.io/learning/insights/why-mcp-gateways-are-not-enough) [10 min Philosophy Why incumbent AI assistants are not enough Every major warehouse vendor has an AI assistant. They work well within their own ecosystem. The problem is that your data does not live in one ecosystem. Read](https://plexara.io/learning/insights/why-incumbent-ai-assistants-are-not-enough) [10 min Governance Why point-solution catalogs and semantic layers are not enough Data catalogs document data but cannot execute queries. Semantic layers define metrics but delegate execution. Neither provides unified context and access. Read](https://plexara.io/learning/insights/why-point-solution-catalogs-are-not-enough) --- # AI Concepts URL: https://plexara.io/learning/ai-concepts/ > Plain-language foundations on large language models, frontier models, and the concepts every enterprise team needs before adopting AI-native data tools. ## LLM & Frontier Models Plain-language foundations your team needs before adopting AI-native data tools. Start here if you are ramping from “I have heard of ChatGPT” to “I can reason about LLM behavior in production.” [12 min Philosophy 101 - What is a Large Language Model? LLMs predict the next token from patterns learned across trillions of training examples. What that means, why it produces fluent reasoning, and its limits. Read](https://plexara.io/learning/ai-concepts/what-is-a-large-language-model) [8 min Product 102 - Tokens and your budget Every LLM interaction is priced and rate-limited in tokens. What a token is, how much text fits a budget, and how to avoid wasting tokens on useful answers. Read](https://plexara.io/learning/ai-concepts/tokens-and-your-budget) [9 min Architecture 103 - Context, compression, and memory The context window is a model's working memory. Each session balances keeping, compressing, or clearing it. Plexara adds enterprise memory on top. Read](https://plexara.io/learning/ai-concepts/context-windows-and-tokens) [12 min Philosophy 104 - Frontier models, specialized models, and why enterprise AI uses both Frontier models bring world knowledge; small local embedding models power memory and catalog search. Knowing each role designs AI systems that work. Read](https://plexara.io/learning/ai-concepts/frontier-models-explained) [10 min Product 105 - What is an AI agent? An AI agent is not a chatbot and not magic. It is a short loop (think, call-tool, observe, think again) on top of a language model. Mental model first. Read](https://plexara.io/learning/ai-concepts/what-is-an-ai-agent) [8 min Integration 110 - Is MCP just an API wrapper? MCP is not a replacement for your APIs and not a thin proxy. It is an application layer on top, like a website is an application layer on top of its APIs. Read](https://plexara.io/learning/ai-concepts/mcp-vs-apis) [Next series 200 · Plexara MCP What an MCP server contains, and what Plexara adds on top of the open standard for enterprise data.](https://plexara.io/learning/mcp) [All six series and the insights archive](https://plexara.io/learning) --- # Plexara MCP URL: https://plexara.io/learning/mcp/ > A plain-language introduction to the Model Context Protocol, how it works, and how Plexara extends it with semantic enrichment, memory, and governance. ## What is an MCP? How the Model Context Protocol becomes your agent's window into governed data, and what Plexara adds on top of the open standard. [15 min Architecture 201 - Anatomy of a Plexara MCP 201 shows what is actually in the box on a Plexara server: the tool inventory by toolkit, the four content layers, the interactive apps a tool result can carry, and the memory, knowledge, and governance underneath. This lesson is the map. Read](https://plexara.io/learning/mcp/what-is-an-mcp) [11 min Product 202 - Your first day with Plexara A new Plexara user gets connected, sends a first question, and platform_info takes over. Walks through day one and how subsequent turns inherit context. Read](https://plexara.io/learning/mcp/first-engagement) [11 min Product 203 - Discovery: one search, then fetch One question reaches every system the agent can see. Results come back grouped by source with a coverage summary, and fetch reads any of them in full. Read](https://plexara.io/learning/mcp/discovery-search-and-fetch) [11 min Product 204 - Trino Query: analytics and insights Plexara reaches customer data through Trino. What Trino is, how it maps to DataHub metadata, why OLAP queries finish fast, and how to export large results. Read](https://plexara.io/learning/mcp/trino-query-analytics-and-insights) [10 min Product 205 - Assets: dashboards, reports, and data Plexara's asset system persists dashboards, reports, and exports outside chat. Naming asset tools in a prompt saves tokens and keeps outputs shareable. Read](https://plexara.io/learning/mcp/assets-dashboards-reports-and-data) [14 min Product 206 - Knowledge: from a memory to something the whole team can use Memory to Insight to Knowledge: the three stages a fact travels, the capability check that promotes it, and the two canonical places it lands. Read](https://plexara.io/learning/mcp/knowledge-from-memory-to-insights) [11 min Product 207 - Governance: personas, access, and audit Governance in Plexara is enforced when a tool is invoked, not described in a policy. Personas, default-deny, layered safeguards, and a single audit log. Read](https://plexara.io/learning/mcp/governance-personas-and-access) [16 min Product 208 - The prompt library: versioned, shared, and measurable Two buckets, collections and facets, version history with approval provenance, attached materials, and running a prompt by whatever handle you know it by. Read](https://plexara.io/learning/mcp/mcp-prompts-reusable-prompts) [15 min Product 209 - Resources: the company files the agent should use, not reinvent Your templates, brand files, and reference documents, uploaded once and used as-is: which layer a file belongs on, search then fetch, revisions that keep every citation resolving, and making a template mandatory. Read](https://plexara.io/learning/mcp/mcp-resources-templates-and-examples) [16 min Product 210 - Putting it all together: a worked end-to-end example A capstone that walks a single real-world question through every Plexara subsystem covered in the 200 series, with a tool-by-tool reference at the end. Read](https://plexara.io/learning/mcp/tool-survey) [13 min Product 211 - Governing the catalog without leaving the portal Tags, domains, the business glossary, context documents, and per-table metadata are edited in the portal, under the same persona grants that govern the agent and in the same audit log. Read](https://plexara.io/learning/mcp/catalog-governance-in-the-portal) [12 min Product 212 - Seeing the shape of what your team knows The portal draws your knowledge corpus as its reference network and measures it: node size is how much of the corpus an entity holds together, and a citation the catalog cannot confirm is stated rather than drawn as if it resolved. Read](https://plexara.io/learning/mcp/the-knowledge-graph) [Previous series 100 · AI Concepts Plain-language foundations: what a large language model does, what a token costs, and what people mean by an agent.](https://plexara.io/learning/ai-concepts) [Next series 300 · Asset Workflows The applied workbook: reports and dashboards, exports, sharing, collections, editing, metadata, and retrieval.](https://plexara.io/learning/assets) [All six series and the insights archive](https://plexara.io/learning) --- # Asset Workflows URL: https://plexara.io/learning/assets/ > Hands-on recipes for the Plexara asset system: creating reports and dashboards, exporting data, and more. ## Working with assets and collections Hands-on recipes for the Plexara asset system: creating dashboards and reports, exporting data, and more. The 300 series picks up where 205 left off. [10 min Product 301 - Creating reports and dashboards AI chat tools produce excellent dashboards and reports in HTML, JSX, and SVG, formats that do not move easily through normal business workflows. Plexara gives them a home in the portal under Assets: your team's catalog of AI-built work, shared like Google Docs, stored in your S3, editable in place, and discoverable by future agent sessions. This article is the working playbook, including the two prompting habits that make the agent produce a saved asset efficiently. Read](https://plexara.io/learning/assets/creating-reports-and-dashboards) [10 min Product 302 - Exporting data When a teammate asks for the data instead of the dashboard: a spreadsheet to pivot, a JSON to feed another system, a markdown table for a wiki. Plexara has a dedicated path for this called Trino Export. It runs the query, writes the file straight to your S3 bucket, and never puts the rows in your chat. This article is the analyst's playbook. Read](https://plexara.io/learning/assets/exporting-data) [14 min Product 303 - Sharing your work Sharing in Plexara sends real mail. Name a colleague and they get an email carrying your note and a link that opens the work; name somebody with no Plexara account and they can still read it, through a single-use link sent to the address you named. This lesson is the playbook for getting a dashboard in front of the right person and knowing what happened to it after you clicked Share. Read](https://plexara.io/learning/assets/sharing-your-work) [10 min Product 304 - Creating collections A board briefing is rarely one dashboard. It's a dashboard plus a summary plus the underlying data, opened from a single link in the order you chose. Plexara calls that packaging unit a collection. You can ask the agent to assemble one during the same session that produced the assets, or build one by hand on the Collections page. This lesson covers both. Read](https://plexara.io/learning/assets/creating-collections) [10 min Product 305 - Editing what you already have When the dashboard you saved last week is mostly right but needs a fix, you do not re-create it from scratch. You edit the existing asset in place. The link the recipient already has keeps working, the version history accumulates on one asset instead of fragmenting across copies, and any collection that references it picks up the change. This lesson covers the three kinds of edit (metadata, content, revert), what each one does to the version history, and the portal vs agent path. Read](https://plexara.io/learning/assets/editing-what-you-already-have) [12 min Product 306 - How an asset was built Every asset in Plexara carries two kinds of metadata: descriptive fields the agent fills when it saves the asset (name, description, tags) and that you can edit later, and provenance the platform records on its own. Provenance is the audit trail Plexara captures at the MCP boundary: the catalog searches and queries the agent invoked, with what parameters, in the producing session. This lesson opens that record, names what it can and cannot tell you, and shows how to use it to answer the questions stakeholders ask about a number. Read](https://plexara.io/learning/assets/how-an-asset-was-built) [13 min Product 307 - Turning a comment into something the agent remembers A reviewer writes "we don't use that term" on your dashboard. In most tools that comment stays a comment, and the same correction gets made again next quarter. In Plexara an agent can fold it into the knowledge loop: memory_capture with thread_ids records the lesson as a pending insight, resolves the thread, and routes it to the review queue that produces knowledge pages and catalog changes. The person who raised it then confirms or disputes the resolution. This lesson covers the whole loop, the notification rules, the access rules, and how a reviewer with no account participates through a public link. Read](https://plexara.io/learning/assets/feedback-that-becomes-knowledge) [11 min Product 308 - Reproducible prompts Plexara has a first-class prompt object: a saved instruction template with named arguments that you (or a teammate) can re-run later with different values. Manage Prompts (manage_prompt) is the tool. This article covers what a prompt record actually is, how arguments substitute at run time, which scope to pick (personal, persona, global), the four built-in workflow prompts, and the limits of what re-running a prompt does and does not guarantee. Read](https://plexara.io/learning/assets/reproducible-prompts) [Previous series 200 · Plexara MCP What an MCP server contains, and what Plexara adds on top of the open standard for enterprise data.](https://plexara.io/learning/mcp) [Next series 400 · Prompts as SOPs Turn the sessions worth repeating into procedures your team can find, run, and improve.](https://plexara.io/learning/prompts) [All six series and the insights archive](https://plexara.io/learning) --- # Prompts as SOPs URL: https://plexara.io/learning/prompts/ > The Plexara 400 series: saving the procedures your team discovers with the agent as reusable prompts. Letting the agent author them, sharing them, improving them with feedback, and running them. ## Prompts as SOPs The procedures your team discovers with the agent are worth keeping. The 400 series is about saving a specialized job as a prompt, letting the agent author it, sharing it, and improving it through feedback. It picks up where 308 left off. [9 min Philosophy 401 - Prompts are the new SOPs You work with the agent for an hour to get one report exactly right, with a year-over-year cut, holiday annotations, and storm-closure markers. The agent saves durable business knowledge on its own. But that specialized report is not institutional knowledge, it is a procedure. This article draws the line between the two, and makes the case that a saved prompt is the standard operating procedure for an AI-run job. Read](https://plexara.io/learning/prompts/prompts-are-the-new-sops) [9 min Product 402 - Letting the agent write the prompt The cheapest way to save a procedure is to not write it yourself. The agent that just spent an hour producing your report still holds the tool order, the corrections, and the values worth turning into arguments. Ask it to author the prompt, review the draft, and save it. This article covers the move, why the agent is the better author, and how to read what it produces. Read](https://plexara.io/learning/prompts/letting-the-agent-write-the-prompt) [12 min Governance 403 - Sharing prompts, and closing the loop with feedback A procedure is only worth as much as the people who can run it. Plexara distributes a prompt two ways: a direct share to one teammate, or a promotion to a whole role or company through the admin review queue. A shared prompt is live, not a copy. Feedback threads then carry corrections back, with a validation step and a path into the knowledge catalog, and the deprecate-and-supersede lifecycle retires old versions cleanly. Read](https://plexara.io/learning/prompts/sharing-prompts-and-feedback) [9 min Product 404 - Running prompts, by hand and on a schedule A saved prompt runs two ways: at your keyboard when you want the report now, and on a schedule when you want it to arrive on a cadence. Running by hand takes a sentence: name it to the agent under any handle it knows, pick it in the List Prompts app, or paste the portal’s copyable invocation. Scheduling is not a Plexara feature at all; it lives in your agent, from an in-session loop to a cloud routine that runs when your machine is off. This article covers both, where the output goes, and how a share turns an unattended run into email somebody actually reads. Read](https://plexara.io/learning/prompts/running-prompts-and-schedules) [Previous series 300 · Asset Workflows The applied workbook: reports and dashboards, exports, sharing, collections, editing, metadata, and retrieval.](https://plexara.io/learning/assets) [Next series 500 · Spreadsheets as Tables A file somebody receives by email becomes a table every agent on the team can join against the warehouse, and stays current month after month.](https://plexara.io/learning/spreadsheets) [All six series and the insights archive](https://plexara.io/learning) --- # Spreadsheets as Tables URL: https://plexara.io/learning/spreadsheets/ > The Plexara 500 series: uploading a file, registering it as a table beside the warehouse, teaching the agent what its columns mean, joining and sharing the result, and keeping the table current when next month’s file arrives. ## Spreadsheets as Tables A file somebody receives by email becomes a table every agent on the team can join against the warehouse, with no DBA, no staging table, and no load job. The 500 series works one supplier price sheet from upload to next month’s revision: registering it, teaching the agent what it means, joining and sharing the result, and keeping it current. [9 min Philosophy 501 - The last mile of data is a spreadsheet The join was never the expensive part of using an outside file. Loading it was, and loading was staffed: a ticket for the table, an engineer for the load, an integration platform somebody had to keep. A chat agent does not close that gap on its own, because a large file does not fit its context and the scripts it writes vanish with the session. This lesson sets out the gap, the registration model that closes it (a table over the file where it sits, nothing copied), and the size rule for when a file needs no table at all. Read](https://plexara.io/learning/spreadsheets/the-last-mile-of-data-is-a-spreadsheet) [11 min Product 502 - Uploading a file and registering it as a table The mechanics. Upload a file to the resource library with a description search will match, export a spreadsheet as UTF-8 CSV first, register it from the file’s own page or with one sentence to the agent, and read what comes back: the qualified name, the columns, and a sample statement with the cast. Then the Scratch Tables page, where every registration is listed with its state, and the three things a file can be refused for, with the repair that writes a corrected version through the file’s own history. Read](https://plexara.io/learning/spreadsheets/uploading-and-registering-a-file) [9 min Product 503 - Teaching the agent what the file means A header row says what the columns are called, not what they mean. This lesson is the five minutes after registration: telling the agent the units, the grain, the effective dating, the join key, and what a missing row means; letting it capture that as memory; promoting the capture to a knowledge page so every teammate’s agent recalls it; and recording the first successful join as a reusable query. Registering publishes the data. This is how you publish the meaning. Read](https://plexara.io/learning/spreadsheets/teaching-the-agent-what-the-file-means) [10 min Product 504 - Joining, visualizing, and sharing The join, with the cast every registered column needs, run against a real supplier quote and a month of sales: cost change by category, the SKUs whose margin falls under a threshold at the current price, and the SKUs the sheet does not cover. The result becomes a dashboard asset with provenance, shared with the people who need it. The lesson closes with the choice between querying a registered table and having a dashboard reference the file directly, which re-reads it on every open. Read](https://plexara.io/learning/spreadsheets/joining-visualizing-and-sharing) [9 min Governance 505 - Next month’s file The new sheet arrives. Replacing the file’s content writes a new revision, and the registered table keeps reading the old one until it is registered again under the same name; the Scratch Tables page says so. This lesson covers the two cases that look alike and behave differently, moving the table forward, unregistering, what deleting the file does, saving the monthly procedure as a prompt, and the point at which a monthly file needs more than a join, which is where the 600 series begins. Read](https://plexara.io/learning/spreadsheets/next-months-file) [Previous series 400 · Prompts as SOPs Turn the sessions worth repeating into procedures your team can find, run, and improve.](https://plexara.io/learning/prompts) [Next series 600 · Automations The agent writes the script, Plexara runs it on demand or on a schedule, and the outputs refresh themselves.](https://plexara.io/learning/automations) [All six series and the insights archive](https://plexara.io/learning) --- # Automations URL: https://plexara.io/learning/automations/ > The Plexara 600 series: the agent writes a script, Plexara runs it on demand or on a schedule, and the outputs refresh themselves. Authoring, outputs, running, governance, and the weekly review that composes scripts, prompts, and knowledge. ## Automations The agent writes the script in a session; Plexara keeps it, versions it, runs it on demand or on a schedule, and the outputs refresh themselves. The 600 series follows three scripts from the first draft to the weekly review the agent runs on the business, with the division of labor that makes it work: a script for the deterministic part, the model for the judgment. [10 min Philosophy 601 - Do not spend AI on what a script can do The report that gets rebuilt every Monday spends tokens on logic that was settled weeks ago and drifts a little each time. Integration platforms automate well but need a platform expert, so a one-off analysis never crosses that bar; an agent on a laptop writes scripts that vanish with the session. This lesson sets out the division of labor the series runs on: a script for the deterministic part, the model for writing it and for judgment about what it produced, and a managed script as the thing Plexara keeps, versions, runs, and schedules. Read](https://plexara.io/learning/automations/do-not-spend-ai-on-what-a-script-can-do) [12 min Product 602 - The agent writes the first script From a solved session to a saved script, with the loop the agent works through: create, validate, dry-run, patch, validate, dry-run, save. What a validate report says about the tools, connections, and destinations a script reaches; what a dry run measures without persisting anything; the dialect’s deliberate absences and the three traps that fail a draft; typed parameters; and the script’s own page in the portal with its source, Validate, Dry run, and versions. Grounded in a real script that reads the 500 series’ registered table. Read](https://plexara.io/learning/automations/the-agent-writes-the-first-script) [11 min Product 603 - Outputs: feeds, reports, and dashboards that refresh themselves What a run produces and where it lands. One script and one output name is one asset, and every run adds a version; a dated name builds an archive instead. Rows become CSV or JSON feeds; a string body becomes a markdown, HTML, or JSX document. A semi-dynamic dashboard is published once and has only its data region refreshed on later runs, so layout edits made in the portal survive. A dashboard can instead reference a file a script rewrites, capped versions keep an asset tidy, and a named bucket drop delivers the same bytes to another system. Read](https://plexara.io/learning/automations/outputs-feeds-reports-and-dashboards) [10 min Product 604 - Running it: by hand, from the portal, and on a schedule Three triggers, one run. From any session with a single call, from the Run button on the script’s page where the form comes from its parameter contract, or on a cadence set in the portal’s builder or by the agent, in a timezone, with the fire date pinned onto the run. What a schedule guarantees: one fire is one run, an overlapping fire is recorded as skipped, a gap produces one run for the latest fire, a failed scheduled run emails its owner and is never retried. And the run history that records every trigger, duration, output, and log. Read](https://plexara.io/learning/automations/running-by-hand-from-the-portal-and-on-a-schedule) [9 min Governance 605 - What a run may do, and the record it leaves A run presents the roles its author held at the save, every call is authorized at that moment, and narrowing the persona takes effect on the next run. A save refuses a credential-shaped literal and source that does not parse. The dialect has no network, no filesystem, and no clock, so everything a script does is a platform call audited under the script’s own identity. The lifecycle from active to disabled, deprecated, and superseded; who sees what; ownership and an administrator’s transfer; and the administrator’s view of every script and every run. Read](https://plexara.io/learning/automations/what-a-run-may-do) [12 min Integration 606 - Scripts as skills: the weekly review the agent runs on your business The capstone. Three scripts (category velocity, the supplier quote margin review, regional weather context) attached to one prompt, so serving the prompt carries each script’s contract and last successful output and the agent runs them for fresh numbers instead of re-deriving them. The agent then reads the outputs against the seasonality calendar, the returns policy, the store formats, and the stock health bands, and produces the week’s action items: promote, discount, discontinue or renegotiate, watch, each with its figure. The scripts did the data work; the model did the judgment; neither is rebuilt next week. Read](https://plexara.io/learning/automations/scripts-as-skills-the-weekly-review) [Previous series 500 · Spreadsheets as Tables A file somebody receives by email becomes a table every agent on the team can join against the warehouse, and stays current month after month.](https://plexara.io/learning/spreadsheets) [Up next Insights Editorial pieces on architecture decisions, comparisons against the alternatives, and where this market is going. Read in any order.](https://plexara.io/learning/insights) [All six series and the insights archive](https://plexara.io/learning) --- # Newsletter URL: https://plexara.io/learning/newsletter/ > The Plexara Monthly Dispatch archive: once a month, what shipped, what is worth reading, and one practical tip for teams building on governed MCP. ## The Plexara Monthly Dispatch Once a month: what shipped, what is worth reading, and one practical tip. Written for data leaders, engineers, and developers building on governed MCP. Every issue is archived here in full. [Issue No. 5 September 18, 2026 Monthly Dispatch: September 2026 Your assistant can hand work to the platform: a report it got right becomes a script Plexara runs on a schedule, a CSV you register becomes a table the warehouse can join, and every query and API call states what it was for. Plus sessions that start lighter, and a tip on asking for the script once the report is right. 8 min read Read issue](https://plexara.io/learning/newsletter/2026-09) [Issue No. 4 August 15, 2026 Monthly Dispatch: August 2026 The transfer gap is closed: a fact one person teaches now reaches a teammate who never saw the conversation 98.9% of the time. Plus a research center with two new pre-registered studies, email notifications that reach people outside the portal, and a tip on asking for strategy, not reports. 8 min read Read issue](https://plexara.io/learning/newsletter/2026-08) [Issue No. 3 July 16, 2026 Monthly Dispatch: July 2026 Canonical knowledge pages land, linked like a wiki, and our benchmark goes public: the same agent went from 42.7% to 98.7% correct on business-context questions. Plus a consolidation tip and four outside reads, two of them benchmarks. 7 min read Read issue](https://plexara.io/learning/newsletter/2026-07) [Issue No. 2 June 15, 2026 Monthly Dispatch: June 2026 A human feedback and review loop lands end to end, the context Plexara attaches to answers now reaches every client, and our flagship piece argues the real asset is the learning loop you own, not the model you rent. 7 min read Read issue](https://plexara.io/learning/newsletter/2026-06) [Issue No. 1 May 15, 2026 Monthly Dispatch: May 2026 The MCP Gateway reaches general availability and the API Gateway opens in beta. Plus three reads from the Learning section, a reusable-prompts tip, and four outside perspectives on enterprise MCP. 6 min read Read issue](https://plexara.io/learning/newsletter/2026-05) ### Subscribe to the Plexara Newsletter Once a month: new product features, MCP and AI educational resources, practical tips, and enterprise AI insights. Written for data leaders, engineers, and developers. Next ### Insights Go deeper with the technical perspectives behind the governed context layer. [Continue](https://plexara.io/learning/insights) --- # Platform Concepts URL: https://plexara.io/learning/concepts/ > Ten visual explainers of the Plexara platform: semantic enrichment, memory, knowledge capture, personas, security, audit, federated SQL, object storage, and metadata governance. ## Platform Concepts Ten visual explainers of how the Plexara platform works: what each capability does, how it works, and why it matters. Expand any concept for an animated walkthrough and the technical detail behind it. ### AI Transparency #### What it does MCP is a standard interface between AI models and your data tools. Every tool call is observable, typed, and logged. You bring your own AI model. Plexara governs the data layer, not the intelligence layer. #### How it works Every tool call is logged before execution with a typed schema describing inputs and outputs. Results come from live data systems and are returned with full provenance. Nothing is hidden, summarized, or transformed outside the audit trail. #### Why it matters When any AI fabricates a number, the damage depends on whether you can trace it. Black-box systems make fabrication hard to spot and impossible to diagnose. Showing the math matters, but showing where the numbers came from is what counts. MCP provides that provenance on every interaction. ### Semantic Enrichment #### What it does Query any data source and receive business context alongside your results. Every response includes ownership, quality scores, PII warnings, deprecation notices, and glossary definitions. #### How it works When a query executes, Plexara intercepts the result set and cross-references each entity against the metadata catalog. Relevant context is embedded in the response before it reaches the AI agent. No additional queries required. #### Why it matters AI stops treating data as anonymous rows and columns. It knows whether a field is deprecated, who owns the data, what the quality score is, and what the business definition means. Automatically, on every query. ### Knowledge Capture #### What it does Domain knowledge shared during AI conversations (column meanings, business rules, data quality observations) is captured, reviewed, and written back to your metadata catalog. #### How it works Insights are detected during sessions, then routed through a governance workflow for review. Approved insights become catalog updates applied to the appropriate entities. The process is: capture, review, synthesize, apply. #### Why it matters Each AI conversation improves the metadata catalog, which improves the next conversation. Tribal knowledge stops walking out the door. ### Lineage-Aware Metadata #### What it does Downstream datasets automatically inherit documentation, quality indicators, and business context from their upstream sources. #### How it works Plexara tracks data lineage at both the dataset and column level. When upstream entities are documented or updated, those annotations propagate downstream through the lineage graph. No manual documentation required. #### Why it matters Document a source table once. Every derived dataset picks up the context automatically. ### Personas & Access Control #### What it does Define who can access which capabilities based on roles mapped from your identity provider. #### How it works Personas map identity provider roles to platform capabilities. Analysts get analytics tools. Executives get high-level exploration. ETL services get pipeline access. Machine-to-machine workflows get governed API endpoints. All controlled through your existing identity infrastructure. #### Why it matters Security is the default operating mode, not an afterthought. Access is defined by business roles, not technical permissions. ### Enterprise Security #### What it does Fail-closed authentication with OIDC, API keys, and a built-in OAuth 2.1 server. Every request is verified against your identity provider before any tool executes. #### How it works OIDC tokens are validated against your identity provider with JWKS auto-discovery. API keys authenticate service accounts. The built-in OAuth 2.1 server bridges MCP clients like Claude Desktop to your upstream IdP with PKCE, rotating refresh tokens, and bcrypt-hashed secrets. #### Why it matters AI touching production data without enterprise authentication is a breach waiting to happen. Plexara is fail-closed: no anonymous mode, no bypass, no permissive fallback. ### Audit & Administration #### What it does Every tool call, query, and error is captured in a structured audit system with an interactive administration portal for real-time metrics, searchable events, and drill-down detail. #### How it works Audit middleware captures every authorized tool call asynchronously with indexed fields for user, tool, timestamp, and status. The admin portal surfaces this as real-time dashboards, searchable event logs with detail drawers, and a tool explorer with dynamic parameter forms. #### Why it matters An audit log you cannot query is not an audit log. Plexara gives you P50/P95/P99 latency, success rates, top tools, top users, and full parameter detail on every interaction, not grep over log files. ### Federated SQL #### What it does Query across PostgreSQL, MySQL, Elasticsearch, Cassandra, BigQuery, MongoDB, Hive, and other sources through a single SQL interface. #### How it works A federated query engine routes SQL across data sources. AI agents write standard SQL without knowing where data physically lives. The federation layer handles routing, optimization, and result assembly. #### Why it matters Your data estate becomes a single queryable surface. No more teaching AI about connection strings, database-specific dialects, or multi-system join logic. ### Object Storage #### What it does AI agents discover, read, and write files across any S3-compatible backend (AWS S3, MinIO, SeaweedFS, Ceph) with full metadata enrichment on every operation. #### How it works Nine MCP tools cover the full object lifecycle: list, read, write, copy, delete, and presign. Every read operation is enriched with ownership, quality scores, and PII classification from the metadata catalog. Write access requires explicit opt-in per connection. #### Why it matters Unstructured data stops being a black box. The AI finds files by searching for business concepts, reads them with full context, and stores results back, all under the same governance as every other capability. ### Metadata Discovery & Governance #### What it does Search, browse, and govern your data estate through a centralized metadata catalog. Datasets, schemas, lineage, context documents, glossary terms, domains, tags, and ownership are all readable and editable from the same governed surface, and every catalog change is recorded as a reviewable changeset that can be rolled back. #### How it works The metadata catalog indexes all connected data sources: schemas, relationships, lineage, and business context. AI agents discover datasets by searching for business concepts rather than technical table names. #### Why it matters AI finds data by meaning, not by memorizing schema names. Ask about revenue and it finds the right tables across systems, with context about freshness, quality, and ownership. Common questions ### Capabilities FAQ Not if you already have one. An existing DataHub instance plugs in directly and Plexara reads from it; teams without a catalog get one deployed as part of the platform. Catalogs that expose their own MCP server can connect through Plexara's MCP gateway today, with native support for additional metadata providers on the roadmap. Either way, the catalog gets richer over time because conversations write captured business context back into it. [Learn more: Why point-solution catalogs and semantic layers are not enough](https://plexara.io/learning/insights/why-point-solution-catalogs-are-not-enough) Context rot is when an agent's working memory fills with stale or irrelevant content mid-session and answer quality degrades. Plexara curates what enters the context window through enriched tool responses, persona-scoped tool visibility, and explicit prompts, so the working set stays small and high-signal. [Learn more: Context, compression, and memory](https://plexara.io/learning/ai-concepts/context-windows-and-tokens) Plexara ships a session-coupled memory and a separate insights pipeline. Within a session, memory accumulates relevant context. Between sessions, multi-strategy recall (entity lookup, semantic search, lineage graph traversal) surfaces prior context on demand. Insights, once admin-reviewed, become organization-wide catalog documentation. [Learn more: Knowledge: from memory to insights](https://plexara.io/learning/mcp/knowledge-from-memory-to-insights) Memory is scoped by persona and user so collaboration agents can share context within a team without leaking across teams. Promoted insights become organization-wide catalog metadata that all future agents benefit from automatically. [Learn more: Knowledge: from memory to insights](https://plexara.io/learning/mcp/knowledge-from-memory-to-insights) Personas extend RBAC by restricting what an agent can SEE, not just what it can call. That covers the tool descriptions in the agent context window, where fewer visible tools means fewer tokens spent and better accuracy, and it covers the data landscape too: search, connection lists, and endpoint lists return only what the persona grants, and a citation cannot be followed around what search left out. When results are held back, the response says so and names the persona, so a user knows the difference between nothing matching and matches they are not cleared for. Default-deny applies to anything not explicitly mapped. [Learn more: Closed by default: least privilege as the starting point](https://plexara.io/learning/insights/closed-by-default-access) Next ### Use Cases See these concepts at work in real engagement stories. [Continue](https://plexara.io/use-cases) --- # Five kinds of memory, and how each comes back URL: https://plexara.io/learning/insights/five-kinds-of-memory/ > A fact, an incident, a person, a link, and a habit are five different kinds of knowledge. Plexara stores each as its own dimension and recalls it the way that kind needs, which is what makes memory across sessions feel like memory rather than search. Field notes / architecture Jun 10, 2026 ## Five kinds of memory, and how each comes back A fact, an incident, a person, a link, and a habit are five different kinds of knowledge. Plexara stores each as its own dimension and recalls it the way that kind needs, which is what makes memory across sessions feel like memory rather than search. 9-minute read Architecture On this page ### One bucket is not enough The simplest way to give an agent memory is to write everything it learns into one store and search that store later. It works in a demo and falls apart in production. A schema change from last quarter, a column definition, the name of the team that owns a dataset, and one user’s export preference all end up in the same pile, and recall returns whatever happens to be textually nearest rather than what is actually relevant. The result is the opposite of what memory is for. Instead of sharpening the working set, undifferentiated recall fills it with near-misses, and [the context window degrades](https://plexara.io/learning/ai-concepts/context-windows-and-tokens) under the weight of memories that should never have surfaced. The agent does not feel like it remembers. It feels like it ran a noisy search. The memory research bears this out. Surveys of agent memory organize it by both how long it lasts and what form it takes, because a durable fact and a passing event are not the same kind of thing and should not be handled the same way. Benchmarks built for long-term conversational recall measure exactly the multi-session and temporal reasoning where a single flat store breaks down. One store, or five Everything in a bucket ##### One undifferentiated store - A schema change and a formatting preference sit in the same pile - Recall returns whatever is textually nearest, relevant or not - No way to age out events without losing durable facts - Context arrives noisy, and the working set fills with the wrong things Stored by kind ##### Five typed dimensions - Each kind of knowledge is indexed the way that kind needs - Recall can target facts, history, people, links, or habits - Events carry time; preferences carry a user; facts carry an entity - The right context surfaces because it was filed correctly ### Five dimensions Plexara structures memory into five dimensions, so each kind of knowledge is stored, indexed, and recalled the way that kind needs. Knowledge is the durable facts: what a column means, what a business rule requires. Events are the things that happened: a migration, an incident, a schema change, each carrying a time. Entities are the people, systems, and teams in the data landscape and the roles they play. Relationships capture how those entities and datasets connect, the links that let recall move from one thing to the things around it. Preferences hold the per-user details: a formatting choice, an export habit, the column a particular analyst always wants. None of these is reducible to the others, and that is the point. A fact has no timestamp the way an event does. A preference belongs to a person the way a fact does not. Filing memory by kind is what makes targeted recall possible. When the agent needs the history of a table, it can ask for events. When it needs to honor how someone works, it can ask for preferences. The structure is what turns "search the memory" into "recall the right kind of thing." The five dimensions Knowledge Facts about data, business rules, and domain expertise. "Column amt is the gross transaction amount in cents; divide by 100 for display." Events Things that happened: migrations, incidents, schema changes. "The revenue table was restructured in Q3 2025; the old columns are deprecated." Entities People, systems, teams, and their roles in the data landscape. "The finance team owns all revenue datasets and prefers net_amt over amt." Relationships Connections between entities, datasets, and business concepts. "The orders table feeds the revenue pipeline through a nightly ETL job." Preferences User-specific settings, formatting choices, and workflow habits. "This user prefers CSV exports with headers and ISO date formatting." Different kinds of knowledge are stored, indexed, and recalled the way each kind needs, rather than flattened into one undifferentiated store. ### Four ways to recall Storing memory well is half the problem. The other half is retrieving it, and different questions need different retrieval. Plexara composes four strategies. Entity lookup fetches the accumulated context of a known dataset directly. Semantic search finds conceptually related memories when the relevant dataset has not been named yet. Graph traversal follows DataHub lineage, so when an agent queries a derived table, memories about its upstream sources surface on their own. Auto mode runs all three and merges the results with deduplication, and it is the default, because most of the time the agent should not have to choose. When it does know what it needs, [it can name the strategy directly](https://plexara.io/learning/insights/intent-driven-tools-and-memory). The strategies and the dimensions reinforce each other. Lineage traversal is only useful because relationships were stored as their own kind. Entity lookup is only sharp because facts were filed against the entities they describe. Structure on the way in is what makes precision on the way out possible. Four ways to recall Entity lookup Direct retrieval by dataset or entity reference, for the accumulated context of a known table. Semantic search Vector similarity over memory content, for exploratory questions where the dataset is not yet named. Graph traversal Follows DataHub lineage, so memories about upstream sources surface when you query a derived table. Auto (combined) Runs all three and merges with deduplication. The default, covering every recall path at once. Different questions need different recall methods. The platform picks automatically, or the agent names the strategy when it knows what it needs. ### Personal, then promoted Memory is scoped to a user and a persona. It captures what an individual taught the agent during their own work, and it does not leak into anyone else’s sessions by default. That isolation is deliberate: one analyst’s working notes are not automatically everyone’s. Sharing happens through one explicit path. When an observation in someone’s memory is worth generalizing, an admin reviews it and promotes it through the insights pipeline, where it becomes catalog documentation every future agent can draw on. That is how [usage turns into durable, organization-wide knowledge](https://plexara.io/learning/mcp/knowledge-from-memory-to-insights) without turning every private note into shared truth. Personal, then promoted 01 Personal Memory is scoped to a user and persona. It captures what that person taught the agent. 02 Reviewed An admin reviews an observation worth sharing and promotes it through the insights pipeline. 03 Org-wide Promoted, it becomes catalog documentation every future agent can use. Nothing leaks by default. Memory stays private to its user and persona. Cross-user sharing happens only through an explicit, reviewed promotion, not by default. [Image: The Memory tab of the Knowledge area, with a strip across the top tracing memory captured automatically to insight proposed for review to promoted knowledge, counters for total, active, stale, and archived memories, status and class filters, and memory cards each labelled with a class such as Business Context or Enhancement, a date, and the table it is about.] Personal memory as its owner sees it. Each card carries its kind and the dataset it describes, and the strip along the top is the one path out: a memory becomes an insight for review, and only a reviewed insight becomes shared knowledge. ### The shape of memory is the point Persistent memory in Plexara has a shape: five kinds of knowledge, each stored as itself, each recalled by the method that fits it, scoped to a person until it is deliberately shared. That structure is why memory across sessions can feel like the agent actually remembers. It stored the right things in the right shapes, and it can find them again on purpose. Strategic takeaway #### The shape of memory is the point. A fact, an incident, a person, a link, and a habit are five different kinds of knowledge, and treating them the same is why naive memory systems return noise. Storing each by its kind, and recalling each by the method that suits it, is what makes memory across sessions feel like the agent actually remembers rather than just searches. Further Reading - [A Survey on the Memory Mechanism of Large Language Model based Agents Zeyu Zhang, Xiaohe Bo, Chen Ma, Rui Li, Xu Chen, Quanyu Dai, Jieming Zhu, Zhenhua Dong, Ji-Rong Wen · 2024 A survey of how memory in LLM-based agents is designed and evaluated, organizing memory by temporal type (short-term and long-term) and structural form (episodic, semantic), and arguing that different kinds of knowledge call for different storage and retrieval.](https://arxiv.org/abs/2404.13501) - [Evaluating Very Long-Term Conversational Memory of LLM Agents Adyasha Maharana, Dong-Ho Lee, Sergey Tulyakov, Mohit Bansal, Francesco Barbieri, Yuwei Fang · 2024 Introduces LoCoMo, a benchmark for long-term conversational memory built from very long multi-session dialogues. It evaluates recall across single-hop, multi-hop, temporal, and adversarial reasoning, the kinds of long-range recall where a single undifferentiated memory store tends to fail.](https://arxiv.org/abs/2402.17753) - [Memory for Autonomous LLM Agents: Mechanisms, Evaluation, and Emerging Frontiers Pengfei Du · 2026 A recent survey framing agent memory along dimensions of temporal scope, representational substrate, and control policy, and surveying mechanism families from retrieval-augmented stores to reflective self-improvement.](https://arxiv.org/abs/2603.07670) On this page [Next Two front doors, one governed surface](https://plexara.io/learning/insights/the-developer-surface) ### Related reading architecture [Architecture 103 - Context, compression, and memory The context window is a model's working memory. Each session balances keeping, compressing, or clearing it. Plexara adds enterprise memory on top.](https://plexara.io/learning/ai-concepts/context-windows-and-tokens) [Architecture 201 - Anatomy of a Plexara MCP 201 shows what is actually in the box on a Plexara server: the tool inventory by toolkit, the four content layers, the interactive apps a tool result can carry, and the memory, knowledge, and governance underneath. This lesson is the map.](https://plexara.io/learning/mcp/what-is-an-mcp) [Architecture Search the capability, not the manual: how Plexara keeps a wide platform light Loading every API spec into context does not scale. A small, fixed tool footprint plus semantic endpoint discovery keeps cost tied to the task, not the size of the platform.](https://plexara.io/learning/insights/search-the-capability-not-the-manual) --- # Two front doors, one governed surface URL: https://plexara.io/learning/insights/the-developer-surface/ > Plexara exposes the same governed surface through an MCP server and a REST API. SDKs connect to both, custom tools extend it, and every path shares one identity, one audit log, and one persona model. Field notes / integration Jun 19, 2026 ## Two front doors, one governed surface Plexara exposes the same governed surface through an MCP server and a REST API. SDKs connect to both, custom tools extend it, and every path shares one identity, one audit log, and one persona model. 8-minute read Integration On this page ### One surface, two doors Plexara exposes one governed surface: assets, collections, knowledge, memory, prompts, personas, audit, and tool execution. There are two ways to reach it. An MCP server speaks to AI agents in the protocol they already understand, and a REST API speaks to ordinary services over HTTP. They are not two different products with a sync problem between them. They are two entrances to the same room. Every call through either door resolves the same identity, writes to the same audit log, and is filtered by the same personas. There is no surface that only one of them can reach and no governance that only one of them enforces. That symmetry is the point. A team can start with an agent over MCP, add a backend integration over REST later, and never reconcile two security models, because there is only one. Two doors, one room MCP server for agents REST API for services One governed surface Assets Collections Knowledge Memory Prompts Personas Audit Tools one identity · one audit log · one persona model The MCP server and the REST API are two entrances to the same governed surface. Both resolve the same identity, write to the same audit log, and obey the same personas. ### Which door to use Choose REST when a service needs a stable, versioned contract: a backend job, a scheduled integration, anything with no agent in the loop. The REST API ships an OpenAPI specification, so a typed client can be generated for whatever language the service is written in using standard tooling. Choose MCP when an AI agent needs the same operations through [a protocol it already speaks](https://plexara.io/learning/ai-concepts/mcp-vs-apis). The server exposes tools, resources, and prompts that the client negotiates at connect time, and it works with any MCP-compatible client SDK, in TypeScript, Python, or the other open-source libraries. The decision is about ergonomics, not capability. Neither door is a subset of the other. They expose the same operations because they are backed by the same surface. Which door to use Service-to-service ##### Reach for REST - A backend service calling a stable, versioned contract - Clients generated from an OpenAPI specification - Scheduled jobs and integrations with no agent in the loop - You want HTTP semantics and a typed SDK Agent-facing ##### Reach for MCP - An AI agent needs the same operations through a protocol it knows - Tools, resources, and prompts negotiated at connect time - Any MCP-compatible client SDK, in TypeScript or Python - You want the model to discover and call capabilities ### Three ways to authenticate, one persona resolution OIDC with required JWT claims is the primary path: your identity provider asserts who the caller is, and Plexara trusts that assertion. OAuth 2.1 with PKCE is supported for new client types, bringing the code-interception protection that PKCE was designed for. API key management is available for service accounts that cannot run an interactive flow. What every method has in common is what happens after authentication. Your identity provider establishes who the caller is. Plexara resolves that identity to a persona, and the persona decides what the caller can see and do. Authentication and authorization are kept distinct on purpose, the same way [enterprise systems are met where they are](https://plexara.io/learning/insights/enterprise-authentication-and-isolation) without weakening isolation. Three ways in, one resolution OIDC with JWT claims The primary path. Your identity provider asserts who the caller is. OAuth 2.1 with PKCE For new client types, with the code-interception protection PKCE provides. API keys For service accounts that cannot run an interactive auth flow. Whichever method authenticates the caller, Plexara resolves it to a persona. The IdP provides identity; Plexara provides what that identity is allowed to see and do. ### Extending the surface A custom tool can be registered through the Portal or the management API. Once registered, it appears in the agent tool list like any other Plexara tool, with persona-scoped visibility and the same audit and authorization treatment. It is part of the governed surface, not a bypass around it. This matters because adding capability is the easy part and governing it is the hard part. A custom tool that escaped the persona model or the audit log would reopen exactly the gap the platform exists to close. Keeping extensions inside the same rules is what lets the surface grow without the governance fraying. It is also why more tools do not automatically mean a more capable agent. [Capability scales with context and governance](https://plexara.io/learning/insights/why-more-tools-wont-make-your-agent-smarter), not with connector count, so a custom tool earns its place by being scoped and described well, not merely by existing. Extending without forking 01 Register A custom tool is added through the Portal or the management API. 02 Scope It is given persona-scoped visibility, like every other tool. 03 Govern It carries the same audit and authorization treatment. A custom tool is not a side channel. It enters the same tool list the agent already sees, under the same rules. ### Pick the protocol, keep the governance For a developer, the choice between REST and MCP is a choice of convenience. A backend service wants a typed HTTP client. An agent wants a protocol it can negotiate. Plexara serves both from one place. What does not change with the door is everything that matters for trust. Whichever entrance a caller uses, the same identity resolution runs, the same personas filter what it can see, and the same audit log records what it did. Plexara governs the surface once and lets each team reach it over the protocol that fits their work. Strategic takeaway #### Pick the protocol, keep the governance. Whether a developer integrates over REST or an agent connects over MCP, the surface is the same and the rules are the same. The choice of door is an ergonomic one. The identity, the audit trail, and the persona model do not change underneath it. Further Reading - [Model Context Protocol Specification (2025-06-18) Anthropic and Model Context Protocol contributors · 2025 An open protocol, originally introduced by Anthropic, that standardizes how client applications connect to servers exposing tools, resources, and prompts over JSON-RPC, including client and server capability negotiation.](https://modelcontextprotocol.io/specification/2025-06-18) - [Proof Key for Code Exchange by OAuth Public Clients (RFC 7636) N. Sakimura (Ed.), J. Bradley, N. Agarwal (IETF) · 2015 The IETF standard defining PKCE, which mitigates authorization-code interception by having the client present a code verifier when it redeems the code. PKCE is mandatory in OAuth 2.1 and underpins secure authorization-code flows for SDK and CLI clients.](https://datatracker.ietf.org/doc/html/rfc7636) - [OpenAPI Specification OpenAPI Initiative (The Linux Foundation) · 2025 A standard, language-agnostic interface description for HTTP APIs that lets humans and machines understand a service without access to its source code. OpenAPI documents are the basis from which typed REST client SDKs are generated.](https://spec.openapis.org/oas/latest.html) On this page [Previous Five kinds of memory, and how each comes back](https://plexara.io/learning/insights/five-kinds-of-memory) [Next What you keep if you leave](https://plexara.io/learning/insights/what-you-keep-if-you-leave) ### Related reading integration [Integration 110 - Is MCP just an API wrapper? MCP is not a replacement for your APIs and not a thin proxy. It is an application layer on top, like a website is an application layer on top of its APIs.](https://plexara.io/learning/ai-concepts/mcp-vs-apis) [Integration 606 - Scripts as skills: the weekly review the agent runs on your business The capstone. Three scripts (category velocity, the supplier quote margin review, regional weather context) attached to one prompt, so serving the prompt carries each script’s contract and last successful output and the agent runs them for fresh numbers instead of re-deriving them. The agent then reads the outputs against the seasonality calendar, the returns policy, the store formats, and the stock health bands, and produces the week’s action items: promote, discount, discontinue or renegotiate, watch, each with its figure. The scripts did the data work; the model did the judgment; neither is rebuilt next week.](https://plexara.io/learning/automations/scripts-as-skills-the-weekly-review) [Integration Meeting enterprise systems where they are Real enterprise APIs authenticate in messy ways: client certificates, basic auth, second credential headers. Supporting them, while keeping each user activity isolated, is what makes an agent usable at work.](https://plexara.io/learning/insights/enterprise-authentication-and-isolation) --- # What you keep if you leave URL: https://plexara.io/learning/insights/what-you-keep-if-you-leave/ > Metadata you author through Plexara lives in DataHub in open formats. If you stop using the platform, you keep the catalog, the lineage, and the definitions your team wrote. Portability is a property of the storage, not a promise on a slide. Field notes / philosophy Jun 27, 2026 ## What you keep if you leave Metadata you author through Plexara lives in DataHub in open formats. If you stop using the platform, you keep the catalog, the lineage, and the definitions your team wrote. Portability is a property of the storage, not a promise on a slide. 8-minute read Philosophy On this page ### The asset is the metadata The data was always yours. It sits in your warehouse, your object storage, your operational databases. What a data platform adds on top is meaning: the description that says what a column actually holds, the glossary term that fixes a business definition, the lineage that traces a number back to its source, the tag that marks a field as sensitive. That layer of meaning is the thing that accumulates. On Plexara it accumulates as a byproduct of use, because [documentation happens while people work](https://plexara.io/learning/insights/knowledge-application-turns-usage-into-documentation) rather than in a separate cataloging project. Over months it becomes the most valuable and most expensive-to-recreate part of the deployment. So the real lock-in question concerns that layer of meaning, not the data. If it is captive, leaving means re-authoring everything your team explained. If it is portable, leaving costs you nothing but the platform itself. What gets written down Descriptions What a table or column actually means Glossary terms The business vocabulary your team agreed on Lineage How data flows from source to report Tags & classifications PII, sensitivity, domain ownership Ownership Who is accountable for each dataset Data contracts The shape and guarantees a dataset promises Every conversation that explains a dataset leaves structured metadata behind. This is the asset that accumulates, and the asset worth keeping. ### Open formats decide it Metadata authored through Plexara is stored in DataHub, modeled as entities, aspects, and relationships in an open, documented schema. DataHub is open source under a permissive license. The catalog is readable by anything that speaks the schema, not only by the platform that wrote it. Lineage is the same story. When provenance is emitted to an open specification rather than written into a private log, the graph of how data flows stays usable in any tool that reads the spec. The record of how a report was built does not evaporate when the tool that recorded it goes away. This is why the format matters more than the promise. A vendor can pledge that you will never want to leave. Only an open storage format can guarantee that leaving is cheap, because the guarantee lives in the data structure, not in the relationship. Where the metadata sits Closed catalog ##### Captive in a proprietary store - Definitions and lineage held in a vendor-specific format - Export is partial, lossy, or gated behind the contract - Leaving the product means re-authoring the documentation - The switching cost points back at the vendor DataHub, open schema ##### Stored in open formats - Entities, aspects, and relationships in a documented schema - Lineage emitted to an open specification, not a private log - The catalog is readable without the platform that wrote it - What your team authored stays yours [Image: The Assets page in the portal on the All view: a search box, type and tag filters, and a grid of saved asset cards including a Q4 revenue dashboard, a sales pipeline chart, and a weekly inventory report, each with a preview, a description, format and topic tags such as HTML, SVG, and Markdown, a size, and a date.] The same principle applies to what people make on the platform. Every saved asset is an ordinary file, and each card says which kind: HTML, SVG, Markdown. There is no proprietary container between you and the report. ### Where it lives, and why that is deliberate Plexara is the layer that captures meaning during a conversation and the governance that decides who can see what. It is not the store of record for your metadata. The store of record is DataHub, in open formats, and that separation is on purpose. It is the same reasoning behind [building on protocols rather than products](https://plexara.io/learning/insights/protocols-outlast-products). The orchestration and governance layer can evolve, or be replaced, without holding the catalog hostage. The metadata sits underneath it in a format that does not depend on it. Regulators have encoded the same principle for personal data: the right to receive it in a structured, machine-readable format and move it elsewhere without hindrance. The instinct is sound well beyond its legal scope. Information you authored should be information you can take with you. Plexara writes, DataHub holds Plexara captures meaning in use DataHub entities · aspects · relationships open schema, Apache-2.0 Schema Descriptions Glossary terms Lineage Tags Ownership Plexara is the layer that captures meaning during use. The meaning is stored in DataHub as entities, aspects, and relationships in an open schema, so it outlives the layer that produced it. ### Portability is a property, not a promise Keeping what you authored should not require staying. When the catalog, the lineage, and the definitions live in open formats, continuing with a platform becomes a decision about the value it delivers, not a decision forced by the cost of extraction. That is the standard worth holding any data platform to: whether the thing it stores is already in a form you could read without it, export button or not. [Image: The asset viewer open on a Q4 revenue dashboard with Feedback, Delete, Download, and Share buttons in the header and a Share Asset dialog in front: a share-by-link row with an audience picker and expiry, a share-with-user section with an email field and permission picker, and an Active Shares list showing a link with twelve views and a user share marked no expiration.] Download sits next to Share. The dashboard leaves as the file it is, to a teammate through a revocable share or to a laptop through the Download button, and either way it is the same file. Strategic takeaway #### Portability is a property, not a promise. A vendor can promise you will never want to leave. Only the storage format can guarantee that leaving costs you nothing. When the catalog, the lineage, and the definitions live in open formats, the question of staying becomes a question of value delivered, not of metadata held hostage. Further Reading - [The Metadata Model DataHub Project · 2026 DataHub models all metadata as entities, aspects, and relationships using an open, documented schema language (PDL). DataHub is open source under the Apache License 2.0, so metadata is stored in a portable format rather than a proprietary one.](https://docs.datahub.com/docs/metadata-modeling/metadata-model) - [OpenLineage Object Model OpenLineage project (The Linux Foundation) · 2026 An open specification for collecting data lineage as standardized run, job, and dataset events across tools. Because lineage is emitted to an open spec rather than locked inside one vendor, the provenance graph remains usable after a platform change.](https://openlineage.io/docs/spec/object-model) - [Art. 20 GDPR: Right to data portability European Union (Regulation (EU) 2016/679) · 2016 Grants the right to receive personal data in a structured, commonly used, and machine-readable format and to transmit it to another controller without hindrance. A recognized governance analogue for the principle that data should be portable, not captive.](https://gdpr-info.eu/art-20-gdpr/) On this page [Previous Two front doors, one governed surface](https://plexara.io/learning/insights/the-developer-surface) [Next Why a Plexara rollout starts small](https://plexara.io/learning/insights/why-a-plexara-rollout-starts-small) ### Related reading philosophy [Philosophy 101 - What is a Large Language Model? LLMs predict the next token from patterns learned across trillions of training examples. What that means, why it produces fluent reasoning, and its limits.](https://plexara.io/learning/ai-concepts/what-is-a-large-language-model) [Philosophy 104 - Frontier models, specialized models, and why enterprise AI uses both Frontier models bring world knowledge; small local embedding models power memory and catalog search. Knowing each role designs AI systems that work.](https://plexara.io/learning/ai-concepts/frontier-models-explained) [Philosophy 401 - Prompts are the new SOPs You work with the agent for an hour to get one report exactly right, with a year-over-year cut, holiday annotations, and storm-closure markers. The agent saves durable business knowledge on its own. But that specialized report is not institutional knowledge, it is a procedure. This article draws the line between the two, and makes the case that a saved prompt is the standard operating procedure for an AI-run job.](https://plexara.io/learning/prompts/prompts-are-the-new-sops) --- # Why a Plexara rollout starts small URL: https://plexara.io/learning/insights/why-a-plexara-rollout-starts-small/ > A first deployment connects two or three data sources and one persona, then expands without rewriting what came before. Phased rollout is not caution for its own sake. It is how a complex system that works actually comes to exist. Field notes / philosophy Jul 6, 2026 ## Why a Plexara rollout starts small A first deployment connects two or three data sources and one persona, then expands without rewriting what came before. Phased rollout is not caution for its own sake. It is how a complex system that works actually comes to exist. 9-minute read Philosophy On this page ### The big-bang temptation The instinct on a new data platform is to connect everything. Map every source, define every persona, specify every use case, then flip the switch. It feels thorough. It also concentrates every unknown into a single cutover, and pushes the first useful answer to the far end of a long integration. A big-bang adoption has a specific risk profile: value arrives only when the whole thing lands, the team learns nothing until late, and a problem anywhere can stall the entire program. The schedule is fixed and the failure modes are correlated. This is the pattern that produces multi-quarter projects that quietly never reach production. A phased rollout inverts the risk. The first deployment is small enough to verify end to end and real enough to be worth shipping. Each later phase adds capability to something that already works, so risk is bounded at every step instead of saved up for one. Two ways to start Big-bang cutover ##### Connect everything at once - Every data source, persona, and use case scoped up front - Value arrives only after the whole integration lands - One fixed cutover date with little room to learn - A failure anywhere stalls the entire program Phased rollout ##### Connect a little, then expand - Two or three sources and one persona in the first deployment - A working answer to one real question within the first phase - Each phase adds sources and personas without rewriting the last - Risk is bounded at every step instead of concentrated at one ### Complex systems evolve from simple ones Gall's law is the cleanest statement of why: a complex system that works is invariably found to have evolved from a simple system that worked, and a complex system designed from scratch never works and cannot be patched into working. No one could have specified on day one the breadth a mature deployment eventually reaches. It accumulates, one working step at a time. None of this means moving slowly. It means keeping each step working. A deployment that answers one real question, correctly, is a simple system that works. From there it can grow. A deployment that tries to answer everything at once, and answers nothing yet, has nothing to grow from. The same logic appears in how careful teams replace legacy systems. Rather than a rewrite, they build the new system around the edges of the old one and let it take over function by function until the old system can be retired. The new capability is always attached to something already running. Gall's law in practice 1. ##### A simple system that works First deployment Two or three connections, one persona, one question the team already asks. Small enough to verify end to end. 2. ##### Grows along the working edges Each phase New sources and personas attach to what already works. Nothing that shipped gets torn out to make room. 3. ##### A complex system that works Where it ends up Breadth that would have been impossible to design up front, reached because every step was a working step. A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched into working. ### What the first deployment looks like A first Plexara deployment connects two or three data sources and defines one persona, aimed at a single question the team already asks every week. Not a hypothetical question, and not a demo. The kind of question that today requires someone to stitch results across a couple of systems by hand. Concretely: a warehouse, an order system, a product catalog, one analyst persona, and the question "which products are selling below forecast this week, and where." That is small enough to ship and verify, and it puts a working agent surface in front of a real workflow. The team can see [the difference business context makes](https://plexara.io/learning/insights/context-gap-in-ai-data-access) on a problem they actually own. Getting one loop working matters more than breadth at this stage. Once the agent answers that question reliably, [the same infrastructure](https://plexara.io/learning/mcp/first-engagement) extends to adjacent questions without re-architecting anything. The shape of a first deployment A few connections Warehouse Order system Product catalog One persona One question “Which products are selling below forecast this week, and where?” Two or three sources, one persona, one question the team asks every week. Small enough to ship and verify, real enough to be worth shipping. ### Why depth compounds Each phase attaches to what already works. Phase one fills in a little catalog and a little memory while answering its question. Phase two adds more sources and an analyst and a steward persona, and phase one keeps answering its question, unchanged. Phase three reaches adjacent questions across teams, and every earlier phase keeps working and keeps teaching. The compounding is not just additive scope. Every conversation captures business context, and [documentation accrues as a byproduct of use](https://plexara.io/learning/insights/knowledge-application-turns-usage-into-documentation) rather than as a separate project. The datasets people actually query accumulate meaning fastest, so the platform gets sharper exactly where demand is highest. Because the foundation is [open protocols rather than a proprietary platform](https://plexara.io/learning/insights/protocols-outlast-products), expansion does not force a re-platforming. Adding a source is adding a connector. The persona model, the audit trail, and the catalog that phase one established all carry forward. Additive, not destructive Phase 1 2-3 sources, 1 persona, 1 question The catalog and memory start filling in Phase 2 More sources, an analyst and a steward persona Phase 1 still answers its question, unchanged Phase 3 Adjacent questions across teams Every prior phase keeps working and keeps teaching Subsequent phases attach to what already works, the way a new system grows around a legacy one until it can stand on its own. Each conversation strengthens the catalog and memory, so depth compounds instead of resetting. ### Small is not slow A first deployment that answers one real question is worth more than a six-month integration that answers none yet. The small start is what makes the large outcome reachable, because each phase rests on a phase that worked. Phased rollout also keeps the decision reversible at every step. Scope is bounded, success criteria are explicit before each phase begins, and the cost of being wrong about phase three is paid in phase three, not retroactively across the whole program. Strategic takeaway #### Small is not slow. A first deployment that answers one real question is worth more than a six-month integration that answers none yet. Because each phase builds on a working phase, the platform reaches breadth no one could have specified on day one, and risk stays bounded at every step instead of concentrated in a single cutover. Further Reading - [Gall's law John Gall, Systemantics: How Systems Work and Especially How They Fail · 1975 States that a complex system that works is invariably found to have evolved from a simple system that worked, and that a complex system designed from scratch never works and cannot be patched into working.](https://en.wikipedia.org/wiki/Gall%27s_law) - [Strangler Fig Application Martin Fowler · 2004 Describes incrementally building a new system around the edges of an existing one, letting it grow until the old system can be retired, instead of attempting a high-risk big-bang rewrite.](https://martinfowler.com/bliki/StranglerFigApplication.html) - [Big bang adoption Wikipedia contributors · 2026 Defines big bang adoption (direct changeover) as switching everyone to a new system at once with no transition period, and notes the higher risk that comes from fewer learning opportunities and a fixed, failure-vulnerable cutover.](https://en.wikipedia.org/wiki/Big_bang_adoption) On this page [Previous What you keep if you leave](https://plexara.io/learning/insights/what-you-keep-if-you-leave) [Next Own the learning loop, not just the model](https://plexara.io/learning/insights/own-the-learning-loop-not-the-model) ### Related reading philosophy [Philosophy 101 - What is a Large Language Model? LLMs predict the next token from patterns learned across trillions of training examples. What that means, why it produces fluent reasoning, and its limits.](https://plexara.io/learning/ai-concepts/what-is-a-large-language-model) [Philosophy 104 - Frontier models, specialized models, and why enterprise AI uses both Frontier models bring world knowledge; small local embedding models power memory and catalog search. Knowing each role designs AI systems that work.](https://plexara.io/learning/ai-concepts/frontier-models-explained) [Philosophy 401 - Prompts are the new SOPs You work with the agent for an hour to get one report exactly right, with a year-over-year cut, holiday annotations, and storm-closure markers. The agent saves durable business knowledge on its own. But that specialized report is not institutional knowledge, it is a procedure. This article draws the line between the two, and makes the case that a saved prompt is the standard operating procedure for an AI-run job.](https://plexara.io/learning/prompts/prompts-are-the-new-sops) --- # Own the learning loop, not just the model URL: https://plexara.io/learning/insights/own-the-learning-loop-not-the-model/ > A frontier model never learns your institutional knowledge. It only gets better at using what your people supply and frame, so the durable equity is built outside the model: a loop that captures human and model coordination and keeps it inside your own ecosystem. That loop is most of what Plexara already is. Field notes / philosophy Jun 2, 2026 ## Own the learning loop, not just the model A frontier model never learns your institutional knowledge. It only gets better at using what your people supply and frame, so the durable equity is built outside the model: a loop that captures human and model coordination and keeps it inside your own ecosystem. That loop is most of what Plexara already is. 11-minute read Philosophy On this page ### The argument in the air There is a widely shared argument right now about the future of the firm in an AI economy. The version that prompted this note frames it in two kinds of capital. Human capital is the knowledge, judgment, relationships, and pattern recognition of your people. Token capital is the AI capability your firm builds and owns. The claim is that human capital does not lose value as token capital grows. It gains value, because human direction is what makes the token capital worth anything. As Satya Nadella put it, "Without human direction, you have compute running in circles." The conclusion that follows is the part worth sitting with. The real asset is not which model you pick. It is the learning loop you build on top of models, where human and token capital compound. You can offload a task, or even a job, but you cannot offload your learning. The firm that captures and compounds that learning ends up with something hard to replicate, regardless of which individual model is best this quarter. And the firm that does not ends up watching its edge erode, because the model it rents is a commodity available to everyone while its own hard-won expertise stays locked in people's heads instead of compounding into something the firm keeps. We did not arrive at that conclusion from the outside. It describes the thing Plexara has been built to do, long before our internal methodology tool grew into an MCP platform. Plexara is not an answer to that whole thesis. It does not, for example, run private reinforcement learning or private evaluation environments. But the part of the argument about capturing, growing, and synthesizing institutional knowledge, and keeping it inside your own ecosystem, is most of what Plexara already is. ### The analyst who is also forced to write the documentation Picture a strong data analyst building a report. Along the way they learn a dozen things that never make it into the final artifact. That a column labeled amount is actually in cents. That one table is only trustworthy after a status filter. That two business terms mean the same thing to finance but different things to operations. That a particular join produces double-counted rows unless you deduplicate first. The report ships. The dozen things they learned evaporate, unless that analyst also happens to maintain a rigorous documentation discipline that almost no one sustains under deadline. In that world, the most valuable analyst is quietly required to also be the most valuable documentation writer, and those are different jobs that compete for the same hours. So the documentation loses. The knowledge stays in one person's head, and the organization relearns what it already knew the next time someone touches that data. This is the tacit-to-explicit conversion problem that organizational researchers have described for decades: the knowledge that matters most is exactly the knowledge that is hardest to write down, so it does not get written down. Give that same analyst Plexara and the economics change. Their productivity goes up because the platform reaches across the stack to answer the question. But the more important shift is that the work of getting to the answer is captured as it happens. The correction, the filter, the synonym, the join caveat become structured insights tied to the specific entity, instead of disappearing when the report is delivered. The analyst keeps doing analysis. The documentation becomes a byproduct of the analysis rather than a second job stacked on top of it. We have written about that inversion in detail in [how knowledge application turns usage into documentation](https://plexara.io/learning/insights/knowledge-application-turns-usage-into-documentation). ### It was never about handing data to a black box The fear underneath the whole argument is that AI turns into a black box that quietly eats your expertise. You feed it your data and your questions, it gets smarter, and the value accrues somewhere that is not you. If that is the only model on offer, then the better the model gets, the more of your industry it commoditizes out from under you. Plexara was built on the opposite premise. The frontier model is rented capability, used because it is genuinely state of the art at reading a question and reasoning over a result. Producing an insight in a chat window that scrolls away is only half the job. The other half is articulating that insight back into the customer's own ecosystem: written into their catalog, their memory, their prompts, their assets. The model is the engine. The learning stays home. This is the same reason we have argued that [a general-purpose assistant bolted on from outside is not enough](https://plexara.io/learning/insights/why-incumbent-ai-assistants-are-not-enough). An assistant that cannot write what it learns back into your systems is, by construction, a black box. ### Memory and insight capture as the substrate For the learning to stay home, it needs somewhere to live and a way to be found again. Plexara's memory system is that somewhere. Captured insights, corrections, and observations are stored as structured records and made retrievable by meaning, so a future question reaches them even when it is phrased differently than the moment they were first learned. The walkthrough in [from memory to insights](https://plexara.io/learning/mcp/knowledge-from-memory-to-insights) shows how a single conversation contributes to a store the next conversation can draw on. Capture comes from more than one direction. A person can correct the agent in the flow of work and have that correction recorded against the right entity. The agent can surface a lower-confidence observation from a query pattern and flag it for a human to confirm. The enrichment layer can notice that a frequently accessed table has no description and log that gap so it gets prioritized by how much it actually matters. None of these require anyone to stop and open a separate documentation tool. Synthesis is what turns a pile of captured fragments into something usable. Multiple insights about the same table get combined into a coherent description rather than a stack of sticky notes. This is the queryable institutional memory the broader argument calls for, and it is the part that compounds: the more the platform is used, the more it knows, and the more it knows, the more useful the next answer is. ### When the method becomes a catalog of SOPs Insight capture records what was learned. There is a second, often more valuable thing to capture: how the work was actually done. When an analyst works out the exact sequence of questions that produces a reliable monthly margin report, that sequence is a method. Left alone, it lives as a private string in someone's notes and leaves with them. Plexara treats a prompt as a governed, first-class asset with a lifecycle and a review status, so the working method can be promoted to an approved standard, tagged by domain, shared as a runnable tool rather than a screenshot, and found later by meaning. Distilled this way, a collection of prompts becomes an organic set of standard operating procedures: the actual, tested methods the organization uses, captured from real work rather than written once for a binder no one reads. We cover the mechanics in [when prompts become shared infrastructure](https://plexara.io/learning/insights/governed-prompts-and-relevance-search). ### Human judgment, now first-class in the loop The newest piece closes the loop with the human. A captured insight or a proposed change should not become institutional truth just because a model suggested it. Someone with the standing to judge it has to weigh in, and that judgment should itself become part of the record. Plexara now carries a human feedback and review loop for exactly this. Feedback lives as a thread attached to the asset, collection, or prompt it concerns, or in a shared general channel, so a comment becomes a durable, addressable object instead of a message that disappears. That thread runs a real lifecycle. The person who raised the feedback can request validation from a subject-matter expert, who marks it validated or disputed with a reason, and a dispute reopens the thread instead of papering over it. Sign-off aggregates across an item so you can see that it has been approved by a known set of reviewers, and worklists give practitioners and experts a scoped inbox of what is waiting on them, without needing a notification system bolted on. An agent can review and act on pending feedback through a single dedicated tool, so the loop is reachable from the assistant as well as the portal. The important design choice is that this connects to the knowledge loop instead of sitting beside it. A feedback thread can be linked to the captured insight it produced, and that insight flows into a tracked changeset against the catalog, so the chain from a human raising a concern to the expert who validated it to the change that resulted is visible and reversible. Nothing writes to the system of record without that human approval, which is the same execution-time governance posture we describe in [governance at execution time](https://plexara.io/learning/insights/governance-at-execution-time), and the same reason consequential AI output should be checked by a person before it counts. This is how a single expert's judgment becomes replicable and scalable: it is captured, validated, and made part of a system other people inherit, rather than staying a thing that one person happened to know. ### Swap the model, keep the veteran The argument names a concrete test of whether you actually own your learning loop: can you switch out a generalist model without losing the company-veteran expertise built into your systems? If changing models means starting your institutional knowledge over, the knowledge was never really yours. It was the model's. Plexara sits above the model on the protocol layer, so the captured memory, the synthesized documentation, the governed prompts, and the validated feedback all live independently of whichever frontier model is behind the gateway. Change the model and the veteran stays, because the veteran was built into the loop you own. This is the practical payoff of betting on the protocol rather than the product, which we argued in [protocols outlast products](https://plexara.io/learning/insights/protocols-outlast-products). It is worth being precise about the boundary. Plexara is not the entire thesis. We do not run private evaluation suites that score a model against your business outcomes, and we do not operate private reinforcement learning environments that train on your internal traces. Those are real and distinct capabilities. What Plexara does is the capture, synthesis, governance, and human-validation half of the loop, the half that determines whether your institutional knowledge accumulates and stays sovereign. That half has to exist before any of the training-side machinery has anything worth training on. ### Already part of the stable equilibrium The healthy version of the AI future is one where value flows broadly, where each organization owns the loop that encodes its own knowledge, and where the platform enables more value on top than it captures inside. That is the ethos the argument lands on, and it is the one Plexara was built around. We use the most capable models available, and we make sure their output strengthens the customer's ecosystem rather than draining into someone else's. This argument is close to a founding premise for Plexara. Owning your learning loop, keeping your knowledge from being commoditized, turning individual expertise into systems your organization keeps: that is the work insight capture, knowledge synthesis, and the human feedback loop do today. The capture, synthesis, and validation half of the loop is shipping now, and it is the half that decides whether your institutional knowledge stays yours. Further Reading - [A frontier without an ecosystem is not stable Satya Nadella · 2026 The Microsoft CEO's June 2026 essay argues that every firm must build a learning loop on top of frontier models so its institutional knowledge compounds rather than being commoditized by a few models, and that a firm should be able to swap out a generalist model without losing the company-veteran expertise built into its own systems.](https://x.com/satyanadella/status/2066182223213293753) - [A Dynamic Theory of Organizational Knowledge Creation Ikujiro Nonaka · 1994 Published in Organization Science, this paper models knowledge creation as the conversion between tacit and explicit knowledge, arguing that an organization's most competitive knowledge is tacit and is lost unless it is deliberately externalized into a form other people can reuse.](https://pubsonline.informs.org/doi/10.1287/orsc.5.1.14) - [Co-audit: tools to help humans double-check AI-generated content Andrew D. Gordon, Carina Negreanu, José Cambronero, et al. · 2023 This Microsoft Research paper argues that AI output used in consequential work needs tooling for a person to check it, which is the case for a review step where a human validates machine-generated documentation before it becomes part of the system of record.](https://arxiv.org/abs/2310.01297) On this page [Previous Why a Plexara rollout starts small](https://plexara.io/learning/insights/why-a-plexara-rollout-starts-small) [Next When prompts become shared infrastructure](https://plexara.io/learning/insights/governed-prompts-and-relevance-search) ### Related reading philosophy [Philosophy 101 - What is a Large Language Model? LLMs predict the next token from patterns learned across trillions of training examples. What that means, why it produces fluent reasoning, and its limits.](https://plexara.io/learning/ai-concepts/what-is-a-large-language-model) [Philosophy 104 - Frontier models, specialized models, and why enterprise AI uses both Frontier models bring world knowledge; small local embedding models power memory and catalog search. Knowing each role designs AI systems that work.](https://plexara.io/learning/ai-concepts/frontier-models-explained) [Philosophy 401 - Prompts are the new SOPs You work with the agent for an hour to get one report exactly right, with a year-over-year cut, holiday annotations, and storm-closure markers. The agent saves durable business knowledge on its own. But that specialized report is not institutional knowledge, it is a procedure. This article draws the line between the two, and makes the case that a saved prompt is the standard operating procedure for an AI-run job.](https://plexara.io/learning/prompts/prompts-are-the-new-sops) --- # When prompts become shared infrastructure URL: https://plexara.io/learning/insights/governed-prompts-and-relevance-search/ > A good prompt is only useful if other people can find it, trust it, and run it. Treating prompts as governed, searchable assets turns one person's good question into everyone's. Field notes / product May 24, 2026 ## When prompts become shared infrastructure A good prompt is only useful if other people can find it, trust it, and run it. Treating prompts as governed, searchable assets turns one person's good question into everyone's. 7-minute read Product On this page ### The problem with prompts as personal scratchpads In most AI tools, a prompt is a private string. Someone works out the exact phrasing that produces a reliable monthly revenue summary, pastes it into a note, and reuses it. The phrasing is valuable, but it lives nowhere the rest of the team can reach. The next person solves the same problem from scratch, slightly worse. This is the same failure pattern as [tribal knowledge in a data warehouse](https://plexara.io/learning/insights/knowledge-application-turns-usage-into-documentation). The understanding exists, but it is trapped in an individual rather than held by the system. When that person changes teams, the working prompt leaves with them, and the organization quietly relearns what it already knew. A prompt library only fixes this if it is more than a shared folder. People need to know which prompts are approved, which are experiments, and which have been retired. Without that, a shared list becomes another place where good and stale advice sit side by side with no way to tell them apart. ### A prompt is an asset, not a string Plexara treats a prompt as a first-class asset with a lifecycle. A prompt can be a draft, an approved standard, or a deprecated relic, and that status is visible wherever the prompt appears. An admin promotes a prompt to approved through a review queue, so the library reflects deliberate decisions rather than whatever happened to accumulate. Prompts carry tags so they can be organized by domain or task, and they can be shared directly between people by email. The detail that matters: the recipient gets a real, runnable prompt, not a flattened copy of the text. They receive the working tool, with its parameters intact, rather than a screenshot of someone else's success. The unit of reuse shifts from the individual to the platform. The person who worked out the reliable phrasing publishes it once. Everyone else runs it, and the organization keeps the capability even after that person moves on. [Image: A prompt detail page in the portal showing the prompt text with date and threshold placeholders, an attached materials list, a Run from chat card with a copyable command, and a Version history where a draft v4 is pending review while v3 is marked applied and current with its approver named, above a superseded v2 and an earlier applied v1.] The lifecycle from the paragraph above, on one prompt. The banner says a draft is pending review and that readers keep getting the approved version until an admin approves the new one. Each version names who wrote it and who approved it, and any two versions can be compared. ### Search that ranks by meaning, everywhere A library is only as good as your ability to find the right thing in it. Exact-keyword search fails the moment someone describes what they want in different words than the author used. Asking for "churn by segment" should surface a prompt titled "retention breakdown by customer tier" if that is what it does. Plexara [ranks results by meaning](https://plexara.io/learning/insights/search-the-capability-not-the-manual), with an automatic fallback to keyword matching when that serves better. The same relevance search now spans captured knowledge, prompts, saved assets, and collections, in both the assistant and the portal. One way of searching reaches everything the platform knows, rather than a separate box for each kind of thing. Every result stays [scoped to what the person is allowed to see](https://plexara.io/learning/insights/closed-by-default-access). Relevance and governance are not in tension here. The ranking surfaces the most useful match, and access rules decide whether it appears at all. [Image: The Prompts page on the Library tab, with a search box labelled Search prompts by meaning, filters for collection, tag, owner, and activity, and prompts grouped by collection such as Data Operations, Executive Briefings, and Sales Reporting, each row showing a description, run count, and time since last run, with badges marking unused or never-run prompts.] The shared library. The search box ranks by meaning rather than exact title, and the run count and last-run columns make a stale prompt visible instead of leaving it to sit beside the ones people actually use. ### Why this compounds Each of these pieces is modest on its own. Together they change how knowledge accumulates. A useful prompt gets captured, reviewed, and made findable by meaning, which means it gets reused, which means the next person starts from the best known approach rather than a blank box. The work people do to make the assistant effective stops evaporating at the end of the conversation and becomes shared infrastructure that the next person can build on. Further Reading - [Dense Passage Retrieval for Open-Domain Question Answering Vladimir Karpukhin, Barlas Oguz, Sewon Min, Patrick Lewis, Ledell Wu, Sergey Edunov, Danqi Chen, Wen-tau Yih · 2020 This EMNLP 2020 paper shows a learned dense (semantic) retriever outperforms a strong Lucene-BM25 keyword system by 9-19% absolute in top-20 retrieval accuracy, establishing that ranking by learned meaning beats exact-keyword matching.](https://aclanthology.org/2020.emnlp-main.550/) - [Vocabulary mismatch Wikipedia contributors · 2024 Documents the long-standing information-retrieval problem that keyword-matching systems fail when a query and a relevant document use different words for the same concept (e.g. 'car rental' vs 'automobile hire').](https://en.wikipedia.org/wiki/Vocabulary_mismatch) - [Role-Based Access Control Models Ravi S. Sandhu, Edward J. Coyne, Hal L. Feinstein, Charles E. Youman · 1996 The foundational RBAC paper, hosted by NIST, establishes that role-based access control enforces the principle of least privilege by granting users only the permissions required for their role, which is the mechanism for scoping retrieval results to what a user is permitted to see.](https://csrc.nist.gov/CSRC/media/Projects/Role-Based-Access-Control/documents/sandhu96.pdf) On this page [Previous Own the learning loop, not just the model](https://plexara.io/learning/insights/own-the-learning-loop-not-the-model) [Next Closed by default: least privilege as the starting point](https://plexara.io/learning/insights/closed-by-default-access) ### Related reading product [Product 102 - Tokens and your budget Every LLM interaction is priced and rate-limited in tokens. What a token is, how much text fits a budget, and how to avoid wasting tokens on useful answers.](https://plexara.io/learning/ai-concepts/tokens-and-your-budget) [Product 105 - What is an AI agent? An AI agent is not a chatbot and not magic. It is a short loop (think, call-tool, observe, think again) on top of a language model. Mental model first.](https://plexara.io/learning/ai-concepts/what-is-an-ai-agent) [Product 202 - Your first day with Plexara A new Plexara user gets connected, sends a first question, and platform_info takes over. Walks through day one and how subsequent turns inherit context.](https://plexara.io/learning/mcp/first-engagement) --- # Closed by default: least privilege as the starting point URL: https://plexara.io/learning/insights/closed-by-default-access/ > Access control that starts open and gets locked down later never actually finishes. Closing connection access by default means every role sees exactly what it was granted and nothing more. Field notes / governance May 16, 2026 ## Closed by default: least privilege as the starting point Access control that starts open and gets locked down later never actually finishes. Closing connection access by default means every role sees exactly what it was granted and nothing more. 6-minute read Governance On this page ### The drift problem with open by default Many systems begin permissive. Every role can reach every connection, and the plan is to tighten things up once the team understands who needs what. That cleanup rarely happens. New connections arrive faster than anyone audits the old ones, and the access map drifts further from intent with every addition. The risk is quiet because nothing breaks. An analyst role that can technically reach a finance connection it never uses looks fine until the day an agent, acting on that role, follows a question somewhere it should not have gone. Open by default means the safe state is the one you have to remember to create, and memory is not a control. ### Closed by default, granted explicitly Plexara inverts the default. Connection access is closed unless it is explicitly granted. A role sees exactly the connections it has been given and nothing more. The safe state is the starting state, and widening access is a deliberate act rather than the absence of one. This matters most for agents, because an agent does not exercise judgment about scope the way a person might. It will use whatever it can reach to answer the question in front of it. Bounding what a role can reach is the same as bounding what the agent can do on that role behalf, which is the kind of [enforcement that happens at execution time](https://plexara.io/learning/insights/governance-at-execution-time) rather than only when the catalog was assembled. Closed by default also makes the access map legible. When every grant is intentional, the list of what a role can touch is a statement of design, not an archaeological record of everything that was ever switched on. [Image: The New Persona form in the admin portal with a name and display name filled in and no allow or deny patterns yet: a notice reads that no allow patterns means no tools are reachable, and the live Permissions preview reports 0 tools allowed and 17 denied, every tool listed with a blocked marker.] A persona starts with nothing. Until an admin adds an allow pattern, the preview shows every tool denied and says so in plain words. Widening access is something someone does on purpose, and the counts on the right update as they do it. ### Why it matters more as you connect more A platform that connects to one warehouse can get away with loose defaults. A platform whose [agent reaches across the whole stack](https://plexara.io/learning/insights/when-an-agent-can-see-the-whole-stack), a warehouse, a catalog, object storage, and a growing set of external APIs, cannot. Each new connection multiplies the number of role-to-resource pairs that an open default would expose by accident. Closing access by default keeps the blast radius flat as the platform reach grows. Adding a connection does not silently expand what every existing role can do. It adds something that someone must choose to grant, which is exactly the property you want as the surface area increases. ### Self-service configuration without widening the blast radius Tighter defaults often come at the cost of convenience, pushing every change through an engineering queue. Plexara avoids that trade by letting admins configure roles, connections, and access directly, including by asking the assistant to make the change, with every change attributed and logged to the admin who made it. Plexara pairs closed-by-default access with self-service administration. Every grant is a deliberate act, logged to the admin who made it, so least privilege holds as the resting state without routing each change through an engineering queue. The [personas, access, and audit lesson](https://plexara.io/learning/mcp/governance-personas-and-access) walks through the model in practice. [Image: The Visibility tab for the Trino Query tool in the admin Tools screen: a global kill-switch card with a Hide tool button, a Persona access table listing six personas with an allow decision and the pattern each matched, an Edit persona rules link, and a field to preview the decision for any persona name.] Access is legible from the tool side as well. For any tool, an admin can read which personas reach it and through which pattern, hide it from every client with one switch, or type a persona name to preview the decision before changing anything. Further Reading - [least privilege - Glossary | CSRC National Institute of Standards and Technology (NIST) · 2020 NIST defines least privilege as allowing only the authorized accesses necessary for users (or processes acting on their behalf) to accomplish assigned tasks, the formal basis for granting a role exactly what it needs and nothing more.](https://csrc.nist.gov/glossary/term/least_privilege) - [Zero Trust Architecture Scott Rose, Oliver Borchert, Stu Mitchell, Sean Connelly (NIST) · 2020 NIST's Zero Trust Architecture establishes that no implicit trust is granted and access must be explicitly authorized per request on a default-deny basis, the standards-body articulation of closed-by-default access.](https://nvlpubs.nist.gov/nistpubs/specialpublications/NIST.SP.800-207.pdf) - [LLM06:2025 Excessive Agency OWASP Gen AI Security Project · 2025 OWASP identifies excessive functionality and excessive permissions in agentic systems as a top LLM risk, since an agent dynamically decides which reachable tool to call and will use whatever access it has, so bounding reachable resources is the mitigation.](https://genai.owasp.org/llmrisk/llm062025-excessive-agency/) On this page [Previous When prompts become shared infrastructure](https://plexara.io/learning/insights/governed-prompts-and-relevance-search) [Next Search the capability, not the manual: how Plexara keeps a wide platform light](https://plexara.io/learning/insights/search-the-capability-not-the-manual) ### Related reading governance [Governance 403 - Sharing prompts, and closing the loop with feedback A procedure is only worth as much as the people who can run it. Plexara distributes a prompt two ways: a direct share to one teammate, or a promotion to a whole role or company through the admin review queue. A shared prompt is live, not a copy. Feedback threads then carry corrections back, with a validation step and a path into the knowledge catalog, and the deprecate-and-supersede lifecycle retires old versions cleanly.](https://plexara.io/learning/prompts/sharing-prompts-and-feedback) [Governance 505 - Next month’s file The new sheet arrives. Replacing the file’s content writes a new revision, and the registered table keeps reading the old one until it is registered again under the same name; the Scratch Tables page says so. This lesson covers the two cases that look alike and behave differently, moving the table forward, unregistering, what deleting the file does, saving the monthly procedure as a prompt, and the point at which a monthly file needs more than a join, which is where the 600 series begins.](https://plexara.io/learning/spreadsheets/next-months-file) [Governance 605 - What a run may do, and the record it leaves A run presents the roles its author held at the save, every call is authorized at that moment, and narrowing the persona takes effect on the next run. A save refuses a credential-shaped literal and source that does not parse. The dialect has no network, no filesystem, and no clock, so everything a script does is a platform call audited under the script’s own identity. The lifecycle from active to disabled, deprecated, and superseded; who sees what; ownership and an administrator’s transfer; and the administrator’s view of every script and every run.](https://plexara.io/learning/automations/what-a-run-may-do) --- # Search the capability, not the manual: how Plexara keeps a wide platform light URL: https://plexara.io/learning/insights/search-the-capability-not-the-manual/ > Loading every API spec into context does not scale. A small, fixed tool footprint plus semantic endpoint discovery keeps cost tied to the task, not the size of the platform. Field notes / architecture May 7, 2026 ## Search the capability, not the manual: how Plexara keeps a wide platform light Loading every API spec into context does not scale. A small, fixed tool footprint plus semantic endpoint discovery keeps cost tied to the task, not the size of the platform. 9-minute read Architecture On this page ### Loading the whole manual does not scale There is a naive way to give an agent access to an API, and almost everyone tries it first. You take the OpenAPI specification, you load it into the context window, and you let the model read the manual before it acts. It works for one small API. It falls apart the moment you have a real platform. Here is the arithmetic that breaks it. A public media analytics platform we work with runs eleven API connections. Their catalogued operations total roughly eighteen hundred: the CRM and fundraising system alone contributes well over five hundred operations, and that is one connection of eleven. Loaded as full schemas with request and response shapes, that surface runs into the millions of tokens before a single byte of actual data is retrieved. You cannot put that in a context window. Even if you could afford to, you should not, because the agent would spend its attention reading documentation instead of solving the problem, and most of what it read would be irrelevant to the task at hand. The instinct to load everything up front is the same instinct that fails with tools generally. The agent needs exactly one thing: the operation that does what it is trying to do, found at the moment it is trying to do it. ### A small tool footprint over an unbounded surface Plexara's answer is to keep the agent's actual toolset small and fixed, regardless of how many APIs sit behind it. A handful of stable, general tools cover the entire integration surface: list the configured connections; list the sections of a given API; search the operations of an API for a capability; fetch the schema for one specific operation, on demand; invoke an operation; and stream a large response to storage instead of through the model. That is the whole footprint. It does not grow when you add a connection. Adding the orchestration engine, or the events platform, or a second CRM, does not add tools to the agent's working set. It adds rows to a registry that the same six tools already know how to traverse. The agent's cognitive load stays flat while the platform's reach expands without limit. This is the deliberate inverse of the [tool-sprawl approach](https://plexara.io/learning/insights/why-more-tools-wont-make-your-agent-smarter), where every new system bolts another handful of bespoke tools onto an ever-heavier agent. ### Semantic discovery: find the endpoint by intent A small toolset only works if the search tool is good, because search is now how the agent navigates everything. This is where semantic discovery earns its place. When the agent needs a capability, it does not scroll a list of operation names hoping to recognize one. It describes what it wants and the platform ranks the operations by relevance. The ranking can be lexical for exact term matching, semantic for matching by intent when the agent's phrasing does not share vocabulary with the spec author's, or a hybrid of both. "Find the flows that are running" can surface the right orchestration endpoint even when the operation is named something the agent would never have guessed, because the match is on meaning rather than on string overlap. The pattern in practice is search, then narrow, then act. The agent searches the connection for the handful of operations that fit its intent. It reads the schema for the one it chooses, and only that one. Then it invokes. The full specification for the other seventeen hundred operations never enters the context window, because the agent never needed it. It needed three operations for this task and it found them by searching. This is the same principle the broader platform applies to its own tools. Rather than exposing every capability at once, [tools are loaded on demand by relevance](https://plexara.io/learning/insights/intent-driven-tools-and-memory). The agent searches the capability it needs and the matching tools arrive. Endpoint discovery is that same idea pushed down into each connected API. Whether the agent is finding a platform tool or finding an operation inside a thousand-operation CRM, the move is identical: search for the capability, retrieve only what matches, leave the rest on disk. ### Why this is the architecture that scales The contrast is clearest when you imagine adding a twelfth API, then a twentieth. Under the load-everything model, each addition makes every task more expensive, because the documentation the agent wades through grows with the platform whether or not the new API is relevant to the question. Cost and latency climb, and the agent's accuracy degrades as the signal it needs is buried under specs it does not. The architecture punishes growth. Under search-on-demand, the twentieth API costs the same per task as the second. The registry is larger, but the agent still searches, still retrieves a handful of candidates, still reads one schema, still acts. Context consumption is governed by the complexity of the task, not by the size of the platform. The architecture is indifferent to growth, which is exactly the property you want when the entire premise is connecting an agent to deep and wide infrastructure. There is a quieter benefit that matters to anyone responsible for spend and reliability. An agent that reads only the operations it uses is an agent whose behavior is legible. You can see which connection it searched, which operation it chose, which schema it pulled. The reasoning path is narrow and inspectable, instead of a model swimming through a megabyte of documentation and arriving somewhere you cannot reconstruct. The same small footprint that keeps the bill down is what makes the agent auditable. ### What this means for the decision The [token economics of agent platforms](https://plexara.io/learning/insights/token-efficiency-in-enterprise-mcp) look like an implementation detail. They are an architectural fork that determines whether your platform gets cheaper or more expensive to use as it grows. A platform that front-loads documentation has costs that scale with its own size. A platform built on a small tool footprint and semantic discovery has costs that scale with the task. Over a roadmap that adds connections every quarter, those two curves diverge sharply. The right question to ask a vendor, or your own team, is simple. When you add the next ten integrations, does every existing workflow get more expensive, or does nothing change but the size of a registry the agent already knows how to search. The answer tells you whether you are buying something that compounds in your favor or against you. Plexara is built on the second curve. A fixed set of general tools, semantic search over every connected operation, and schemas fetched one at a time keep per-task cost flat whether the platform behind the agent exposes two hundred operations or eighteen hundred. Further Reading - [Code execution with MCP: Building more efficient agents Anthropic (Adam Jones and Conor Kelly) · 2025 Anthropic's engineering team documents that loading all MCP tool definitions up front consumes hundreds of thousands of tokens before the agent reads a request, and advocates on-demand loading where models read tool definitions only when needed (a 150,000 to 2,000 token reduction in their example).](https://www.anthropic.com/engineering/code-execution-with-mcp) - [RAG-MCP: Mitigating Prompt Bloat in LLM Tool Selection via Retrieval-Augmented Generation Tiantian Gan, Qiyao Sun · 2025 This paper shows that semantically retrieving only the relevant tools for a query before invoking the LLM cuts prompt tokens by over 50% and more than triples tool-selection accuracy (43.13% vs 13.62% baseline), with new tools added by indexing rather than fine-tuning.](https://arxiv.org/abs/2505.03275) - [Lost in the Middle: How Language Models Use Long Contexts Nelson F. Liu, Kevin Lin, John Hewitt, Ashwin Paranjape, Michele Bevilacqua, Fabio Petroni, Percy Liang · 2023 Peer-reviewed study demonstrating that model performance degrades substantially as input context grows longer and when relevant information is buried among irrelevant content, showing models do not robustly use information in long contexts.](https://arxiv.org/abs/2307.03172) On this page [Previous Closed by default: least privilege as the starting point](https://plexara.io/learning/insights/closed-by-default-access) [Next Letting the agent find the right tool](https://plexara.io/learning/insights/intent-driven-tools-and-memory) ### Related reading architecture [Architecture 103 - Context, compression, and memory The context window is a model's working memory. Each session balances keeping, compressing, or clearing it. Plexara adds enterprise memory on top.](https://plexara.io/learning/ai-concepts/context-windows-and-tokens) [Architecture 201 - Anatomy of a Plexara MCP 201 shows what is actually in the box on a Plexara server: the tool inventory by toolkit, the four content layers, the interactive apps a tool result can carry, and the memory, knowledge, and governance underneath. This lesson is the map.](https://plexara.io/learning/mcp/what-is-an-mcp) [Architecture Five kinds of memory, and how each comes back A fact, an incident, a person, a link, and a habit are five different kinds of knowledge. Plexara stores each as its own dimension and recalls it the way that kind needs, which is what makes memory across sessions feel like memory rather than search.](https://plexara.io/learning/insights/five-kinds-of-memory) --- # Letting the agent find the right tool URL: https://plexara.io/learning/insights/intent-driven-tools-and-memory/ > An agent that rereads every tool description on every turn is slow and error-prone. Selecting tools by intent, and remembering context across sessions, is what makes a wide platform feel fast. Field notes / architecture Apr 29, 2026 ## Letting the agent find the right tool An agent that rereads every tool description on every turn is slow and error-prone. Selecting tools by intent, and remembering context across sessions, is what makes a wide platform feel fast. 7-minute read Architecture On this page ### The cost of a long tool list Every tool an agent can call carries a description and a parameter schema, and those definitions are part of the context the model reads before it answers. A handful of tools is free. A few dozen is a tax the agent pays on every single turn, whether or not any of them are relevant to the question. The cost is not only tokens. A long list degrades judgment. Faced with dozens of similar-sounding tools, an agent picks the wrong one more often, calls it with the wrong arguments, and burns a round trip discovering the mistake. Past the point where the agent can hold them all in view, [more options tend to produce worse decisions](https://plexara.io/learning/insights/why-more-tools-wont-make-your-agent-smarter). ### Finding the right tool by intent Plexara lets the agent locate the best tool for a request by intent rather than by scanning a flat list. The agent describes what it is trying to do, and the platform [returns the tool that matches that meaning](https://plexara.io/learning/insights/search-the-capability-not-the-manual), even when the wording does not line up with the tool name. This keeps the working set small without making the platform small. The full breadth of connections and operations stays available, but the agent does not have to carry all of it at once. It reaches for the right capability when the task calls for it, which is how a person uses a large toolbox without memorizing every drawer. The result is that the agent spends less of each conversation deciding what to use and more of it doing the work. [Image: The admin Tools screen with tools grouped by connection in a left-hand list and Trino Query selected: the Overview tab shows an editable description, a routing card naming toolkit, kind, and connection, a personas table listing which personas may call the tool and the pattern each matched, and the start of the input schema.] What the platform knows about one tool. The description at the top is what the agent reads when deciding whether a tool fits the request, and an admin can edit it here so a tool that keeps being passed over gets described the way people actually ask for it. [Image: The Activity tab for the Trino Query tool, aggregated over the last day: cards for calls, success rate, and average duration, with a link to the full audit log for this tool.] The same tool's activity. Which tools are actually reached for, how often they succeed, and how long they take, per tool, with the audit log one click away. ### Memory that carries across sessions Efficiency within a single conversation is only half the problem. Without memory, every session starts cold. The agent relearns the same preferences, rediscovers the same corrections, and reestablishes the same context it had yesterday, paying for that ramp-up every time. Plexara recall [blends meaning and keywords](https://plexara.io/learning/insights/why-proximity-matters-tools-meaning-memory), so the agent brings back the context that actually relates to the current question rather than the most recent or most literal match. Preferences, corrections, and prior findings carry across sessions for both agents and analysts. The result is an assistant that accumulates rather than resets. A correction made once stays made. Context established in one session is available in the next, so the work compounds instead of repeating. ### Efficiency as a feature, not an accident It is tempting to treat tool selection and memory as plumbing. In practice they are what separate an assistant that feels sluggish and forgetful from one that feels sharp. The user does not see the search index or the recall strategy. They feel the difference as answers that arrive faster and a system that remembers what they told it. Selecting by intent and remembering across sessions are deliberate design choices with a single aim: an agent whose cognitive load tracks the task in front of it, however large the platform behind it grows. Further Reading - [RAG-MCP: Mitigating Prompt Bloat in LLM Tool Selection via Retrieval-Augmented Generation Tiantian Gan, Qiyao Sun · 2025 Shows that loading all tool definitions into the prompt causes 'prompt bloat' and that baseline tool-selection accuracy collapses to 13.62% with a large tool pool, rising to 43.13% when semantic retrieval pre-filters tools, while cutting prompt tokens by over 50%.](https://arxiv.org/abs/2505.03275) - [LongFuncEval: Measuring the effectiveness of long context models for function calling Kiran Kate, Tejaswini Pedapati, Kinjal Basu, Yara Rizk, Vijil Chenthamarakshan, Subhajit Chaudhury, Mayank Agarwal, Ibrahim Abdelaziz · 2025 Empirically demonstrates that LLM function-calling accuracy deteriorates significantly as the number of available tools and the resulting context length grow, with position bias becoming more pronounced.](https://arxiv.org/pdf/2505.10570) - [Domain-specific Question Answering with Hybrid Search Dewang Sultania, Zhaoyu Lu, Twisha Naik, Franck Dernoncourt, et al. · 2024 Reports that a hybrid approach combining a dense (semantic) retriever with keyword-based sparse search reaches nDCG 0.847, outperforming the dense retriever alone (0.828) and keyword/BM25 alone (0.640).](https://arxiv.org/html/2412.03736v2) On this page [Previous Search the capability, not the manual: how Plexara keeps a wide platform light](https://plexara.io/learning/insights/search-the-capability-not-the-manual) [Next The combinatorial platform: when an agent can see across the whole stack](https://plexara.io/learning/insights/when-an-agent-can-see-the-whole-stack) ### Related reading architecture [Architecture 103 - Context, compression, and memory The context window is a model's working memory. Each session balances keeping, compressing, or clearing it. Plexara adds enterprise memory on top.](https://plexara.io/learning/ai-concepts/context-windows-and-tokens) [Architecture 201 - Anatomy of a Plexara MCP 201 shows what is actually in the box on a Plexara server: the tool inventory by toolkit, the four content layers, the interactive apps a tool result can carry, and the memory, knowledge, and governance underneath. This lesson is the map.](https://plexara.io/learning/mcp/what-is-an-mcp) [Architecture Five kinds of memory, and how each comes back A fact, an incident, a person, a link, and a habit are five different kinds of knowledge. Plexara stores each as its own dimension and recalls it the way that kind needs, which is what makes memory across sessions feel like memory rather than search.](https://plexara.io/learning/insights/five-kinds-of-memory) --- # The combinatorial platform: when an agent can see across the whole stack URL: https://plexara.io/learning/insights/when-an-agent-can-see-the-whole-stack/ > A warehouse connection tells you what the data is. The valuable questions need an agent that reasons across query, catalog, orchestration, and source layers at once. Field notes / architecture Apr 20, 2026 ## The combinatorial platform: when an agent can see across the whole stack A warehouse connection tells you what the data is. The valuable questions need an agent that reasons across query, catalog, orchestration, and source layers at once. 10-minute read Architecture On this page ### Where most agent integrations stop A warehouse connection answers "what is the data." That is useful and it is also where most agent integrations stop. The harder and more valuable questions are the ones a single connection cannot reach: why is this number different from last week, where did this record actually come from, which pipeline produced it, is that pipeline even running, and is the cluster underneath it healthy. Answering those requires seeing across layers that have traditionally lived in separate tools owned by separate teams. Plexara's recent addition of API connections is what closes that gap. The platform already federated query engines and a catalog. Now it can also reach the orchestration engine, the remote sources and destinations, and the operational substrate of the platform itself. More connections is the boring part. What matters is what becomes possible when an agent can hold all of them at once. ### Each layer answers a different question Think of the layers by the question each one is built to answer. A federated query engine answers what the data is. Revenue by location, members by status, events by date. This is the analytical surface. A catalog answers what the data means. Descriptions, ownership, lineage, glossary terms, and the [accumulated insights that turn usage into documentation](https://plexara.io/learning/insights/knowledge-application-turns-usage-into-documentation). This is the semantic surface. An orchestration engine answers how the data got here. Which flows are running, where flowfiles are queued, what is backed up, what threw an error, how a record moved from a source system to the table you are querying. This is the provenance and movement surface. The cluster substrate answers whether the machinery is healthy. What is scheduled, what is failing, what is starved for resources. This is the operational surface. Source and destination APIs answer what is true at the edges. The CRM's own view of a constituent, the email platform's own view of a campaign, before any of it has been transformed and loaded. This is the ground-truth surface. In isolation, each of these is a familiar tool with a familiar owner. The combinatorial effect is what happens when one agent can move across all five in a single line of reasoning. ### What the combination unlocks A worked shape, sanitized from real environments. An analyst asks why a membership metric dropped. A warehouse-only agent can confirm the drop and speculate. An agent with the full stack does something categorically different. It reads the metric from the query engine. It checks the catalog and learns which pipeline feeds that table and which join key is correct. It queries the orchestration engine and finds that the relevant flow has a connection with a large queue backlog and a processor sitting in an error state. It checks the source API directly and confirms the upstream records exist and are current. The conclusion is no longer "the number went down." It is "the number went down because this specific pipeline stalled at this specific step on this date, the source data is intact, and here is what to restart." One is an observation. The other is a diagnosis with a remedy. That chain is only possible because the layers are combined. Provenance without the catalog tells you a flow stalled but not which metric it poisons. The catalog without the orchestration view tells you what should feed the table but not whether it actually did. The source API without either tells you the upstream is fine but not why the downstream is wrong. Value comes from the joins between layers, not from any single layer, in exactly the way value in a relational database comes from joins rather than from any one table. The two deployments we work with most closely show the same pattern at different scales. A retail POS analytics platform combines its query engines and catalog with orchestration-engine and cluster API access, so an agent can trace a sales figure from the index it was aggregated from, back through the flow that loaded it, down to the pods running the job. A public media analytics platform runs more than ten API connections covering its CRM and fundraising system, its email and events platforms, its BI cloud and file-sync service, plus the same orchestration and cluster layers, so an agent can follow a constituent record from the source system of record all the way to the dashboard and explain every transformation in between. Different industries, different sources, same architecture: see deep, into how the data moves and why, and see wide, across every system it touches. ### Reach is a responsibility, not just a capability Breadth like this raises an obvious and correct concern from anyone responsible for the platform. An agent that can read the orchestration engine and the cluster is an agent operating close to production machinery. The answer is that reach and authority are separate decisions, and the platform should let you set them separately. A connection can be registered as read-only, and the meaningful version of that posture is enforced at the source system's own authorization layer, not merely by which operations the platform chooses to expose. The distinction matters and it is worth being precise about, because the two are not equivalent. A curated catalog that lists only read operations narrows what is convenient. A source-side credential that is genuinely scoped to read narrows what is possible. The second is the one that holds when something unexpected happens. In practice that means an orchestration-engine connection used for pipeline debugging should authenticate as an identity whose own permissions are read, view, and provenance only, with write denied at the engine. This is [least privilege as the starting point](https://plexara.io/learning/insights/closed-by-default-access) rather than something added afterward. Then the agent can see everything it needs to diagnose a stalled flow and cannot, as a matter of credential scope rather than catalog politeness, change one. [Enforcement lives at the auth layer](https://plexara.io/learning/insights/governance-at-execution-time), not in the catalog. Claim only what is actually enforced there, and scope the credential to match the access you intend. ### What this means for the decision The strategic read is that the value of each new connection is not additive, it is multiplicative against the connections already present. A source API on its own is a thin integration. The same source API alongside a catalog, a query engine, and an orchestration view is a diagnostic capability no single-layer tool can match. This is why "how many integrations" is the wrong evaluation question and "can the agent reason across them in one chain" is the right one. It also means the operational and security posture has to be designed in, not bolted on. The same architecture that lets an agent see across the whole stack is the architecture that has to scope what it can do at each layer. Get that right and you have an agent that can diagnose your platform end to end while being structurally unable to harm it. The remaining question is mechanical and it is not small: how does an agent actually navigate this many systems without drowning in their documentation? More than ten APIs with well over a thousand operations between them is far more than any context window should hold. The next piece is about how Plexara solves that with a deliberately small tool footprint and semantic endpoint discovery, so the agent [searches for the capability it needs](https://plexara.io/learning/insights/search-the-capability-not-the-manual) instead of memorizing all of them. Further Reading - [MCP-Zero: Active Tool Discovery for Autonomous LLM Agents Xiang Fei, Xiawu Zheng, Hao Feng · 2025 Demonstrates that injecting full tool/API schemas into an LLM context does not scale, and proposes letting the agent actively retrieve only the tools it needs via semantic discovery from a large tool repository.](https://arxiv.org/abs/2506.01056) - [What Affects the Stability of Tool Learning? An Empirical Study on the Robustness of Tool Learning Frameworks Chengrui Huang, Zhengliang Shi, Yuntao Wen, Xiuying Chen, Peng Han, Shen Gao, Shuo Shang · 2024 Empirically shows that both closed- and open-source LLMs suffer substantial performance degradation as the toolset scales and when irrelevant tools are present, validating that exposing too many tools at once harms agent reasoning.](https://arxiv.org/abs/2407.03007) - [least privilege - Glossary | CSRC National Institute of Standards and Technology (NIST) · 2020 NIST defines least privilege as granting each entity (including processes acting on behalf of users) only the minimum authorizations needed to perform its function, the authoritative basis for scoping an agent's source-side credentials to read-only.](https://csrc.nist.gov/glossary/term/least_privilege) On this page [Previous Letting the agent find the right tool](https://plexara.io/learning/insights/intent-driven-tools-and-memory) [Next Meeting enterprise systems where they are](https://plexara.io/learning/insights/enterprise-authentication-and-isolation) ### Related reading architecture [Architecture 103 - Context, compression, and memory The context window is a model's working memory. Each session balances keeping, compressing, or clearing it. Plexara adds enterprise memory on top.](https://plexara.io/learning/ai-concepts/context-windows-and-tokens) [Architecture 201 - Anatomy of a Plexara MCP 201 shows what is actually in the box on a Plexara server: the tool inventory by toolkit, the four content layers, the interactive apps a tool result can carry, and the memory, knowledge, and governance underneath. This lesson is the map.](https://plexara.io/learning/mcp/what-is-an-mcp) [Architecture Five kinds of memory, and how each comes back A fact, an incident, a person, a link, and a habit are five different kinds of knowledge. Plexara stores each as its own dimension and recalls it the way that kind needs, which is what makes memory across sessions feel like memory rather than search.](https://plexara.io/learning/insights/five-kinds-of-memory) --- # Meeting enterprise systems where they are URL: https://plexara.io/learning/insights/enterprise-authentication-and-isolation/ > Real enterprise APIs authenticate in messy ways: client certificates, basic auth, second credential headers. Supporting them, while keeping each user activity isolated, is what makes an agent usable at work. Field notes / integration Apr 12, 2026 ## Meeting enterprise systems where they are Real enterprise APIs authenticate in messy ways: client certificates, basic auth, second credential headers. Supporting them, while keeping each user activity isolated, is what makes an agent usable at work. 6-minute read Integration On this page ### The authentication reality of enterprise systems Demos connect to APIs that use a clean bearer token. Real enterprises do not. The systems an agent actually needs to reach authenticate with client certificates, with basic username and password, with a second credential header alongside the first, and with quirks that no specification fully describes. An integration story that only handles the clean case is a story that works until the first system that matters. The unglamorous work of supporting the messy authentication methods already deployed across an organization is what decides whether an agent can be used at work or only in a sandbox. ### mTLS, basic auth, and the long tail Plexara supports the authentication methods enterprise systems actually use. Internal and corporate APIs secured with client certificates (mTLS) are handled, as are APIs that authenticate with basic username and password, and APIs that require a second credential header in addition to the primary one. Sign-in for both AI-tool and web-API connections is unified, with automatic token refresh before expiry, a history of authentication events, and clearer errors when something is misconfigured. Connections that depend on a sign-in turn themselves on once their prerequisites are met, rather than failing silently and leaving someone to guess why. None of this is glamorous. Covering the long tail of how real systems authenticate is what makes a connector work in your environment, against the systems your organization already runs. ### Isolation between users is not optional Connecting to sensitive systems raises the stakes on a question that is easy to overlook: can one person see another person activity? On a platform that [records every action for audit](https://plexara.io/learning/mcp/governance-personas-and-access), the answer has to be no, enforced rather than assumed. Plexara hardened isolation so that one user activity history cannot be visible to another, including on the connection types where that boundary is subtlest. This is where [least privilege as the starting point](https://plexara.io/learning/insights/closed-by-default-access) matters: strong authentication into a system means little if the record of what was done with it leaks across users. The two have to hold together. ### Operability you can see Enterprise systems also demand that you can tell whether things are healthy. Live health and usage metrics are on by default, with an admin dashboard, so operators see the state of the platform and its connections without standing up separate monitoring first. Authentication, isolation, and visibility are what a security team asks about before an agent touches a production system, the same concerns that push policy decisions to [governance at execution time](https://plexara.io/learning/insights/governance-at-execution-time). Plexara builds all three in from the start: support for the authentication methods enterprises actually run, enforced per-user isolation, and live health metrics with an admin dashboard, on by default. [Image: The API Gateway tab of the admin dashboard on a 24-hour range: counters for inbound requests, outbound calls, outbound error rate, and upstream server errors, a Status Mix chart of requests per second by response class across the day, and a Usage Rhythm heatmap of requests by weekday and hour over the last seven days.] The gateway view of the dashboard. Error rate and upstream failures sit beside volume, so a partner API that starts misbehaving shows up here before anyone files a ticket. [Image: The Health tab of the admin dashboard listing the nodes serving the platform, each as a card with a status badge, uptime, CPU, memory, heap, and in-flight request figures, and small CPU and memory charts over the last hour; one node is marked Healthy and another Restarted recently.] Runtime health per node, in the same portal. An admin opens the Health tab and sees uptime and resource use for every node, including one that restarted a few minutes ago. Further Reading - [OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens Internet Engineering Task Force (IETF) · 2020 The IETF standard defining how clients authenticate to a server by presenting an X.509 client certificate (mutual TLS), confirming mTLS is a recognized, specified enterprise authentication method.](https://www.rfc-editor.org/rfc/rfc8705) - [The 'Basic' HTTP Authentication Scheme J. Reschke · 2015 The IETF standard defining HTTP Basic authentication via Base64-encoded user-id/password pairs, and noting it must be paired with HTTPS because credentials are transmitted in cleartext.](https://www.rfc-editor.org/rfc/rfc7617.html) - [least privilege - Glossary | CSRC National Institute of Standards and Technology (NIST) · 2020 NIST defines least privilege as allowing only the authorized accesses necessary for assigned tasks, the principle that underpins enforcing isolation so one user cannot access another user's activity.](https://csrc.nist.gov/glossary/term/least_privilege) - [NIST SP 800-53 Rev. 5: Security and Privacy Controls for Information Systems and Organizations Joint Task Force / National Institute of Standards and Technology (NIST) · 2020 The NIST Audit and Accountability (AU) family, including AU-2 Event Logging and AU-3 Content of Audit Records, establishes recording every action with who/what/when/outcome as a core security control for production systems.](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) On this page [Previous The combinatorial platform: when an agent can see across the whole stack](https://plexara.io/learning/insights/when-an-agent-can-see-the-whole-stack) [Next Why more tools won't make your agent smarter](https://plexara.io/learning/insights/why-more-tools-wont-make-your-agent-smarter) ### Related reading integration [Integration 110 - Is MCP just an API wrapper? MCP is not a replacement for your APIs and not a thin proxy. It is an application layer on top, like a website is an application layer on top of its APIs.](https://plexara.io/learning/ai-concepts/mcp-vs-apis) [Integration 606 - Scripts as skills: the weekly review the agent runs on your business The capstone. Three scripts (category velocity, the supplier quote margin review, regional weather context) attached to one prompt, so serving the prompt carries each script’s contract and last successful output and the agent runs them for fresh numbers instead of re-deriving them. The agent then reads the outputs against the seasonality calendar, the returns policy, the store formats, and the stock health bands, and produces the week’s action items: promote, discount, discontinue or renegotiate, watch, each with its figure. The scripts did the data work; the model did the judgment; neither is rebuilt next week.](https://plexara.io/learning/automations/scripts-as-skills-the-weekly-review) [Integration Two front doors, one governed surface Plexara exposes the same governed surface through an MCP server and a REST API. SDKs connect to both, custom tools extend it, and every path shares one identity, one audit log, and one persona model.](https://plexara.io/learning/insights/the-developer-surface) --- # Why more tools won't make your agent smarter URL: https://plexara.io/learning/insights/why-more-tools-wont-make-your-agent-smarter/ > An agent with fifty tools and no context is a confident intern with root access. Capability scales with understanding of the data, not connector count. Field notes / philosophy Apr 3, 2026 ## Why more tools won't make your agent smarter An agent with fifty tools and no context is a confident intern with root access. Capability scales with understanding of the data, not connector count. 8-minute read Philosophy On this page ### Counting tools is the wrong instinct Most teams adding an AI agent to their data stack start by counting tools. Connect the warehouse, connect the CRM, connect the orchestration layer, wire in a few more endpoints, and the assumption is that capability scales with the number of integrations. It does not. A year of agent deployments has made the failure mode clear: an agent with fifty tools and no context is a confident intern with root access and no idea what anything means. The agent has access. What it lacks is understanding. An agent can hold a perfectly valid connection to your sales index and still produce a number that is wrong by an order of magnitude, because nobody told it that the amount field is stored in cents, that test transactions are tagged a certain way and must be excluded, or that a particular table was deprecated eighteen months ago and only looks authoritative. The tool worked. The query ran. The answer was garbage. No amount of additional tools fixes that. The missing piece is [knowledge about the data the tools touch](https://plexara.io/learning/insights/context-gap-in-ai-data-access). This is the distinction Plexara has been built around from the start. The product is a context layer. The central question it answers for an agent is not "what can I call" but "where does the data live, what does it mean, how did it get here, and what has the organization already learned about it." ### The cost of context-free tooling Consider what context-free actually looks like in production. A public media organization we work with runs more than ten distinct API connections feeding a single analytics platform: a fundraising and CRM system, an email engagement platform, an events and guest-list system, a business-intelligence cloud, a file-sync service, the orchestration engine that moves data between all of them, and the cluster substrate underneath. That is before you reach the warehouse, the search indices, and the catalog. Hand a raw agent that environment and the failure is quiet and expensive. The agent picks a plausible-looking table, joins on the obvious key instead of the correct one, misreads a field, and hands back an answer that is interpretable, professional, and false. The reviewer who could have caught it was the reason you wanted the agent in the first place. You have automated the production of mistakes that look like insights. The instinct is to respond by adding guardrails per task: a prompt that explains the join key here, a note about the deprecated table there. That works until the next question, the next dataset, the next analyst. It does not compound. Every correction lives and dies inside one conversation. The organization learns nothing. ### Context as the primary asset Plexara treats the understanding of your data as the asset worth accumulating, ahead of any individual integration. Three mechanisms make that real. First, the agent always knows where data lives and what it means before it queries. Connections are registered with their semantics attached, and a [versioned catalog layer](https://plexara.io/learning/insights/versioned-api-catalogs) carries descriptions, ownership, lineage, and business glossary terms. When the agent reaches for a table, the meaning of that table arrives with it. The join-key correction, the cents-versus-dollars rule, the deprecation flag: these are catalog facts, not things the agent has to rediscover or be told again. Second, insights are captured as they are discovered. When an analyst corrects an interpretation, or the agent figures out through exploration that a column is in cents based on its value distribution, that finding is recorded against the specific dataset it concerns. It does not evaporate at the end of the session. The next agent, the next analyst, the next question inherits it. Third, knowledge synthesizes over time. Captured insights are reviewed and [written back into the catalog](https://plexara.io/learning/insights/knowledge-application-turns-usage-into-documentation), so the platform's understanding of the data improves continuously rather than resetting with each conversation. The system is designed so that if someone teaches it something important once, no one should ever have to teach it the same thing again. That last property is the one that matters most to anyone funding this. The value of a context-first platform appreciates. Every analyst-hour spent correcting and refining is deposited into an asset the whole organization draws on, instead of being spent and lost. ### What this means for the decision If you are evaluating agent platforms by counting connectors, you are measuring the wrong axis. Connectors are necessary and they are also the commodity part. Any platform can list integrations. The questions that separate a system that compounds value from one that quietly manufactures expensive mistakes are different. When the agent touches a dataset, does the meaning of that data arrive with it, or does the agent guess? When someone corrects the agent, does the correction persist and propagate, or does it die with the conversation? Does the platform understanding of your data improve month over month, or start from zero every morning? Tools determine what an agent can reach. Context determines whether what it reaches back with is true, and that is where the durable value lives. In the next piece, we look at what happens when the [context layer spans the whole stack](https://plexara.io/learning/insights/when-an-agent-can-see-the-whole-stack), not just your warehouse but the operational substrate underneath it: the orchestration engine, the cluster, the remote sources and destinations. An agent with that view can trace a number on a dashboard back through the pipeline that produced it and explain why it changed. Further Reading - [TaskBench: Benchmarking Large Language Models for Task Automation Yongliang Shen, Kaitao Song, Xu Tan, Wenqi Zhang, Kan Ren, Siyu Yuan, Weiming Lu, Dongsheng Li, Yueting Zhuang · 2023 NeurIPS 2024 benchmark showing LLM task-automation accuracy on its 'Tool Graph' falls sharply as the number of tools grows, from 96.16% on single-node tasks to 39.31% at 6 tools and 25.00% at 8 tools.](https://arxiv.org/abs/2311.18760) - [Semantic Layers for Reliable LLM-Powered Data Analytics: A Paired Benchmark of Accuracy and Hallucination Across Three Frontier Models Michael Rumiantsau and Ivan Fokeev · 2026 Paired benchmark across three frontier models showing that supplying explicit business semantics (measures, conventions, disambiguation rules) alongside the schema raises query accuracy by 17 to 23 percentage points and suppresses the dominant class of confident-but-wrong answers.](https://arxiv.org/abs/2604.25149) - [A Survey on Hallucination in Large Language Models: Principles, Taxonomy, Challenges, and Open Questions Lei Huang, Weijiang Yu, Weitao Ma, Weihong Zhong, Zhangyin Feng, Haotian Wang, Qianglong Chen, Weihua Peng, Xiaocheng Feng, Bing Qin, Ting Liu · 2023 Comprehensive survey establishing that LLMs are prone to generating plausible-sounding yet nonfactual, ungrounded content, with extrinsic hallucinations producing fluent output unsupported by the input.](https://arxiv.org/pdf/2311.05232) - [Memory for Autonomous LLM Agents: Mechanisms, Evaluation, and Emerging Frontiers Pengfei Du · 2026 Survey establishing that LLMs are fundamentally stateless with knowledge bounded by the context window, so corrections and learned context are lost between sessions unless an external memory mechanism persists, organizes, and recalls them across interactions.](https://arxiv.org/html/2603.07670v1) On this page [Previous Meeting enterprise systems where they are](https://plexara.io/learning/insights/enterprise-authentication-and-isolation) [Next Why an agent needs a versioned API catalog](https://plexara.io/learning/insights/versioned-api-catalogs) ### Related reading philosophy [Philosophy 101 - What is a Large Language Model? LLMs predict the next token from patterns learned across trillions of training examples. What that means, why it produces fluent reasoning, and its limits.](https://plexara.io/learning/ai-concepts/what-is-a-large-language-model) [Philosophy 104 - Frontier models, specialized models, and why enterprise AI uses both Frontier models bring world knowledge; small local embedding models power memory and catalog search. Knowing each role designs AI systems that work.](https://plexara.io/learning/ai-concepts/frontier-models-explained) [Philosophy 401 - Prompts are the new SOPs You work with the agent for an hour to get one report exactly right, with a year-over-year cut, holiday annotations, and storm-closure markers. The agent saves durable business knowledge on its own. But that specialized report is not institutional knowledge, it is a procedure. This article draws the line between the two, and makes the case that a saved prompt is the standard operating procedure for an AI-run job.](https://plexara.io/learning/prompts/prompts-are-the-new-sops) --- # Why an agent needs a versioned API catalog URL: https://plexara.io/learning/insights/versioned-api-catalogs/ > Pointing an agent at an API is the easy part. Making it dependable when the API changes, returns surprises, or needs a second credential is the hard part. A versioned catalog is what turns a connection into something you can rely on. Field notes / integration Mar 26, 2026 ## Why an agent needs a versioned API catalog Pointing an agent at an API is the easy part. Making it dependable when the API changes, returns surprises, or needs a second credential is the hard part. A versioned catalog is what turns a connection into something you can rely on. 6-minute read Integration On this page ### Connecting is the easy twenty percent Giving an agent the ability to call an external API is a short demo. You hand it a base URL and a credential, and it makes a request. The hard part is everything after that first successful call: what happens when the API has hundreds of operations, when its description is imprecise, when it changes next month, or when it returns something the agent did not expect. An agent that rediscovers an API shape on every request is both slow and fragile. It spends tokens relearning what is available and breaks the moment the API drifts from what it assumed. Reliability comes from giving the agent a stable, structured understanding of the API to reason against, rather than making it improvise each time. ### A versioned catalog the agent can reason about Plexara gives each connected API a versioned catalog: a structured record of its operations and their inputs that the agent can consult instead of reverse-engineering the API live. Because it is versioned, the agent reasons against a known shape, and changes to the API are something the catalog absorbs rather than something that quietly breaks behavior. The catalog also accommodates the realities of production APIs. It handles operations that require a second credential header beyond the primary authentication, and it tolerates the imperfections and inconsistencies common in real-world API descriptions, rather than assuming every provider published a flawless specification. This is what lets the agent [keep a small, fixed set of tools](https://plexara.io/learning/insights/why-more-tools-wont-make-your-agent-smarter) while reaching an unbounded number of operations. The tools traverse the catalog; the catalog holds the detail. Adding an API adds entries to the catalog, not weight to the agent. [Image: The API Catalogs admin screen with a Salesforce REST API catalog selected from a list that also holds GitHub and Stripe catalogs: the detail shows the catalog identifier, a version badge, how many connections reference it, a description, and a Component specs table where each spec reports its source, an indexed operation count, and when it was fetched, under a notice that all specs are indexed and semantic ranking is active.] The versioned catalog itself. Each catalog carries a version, can back several connections, and is made of component specs whose operations are indexed for the intent-based search covered below. [Image: The Add component spec dialog: a spec name field, tabs to paste, upload, or fetch an OpenAPI description from a URL, a text area holding the beginning of a pasted specification, an optional base path field set to /v1 with an explanation for when the description ships without a server entry, and an optional title field.] Adding a spec to a catalog. The optional base path is one of the accommodations mentioned above: when a provider's description leaves out its server address or pins the wrong one, an admin sets the prefix here instead of editing the specification itself. ### Search operations by intent, not exact words A large API can expose hundreds of operations. Finding the right one by exact keyword is the same losing game as finding a tool by exact name. The agent should be able to [ask for the capability it needs](https://plexara.io/learning/insights/search-the-capability-not-the-manual) and get the operation that provides it, even when the naming does not match. Plexara ranks API operations by intent, so the agent locates the operation that does what it means rather than the one whose name happens to contain the search term. The agent describes the goal; the catalog returns the operation that meets it. ### Reliability is what makes it production-grade Alongside the catalog, sign-in became more dependable: automatic token refresh before expiry, a clear history of [authentication events](https://plexara.io/learning/insights/enterprise-authentication-and-isolation), and better errors when something is wrong. These are the details that separate a connection that works once from one you can leave running. A versioned catalog, intent-based operation search, and reliable sign-in all serve the same goal: making the agent use of an external API predictable enough to run against real systems unattended. Further Reading - [Code execution with MCP: Building more efficient agents Anthropic (Adam Jones and Conor Kelly) · 2025 Anthropic's engineering team documents that loading all MCP tool definitions upfront occupies context-window space, increases cost and latency (hundreds of thousands of tokens before reading a request), and that loading only needed tools on demand cut one example from 150,000 to 2,000 tokens.](https://www.anthropic.com/engineering/code-execution-with-mcp) - [Gorilla: Large Language Model Connected with Massive APIs Shishir G. Patil, Tianjun Zhang, Xin Wang, Joseph E. Gonzalez · 2023 NeurIPS 2024 paper showing LLMs tend to hallucinate incorrect API usage, and that retriever-aware training lets a model adapt to test-time API changes such as version evolution and argument changes.](https://arxiv.org/abs/2305.15334) - [ToolLLM: Facilitating Large Language Models to Master 16000+ Real-world APIs Yujia Qin, Shihao Liang, Yining Ye, et al. · 2023 ICLR 2024 paper that collects 16,464 real-world RESTful APIs and equips the model with a neural API retriever that recommends appropriate APIs per instruction instead of exposing the full catalog, demonstrating semantic/intent-based retrieval over large real-world API sets.](https://arxiv.org/abs/2307.16789) - [Semantic Tool Discovery for Large Language Models: A Vector-Based Approach to MCP Tool Selection Sarat Mudunuri, Jian Wan, Ally Qin, Srinivasan Manoharan · 2026 Describes a vector-based retrieval architecture that indexes tools with dense embeddings capturing the relationship between tool capability and user intent, selecting only the few most relevant tools rather than exposing the entire catalog, with large reductions in tool-related token consumption.](https://arxiv.org/abs/2603.20313) On this page [Previous Why more tools won't make your agent smarter](https://plexara.io/learning/insights/why-more-tools-wont-make-your-agent-smarter) [Next Why proximity matters: tools, meaning, and memory belong together](https://plexara.io/learning/insights/why-proximity-matters-tools-meaning-memory) ### Related reading integration [Integration 110 - Is MCP just an API wrapper? MCP is not a replacement for your APIs and not a thin proxy. It is an application layer on top, like a website is an application layer on top of its APIs.](https://plexara.io/learning/ai-concepts/mcp-vs-apis) [Integration 606 - Scripts as skills: the weekly review the agent runs on your business The capstone. Three scripts (category velocity, the supplier quote margin review, regional weather context) attached to one prompt, so serving the prompt carries each script’s contract and last successful output and the agent runs them for fresh numbers instead of re-deriving them. The agent then reads the outputs against the seasonality calendar, the returns policy, the store formats, and the stock health bands, and produces the week’s action items: promote, discount, discontinue or renegotiate, watch, each with its figure. The scripts did the data work; the model did the judgment; neither is rebuilt next week.](https://plexara.io/learning/automations/scripts-as-skills-the-weekly-review) [Integration Two front doors, one governed surface Plexara exposes the same governed surface through an MCP server and a REST API. SDKs connect to both, custom tools extend it, and every path shares one identity, one audit log, and one persona model.](https://plexara.io/learning/insights/the-developer-surface) --- # Why proximity matters: tools, meaning, and memory belong together URL: https://plexara.io/learning/insights/why-proximity-matters-tools-meaning-memory/ > Most AI agent stacks are gateways wrapped in auth. The hard work is not routing tool calls; it is making sure context arrives with them. Field notes / architecture Mar 17, 2026 ## Why proximity matters: tools, meaning, and memory belong together Most AI agent stacks are gateways wrapped in auth. The hard work is not routing tool calls; it is making sure context arrives with them. 12-minute read Architecture On this page ### The integration thesis An AI agent operating against enterprise data needs three things to be useful. It needs tools, so it can act. It needs meaning, so it knows what its actions return. It needs memory, so the next agent in its place inherits what the last one figured out. The naive stack treats these as three separate problems solved by three separate products: a gateway for tools, a catalog for meaning, a memory store for state. The integrated stack treats them as one problem solved at one layer. Plexara is built around the second view. The MCP envelope that carries a tool call to a backend system also carries the catalog context that explains the response and the knowledge captured from the last hundred sessions that asked something similar. The agent does not have to ask for context; context arrives with the call. The agent does not have to consult a memory store; memory has already shaped the response. Tools, meaning, and memory share the same envelope. This article argues why that proximity matters. Not as a vendor claim, but as a sequence of concrete consequences for hallucination rates, latency budgets, audit posture, and adoption gradients. The thesis is simple. Co-locating tools, meaning, and memory inside one MCP envelope produces an agent that is qualitatively different from a tool-caller wrapped in auth. ### Tools without context hallucinate Most AI agent platforms today are gateway products. They authenticate the agent, route tool calls to backend systems, and return whatever the backend returned. The agent gets the rows but not the meaning of the columns. It gets the response but not the provenance. It does not know that the customer_id field is a foreign key to a deprecated schema, or that the price column is denominated in cents and not dollars, or that the row count it just retrieved excludes a tenant that was migrated last quarter. In this configuration, the agent has to guess. The model is good at guessing, but enterprise data is full of hidden landmines that no amount of training can prepare it for: tribal naming conventions, soft-deleted records, business rules encoded in trigger logic, columns whose semantics changed three years ago when an integration was rewritten. An agent without semantic grounding produces queries that look right but compute the wrong number. The fix is not a smarter model, and it is not [more tools](https://plexara.io/learning/insights/why-more-tools-wont-make-your-agent-smarter). The fix is making sure the response includes what the response means. A tool call that returns a table should also return the catalog metadata for that table: ownership, sensitivity classification, deprecation status, glossary terms applied to each column, recent changes from the last data contract revision. The agent reasons about an enriched response, not a bare one. Hallucination drops because the floor of available context is higher. ### Context without action is academic The mirror failure mode is a catalog the agent can read but not act on. Some enterprises have invested heavily in metadata catalogs, glossaries, and data contracts. The catalog is rich. The agent can browse it. What the agent cannot do is execute a query against the data described by the catalog. The catalog and the execution engine live in different products, with different auth, different APIs, and different latency budgets. The agent ends up doing five hops to answer one question, three of them metadata and two of them data. This is the gateway problem in reverse. A pure gateway gives the agent action without context. A pure catalog gives the agent context without action. Neither is autonomous. Both require the agent to do orchestration work that should be a property of the platform. Plexara puts both in the same envelope: the catalog context that describes a dataset arrives with the data when the agent queries it. There is no separate catalog round trip. The action and the context fuse at the protocol layer. ### The latency tax of separate products Latency is the easiest number to put on the proximity argument. Suppose an agent answers a single business question by calling one query tool. In a separate-product stack the agent has to coordinate at least three round trips: one to the gateway to call the query tool, one to the catalog to fetch metadata for the result, one to the memory store to retrieve any prior knowledge about how this question has been answered before. Each round trip is a network hop, a [token-budget burn](https://plexara.io/learning/insights/token-efficiency-in-enterprise-mcp), and an opportunity for the orchestration to fail. In the integrated stack the same question is one round trip. The agent calls the tool. The response includes the catalog context and the applied knowledge. The agent reasons over the unified payload. Three round trips become one, three sets of credentials become one, three potential failure modes become one. At the scale of autonomous agents running thousands of questions per day, that integration decides whether the system is feasible at all. The latency math is also why bolting a gateway in front of a separate catalog and memory product never quite works. The gateway can authenticate and route, but it cannot atomically merge the responses from three independent backends without becoming an integration platform itself. The hard part of the integration is not auth. The hard part is fusing the responses at the protocol layer with consistent semantics. That is application logic, and it does not live at the gateway tier. ### Knowledge closes the loop The third capability in the envelope is memory, but memory in the Plexara sense is more than a vector store of past conversations. It is the closed loop where corrections from one session improve responses in the next. An analyst tells an agent that a column it just queried is deprecated; that observation flows back through the governance workflow and lands in the catalog as an annotation. The next agent that queries the same column in any session, for any persona, sees the deprecation warning attached to the response automatically. In a separate-product stack this loop is broken. The memory store records that a given conversation flagged a deprecation, but the catalog never learns. The next agent has to re-discover the same fact. Tribal knowledge accumulates in conversation logs but never becomes [institutional knowledge that improves the catalog](https://plexara.io/learning/insights/knowledge-application-turns-usage-into-documentation). The platform does not improve with use; it merely accumulates a transcript. Plexara treats every tool call as potential training signal for the catalog. Knowledge captured during one session, once reviewed through governance, enriches the catalog, which enriches future tool calls. The platform improves with use because the loop is closed at the protocol layer, not at the application layer. This is what proximity buys: the feedback path is shorter than the gap between products. ### Trust boundaries belong at the tool-call layer Persona-based access control, PII flags, deprecation notices, ownership boundaries: these are governance concerns that exist as catalog metadata. In a separate-product stack, applying them to a tool call requires the agent to do the right post-hoc lookups. An analyst persona queries a sensitive table; the agent must remember to consult the catalog to discover that the table is sensitive, then redact accordingly. The governance is correct only if the agent is disciplined. Inside the Plexara envelope, [governance applies at the tool-call layer](https://plexara.io/learning/insights/governance-at-execution-time) automatically. The same response that carries the rows carries the persona-aware redaction, the PII flags applied to specific columns, the deprecation warning if the table should not be used for new analysis. The agent does not have to discover these constraints; they are properties of the response. Trust boundaries align with the unit of work. For regulated industries, that single record separates a defensible audit trail from a brittle one. An auditor asking whether the agent saw the PII flag at the moment of the query gets a single timestamped record showing exactly what the agent received. In a separate-product stack the same answer requires reconstructing across the gateway log, the catalog log, and the agent transcript, hoping the timestamps line up. Proximity is what makes that single record possible. ### Adoption gradient: existing investments get smarter A reasonable objection to the integrated thesis is that it sounds like a rip-and-replace platform. It is not. The two gateway capabilities, MCP Gateway and API Gateway, exist precisely to bring existing investments into the envelope without rewrite. The MCP Gateway pulls in any MCP-compatible server an organization already runs. The API Gateway pulls in any REST or GraphQL endpoint, with the same enrichment pipeline applied. Existing infrastructure does not get replaced; it gets enriched. This matters for the buying motion. A team can adopt Plexara as the connective tissue across what they have rather than as a replacement for it. The first agent the team deploys uses the API Gateway to reach an internal service that already exists. The response comes back enriched with catalog context and applied knowledge. The team did not rewrite the service. They added a layer that makes every call to it smarter. The adoption gradient also reverses a subtle assumption about agent platforms. Many platforms are built on the idea that agents need new tools written specifically for them. Plexara is built on the idea that agents should make better use of the tools that already exist. The MCP and API gateways are the path. The enrichment pipeline is the value. ### A four-capability map for senior data leaders A senior data leader evaluating an AI platform is usually asking four questions in some order. Will my agents hallucinate? Will I lose the tribal knowledge that lives in my analysts' heads? Can I integrate this with the data infrastructure I already paid for? Can I prove what the agent saw when something goes wrong? Each of these questions maps directly to one of the four capabilities in the Plexara envelope. Hallucination maps to semantic enrichment. Tribal knowledge maps to knowledge capture. Integration maps to the two gateways. Audit posture maps to the persona-aware governance proximity that comes with all of the above. The questions are not independent and the answers are not independent; the whole point of the integrated stack is that solving one problem requires the others to be in proximity. A vendor selling only a gateway, only a catalog, or only a memory store can answer one question well and the others poorly. A platform that puts all three in the same envelope answers them together because the answers depend on each other. That dependency is the moat. It is also why the integrated story is hard to copy by adding features to a single-capability product. ### When proximity matters most Proximity is a free lunch when you are answering one question with one tool. It is everything when you are running autonomous agents at scale, in regulated industries, across multi-team data estates that none of the agents have full mental models of. The harder the question, the more the agent has to lean on the platform rather than on the model. The more the agent leans on the platform, the more the gaps between separate products become the dominant failure mode. The bet behind Plexara is that the next phase of enterprise AI will be won by platforms that make existing models useful against existing data. The gateway-only architectures will get the easy questions right and the hard questions wrong. The integrated architectures will get the hard questions right because the hard questions require tools, meaning, and memory all at once. Plexara puts tools, meaning, and memory in one envelope: the query, the catalog context that explains its result, and the knowledge earlier sessions left behind, all in a single response. An agent working from that envelope answers hard questions in one round trip, carries its governance with it, and inherits everything the organization has already learned. Further Reading - [Introducing the Model Context Protocol Anthropic · 2024 Anthropic's official announcement establishes MCP as an open standard for connecting AI assistants to systems/data via a single protocol, replacing fragmented per-source integrations.](https://www.anthropic.com/news/model-context-protocol) - [A Survey on Hallucination in Large Language Models: Principles, Taxonomy, Challenges, and Open Questions Lei Huang, Weijiang Yu, Weitao Ma, Weihong Zhong, Zhangyin Feng, Haotian Wang, Qianglong Chen, Weihua Peng, Xiaocheng Feng, Bing Qin, Ting Liu · 2023 This peer-reviewed survey documents that LLMs hallucinate when they must produce outputs beyond their grounded knowledge and that supplying external knowledge/context is a primary mitigation.](https://arxiv.org/abs/2311.05232) - [Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks Patrick Lewis, Ethan Perez, Aleksandra Piktus, Fabio Petroni, Vladimir Karpukhin, Naman Goyal, Heinrich Küttler, Mike Lewis, Wen-tau Yih, Tim Rocktäschel, Sebastian Riedel, Douwe Kiela · 2020 The foundational RAG paper shows that conditioning generation on retrieved external (non-parametric) knowledge improves factual accuracy over relying on a model's parametric memory alone.](https://arxiv.org/abs/2005.11401) - [least privilege - Glossary | CSRC National Institute of Standards and Technology (NIST), Computer Security Resource Center (CSRC) · 2023 NIST defines least privilege as restricting each entity to the minimum access needed for its function, the canonical basis for persona/role-scoped access and redaction.](https://csrc.nist.gov/glossary/term/least_privilege) On this page [Previous Why an agent needs a versioned API catalog](https://plexara.io/learning/insights/versioned-api-catalogs) [Next The context gap in AI data access](https://plexara.io/learning/insights/context-gap-in-ai-data-access) ### Related reading architecture [Architecture 103 - Context, compression, and memory The context window is a model's working memory. Each session balances keeping, compressing, or clearing it. Plexara adds enterprise memory on top.](https://plexara.io/learning/ai-concepts/context-windows-and-tokens) [Architecture 201 - Anatomy of a Plexara MCP 201 shows what is actually in the box on a Plexara server: the tool inventory by toolkit, the four content layers, the interactive apps a tool result can carry, and the memory, knowledge, and governance underneath. This lesson is the map.](https://plexara.io/learning/mcp/what-is-an-mcp) [Architecture Five kinds of memory, and how each comes back A fact, an incident, a person, a link, and a habit are five different kinds of knowledge. Plexara stores each as its own dimension and recalls it the way that kind needs, which is what makes memory across sessions feel like memory rather than search.](https://plexara.io/learning/insights/five-kinds-of-memory) --- # The context gap in AI data access URL: https://plexara.io/learning/insights/context-gap-in-ai-data-access/ > AI agents can execute SQL, but without business context they generate inaccurate queries and untrustworthy results. Not a better model. Better context. Field notes / integration Mar 9, 2026 ## The context gap in AI data access AI agents can execute SQL, but without business context they generate inaccurate queries and untrustworthy results. Not a better model. Better context. 12-minute read Integration On this page ### The accuracy problem, quantified Give an AI agent access to a database and it will generate SQL. Give it access to the same database with business definitions, column descriptions, ownership records, glossary terms, and data quality signals, and it will generate accurate SQL. The difference is not marginal. Peer-reviewed research on the BIRD benchmark shows that semantic context improves text-to-SQL accuracy by up to 20 percentage points over schema-only approaches. This finding is consistent across production deployments. LinkedIn built its internal Trino chatbot on a foundation of knowledge graphs and semantic context, not just schema introspection. Every serious enterprise deployment of AI-powered data access has converged on the same architectural conclusion: schema is necessary but not sufficient. Gartner projects that 60 percent of agentic analytics projects relying solely on MCP without a semantic layer will fail by 2028. The prediction targets a specific failure mode: agents that can reach data but cannot understand what the data means. Evidence +20 pp Accuracy improvement from semantic context over schema-only text-to-SQL BIRD benchmark, peer-reviewed 60 % Agentic analytics projects on MCP without a semantic layer projected to fail Gartner, by 2028 12,751 Question/SQL pairs with explicit knowledge evidence in the BIRD evaluation set 95 databases Schema-only access is the dominant failure mode researchers are now measuring directly. ### Why schema is not enough A database schema tells an agent that a column named "amt" exists in a table called "txn_detail" with type DECIMAL(12,2). It does not tell the agent that "amt" represents gross transaction amount in cents, that it includes tax, that it should be divided by 100 for display, that it was renamed from "total_amount" in Q3 2025, or that the finance team considers it deprecated in favor of "net_amt" for revenue reporting. Without this context, the agent will use "amt" in queries where "net_amt" is correct. It will format the value in dollars instead of cents. It will join on tables that have been superseded. The queries will execute successfully and return plausible results. The results will be wrong. More sophisticated prompts do not compensate for missing business context. Retrieval-augmented generation helps only when the relevant documentation exists, is current, and is retrievable. In most enterprises, it is none of these things. The business context lives in the heads of experienced team members who learned it through years of working with the data. Schema vs. enriched response Schema-only response ``` { "table": "txn_detail", "columns": [ { "name": "amt", "type": "DECIMAL(12,2)" }, { "name": "created_at", "type": "TIMESTAMP" } ] } ``` - Is `amt` dollars or cents? - Does it include tax? Is it gross or net? - Is it the field you should be using at all? Plexara enriched response ``` { "table": "txn_detail", "description": "Line-item transactions", "owner": "finance-platform", "columns": [{ "name": "amt", "type": "DECIMAL(12,2)", "semantic": "Gross transaction (cents)", "includes_tax": true, "deprecated_for": "net_amt", "glossary": "gross_margin", "quality": 0.94 }] } ``` - Correct unit, correct aggregation, correct field. - Deprecation caught before the query runs. - One response, no additional catalog calls. The same tool call, with and without protocol-level enrichment. The agent sees the column; only the enriched version tells it what to do with it. ### What semantic enrichment adds Semantic enrichment delivers business context at the protocol level, before the agent makes decisions about how to query. When an agent describes a table through a query engine, the enriched response includes not just the schema but also column descriptions, data owners, classification tags, glossary term mappings, deprecation warnings, data quality scores, upstream and downstream lineage, and active incidents. This transforms the agent interaction from "here are the columns and their types" to "here are the columns, what they mean, who owns them, how they relate to business concepts, whether they are reliable, and what you should watch out for." The agent receives in a single response what would otherwise require four or more separate tool calls to a catalog, a quality monitoring system, an ownership registry, and a lineage tracker. The consolidation matters architecturally, beyond convenience. Every additional tool call [consumes tokens](https://plexara.io/learning/insights/token-efficiency-in-enterprise-mcp), increases latency, introduces failure modes, and requires the agent to synthesize information from disparate sources. A single enriched response eliminates these costs and gives the agent complete context every time. > Schema tells an agent what columns exist. Context tells it what they mean. Only the second one produces queries you can trust. > The thesis ### The cross-enrichment approach Bidirectional cross-enrichment is the mechanism that makes semantic enrichment practical at scale. When an agent queries through a SQL engine, metadata from the catalog is included in the response. When an agent searches the catalog, availability information from the query engine is included in the results. When an agent inspects an object in storage, catalog metadata about that object is included. Each service enriches responses from the others. This approach is fundamentally different from expecting agents to call multiple services and correlate the results. Correlation requires the agent to understand the relationship between services, to know which catalog entity corresponds to which query engine table, and to handle the case where metadata exists in one system but not another. Cross-enrichment handles all of this at the platform level, transparently. The enrichment is session-aware. Once business context for a dataset has been provided in a conversation, it is not repeated in subsequent responses within the same session. This deduplication further reduces token consumption without sacrificing context quality. Cross-enrichment Plexara 1 call enriched response Query engine schema + types Catalog descriptions + ownership Quality scores + incidents Lineage upstream + downstream Glossary business terms linked One enriched response replaces what would otherwise be four or more cross-service correlations. Deduplicated per session. ### Industry validation The BIRD benchmark, designed specifically to evaluate text-to-SQL with external knowledge, demonstrates that models with access to business definitions, value descriptions, and domain knowledge significantly outperform models working from schema alone. With 12,751 question-SQL pairs across 95 databases and explicit knowledge evidence, it is one of the most rigorous tests of context-aware SQL generation. Production architectures at scale reinforce this finding. Enterprise deployments that achieve reliable AI data access invariably include a semantic or context layer between the agent and the data. The specific implementation varies, but the architectural pattern is consistent: raw schema access produces unreliable results; contextually enriched access produces trustworthy ones. The market is recognizing this pattern. Catalog vendors, semantic layer vendors, and query engine vendors are all adding context delivery mechanisms. The debate has moved from whether context is necessary to how it should be delivered. The most efficient approach is enrichment at the protocol level: every response enriched automatically, no additional tool calls required, no agent-side correlation logic needed. A standalone catalog or [semantic layer bolted on as a point solution](https://plexara.io/learning/insights/why-point-solution-catalogs-are-not-enough) leaves the agent to do that correlation itself. ### The cost of getting it wrong An inaccurate query that executes successfully is more dangerous than one that fails. A failed query surfaces an error. An inaccurate query surfaces plausible-looking numbers that may inform decisions before anyone realizes they are wrong. In regulated industries, inaccurate data access can trigger compliance violations. In financial services, it can produce incorrect risk calculations. In healthcare, it can lead to flawed analyses of patient outcomes. The context gap compounds over time. Agents that generate inaccurate queries erode trust in AI-powered data access. Teams that lose trust in the results revert to manual processes, negating the investment in AI infrastructure. Gartner predicts that 50 percent of AI agent deployment failures by 2030 will stem from insufficient [governance enforcement at runtime](https://plexara.io/learning/insights/governance-at-execution-time), a failure mode that is closely linked to the absence of business context at the point of query execution. Closing the context gap is the prerequisite for trustworthy AI data access, and no model upgrade or prompt engineering substitutes for it. What closes it is better context, delivered automatically, at the protocol level, on every response: an agent that already knows what "amt" means before it writes the query. The bottom line #### The solution is not a better model. It is better context. An inaccurate query that executes successfully is more dangerous than one that fails. The failed one surfaces an error. The inaccurate one surfaces plausible numbers before anyone realizes they are wrong. Closing the context gap is the prerequisite for trustworthy AI data access, delivered automatically, at the protocol level, on every response. Further Reading - [Can LLM Already Serve as A Database Interface? A BIg Bench for Large-Scale Database Grounded Text-to-SQLs Jinyang Li, Binyuan Hui, Ge Qu, Jiaxi Yang, et al. · 2023 Peer-reviewed NeurIPS 2023 paper introducing the BIRD benchmark of 12,751 text-to-SQL pairs across 95 databases, showing that models given external knowledge (domain definitions, value illustrations) substantially outperform schema-only approaches.](https://arxiv.org/abs/2305.03111) - [Introducing the Model Context Protocol Anthropic · 2024 Official Anthropic announcement establishing MCP as an open protocol that delivers context and tools to AI agents at the protocol level, replacing fragmented per-source integrations.](https://www.anthropic.com/news/model-context-protocol) - [Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks Patrick Lewis, Ethan Perez, Aleksandra Piktus, Fabio Petroni, Vladimir Karpukhin, Naman Goyal, Heinrich Küttler, Mike Lewis, Wen-tau Yih, Tim Rocktäschel, Sebastian Riedel, Douwe Kiela · 2020 The foundational NeurIPS 2020 RAG paper showing that LLMs' factual accuracy improves only when relevant external knowledge is retrievable from a non-parametric memory, establishing that RAG's benefit is contingent on the existence and retrievability of the documentation.](https://arxiv.org/abs/2005.11401) On this page [Previous Why proximity matters: tools, meaning, and memory belong together](https://plexara.io/learning/insights/why-proximity-matters-tools-meaning-memory) [Next Protocols outlast products](https://plexara.io/learning/insights/protocols-outlast-products) ### Related reading integration [Integration 110 - Is MCP just an API wrapper? MCP is not a replacement for your APIs and not a thin proxy. It is an application layer on top, like a website is an application layer on top of its APIs.](https://plexara.io/learning/ai-concepts/mcp-vs-apis) [Integration 606 - Scripts as skills: the weekly review the agent runs on your business The capstone. Three scripts (category velocity, the supplier quote margin review, regional weather context) attached to one prompt, so serving the prompt carries each script’s contract and last successful output and the agent runs them for fresh numbers instead of re-deriving them. The agent then reads the outputs against the seasonality calendar, the returns policy, the store formats, and the stock health bands, and produces the week’s action items: promote, discount, discontinue or renegotiate, watch, each with its figure. The scripts did the data work; the model did the judgment; neither is rebuilt next week.](https://plexara.io/learning/automations/scripts-as-skills-the-weekly-review) [Integration Two front doors, one governed surface Plexara exposes the same governed surface through an MCP server and a REST API. SDKs connect to both, custom tools extend it, and every path shares one identity, one audit log, and one persona model.](https://plexara.io/learning/insights/the-developer-surface) --- # Protocols outlast products URL: https://plexara.io/learning/insights/protocols-outlast-products/ > MCP, Trino, and DataHub are open protocols with communities larger than any vendor. Building on protocols, not proprietary platforms, is the durable choice. Field notes / philosophy Feb 28, 2026 ## Protocols outlast products MCP, Trino, and DataHub are open protocols with communities larger than any vendor. Building on protocols, not proprietary platforms, is the durable choice. 10-minute read Philosophy On this page ### The protocol vs. product distinction SQL outlasted every proprietary query language. HTTP outlasted every proprietary network protocol. SMTP outlasted every proprietary messaging system. The pattern is consistent across five decades of computing: open protocols survive, proprietary alternatives get acquired, sunset, or abandoned. The economics drive the pattern. Protocols accumulate investment from many participants. Each implementation strengthens the ecosystem. Each integration raises the switching cost away from the protocol, not toward any single vendor. Products accumulate investment from one vendor. When that vendor changes strategy, gets acquired, or fails, every customer pays the re-platforming cost. Enterprise technology decisions made today will be evaluated against the same pattern. The AI infrastructure being built now will either rest on durable open standards or on proprietary foundations that will require replacement within a product cycle. Forty years of pattern 1. ##### SMTP 1982 Displaced MCI Mail, CompuServe mail, proprietary X.400 Closed messaging systems were absorbed into an open standard no one owned. 2. ##### HTTP 1989 Displaced Gopher, WAIS, proprietary on-line services The web won because HTTP was implementable by anyone; nothing else was. 3. ##### SQL 1986 Displaced QUEL, proprietary query DSLs Forty years in and SQL is still the lingua franca of data. Each vendor's DSL is not. 4. ##### MCP 2024 Live now Displaced Per-framework tool interfaces Before MCP, integrating a data source with each AI framework meant a separate project. Now it is one. Proprietary alternatives get acquired, sunset, or abandoned. Protocols accumulate investment from many participants until the cost of not supporting them exceeds the cost of supporting them. ### MCP as USB-C for AI The Model Context Protocol standardizes [how AI agents interact with external tools and data sources](https://plexara.io/learning/ai-concepts/mcp-vs-apis). Before MCP, every agent framework defined its own tool interface. Integrating a data source with Claude, GPT, Gemini, and Llama required four separate implementations. MCP collapses this to one. The analogy to USB-C is precise. Before USB-C, every device manufacturer chose its own connector. Users accumulated drawers full of incompatible cables. USB-C did not make better cables. It made cables interchangeable. MCP does the same for AI tool integration: any MCP-compatible client can connect to any MCP server. The client and server evolve independently. MCP adoption has grown from zero to tens of thousands of server implementations in under a year. Claude Desktop, Cursor, and custom agents built with SDKs in every major language all speak MCP. This adoption velocity matches historical patterns for protocols that reach critical mass. Once a protocol crosses the threshold where the cost of not supporting it exceeds the cost of supporting it, adoption accelerates and becomes self-reinforcing. The USB-C analogy AI Clients Claude Desktop Cursor Custom agent (Python) Custom agent (TS) MCP one protocol, any pair MCP Servers Plexara GitHub Filesystem Slack …thousands more MCP does not make better tool calls; it makes them interchangeable. Client and server evolve independently. ### Trino's federation model Trino federates SQL execution across data sources that were never designed to work together. A single query can join a PostgreSQL table with an Elasticsearch index, an Iceberg lakehouse, and a Cassandra cluster. Trino does not require data to be moved, copied, or transformed. It queries data where it lives. This federation model has a specific architectural consequence for AI agents: they do not need to know where data is physically stored. An agent writes standard SQL. Trino routes the query to the correct data source, executes it, and returns results in a uniform format. The agent interacts with one query engine [regardless of how many underlying data sources exist](https://plexara.io/learning/insights/when-an-agent-can-see-the-whole-stack). Trino supports over 40 connectors. It is used in production at scale by organizations that process petabytes of data daily. The connector ecosystem continues to expand because Trino is an open protocol with a permissive license: anyone can build a connector, and each new connector is available to every Trino user. Federation, not migration Agent standard SQL Trino federated execution PostgreSQL Iceberg Elasticsearch Cassandra Kafka S3 MySQL Snowflake …40+ A single SQL query can join a PostgreSQL table, an Iceberg lakehouse, an Elasticsearch index, and a Cassandra cluster. Data is queried where it lives. ### DataHub's metadata graph DataHub models metadata as a graph: entities (datasets, dashboards, users, glossary terms), relationships (lineage, ownership, containment), and aspects (schema, descriptions, tags, quality signals). This graph structure captures the full context of an enterprise data estate in a way that flat catalogs cannot. The graph model matters for AI agents because it supports traversal. An agent can start with a dataset, follow lineage to upstream sources, check quality signals on those sources, find the glossary terms that define the business concepts, and identify the data steward responsible for accuracy. This traversal provides the [deep context that prevents incorrect queries](https://plexara.io/learning/insights/context-gap-in-ai-data-access). DataHub is the most widely adopted open metadata platform, with contributions from organizations across industries. Its entity model is extensible: custom entity types, structured properties, and data contracts can capture domain-specific metadata without forking the platform. Building on DataHub means building on a metadata standard, not a vendor catalog. > Protocols accumulate investment from many participants. Products accumulate investment from one vendor. When that vendor changes strategy, every customer pays the re-platforming cost. > Economics, not philosophy ### Why each was chosen MCP was chosen because it is the only protocol-level standard for AI tool integration with meaningful adoption. Trino was chosen because it is the only open federated query engine that supports the breadth of data sources enterprises actually use. DataHub was chosen because it is the only open metadata platform with a graph model rich enough to support bidirectional semantic enrichment. Each choice was evaluated against proprietary alternatives. Proprietary query engines offer deeper integration with their own storage but cannot federate across sources from other vendors. Proprietary catalogs offer polished interfaces but lock metadata into closed ecosystems. Proprietary AI frameworks offer convenience but tie agents to specific model providers. The common thread is portability. An enterprise that builds on MCP, Trino, and DataHub can change its LLM provider without changing its data infrastructure. It can add new data sources without re-architecting its agent layer. It can replace any individual component without disrupting the others. This modularity is how enterprises survive technology transitions. The tradeoff Single-vendor stack ##### Built on proprietary products - Deep integration inside one ecosystem, breakdown at the edges - Connector surface area controlled by one vendor - AI assistant tied to vendor compute and semantic layer - Re-platforming cost on every strategic pivot MCP · Trino · DataHub ##### Built on open protocols - Change LLM providers without changing data infrastructure - Add data sources by adding a Trino connector - Replace any component without disrupting the others - Switching cost is paid toward the protocol, not the vendor ### What happens when you build on proprietary alternatives Every major data warehouse vendor has shipped an [AI assistant that works well within its own ecosystem](https://plexara.io/learning/insights/why-incumbent-ai-assistants-are-not-enough). They access the vendor catalog, they query the vendor compute engine, they use the vendor semantic layer. The integration is seamless because everything is controlled by one company. The problem emerges when the enterprise has data outside that ecosystem, which every enterprise does. A second warehouse, a legacy database, SaaS applications, object storage in a different cloud. The vendor assistant cannot reach this data. The enterprise now needs a second AI integration for the data outside the primary vendor, and a third for the data outside both. Each integration is proprietary, with its own configuration, its own security model, and its own limitations. Building on protocols avoids this fragmentation. A single MCP server connected to a federated query engine accesses all data sources through one interface. The security model is unified. The metadata is centralized. The agent experience is consistent. When the enterprise adds a new data source, it adds a Trino connector. The rest of the stack is unchanged. Strategic takeaway #### The modularity is not a theoretical benefit. It is how enterprises survive technology transitions. Every integration raises the switching cost away from the protocol, not toward any single vendor. Every MCP server makes every other MCP-compatible client more valuable. This is the pattern that produced SQL, HTTP, and SMTP, and it is now producing the open foundation for enterprise AI. Further Reading - [What is the Model Context Protocol (MCP)? Anthropic / Model Context Protocol project · 2025 Anthropic's official MCP documentation defines MCP as an open standard that works like a USB-C port for AI applications, providing a standardized way for AI clients to connect to external tools and data sources.](https://docs.anthropic.com/en/docs/mcp) - [Introducing the Model Context Protocol Anthropic · 2024 Anthropic's launch announcement establishes MCP as an open protocol creating a single standard to replace the prior need for separate, fragmented integrations between each AI model and each data source.](https://www.anthropic.com/news/model-context-protocol) - [Overview - Trino Documentation Trino Software Foundation · 2026 The official Trino docs define Trino as a distributed SQL query engine designed to query large data sets distributed over one or more heterogeneous data sources, querying data where it lives via connectors rather than moving it.](https://trino.io/docs/current/overview.html) - [The Metadata Model | DataHub DataHub Project · 2025 DataHub's official metadata-model documentation describes the Metadata Graph as composed of Entities, Aspects, and Relationships, and explicitly supports querying via relationship traversal, matching the article's graph-traversal claim.](https://docs.datahub.com/docs/metadata-modeling/metadata-model) On this page [Previous The context gap in AI data access](https://plexara.io/learning/insights/context-gap-in-ai-data-access) [Next How knowledge application turns usage into documentation](https://plexara.io/learning/insights/knowledge-application-turns-usage-into-documentation) ### Related reading philosophy [Philosophy 101 - What is a Large Language Model? LLMs predict the next token from patterns learned across trillions of training examples. What that means, why it produces fluent reasoning, and its limits.](https://plexara.io/learning/ai-concepts/what-is-a-large-language-model) [Philosophy 104 - Frontier models, specialized models, and why enterprise AI uses both Frontier models bring world knowledge; small local embedding models power memory and catalog search. Knowing each role designs AI systems that work.](https://plexara.io/learning/ai-concepts/frontier-models-explained) [Philosophy 401 - Prompts are the new SOPs You work with the agent for an hour to get one report exactly right, with a year-over-year cut, holiday annotations, and storm-closure markers. The agent saves durable business knowledge on its own. But that specialized report is not institutional knowledge, it is a procedure. This article draws the line between the two, and makes the case that a saved prompt is the standard operating procedure for an AI-run job.](https://plexara.io/learning/prompts/prompts-are-the-new-sops) --- # How knowledge application turns usage into documentation URL: https://plexara.io/learning/insights/knowledge-application-turns-usage-into-documentation/ > Most data catalogs are empty because documentation is a separate task. Plexara inverts this: documentation happens as a byproduct of people using data. Field notes / product Feb 20, 2026 ## How knowledge application turns usage into documentation Most data catalogs are empty because documentation is a separate task. Plexara inverts this: documentation happens as a byproduct of people using data. 11-minute read Product On this page ### Why catalogs stay empty Every enterprise has a data catalog. Most of them are empty. The tables are registered, the schemas are synced, and the descriptions are blank. Column-level documentation hovers near zero percent coverage. Glossary terms exist but are not linked to the datasets they define. Ownership records are stale. This is not a tooling failure. The catalog products are capable. The failure is structural: documentation is treated as a separate activity from data usage. A data engineer who discovers that a column represents gross margin in cents has no mechanism to record that discovery at the point of discovery. Instead, the engineer is expected to open the catalog, find the correct entity, edit the column description, and save the change. This takes minutes for a single column. Multiply by thousands of undocumented columns across hundreds of datasets, and the backlog becomes permanent. The result is a catalog that is technically deployed and functionally vacant. AI agents that rely on this catalog for context receive empty descriptions and missing ownership records. The agents generate queries based on schema alone, reproducing the [accuracy problems that come from a missing context layer](https://plexara.io/learning/insights/context-gap-in-ai-data-access) that the catalog was supposed to solve. Starting state ~0 % Typical column-level documentation coverage in enterprise catalogs Industry observation 5→18 Documented columns in txn_detail before and after 30 days of normal usage with knowledge application Illustrative catalog entity 3 Capture sources feeding the review pipeline Users, agents, gap detection The failure is not tooling. It is structural: documentation has always been an activity separate from usage. ### Three capture sources Plexara captures knowledge from three sources, each addressing a different gap in catalog documentation. The first source is user-provided knowledge. When a user corrects an agent during a conversation ("that column is gross margin, not revenue" or "always filter on status=active for this table"), the correction is captured as a structured insight with the specific entity, the type of correction, and the suggested catalog change. The user does not need to open a separate tool or navigate to the catalog. The knowledge is captured in the flow of work. The second source is agent-discovered insights. When an agent queries data and observes patterns ("column amt appears to be in cents based on value ranges" or "this table has not been updated since January"), these observations are captured as lower-confidence insights flagged for human review. The agent does the analytical work; humans validate the conclusion. The third source is enrichment gaps. When the semantic enrichment middleware processes a tool response and finds missing metadata ("this table has no description," "12 columns have no documentation," "no owner is assigned"), the gap is recorded automatically. Over time, the gap log becomes a prioritized list of documentation debt, ranked by how frequently each undocumented entity is accessed. Three capture sources src 01 ##### User-provided A correction in the flow of work > "That column is gross margin, not revenue." Confidence: high src 02 ##### Agent-discovered Observed patterns flagged for review > "Column amt appears to be in cents based on value ranges." Confidence: medium src 03 ##### Enrichment gaps Missing metadata logged automatically > "Table has no description. 12 columns undocumented." Confidence: detected Each source addresses a different gap. Together they cover the full surface where organizational knowledge leaks away. ### The review pipeline Nothing writes to the catalog without human approval. This is a deliberate design decision. AI-generated documentation that bypasses human review accumulates errors that are difficult to detect and expensive to correct. The review pipeline ensures quality while minimizing the effort required from reviewers. Captured insights flow through four stages: capture, review, synthesis, and application. During capture, the insight is recorded with its source, confidence level, and suggested changes. During review, an administrator evaluates the insight for accuracy and relevance. During synthesis, related insights about the same entity are combined into cohesive documentation. During application, the approved changes are written to the catalog as a tracked changeset. Every changeset includes full provenance: which insights contributed, who approved the changes, and what the previous values were. Administrators can rollback any changeset to restore the prior state. This audit trail satisfies the same [governance requirements that apply at execution time](https://plexara.io/learning/insights/governance-at-execution-time) while giving teams confidence to approve changes knowing they are reversible. The review pipeline 1. Stage 01 Capture Source, confidence, suggested change 2. Stage 02 Review Administrator evaluates accuracy 3. Stage 03 Synthesize Related insights merged coherently 4. Stage 04 Apply Tracked changeset written to catalog Nothing writes to the catalog without human approval. Every changeset is rollback-able with full provenance. [Image: The Insights tab of the Knowledge area switched to the Review queue: summary cards for pending review, total insights, top category, and applied count, filters for status, category, confidence, and sort order, and a table of captured insights showing who captured each one, its category, a low, medium, or high confidence badge, the insight text, and a status of pending, approved, applied, rejected, or rolled back.] The review stage as a queue. Every row carries its source and a confidence level, and the status column shows the whole lifecycle at once: pending, approved, applied, rejected, and rolled back sit side by side, because a change written to the catalog can be undone from here. ### The maturity flywheel The knowledge application system creates a self-reinforcing cycle. Usage generates insights. Insights improve documentation. Better documentation improves agent accuracy. Better accuracy drives more usage. Each rotation of the cycle makes the data platform more valuable. This flywheel effect distinguishes knowledge application from one-time documentation initiatives. A documentation sprint produces a snapshot that begins decaying immediately. The knowledge application system produces documentation that improves continuously because it is connected to the ongoing activity of people using data. The rate of improvement is proportional to usage. Datasets that are queried frequently accumulate documentation faster. Columns that are discussed in conversations get descriptions sooner. Business terms that are explained to agents get linked to glossary entries. The documentation naturally prioritizes the data that matters most to the organization. Maturity flywheel Knowledge application Usage Insights Documentation Accuracy Datasets queried frequently accumulate documentation faster. The rate of improvement is proportional to usage. Each rotation makes the platform more valuable. ### Concrete before and after Consider a table called "txn_detail" with 24 columns. Before knowledge application: the table has no description, no column documentation, no linked glossary terms, and an owner record pointing to an employee who left the company two years ago. An agent querying this table relies entirely on column names and types to generate SQL. After 30 days of normal usage with knowledge application enabled: the table has a description generated from three user corrections synthesized during review. Eighteen of twenty-four columns have descriptions, sourced from user corrections (8), agent discoveries (6), and synthesis of multiple insights (4). Three glossary terms (gross margin, net revenue, transaction status) are linked. The owner record has been updated based on a user correction identifying the current steward. Six enrichment gap flags remain for columns that were not discussed during the period. No one ran a documentation initiative. No one assigned a documentation task. The catalog improved because people used the data, and the platform captured what they already knew. Concrete outcome Day 0: catalog entry txn_detail Day 30: same table txn_detail description (none) description Synthesized from 3 user corrections documented columns 0 / 24 documented columns 18 / 24 (8 user, 6 agent, 4 synth) glossary links 0 glossary links 3 (gross margin, net revenue, status) owner Former employee (2024) owner Current steward (updated) A single table, txn_detail, before and after 30 days of normal usage with knowledge application enabled. No one ran a documentation initiative. [Image: The Knowledge tab with Search All selected and the query revenue entered: source filter chips for catalog, knowledge pages, insights, memory, assets, and prompts, and grouped results showing two catalog datasets, two knowledge pages titled Revenue Definition and Fiscal Calendar, and a pending insight stating that loyalty points are not recognized as revenue.] What the accumulation looks like from the reading side. One search for a business term returns the catalog entries, the knowledge pages written about it, and an insight still in review, each labelled by where it came from and how far through the pipeline it has travelled. ### Why this capability is rare Building a knowledge application system requires control of both the execution layer and the metadata layer, the kind of reach a platform gets only when [an agent can see the whole stack](https://plexara.io/learning/insights/when-an-agent-can-see-the-whole-stack). A catalog vendor can build the review pipeline but cannot capture insights from query sessions because the catalog does not execute queries. A query engine vendor can capture observations from query patterns but cannot write documentation back to the catalog because the engine does not manage metadata. The knowledge application system works because the same platform that executes queries also manages the metadata catalog and provides the review workflow. Corrections captured during a Trino query session are written to DataHub through an admin pipeline hosted on the same platform. The architecture is vertically integrated by design. This vertical integration also explains why the feature cannot be replicated by stitching together point solutions. A separate capture tool, a separate review tool, and a separate catalog require three integration projects and continuous synchronization. The complexity is prohibitive, which is why most enterprises have a catalog and a query engine but not a knowledge feedback loop connecting them. Architectural consequence #### Vertical integration is not optional for this capability. A knowledge feedback loop requires control of the execution layer and the metadata layer. A catalog vendor cannot observe query sessions. A query engine vendor cannot write back to a catalog it does not own. That is why most enterprises have both a catalog and a query engine but no feedback loop connecting them, and why point solutions cannot replicate this by being stitched together. Further Reading - [SQLFixAgent: Towards Semantic-Accurate Text-to-SQL Parsing via Consistency-Enhanced Multi-Agent Collaboration Jipeng Cen, Jiaxin Liu, Zhixu Li, Jingjing Wang · 2024 Peer-reviewed-style arXiv paper establishing that LLMs readily generate grammatically valid SQL but frequently produce semantically inaccurate queries that execute smoothly yet return wrong results, causing user confusion.](https://arxiv.org/abs/2406.13408) - [Co-audit: tools to help humans double-check AI-generated content Andrew D. Gordon, Carina Negreanu, Jose Cambronero, Rasika Chakravarthy, Ian Drosos, Hao Fang, Bhaskar Mitra, Hannah Richardson, Advait Sarkar, Stephanie Simmons, Jack Williams, Ben Zorn · 2023 Microsoft Research paper arguing that as generative models produce complex outputs (code, tables, summaries), human auditing of that output is necessary wherever quality matters and errors are consequential.](https://arxiv.org/abs/2310.01297) - [A Comprehensive Survey of Retrieval-Augmented Generation (RAG): Evolution, Current Landscape and Future Directions Shailja Gupta, Rajesh Ranjan, Surya Narayan Singh · 2024 Survey establishing that combining retrieval of external knowledge with generative models enhances the factual accuracy of LLM outputs and addresses core LLM limitations.](https://arxiv.org/abs/2410.12837) On this page [Previous Protocols outlast products](https://plexara.io/learning/insights/protocols-outlast-products) [Next Governance at execution time vs. catalog time](https://plexara.io/learning/insights/governance-at-execution-time) ### Related reading product [Product 102 - Tokens and your budget Every LLM interaction is priced and rate-limited in tokens. What a token is, how much text fits a budget, and how to avoid wasting tokens on useful answers.](https://plexara.io/learning/ai-concepts/tokens-and-your-budget) [Product 105 - What is an AI agent? An AI agent is not a chatbot and not magic. It is a short loop (think, call-tool, observe, think again) on top of a language model. Mental model first.](https://plexara.io/learning/ai-concepts/what-is-an-ai-agent) [Product 202 - Your first day with Plexara A new Plexara user gets connected, sends a first question, and platform_info takes over. Walks through day one and how subsequent turns inherit context.](https://plexara.io/learning/mcp/first-engagement) --- # Governance at execution time vs. catalog time URL: https://plexara.io/learning/insights/governance-at-execution-time/ > Traditional governance creates policies in a catalog and hopes they are enforced. AI agents expose the gap. Closing it unifies governance with execution. Field notes / governance Feb 11, 2026 ## Governance at execution time vs. catalog time Traditional governance creates policies in a catalog and hopes they are enforced. AI agents expose the gap. Closing it unifies governance with execution. 11-minute read Governance On this page ### The catalog-execution gap A data catalog says this dataset contains PII. A column is tagged as "confidential." An ownership record identifies the data steward responsible for access decisions. A classification policy requires audit logging for every query against sensitive tables. These are governance policies, and in most enterprises they exist only in the catalog. The query engine that actually executes SQL against the data has no knowledge of these policies. It receives a query, checks database-level permissions, and returns results. Whether the query came from a junior analyst, a production pipeline, or an AI agent makes no difference to the query engine. The governance policies in the catalog and the access controls at the execution layer are disconnected systems maintained by different teams. This disconnection has always been a problem. AI agents make it a crisis. An agent can discover in the catalog that a dataset is classified as PII, then query it through a separate, ungoverned SQL connection. The catalog told the agent the data is sensitive. Nothing prevented the agent from accessing it. The gap Catalog ##### Knows the policies - • PII classification tags - • Ownership + stewards - • Access requirements - • Audit requirements The gap no shared enforcement Query engine ##### Executes queries - • DB-level permissions only - • No catalog awareness - • No classification check - • No audit correlation The catalog knows the policy. The query engine does not check the catalog before executing. Agents take the efficient path, which means straight through the gap. ### How agents exploit governance gaps AI agents are optimization engines. Given a goal and a set of available tools, they will find the most efficient path to results. If the most efficient path bypasses governance controls, the agent will take it. Nothing about that is malicious. Give an agent tools with inconsistent access controls and this is the predictable result. A typical multi-tool agent deployment includes an MCP server for the data catalog, a separate MCP server for the query engine, and possibly a third for object storage. The catalog MCP server enforces its own access controls. The query engine MCP server enforces different access controls. The agent can read metadata about datasets it cannot query, and it can query datasets it cannot see metadata for. The governance model has gaps at every seam between tools. Session-level consistency is another gap. An agent may check permissions at the start of a session but not on subsequent queries. It may verify that the user has access to a catalog entity but not verify that the same user has access to the underlying data through the query engine. These inconsistencies create windows where governance policies are not enforced. > AI agents are optimization engines. If the most efficient path bypasses governance controls, the agent will take it. This is not malicious. It is the predictable result of inconsistent access controls. > Why agents force the question ### The fail-closed model A fail-closed security model denies access when the system cannot determine whether access should be allowed. Missing credentials, expired tokens, unrecognized roles, and configuration errors all result in denial, never bypass. This is the opposite of the fail-open models common in development tools, where missing configuration defaults to full access. Fail-closed is the only viable security posture for AI agents accessing enterprise data. An agent that receives full access by default when authentication fails is an agent that will eventually access data it should not. The probability approaches certainty as the number of agents, sessions, and configuration changes increases. The fail-closed model extends to authorization. No persona assigned means zero tool access. The default state for a new user is no access. Access must be explicitly granted through persona configuration that maps identity provider roles to tool allow patterns. This [closed-by-default posture](https://plexara.io/learning/insights/closed-by-default-access) ensures that misconfiguration results in denied access, not unauthorized access. The only viable posture Typical dev default ##### Fail-open - Missing credentials default to full access - New users start with broad permissions - Config errors degrade to permissive behavior - Probability of breach approaches certainty at scale Plexara default ##### Fail-closed - Missing credentials produce denial - New users start with zero tool access - No persona assigned means no capability - Misconfiguration results in denied access, never unauthorized access Fail-open defaults are catastrophic with agents at scale. Misconfiguration must result in denial, never bypass. ### Persona-based tool filtering Persona configuration maps [roles from an identity provider](https://plexara.io/learning/insights/enterprise-authentication-and-isolation) to sets of allowed and denied tools. An analyst persona might allow all query and catalog read tools but deny write operations and administrative tools. A steward persona might allow catalog write tools but deny direct data query tools. An admin persona might allow everything. Tool filtering serves two purposes simultaneously. The first is security: agents operating under a persona cannot invoke tools outside their allow pattern. The second is efficiency: agents only see tools they are authorized to use. An analyst agent receives a tool list that includes query and catalog tools. It does not see admin tools, write tools, or tools for services the analyst role cannot access. Fewer visible tools means [fewer tokens consumed](https://plexara.io/learning/insights/token-efficiency-in-enterprise-mcp) by tool descriptions in the agent context window. The wildcard pattern syntax supports precise control. A pattern like "trino_*" allows all Trino tools. A pattern like "datahub_create" with deny precedence blocks catalog creation while allowing all other catalog operations. Deny rules take precedence over allow rules, enabling a pattern where broad access is granted and specific operations are excluded. Persona-based tool filtering Persona Allow Deny (precedence) Analyst `search` `fetch` `trino_query` `trino_describe_table` `*_write` `*_admin` Steward `datahub_*` `trino_describe_table` `trino_query` Admin `*` (none) Pattern-based allow/deny rules. Deny takes precedence. Agents only see tools their persona authorizes, which also reduces token overhead on every request. [Image: The Personas admin screen with the Data Engineer persona selected: an identity panel listing name, roles, and priority, allow patterns for trino_*, datahub_*, s3_*, and save_asset with one deny pattern below, and a live Permissions preview reporting 13 tools allowed and 4 denied, each row naming the pattern it matched.] The allow and deny lists in the matrix above are the left column of this screen. The preview on the right resolves them against every tool the platform exposes, so an admin sees which tools a persona will actually receive before saving, and the quick templates offer starting points such as read-only or analyst. ### Audit logging with full provenance Every tool call is logged with the user identity, the resolved persona, the connection used, the tool name, the parameters provided, the duration, and the outcome (success or failure). This audit trail captures not just what happened but who did it, under what authority, and through which data path. The audit log is stored in PostgreSQL with configurable retention. In regulated industries, retention requirements may extend to years. The log is queryable, enabling compliance teams to answer questions like "which users accessed this dataset in the last 90 days" or "how many queries did this agent execute against PII-classified tables" without parsing application logs. Audit logging at the platform level captures tool calls that would be invisible at the database level. A database log shows that a query was executed by a service account. The platform audit log shows which human user initiated the session, which persona they were operating under, which agent client they used, and which tool call triggered the query. This provenance chain is essential for regulatory compliance and incident investigation. Audit trail with provenance plexara.audit / 2026-04-21T14:03:22Z user “maya.patel@acme.com” persona “analyst” connection “acme-warehouse-prod” tool “trino_query” duration_ms “218” outcome “success” stored in PostgreSQL · queryable · retention configurable by policy Platform-level audit captures the provenance chain a database log cannot: which human, which persona, which agent client, which tool call. [Image: The Events tab of the admin dashboard, a table of tool calls listing timestamp, user, tool, and toolkit, with an Event Detail panel open on the right showing the user, resolved persona, tool, connection, duration, status, session, request and response sizes, the SQL parameters that were sent, and a Replay in Inspector button.] One row of the audit log opened in place. The panel holds the provenance chain described above: the human user, the persona they resolved to, the connection and tool, the exact parameters, and the outcome, with a Replay button for reproducing the call during an investigation. ### When governance and execution are unified When the governance layer and the execution layer are the same platform, enforcement is inherent rather than aspirational. A PII classification tag in the catalog directly affects which personas can query the tagged dataset. An ownership change in the catalog immediately updates who can approve access. A deprecation warning in the catalog surfaces in every query response for that dataset. Session-aware workflow enforcement adds a behavioral layer to governance. The platform tracks whether an agent called discovery tools before query tools, whether it checked for curated queries before writing SQL, and whether it verified data quality signals before returning results. Agents that skip required steps receive escalating warnings. This is not hard blocking but guided compliance that improves agent behavior over time. The alternative, governance in one system and execution in another, requires continuous synchronization between the systems, agreement on identity representation across systems, and monitoring to detect when policies are not being enforced. This synchronization overhead is the hidden cost of the [multi-vendor data stack](https://plexara.io/learning/insights/replacing-the-five-vendor-data-stack). Unifying governance and execution eliminates it. Unified, not aspirational #### When governance and execution are the same platform, enforcement is inherent. A classification tag in the catalog directly affects which personas can query the tagged dataset. An ownership change immediately updates who can approve access. A deprecation warning surfaces in every query response. The synchronization overhead of a multi-vendor stack simply disappears. Further Reading - [NIST SP 800-53 Rev. 5: Security and Privacy Controls for Information Systems and Organizations National Institute of Standards and Technology (NIST) · 2020 NIST's authoritative control catalog defines least privilege (AC-6) as authorizing only the access necessary for assigned tasks and applying it to processes acting on behalf of users, with default-deny configurations.](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) - [Specification gaming: the flip side of AI ingenuity Victoria Krakovna, Jonathan Uesato, Vladimir Mikulik, Matthew Rahtz, Tom Everitt, Ramana Kumar, Zac Kenton, Jan Leike, Shane Legg (Google DeepMind) · 2020 DeepMind documents that learning agents reliably exploit the literal specification of an objective and find unintended shortcuts to maximize reward without achieving the designer's intended goal.](https://deepmind.google/blog/specification-gaming-the-flip-side-of-ai-ingenuity/) - [Security Best Practices - Model Context Protocol Model Context Protocol (Anthropic / MCP project) · 2025 The MCP spec warns that without proper validation at the MCP server, downstream logs show only a generic service identity, making it impossible to distinguish which client/user acted and breaking incident investigation and auditing.](https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices) On this page [Previous How knowledge application turns usage into documentation](https://plexara.io/learning/insights/knowledge-application-turns-usage-into-documentation) [Next Token efficiency in enterprise MCP deployments](https://plexara.io/learning/insights/token-efficiency-in-enterprise-mcp) ### Related reading governance [Governance 403 - Sharing prompts, and closing the loop with feedback A procedure is only worth as much as the people who can run it. Plexara distributes a prompt two ways: a direct share to one teammate, or a promotion to a whole role or company through the admin review queue. A shared prompt is live, not a copy. Feedback threads then carry corrections back, with a validation step and a path into the knowledge catalog, and the deprecate-and-supersede lifecycle retires old versions cleanly.](https://plexara.io/learning/prompts/sharing-prompts-and-feedback) [Governance 505 - Next month’s file The new sheet arrives. Replacing the file’s content writes a new revision, and the registered table keeps reading the old one until it is registered again under the same name; the Scratch Tables page says so. This lesson covers the two cases that look alike and behave differently, moving the table forward, unregistering, what deleting the file does, saving the monthly procedure as a prompt, and the point at which a monthly file needs more than a join, which is where the 600 series begins.](https://plexara.io/learning/spreadsheets/next-months-file) [Governance 605 - What a run may do, and the record it leaves A run presents the roles its author held at the save, every call is authorized at that moment, and narrowing the persona takes effect on the next run. A save refuses a credential-shaped literal and source that does not parse. The dialect has no network, no filesystem, and no clock, so everything a script does is a platform call audited under the script’s own identity. The lifecycle from active to disabled, deprecated, and superseded; who sees what; ownership and an administrator’s transfer; and the administrator’s view of every script and every run.](https://plexara.io/learning/automations/what-a-run-may-do) --- # Token efficiency in enterprise MCP deployments URL: https://plexara.io/learning/insights/token-efficiency-in-enterprise-mcp/ > Most MCP implementations waste tokens through tool explosion, redundant metadata fetches, and repeated context. Three mechanisms eliminate these costs. Field notes / architecture Feb 3, 2026 ## Token efficiency in enterprise MCP deployments Most MCP implementations waste tokens through tool explosion, redundant metadata fetches, and repeated context. Three mechanisms eliminate these costs. 10-minute read Architecture On this page ### Quantifying token waste in typical MCP architectures A typical enterprise MCP deployment exposes dozens to hundreds of tools. Each tool carries a description, parameter schema, and usage instructions. These tool definitions are sent to the LLM on every request as part of the context window. A deployment with 80 tools can consume 15,000 to 25,000 [tokens](https://plexara.io/learning/ai-concepts/tokens-and-your-budget) in tool definitions alone, before the user has asked a question. Beyond tool definitions, agents make redundant metadata fetches. When an agent queries a table, it receives raw results. To understand the results, it calls the catalog for column descriptions. Then ownership. Then quality scores. Then deprecation status. Each call consumes tokens for the request, the response, and the agent reasoning about what to do next. A single "describe this table" workflow can consume 3,000 to 5,000 tokens across multiple round trips. Session-level waste compounds the problem. If an agent queries the same table twice in a conversation, it may re-fetch the same metadata. If it queries a related table, it may re-fetch overlapping context. Without session awareness, every interaction starts cold. Where the tokens go 15–25K Tokens consumed by tool definitions alone before the user asks anything Deployment with 80 tools 3–5K Tokens per describe-table workflow in a naive multi-call architecture Four-plus round trips 40–60 % Per-session token reduction with cross-enrichment, filtering, and dedup vs naive MCP deployment 380K Cumulative tokens saved per 20-exchange session by persona filtering alone 25K → 6K per request The compounding effect is the real story. A deployment that looks fine at one exchange bleeds at twenty. ### Cross-enrichment consolidation The first efficiency mechanism is cross-enrichment: enriching every tool response with [context from complementary services](https://plexara.io/learning/insights/why-proximity-matters-tools-meaning-memory). When an agent describes a table through Trino, the response includes DataHub metadata automatically. One enriched response does the work of five or more separate tool calls. The token savings are direct. Four tool calls averaging 800 tokens each (request + response + reasoning) consume 3,200 tokens. One enriched response consumes 1,200 tokens. The savings scale linearly with the number of tables and datasets an agent interacts with in a session. Cross-enrichment also eliminates the agent reasoning overhead between calls. Without enrichment, the agent must decide what additional context to fetch, formulate the request, interpret the response, and decide if more context is needed. With enrichment, the agent receives complete context in a single response and proceeds directly to answering the question. Naive vs. enriched token budget Naive multi-tool MCP Per-session budget: 65,000 tokens Tool definitions 25,000 tokens 80 tools, every request Round-trip chatter 16,000 tokens 4× describe/ownership/quality Redundant re-fetches 9,000 tokens No session awareness Work tokens 15,000 tokens Actual reasoning + answer Plexara enriched MCP Per-session budget: 26,000 tokens Tool definitions 6,000 tokens Filtered to analyst persona Enriched single calls 5,000 tokens One response, full context Dedup savings 0 tokens Suppressed repeats Work tokens 15,000 tokens Same answer, same model ### Tool visibility filtering The second mechanism is tool visibility filtering. [Persona-based access control](https://plexara.io/learning/insights/closed-by-default-access) determines which tools an agent can see, not just which tools it can call. An analyst persona might see 15 query and catalog tools. The same deployment might expose 60 tools total, but the analyst agent never receives the other 45 tool definitions. This reduces the tool definition overhead from 25,000 tokens to 6,000 tokens on every request. Over a session with 20 exchanges, the cumulative savings reach 380,000 tokens. At typical API pricing, this translates directly to reduced cost per session. Visibility filtering also improves agent accuracy. An agent with 15 relevant tools makes better tool selection decisions than one parsing 60 tool descriptions. Fewer options means less reasoning overhead and fewer incorrect tool selections that waste tokens on failed or irrelevant calls. Three mechanisms M01 At the response ##### Cross-enrichment Every tool response is enriched with context from complementary services. Four calls collapse to one. 3,200 → 1,200 tokens per describe flow M02 At the schema ##### Visibility filtering Persona-based access control determines which tools an agent can see, not just call. Unused tool descriptions never enter the context window. 25,000 → 6,000 tokens per request M03 Across the turn ##### Session dedup Metadata provided earlier in a conversation is not re-sent on subsequent calls against the same entity. Enrichment stays active, duplication is suppressed. Compounds with session length Each mechanism addresses a different source of waste. Together they produce sessions that accomplish more with fewer tokens. ### Session-aware deduplication The third mechanism is session-aware deduplication. The platform tracks which metadata context has been provided within a conversation. If an agent described a table earlier in the session, subsequent queries against that table do not re-send the same metadata. The enrichment is still active, but duplicated context is suppressed. Deduplication is particularly effective in exploratory sessions where an agent queries multiple tables in the same schema or follows lineage across related datasets. Overlapping metadata (shared owners, common tags, related glossary terms) is provided once and referenced subsequently. The combination of all three mechanisms reduces per-session token consumption by 40 to 60 percent compared to a naive multi-tool MCP deployment. For organizations running thousands of agent sessions per day, this represents a meaningful reduction in LLM API costs. > Fewer tools that return richer responses. A single describe-table tool returns schema, context, quality, ownership, lineage, and deprecation in one call. > The architectural choice ### Why fewer, richer tools outperform many narrow ones The MCP ecosystem trend is toward [tool proliferation](https://plexara.io/learning/insights/why-more-tools-wont-make-your-agent-smarter): one tool per API endpoint, resulting in MCP servers with 50 to 200 narrow tools. Each tool does one thing. The agent must orchestrate multiple tools to accomplish any useful task. Plexara takes the opposite approach: fewer tools that return richer responses. A single describe-table tool returns schema, business context, quality signals, ownership, lineage, and deprecation warnings. The agent receives everything it needs in one call and can proceed to answering the question. This architectural choice compounds. Fewer tools shrink the definition overhead paid on every request, and richer responses cut both the round trips and the reasoning the agent spends between them. That compounding is where the 40 to 60 percent per-session reduction comes from. Compounding efficiency #### Fewer tools, smaller overhead, fewer trips, less reasoning, better answers. The MCP ecosystem trend is toward tool proliferation. Plexara takes the opposite approach, because the compounding effect of rich tools is the difference between a session that accomplishes work and a session that burns its budget arguing with itself. Further Reading - [Lost in the Middle: How Language Models Use Long Contexts Nelson F. Liu, Kevin Lin, John Hewitt, Ashwin Paranjape, Michele Bevilacqua, Fabio Petroni, Percy Liang · 2023 Demonstrates that LLM performance degrades significantly as input context grows and relevant information is surrounded by additional content, supporting the value of suppressing redundant/duplicated context rather than re-sending it.](https://arxiv.org/abs/2307.03172) On this page [Previous Governance at execution time vs. catalog time](https://plexara.io/learning/insights/governance-at-execution-time) [Next Replacing the five-vendor data stack with one platform](https://plexara.io/learning/insights/replacing-the-five-vendor-data-stack) ### Related reading architecture [Architecture 103 - Context, compression, and memory The context window is a model's working memory. Each session balances keeping, compressing, or clearing it. Plexara adds enterprise memory on top.](https://plexara.io/learning/ai-concepts/context-windows-and-tokens) [Architecture 201 - Anatomy of a Plexara MCP 201 shows what is actually in the box on a Plexara server: the tool inventory by toolkit, the four content layers, the interactive apps a tool result can carry, and the memory, knowledge, and governance underneath. This lesson is the map.](https://plexara.io/learning/mcp/what-is-an-mcp) [Architecture Five kinds of memory, and how each comes back A fact, an incident, a person, a link, and a habit are five different kinds of knowledge. Plexara stores each as its own dimension and recalls it the way that kind needs, which is what makes memory across sessions feel like memory rather than search.](https://plexara.io/learning/insights/five-kinds-of-memory) --- # Replacing the five-vendor data stack with one platform URL: https://plexara.io/learning/insights/replacing-the-five-vendor-data-stack/ > The modern data stack costs $300K-$1M per year across 5+ products. Plexara consolidates catalog, query, governance, enrichment, and agent framework into one. Field notes / product Jan 25, 2026 ## Replacing the five-vendor data stack with one platform The modern data stack costs $300K-$1M per year across 5+ products. Plexara consolidates catalog, query, governance, enrichment, and agent framework into one. 9-minute read Product On this page ### The true cost of the modern data stack A mid-market enterprise running a modern data stack typically licenses a data catalog, a semantic layer, a query engine or warehouse, an observability platform, and a governance tool. Licensing alone runs $300K to $1M per year. The vendor count is five at minimum, often seven or eight after adding specialized tools for lineage, quality monitoring, and access management. Licensing is the visible cost. The hidden cost is integration engineering. Each vendor exposes its own API, its own data model, and its own authentication system. Connecting them requires custom integration code that must be maintained as each vendor releases updates. A single breaking API change in one vendor can cascade through the integration layer. Context synchronization is the third cost. When a data steward updates a column description in the catalog, that description does not automatically appear in the semantic layer, the query engine, or the governance tool. Each system maintains its own copy of metadata, and keeping them synchronized requires either manual effort or yet another integration. The visible cost 5+ Point products in a typical modern data stack Catalog + semantic + query + observability + governance $300K–$1M Annual licensing before integration engineering Mid-market range 20–40 % Data engineering capacity consumed by integration maintenance Self-reported from enterprise teams 1 Platform, fully managed, when the five products are replaced Plexara Licensing is the visible cost. Integration engineering and context synchronization are the hidden ones, and they are larger. ### What integration engineering actually costs Integration engineering is an ongoing tax on every team that touches data infrastructure. When the catalog vendor ships a new API version, the integration code must be updated. When the query engine adds a new connector, the semantic layer must learn about the new data sources. When the governance tool changes its policy format, the enforcement layer must adapt. Most enterprises estimate that 20 to 40 percent of their data engineering capacity is consumed by integration maintenance rather than building new capabilities. That is an architecture problem, and hiring cannot fix it. The more vendors in the stack, the more integration surface area, and the more engineering capacity consumed by glue code. The opportunity cost is equally significant. Engineers maintaining integrations are not building the data products, analytics pipelines, or AI capabilities that the business is asking for. The integration tax directly reduces the team velocity available for value-creating work. The engineering tax Where a data engineering week actually goes Average week: 40 hours Integration glue 16 hours Breaking APIs, reformatting, syncing Metadata sync 6 hours Keeping catalog/query/governance aligned On-call + incident 4 hours Debugging multi-vendor interactions Value work 14 hours New data products and analytics Integration maintenance is not a one-time cost. It is ongoing, reducing capacity for the work the business is actually asking for. ### Context fragmentation across point solutions Each vendor in the modern data stack has a partial view of the data estate. The catalog knows what data exists and what it means. The query engine knows how to access it. The governance tool knows who should have access. The semantic layer knows how business metrics are defined. No single system [sees the whole stack](https://plexara.io/learning/insights/when-an-agent-can-see-the-whole-stack) at once. When an AI agent needs to answer a business question, it must consult multiple systems and correlate their responses. The catalog says the table exists. The query engine says it is accessible. The governance tool says the user has permission. The semantic layer says the revenue metric uses a specific calculation. Each response comes from a different system with a different context window. This fragmentation is the root cause of [inaccurate AI data access](https://plexara.io/learning/insights/context-gap-in-ai-data-access). The agent assembles context from fragments, and any missing fragment produces an incomplete or incorrect answer. A complete answer requires complete context, and complete context requires a unified platform. The five-vendor constellation Before Stitched together Catalog Semantic layer Query engine Governance Observability integration tax After Composed in one platform Plexara one platform - Catalog - Semantic - Query - Governance - Enrichment - Agent framework Five services with five APIs, five auth models, five metadata stores. Each arrow is an integration project that has to be rebuilt whenever any vendor ships a breaking change. ### How Plexara consolidates Plexara replaces the five-vendor integration with a single platform that owns the full context. DataHub provides the catalog and semantic metadata. Trino provides federated query execution. Built-in governance provides access control and audit logging. Cross-enrichment provides semantic context. MCP provides the agent framework. The five capabilities ship as layers of one platform, composed through a shared middleware pipeline where each layer enriches the others. A query result carries catalog context. A catalog search result shows query engine availability. [Governance is enforced on every tool call](https://plexara.io/learning/insights/governance-at-execution-time), not as a separate check. The result is that an AI agent makes one tool call and receives a response that would have required five vendor consultations in the traditional stack. With one platform there is nothing to integrate and only one copy of context to keep current. What stays external Data sources PostgreSQL, Iceberg, Elastic, Kafka, S3: queried where they live LLM provider Claude, GPT, Gemini, Llama: bring your own BI tools Dashboards and reports can be exported to existing downstream tools Consolidation is opinionated, not totalizing. Your data sources, your model provider, and your BI tools remain yours. ### What remains external Plexara does not replace your data sources. PostgreSQL, MySQL, Elasticsearch, Iceberg, and every other system where data lives continues to operate as before. Trino federates queries to these sources without moving data. Plexara does not replace your LLM provider. You bring your own model. Claude, GPT, Gemini, Llama, or any other model that supports MCP can connect to Plexara. The platform governs the data layer, not the intelligence layer. Plexara does not replace your BI tools. Dashboards, reports, and visualizations generated through Plexara can be exported and consumed by any downstream tool. The Portal provides its own asset management, but it complements rather than replaces existing BI investments. Architectural consequence #### There is nothing to integrate, and one context instead of five. A query result carries catalog context. A catalog search shows query engine availability. Governance is enforced on every tool call, not as a separate check. The integration engineering is eliminated because nothing separate exists to stitch together. Further Reading - [Trino | Distributed SQL query engine for big data Trino Software Foundation · 2026 Official Trino project site states Trino runs federated queries across object storage, relational databases, and streaming/NoSQL systems in a single query without unnecessary data movement.](https://trino.io/) - [Introducing the Model Context Protocol Anthropic · 2024 Anthropic's official announcement defines MCP as an open standard for connecting AI assistants to the systems where data lives, replacing fragmented per-source integrations with a single protocol.](https://www.anthropic.com/news/model-context-protocol) - [What is DataHub? DataHub Project · 2026 DataHub's official documentation describes it as an open-source metadata platform providing data discovery, table/column-level lineage, governance, and semantic/business metadata across the data ecosystem.](https://docs.datahub.com/docs/features) On this page [Previous Token efficiency in enterprise MCP deployments](https://plexara.io/learning/insights/token-efficiency-in-enterprise-mcp) [Next Why MCP gateways are not enough](https://plexara.io/learning/insights/why-mcp-gateways-are-not-enough) ### Related reading product [Product 102 - Tokens and your budget Every LLM interaction is priced and rate-limited in tokens. What a token is, how much text fits a budget, and how to avoid wasting tokens on useful answers.](https://plexara.io/learning/ai-concepts/tokens-and-your-budget) [Product 105 - What is an AI agent? An AI agent is not a chatbot and not magic. It is a short loop (think, call-tool, observe, think again) on top of a language model. Mental model first.](https://plexara.io/learning/ai-concepts/what-is-an-ai-agent) [Product 202 - Your first day with Plexara A new Plexara user gets connected, sends a first question, and platform_info takes over. Walks through day one and how subsequent turns inherit context.](https://plexara.io/learning/mcp/first-engagement) --- # Why MCP gateways are not enough URL: https://plexara.io/learning/insights/why-mcp-gateways-are-not-enough/ > MCP gateways solve the plumbing problem but not the meaning problem. A gateway authenticates a tool call. It cannot tell you what the data means. Field notes / architecture Jan 17, 2026 ## Why MCP gateways are not enough MCP gateways solve the plumbing problem but not the meaning problem. A gateway authenticates a tool call. It cannot tell you what the data means. 9-minute read Architecture On this page ### What gateways do well MCP gateway products solve real infrastructure problems. They provide authentication and authorization for MCP traffic, routing tool calls to the correct backend server, rate limiting to prevent abuse, and observability into what agents are doing. Several well-funded startups have raised significant seed rounds building gateway products, and some have signed major enterprise accounts within months. The narrative is compelling and simple: gateways are "the Okta for AI agents." Enterprises need a control plane for MCP traffic, and gateways provide it. SOC 2 Type II certification, enterprise SSO integration, and usage dashboards make the products easy to evaluate and procure. These are legitimate capabilities. Every enterprise deploying MCP agents at scale needs authentication, routing, and observability. None of it, though, gets an agent any closer to understanding the data on the other side of the call. Layers of the stack Layer 03 L7 / intelligence Context enrichment Reads the content of tool responses, correlates across services, enriches with business meaning Layer 02 L7 / intelligence Session awareness Knows which entities have been discussed, dedupes metadata, tracks workflow compliance Layer 01 L4 / transport Gateway (auth, routing, rate limit, obs) Sees payloads as opaque. Knows the tool was called. Cannot know what the data means. Gateways sit at the transport layer. Semantic enrichment sits at the application layer. Conflating them leads to architectures that are well-plumbed but contextually impoverished. ### What gateways cannot do A gateway sees tool calls as opaque payloads. It knows that an agent called a tool named "describe_table" with a parameter "table_name." It authenticated the request, routed it to the correct MCP server, and logged the result. It does not know what the table contains, who owns it, whether it is deprecated, or how it connects to other datasets. A gateway cannot enrich the response with business context. When an agent queries a table through a gateway, the gateway passes the request through and returns the response unchanged. The agent still has no idea what the columns mean, whether the data is PII-classified, or what glossary terms apply. The response is as context-free leaving the gateway as it was entering. A gateway cannot correlate across services. It routes to the query engine or the catalog independently. It does not know that the table being queried in one call is the same entity being described in another. Cross-service correlation, the foundation of semantic enrichment, is architecturally impossible at the gateway layer. What the gateway sees Gateway view ``` POST /mcp HTTP/1.1 Authorization: Bearer *** X-Persona: analyst {"tool": "describe_table", "params": {"table": "txn_detail"}} ... opaque bytes ... ``` routed · authenticated · logged Plexara view - txn_detail is PII-classified; analyst persona may read - amt column is cents, deprecated for net_amt - Quality score 0.94; last refresh 2 hours ago - Dedup: full context sent once per session Authentication succeeded. Routing succeeded. Nothing else about the content is visible. ### Infrastructure layer, not data intelligence layer The distinction matters because the hard problems enterprises face with AI data access are [context problems](https://plexara.io/learning/insights/context-gap-in-ai-data-access). An agent that can authenticate and reach a database but cannot understand what the data means will generate inaccurate queries. No amount of gateway sophistication changes this. Gateways operate at the transport layer. They manage connections, credentials, and traffic. Semantic enrichment operates at the application layer. It understands the content of tool responses and augments them with [business meaning carried alongside the data](https://plexara.io/learning/insights/why-proximity-matters-tools-meaning-memory). These are different layers of the stack, and conflating them leads to architectures that are well-plumbed but contextually impoverished. None of this criticizes gateway products; it clarifies their scope. A gateway is to MCP what a load balancer is to HTTP: necessary infrastructure that does not replace the application logic behind it. > A gateway is to MCP what a load balancer is to HTTP: necessary infrastructure that does not replace the application logic behind it. > Layer clarity ### The commoditization trajectory Gateway features are commoditizing rapidly. Every major cloud provider is adding MCP routing and authentication to their existing API gateway products. Enterprise identity platforms are extending their agent governance features to cover MCP traffic. The standalone gateway category will face the same competitive pressure that standalone API gateways faced a decade ago. SOC 2 Type II certification, once a differentiator, is becoming table stakes. Enterprise SSO integration is a feature, not a product. Rate limiting and observability are infrastructure capabilities that cloud platforms absorb naturally. The competitive moat around gateway features is shallow and getting shallower. Context enrichment, by contrast, requires deep integration between query engines, metadata catalogs, and enrichment pipelines. It cannot be bolted on at the transport layer. The competitive moat around context is architectural: it requires controlling both the execution and the metadata, which gateway-only products do not. Commoditization trajectory Gateway moat depth: heading to zero Transport features commoditize quickly as hyperscalers absorb them. Context enrichment does not, because its moat is architectural, not positional. ### Where the layers meet Plexara and MCP gateways operate at different layers of the stack. A gateway manages MCP traffic. Plexara enriches it with business context. In theory, they are complementary. In practice, most gateway value is subsumed by a platform that already handles authentication, authorization, audit logging, and routing internally. An enterprise deploying Plexara gets gateway-level capabilities (authentication, [persona-based access control](https://plexara.io/learning/mcp/governance-personas-and-access), audit logging, connection routing) as built-in features of the platform. Adding a separate gateway in front of Plexara adds infrastructure complexity without adding context. The gateway sees Plexara as another MCP server to route to, unaware of the enrichment happening inside. The strategic question for enterprises is whether to invest in infrastructure that routes context-free traffic or in a platform that enriches every response with business meaning. Gateways solve the plumbing. Plexara delivers what the plumbing carries: every response an agent receives arrives with ownership, classification, glossary terms, and deprecation status attached. Strategic takeaway #### Plumbing or intelligence. Your agents will not pick. Plexara deployments get gateway-level capabilities, authentication, persona-based access, audit logging, routing, as built-in features of the platform. Adding a separate gateway adds complexity without adding context. The question for enterprises is whether to invest in infrastructure that routes context-free traffic or a platform that enriches every response with meaning. Further Reading - [Authorization Model Context Protocol (modelcontextprotocol.io) · 2025 The official MCP spec confirms authorization operates at the transport level via OAuth 2.1, with token-based access control, scopes, and least-privilege enforcement for tool calls between clients and servers.](https://modelcontextprotocol.io/specification/draft/basic/authorization) - [Can LLM Already Serve as A Database Interface? A BIg Bench for Large-Scale Database Grounded Text-to-SQLs Jinyang Li, Binyuan Hui, Ge Qu, Jiaxi Yang, et al. · 2023 On the BIRD benchmark, GPT-4 reaches 54.89% execution accuracy with curated external-knowledge/business-context evidence but falls to 34.88% without it, a roughly 20-point gap quantifying how much accurate querying depends on semantic context beyond reaching the database.](https://arxiv.org/abs/2305.03111) - [Next-Generation Database Interfaces: A Survey of LLM-based Text-to-SQL Zijin Hong, Zheng Yuan, Qinggang Zhang, Hao Chen, Junnan Dong, Feiran Huang, Xiao Huang · 2024 This peer-reviewed survey establishes that LLM text-to-SQL correctness hinges on database schema comprehension and metadata grounding alongside question understanding, and that incomplete schema/metadata context drives persistent semantic (not just syntactic) query errors.](https://arxiv.org/abs/2406.08426) On this page [Previous Replacing the five-vendor data stack with one platform](https://plexara.io/learning/insights/replacing-the-five-vendor-data-stack) [Next Why incumbent AI assistants are not enough](https://plexara.io/learning/insights/why-incumbent-ai-assistants-are-not-enough) ### Related reading architecture [Architecture 103 - Context, compression, and memory The context window is a model's working memory. Each session balances keeping, compressing, or clearing it. Plexara adds enterprise memory on top.](https://plexara.io/learning/ai-concepts/context-windows-and-tokens) [Architecture 201 - Anatomy of a Plexara MCP 201 shows what is actually in the box on a Plexara server: the tool inventory by toolkit, the four content layers, the interactive apps a tool result can carry, and the memory, knowledge, and governance underneath. This lesson is the map.](https://plexara.io/learning/mcp/what-is-an-mcp) [Architecture Five kinds of memory, and how each comes back A fact, an incident, a person, a link, and a habit are five different kinds of knowledge. Plexara stores each as its own dimension and recalls it the way that kind needs, which is what makes memory across sessions feel like memory rather than search.](https://plexara.io/learning/insights/five-kinds-of-memory) --- # Why incumbent AI assistants are not enough URL: https://plexara.io/learning/insights/why-incumbent-ai-assistants-are-not-enough/ > Every major warehouse vendor has an AI assistant. They work well within their own ecosystem. The problem is that your data does not live in one ecosystem. Field notes / philosophy Jan 8, 2026 ## Why incumbent AI assistants are not enough Every major warehouse vendor has an AI assistant. They work well within their own ecosystem. The problem is that your data does not live in one ecosystem. 10-minute read Philosophy On this page ### What incumbents offer Every major data warehouse and lakehouse vendor now has an AI assistant and MCP server support. These are deeply integrated with their own platforms. They access the vendor catalog, query the vendor compute engine, and use the vendor semantic layer. The integration is smooth because everything is controlled by one company. Some have the most mature managed MCP server implementations in the market. Others have comprehensive agent frameworks with supervisor agents for orchestration. At least one has signed a $200M AI partnership for model hosting. These are substantial products backed by substantial investment. For enterprises that keep all their data within a single vendor ecosystem, these AI assistants may be sufficient. The vendor assistant knows the catalog, understands the semantic layer, and can execute queries with full context. Within its own walls, the experience is compelling. The walled garden Vendor garden Warehouse vendor assistant Vendor catalog Vendor compute Vendor semantic layer Vendor AI assistant Deep integration. Polished UX. Full context, but only inside. Data that lives outside Unreachable by the vendor assistant - Legacy Oracle on-prem - Salesforce SaaS - MongoDB cluster ops - S3 buckets object - Mainframe exports legacy - Marketing data lake separate cloud Reaching them means a second assistant, a third assistant, and so on. Each with its own config, security model, and limits. Every major warehouse vendor assistant works beautifully inside its walls. The problem is that enterprise data does not respect walls. ### The lock-in calculus AI features that deepen dependency on a single vendor create a specific kind of lock-in. When the AI assistant is the primary way analysts interact with data, switching the underlying platform means retraining every workflow. Semantic definitions tied to one vendor cannot be ported to another. Agent instructions tuned for one platform do not transfer. This is not incidental. It is the business model. AI features create usage patterns that are harder to migrate than data. Data can be exported. Workflows, prompts, and institutional knowledge about how to use the AI assistant cannot. Each productive session deepens the dependency. The timing is deliberate. Vendors are adding AI features precisely when enterprises should be preserving optionality. The AI infrastructure being built now will be evaluated against [open standards that outlast individual products](https://plexara.io/learning/insights/protocols-outlast-products) within two to three years. Enterprises that build on proprietary AI assistants will face re-platforming costs when that evaluation happens. The lock-in calculus Proprietary ecosystem ##### Vendor AI assistant - Semantic definitions tied to one vendor, not portable - Agent instructions tuned to one framework - Per-token LLM charges bundled with warehouse compute - Re-platforming cost grows with every productive session Plexara ##### Open protocols + BYO model - Federated SQL across warehouses, lakes, operational DBs - Change model provider without changing data infrastructure - Transparent pricing; LLM cost is between you and the model provider - Optionality preserved for the next evaluation cycle AI features create usage patterns that are harder to migrate than data. Data can be exported. Institutional knowledge about how to use the assistant cannot. ### The multi-source reality Most enterprises have data across three or more systems. A primary data warehouse, a legacy database that has not been migrated, SaaS applications with their own data stores, a data lake for unstructured data, and object storage for files and exports. No single vendor assistant can reach all of this. When the vendor assistant cannot reach data outside its ecosystem, the enterprise needs a second AI integration for the external data. And a third for the data outside both. Each integration has its own configuration, its own security model, and its own limitations. The agent experience is fragmented across [multiple tools that do not share context](https://plexara.io/learning/insights/why-mcp-gateways-are-not-enough). Building on a [federated platform where the agent can see the whole stack](https://plexara.io/learning/insights/when-an-agent-can-see-the-whole-stack) avoids this fragmentation. A single MCP endpoint connected to Trino queries data across all sources through standard SQL. The agent interacts with one tool regardless of where the data lives. The security model is unified. The metadata is centralized. What enterprise data actually looks like One MCP endpoint Warehouse A Warehouse B Legacy DB Data lake Object storage Most enterprises have data across three or more systems. No single vendor assistant can reach all of it. ### Cost opacity Incumbent AI features create opaque cost layers. Per-token LLM charges are billed through the vendor at a markup. Compute credits for AI functions are priced separately from base compute. Agent pricing may be per-session, per-query, or per-user, with the specific model varying by vendor and changing between billing cycles. This cost opacity makes TCO difficult to predict. An enterprise evaluating AI data access cannot easily compare the cost of the vendor AI assistant against an alternative because the vendor pricing is bundled with other services and subject to negotiated discounts that vary by account. A platform built on open protocols with a bring-your-own-model approach eliminates this opacity. The LLM cost is between the enterprise and the model provider. The platform cost is the platform cost. There are no hidden per-token charges, no compute credit markups, and no AI feature surcharges. Cost opacity #### Bundled pricing makes TCO a guess. Federated, BYO pricing makes it math. Per-token charges marked up through a warehouse. Compute credits priced separately from base compute. Agent pricing per-session, per-query, or per-user, changing between billing cycles. Evaluating one vendor against another is comparing bundles, not costs. ### When incumbent AI is sufficient and when it is not Incumbent AI assistants are sufficient when the enterprise keeps all queryable data within a single vendor platform, the vendor semantic layer covers all business metric definitions, cost opacity is acceptable, and lock-in risk is within tolerance. For many organizations, this describes their current state accurately. Incumbent AI assistants are insufficient when data spans multiple systems (the common case), when the enterprise needs to federate queries across warehouses, lakes, and operational databases, when cost predictability matters, or when the long-term strategy includes preserving the ability to change AI model providers without changing data infrastructure. Which vendor has the better AI assistant is the wrong comparison. The choice that matters is whether AI data access is tied to a specific vendor or built on open protocols that work across all of them. The real question #### Not which vendor has the better assistant. The question is whether AI data access should be tied to a specific vendor or built on open protocols that work across all of them. The first answer is comfortable now and expensive later. The second answer is the one that preserves your options. Further Reading - [Introducing the Model Context Protocol Anthropic · 2024 Anthropic's official announcement establishing MCP as an open standard for connecting AI systems to data sources and tools, replacing fragmented per-source integrations with a single protocol.](https://www.anthropic.com/news/model-context-protocol) - [Trino | Distributed SQL query engine for big data Trino Software Foundation · 2026 Official Trino site documenting that Trino runs federated ANSI SQL queries across heterogeneous sources (relational databases, object storage, NoSQL, data lakes) in a single query without moving the data.](https://trino.io/) - [Snowflake and Anthropic announce $200 million partnership to bring agentic AI to global enterprises Anthropic · 2025 Official announcement of a multi-year $200M agreement making Claude models available within the Snowflake platform (Cortex), confirming a warehouse vendor's $200M AI partnership for model hosting.](https://www.anthropic.com/news/snowflake-anthropic-expanded-partnership) On this page [Previous Why MCP gateways are not enough](https://plexara.io/learning/insights/why-mcp-gateways-are-not-enough) [Next Why point-solution catalogs and semantic layers are not enough](https://plexara.io/learning/insights/why-point-solution-catalogs-are-not-enough) ### Related reading philosophy [Philosophy 101 - What is a Large Language Model? LLMs predict the next token from patterns learned across trillions of training examples. What that means, why it produces fluent reasoning, and its limits.](https://plexara.io/learning/ai-concepts/what-is-a-large-language-model) [Philosophy 104 - Frontier models, specialized models, and why enterprise AI uses both Frontier models bring world knowledge; small local embedding models power memory and catalog search. Knowing each role designs AI systems that work.](https://plexara.io/learning/ai-concepts/frontier-models-explained) [Philosophy 401 - Prompts are the new SOPs You work with the agent for an hour to get one report exactly right, with a year-over-year cut, holiday annotations, and storm-closure markers. The agent saves durable business knowledge on its own. But that specialized report is not institutional knowledge, it is a procedure. This article draws the line between the two, and makes the case that a saved prompt is the standard operating procedure for an AI-run job.](https://plexara.io/learning/prompts/prompts-are-the-new-sops) --- # Why point-solution catalogs and semantic layers are not enough URL: https://plexara.io/learning/insights/why-point-solution-catalogs-are-not-enough/ > Data catalogs document data but cannot execute queries. Semantic layers define metrics but delegate execution. Neither provides unified context and access. Field notes / governance Dec 31, 2025 ## Why point-solution catalogs and semantic layers are not enough Data catalogs document data but cannot execute queries. Semantic layers define metrics but delegate execution. Neither provides unified context and access. 10-minute read Governance On this page ### The catalog-execution gap Data catalog vendors and semantic layer products are both adding MCP servers. This is a meaningful step: AI agents can now search the catalog, browse metadata, and in some cases write documentation back through MCP tool calls. The most capable catalog MCP servers support both read and write operations. The fundamental limitation persists: catalogs document data but cannot execute queries. When an agent discovers a relevant dataset through a catalog MCP server, it needs a separate MCP server to actually query the data. The context about what the data means lives in one system. The ability to access the data lives in another, which is the [context gap in AI data access](https://plexara.io/learning/insights/context-gap-in-ai-data-access). This gap creates multi-hop agent workflows. The agent calls the catalog to find a dataset. Then calls the query engine to describe the schema. Then calls the catalog again for business context. Then calls the query engine to execute a query. Each hop is a separate tool call with its own latency, failure mode, and a [token cost that compounds across the workflow](https://plexara.io/learning/insights/token-efficiency-in-enterprise-mcp). > Catalogs document data but cannot execute queries. Semantic layers define metrics but delegate execution. Neither provides unified context and access in a single endpoint. > The structural limitation ### Multi-hop workflows and their failure modes Multi-hop workflows are fragile. If the catalog MCP server returns a dataset name that does not exactly match the query engine table name, the agent must reconcile the mismatch. If the catalog uses one naming convention and the query engine uses another, the agent must translate. Each translation step is an opportunity for error. Timeout and rate-limiting failures are amplified in multi-hop workflows. If the catalog call succeeds but the query engine call is rate-limited, the agent has partial context. If the query engine call succeeds but a subsequent catalog call for business context times out, the agent returns results without context. The user sees numbers without meaning. Session coherence is another failure mode. If the catalog metadata changes between the discovery call and the query call, the agent may query a dataset that has been deprecated, renamed, or moved. Multi-hop workflows have no transactional consistency across the hops. Multi-hop workflow Agent trace · catalog MCP + query engine MCP 1. 01 `catalog.search` catalog Find a relevant dataset Returns a name that does not match the query engine 2. 02 `query.describe` query Inspect schema Naming convention mismatch; agent must translate 3. 03 `catalog.entity` catalog Pull business context Times out; agent proceeds with partial context 4. 04 `query.execute` query Run the query Catalog says deprecated; query engine has no idea end 4 hops. 4 tool definitions. 4 round trips. No transactional consistency across any of it. Every hop adds latency, a failure mode, and a token cost. The agent is responsible for reconciling information across systems that have no awareness of each other. ### Semantic layers delegate execution Semantic layer vendors face the same structural limitation from the opposite direction. They define metrics, dimensions, and business rules. They know that "revenue" means a specific calculation applied to specific columns with specific filters. What they cannot do is execute the query. When an agent asks a semantic layer MCP server for revenue, the semantic layer translates the request into SQL and passes it to the underlying warehouse for execution. The semantic layer is a translation layer, not an execution layer. It depends on the warehouse connection being available, correctly configured, and authorized for the requesting user. This delegation means the semantic layer cannot enforce [governance at execution time](https://plexara.io/learning/insights/governance-at-execution-time). It can define that certain metrics require certain permissions, but enforcement depends on the warehouse honoring those permissions. If the warehouse connection uses a service account with broad access, the semantic layer permissions are effectively bypassed. Semantic layers delegate Agent “revenue last quarter” Semantic layer defines what “revenue” means cannot execute Warehouse executes the translated SQL enforcement lives here If the warehouse connection uses a service account with broad access, every semantic layer permission is effectively bypassed. The semantic layer is a translation layer, not an execution layer. It depends on the warehouse honoring the permissions it defines. ### Governance enforcement gaps When context lives in the catalog and execution happens in the query engine, governance policies defined in one system may not be enforced in the other. The catalog says a dataset is PII-classified. The query engine does not check the catalog before executing a query against that dataset. This gap is the normal operating condition in most enterprises. Catalog governance policies are aspirational: they describe what should happen. Query engine access controls are operational: they determine what actually happens. The two are maintained by different teams using different tools with different update cycles. AI agents amplify this gap because they interact with both systems programmatically at high speed. A human analyst might check the catalog before querying sensitive data. An AI agent will take the most efficient path to results, which may bypass the catalog entirely if the query engine is directly accessible. Context + execution, unified Agent one tool call Plexara catalog · query · governance · lineage in one response - One tool call, complete business context - No reconciliation between catalog and query engine names - No partial context from timed-out secondary calls - Governance enforced at execution, not aspirational One call returns results with full business context. No reconciliation. No partial context. No governance gaps between systems maintained by different teams. ### Context and execution in one endpoint The architectural solution is to unify context and execution in a single platform. When the same system that executes queries also manages metadata, governance enforcement is inherent. A PII classification in the catalog directly affects what the query engine returns. An ownership change immediately updates access controls. A deprecation warning appears in every query response. This unification eliminates multi-hop workflows. One tool call returns results with full business context. No reconciliation between catalog names and query engine names. No partial context from timed-out secondary calls. No governance gaps between systems maintained by different teams. It also removes the integration tax of [stitching together five vendors](https://plexara.io/learning/insights/replacing-the-five-vendor-data-stack). In Plexara, the catalog, query engine, governance layer, semantic enrichment, and agent framework are layers of one platform. There is no glue code to maintain and no second system for a governance policy to fall between. The unifying move #### There is nothing to stitch when the layers are one platform. Catalog, query engine, governance layer, semantic enrichment, and agent framework are layers of one platform rather than products from five companies. The integration tax disappears. The governance gaps close. The agent gets one context. Further Reading - [Introducing the Model Context Protocol Anthropic · 2024 Official Anthropic announcement establishing MCP as an open standard for connecting AI assistants/agents to external data sources and tools, replacing fragmented per-source custom integrations with a single protocol.](https://www.anthropic.com/news/model-context-protocol) - [ToolHop: A Query-Driven Benchmark for Evaluating Large Language Models in Multi-Hop Tool Use Junjie Ye, Zhengyin Du, Xuesong Yao, Weijian Lin, Yufei Xu, Zehui Chen, Zaiyuan Wang, Sining Zhu, Zhiheng Xi, Siyu Yuan, Tao Gui, Qi Zhang, Xuanjing Huang, Jiecao Chen · 2025 Peer-style benchmark of 14 LLMs across five model families on multi-hop tool use; the leading model (GPT-4o) reaches only 49.04% accuracy, demonstrating that chaining multiple interdependent tool calls is a substantial and unsolved failure mode for current models.](https://arxiv.org/abs/2501.02506) - [least privilege - Glossary | CSRC National Institute of Standards and Technology (NIST) · 2025 NIST's authoritative definition: systems should restrict the access privileges of users and of processes acting on their behalf to the minimum necessary to accomplish assigned tasks, establishing least privilege as the baseline security objective.](https://csrc.nist.gov/glossary/term/least_privilege) On this page [Previous Why incumbent AI assistants are not enough](https://plexara.io/learning/insights/why-incumbent-ai-assistants-are-not-enough) [Next Benchmarking the context layer](https://plexara.io/learning/insights/benchmarking-the-context-layer) ### Related reading governance [Governance 403 - Sharing prompts, and closing the loop with feedback A procedure is only worth as much as the people who can run it. Plexara distributes a prompt two ways: a direct share to one teammate, or a promotion to a whole role or company through the admin review queue. A shared prompt is live, not a copy. Feedback threads then carry corrections back, with a validation step and a path into the knowledge catalog, and the deprecate-and-supersede lifecycle retires old versions cleanly.](https://plexara.io/learning/prompts/sharing-prompts-and-feedback) [Governance 505 - Next month’s file The new sheet arrives. Replacing the file’s content writes a new revision, and the registered table keeps reading the old one until it is registered again under the same name; the Scratch Tables page says so. This lesson covers the two cases that look alike and behave differently, moving the table forward, unregistering, what deleting the file does, saving the monthly procedure as a prompt, and the point at which a monthly file needs more than a join, which is where the 600 series begins.](https://plexara.io/learning/spreadsheets/next-months-file) [Governance 605 - What a run may do, and the record it leaves A run presents the roles its author held at the save, every call is authorized at that moment, and narrowing the persona takes effect on the next run. A save refuses a credential-shaped literal and source that does not parse. The dialect has no network, no filesystem, and no clock, so everything a script does is a platform call audited under the script’s own identity. The lifecycle from active to disabled, deprecated, and superseded; who sees what; ownership and an administrator’s transfer; and the administrator’s view of every script and every run.](https://plexara.io/learning/automations/what-a-run-may-do) --- # Benchmarking the context layer URL: https://plexara.io/learning/insights/benchmarking-the-context-layer/ > We built a benchmark that holds the model constant and varies only the platform. On business-context questions, an agent on raw data tools was right about 43 percent of the time. The same agent on Plexara was right about 99 percent, using fewer tool calls. Field notes / product Jul 13, 2026 Updated Aug 8, 2026 ## Benchmarking the context layer We built a benchmark that holds the model constant and varies only the platform. On business-context questions, an agent on raw data tools was right about 43 percent of the time. The same agent on Plexara was right about 99 percent, using fewer tool calls. 9-minute read Product On this page ### Why measure at all Plexara has been built the way durable software usually is: iteratively, with every version proven against real client data before it shipped. That is how we know the context layer works. It is not, on its own, how we can prove it to someone who has not watched it run. Field experience tells you a thing helps. It does not tell you by how much, on which kinds of question, or where the platform is still leaving accuracy on the table. For that you need a number you did not choose. So we built a benchmark, and we built it as an instrument: a repeatable way to isolate what the platform contributes, separate from what the model contributes, so that we can both confirm the production experience in the lab and see precisely where the next iteration should go. The results below are drawn from controlled, repeated runs, and we publish them the way we intend to keep publishing them, including the parts that are not yet flattering. The rigorous version, with figures, confidence intervals, and reproduction commands, lives in the [full accuracy study](https://plexara.io/benchmark/accuracy). ### The one thing that changes is the platform The design decision that makes the number trustworthy is what the benchmark holds still. Every run uses the same model, the same prompt scaffold, the same seed data, and the same task set. The only thing that varies between runs is the platform configuration. We call these configurations arms, and they are ordinary config profiles, not code forks, because the platform's own configuration surface is the thing under test. The benchmark ladders through four arms, each turning on one more layer. The two that carry the headline are the ends of that ladder. The baseline, A0, gives the agent raw toolkit tools only: it can run queries against the warehouse and read objects from storage, with no semantic enrichment, no search, and no knowledge pages. It is what you get when you wire an AI agent straight to your data with a stack of connectors. The shipped platform adds semantic cross-enrichment on every result, a search tool for discovery, and the curated knowledge pages that carry an organization's business rules. Because the model, the questions, and the data are identical across arms, any difference in the answers is attributable to the platform and nothing else. This is the opposite of the usual AI demo, where a better result could always be a better model, a luckier prompt, or a friendlier question. Here the model is [held constant on purpose](https://plexara.io/learning/insights/own-the-learning-loop-not-the-model). If the platform arm wins, the context layer is why. ### Ground truth you cannot argue with A benchmark is only as good as its answer key. Ours is generated, not written. One fixed-seed dataset model produces everything from a single source: the warehouse tables and their rows, the catalog metadata and column descriptions, the knowledge pages, and the task questions. The correct answer to each question is computed from the generated rows, never typed in by hand, so there is no opportunity to quietly tune the key to the result. A determinism test fails the build if the committed artifacts ever drift from what the generator produces. Measurement runs through the platform's own audit log rather than by reading the transcript and guessing. The harness threads a session handle invisible to the agent and reads efficiency metrics back from the admin audit API. A run fails loudly when a session's audit rows do not reconcile against the harness's own accounting of what it called, and attempts that fail at the harness level, a dropped connection or an audit read-back error, are excluded from accuracy and reported separately. A harness bug is never allowed to count as a wrong answer, and correctness with repeats is scored as pass-of-k: every one of the three attempts must be graded and correct. The run covers three suites at three repeats each, 261 graded attempts per arm across four arms, with zero harness failures. S1 is discovery: which table answers this question. S2 is analytical accuracy: exact numeric answers, some of them SQL graded by executing the query. S3 is knowledge traps: questions that have a plausible wrong answer you will reach unless you know a business rule that lives in the semantic layer. ### Where the platform earns its place On discovery and arithmetic, the arms are effectively tied. A capable model finds tables and computes sums without help, so S1 and S2 sit near the ceiling for every configuration. The platform does not make the agent better at questions it could already answer, and on the easy suites its search-first step even costs a few extra tool calls for the same result. That is worth stating plainly: the context layer is not a universal accelerant, and pretending otherwise would be the kind of claim this benchmark exists to prevent. The knowledge traps are where the arms separate. The raw-tools baseline answered 42.7 percent of them correctly. The full platform answered 98.7 percent, a gain of 56.0 points (95 percent confidence interval, plus 44 to plus 67), and it did so using fewer tool calls: a median of 10 against 16. The platform was both more correct and more efficient, on the same questions, with the same model. The trap-class breakdown shows the mechanism, and it is legible. Some facts, like amounts stored in cents, live in the catalog's column and dataset descriptions, so cross-enrichment alone recovers them. Others, like a February fiscal year or the definition of a key account, live only in knowledge pages, so bare tools and enrichment both score zero on them and only search recovers them. Each trap is defeated exactly when the channel that carries its fact is switched on. The cleanest single example is a question about net revenue. Revenue in this dataset is a policy, not a column: it is the order amount minus the discount, counted over completed orders only, and that rule lives in the dataset description and the revenue-policy knowledge page. Without the rule, an agent returns the gross total, a confident, professional, wrong number. On this trap class the raw-tools baseline scored 13 percent; the platform scored 100. The baseline was not broken. Its queries ran and its arithmetic was fine. It was working without the one fact that changes the answer, and it had no way to know the fact existed. That is the whole thesis of the platform, now with a measurement attached to it. [More tools do not make an agent smarter](https://plexara.io/learning/insights/why-more-tools-wont-make-your-agent-smarter); the missing piece is almost never a tool, it is [knowledge about the data the tools touch](https://plexara.io/learning/insights/context-gap-in-ai-data-access). The benchmark turns that argument from a position into a delta you can reproduce. ### What this is, and is not We report these numbers with their limits attached, because the limits are the point of measuring. The headline is arm-vs-arm on a single pinned model; it is the platform's effect, not a claim that one model beats another. The seed dataset is small and airgapped by design, so the absolute accuracies are not real-world estimates. What the ablation isolates, the platform's contribution holding everything else constant, is what the exercise is for. A second suite measures the memory-to-knowledge lifecycle: can a fact taught in one session be captured, promoted, and reach a different user later? When we first published, this was the part that was not working. Cross-user transfer sat near 45 percent, and we said so rather than market it, because the losses are the roadmap. That number was the roadmap. A later release moved the visibility boundary to the act of applying an insight, which is the exact path the 45 percent measured, and a re-run at five repeats over thirty protocols puts transfer at 98.9 percent. The rerun is on a newer platform build than the ablation above, so the two are not mutually comparable, and the [accuracy study](https://plexara.io/benchmark/accuracy) reports them separately for that reason. The harness is open. The arm configurations, the deterministic seed generator, the graders, and the audit-derived metrics all live in the [benchmark module of the open platform](https://github.com/txn2/mcp-data-platform/tree/main/bench), and the [full report](https://plexara.io/benchmark/accuracy) carries the figures, confidence intervals, and the exact commands to reproduce every number. That is the standard we want to be held to: run the harness and every number in this article reproduces. Further Reading - [Agent-effectiveness benchmark harness (txn2/mcp-data-platform) The open benchmark module: arm configs, deterministic seed generator, graders, and the audit-derived metrics described here.](https://github.com/txn2/mcp-data-platform/tree/main/bench) On this page [Previous Why point-solution catalogs and semantic layers are not enough](https://plexara.io/learning/insights/why-point-solution-catalogs-are-not-enough) [Next When do agents use what you teach them?](https://plexara.io/learning/insights/when-agents-use-what-you-teach) ### Related reading product [Product 102 - Tokens and your budget Every LLM interaction is priced and rate-limited in tokens. What a token is, how much text fits a budget, and how to avoid wasting tokens on useful answers.](https://plexara.io/learning/ai-concepts/tokens-and-your-budget) [Product 105 - What is an AI agent? An AI agent is not a chatbot and not magic. It is a short loop (think, call-tool, observe, think again) on top of a language model. Mental model first.](https://plexara.io/learning/ai-concepts/what-is-an-ai-agent) [Product 202 - Your first day with Plexara A new Plexara user gets connected, sends a first question, and platform_info takes over. Walks through day one and how subsequent turns inherit context.](https://plexara.io/learning/mcp/first-engagement) --- # When do agents use what you teach them? URL: https://plexara.io/learning/insights/when-agents-use-what-you-teach/ > Plexara's knowledge-use study asks what an agent actually does with delivered knowledge. Strong models re-verify anything they can check, and rely completely on the facts they cannot re-derive: conventions, definitions, policies. Without those facts, they invent plausible substitutes 75 percent of the time. Field notes / product Jul 28, 2026 ## When do agents use what you teach them? Plexara's knowledge-use study asks what an agent actually does with delivered knowledge. Strong models re-verify anything they can check, and rely completely on the facts they cannot re-derive: conventions, definitions, policies. Without those facts, they invent plausible substitutes 75 percent of the time. 8-minute read Product On this page ### The question underneath the first number Our first benchmark study produced a number we lead with often: on questions that turn on a business rule, an agent on raw data tools was right 42.7 percent of the time, and the same agent on the platform was right 98.7 percent. That study measured whether the knowledge layer delivers. It left a sharper question open, and a careful buyer eventually asks it: delivery is not use. The platform can place a fact in front of an agent, but whether the agent acts on it, double-checks it, or quietly ignores it is a fact about model behavior, not about platform engineering. We could have answered that question the way most of the industry does, with intuition and a demo. We answered it the way we answer everything about model behavior: we never assume what a model does, we measure it. The result is the [knowledge-use study](https://plexara.io/benchmark/knowledge-use), the second entry in our research series, and its findings changed what we build. ### A study that killed its own premise The study began as a pre-registered benchmark of a hypothesis we found plausible: that agents under-verify stored beliefs that can go stale, and that attaching freshness metadata, how volatile a fact is, how old the observation is, what a recheck costs, would fix the deficit. The protocol fixed the hypotheses, decision rules, and falsifiers before any data existed. The hypothesis died on first contact with the data. Given a stored belief it could check against the live world, the strong model checked it essentially every time, no matter what checking cost. We swept the price of re-verifying from one API call to eleven; verification did not move. We handed the agent a note containing the literal answer; it re-derived the answer anyway and cited the note as corroboration. There was no under-verification deficit to fix, so the freshness features the hypothesis would have justified were retired before a line of product code was written, and the falsification is recorded in the public protocol, with the runs that killed it archived beside the runs that succeeded. We tell this part of the story first because it is the part that makes the rest believable. A benchmark that can only confirm what its author hoped is marketing with error bars. Ours is allowed to lose, and when it loses we publish that and change course. The losses are the roadmap, and sometimes they are also the finding. ### What emerged instead: derivability What the wreckage revealed is a clean two-part structure. The first part: whether an agent uses delivered knowledge depends on whether it could re-derive that knowledge itself. A fact about the current state of the world, how many monitors are provisioned, what a metric reads today, is something a connected agent can always go look up, and the strong model always did, making delivery of such facts harmless but redundant. Then we delivered a fact no query can reconstruct: an internal reporting convention, the kind of rule every organization has, stating that a day counts as positive coverage when its sentiment score is 70 or higher. The experiment was built so any answer betrays the threshold that produced it. With the convention delivered, the agent used it in every single attempt, eight of eight. Without it, the agent did not stop and say it could not know. In six of eight control attempts it adopted a threshold of its own invention, called it a neutral midpoint, and answered confidently. No control attempt ever guessed the real rule. That is the two-sided result at the center of the study: delivered institutional knowledge is used completely, and its absence does not produce ignorance, it produces confident fabrication. Seventy-five percent of the time without the rule; zero with it. ### What this says you should teach your platform The practical reading is a priority list for what belongs in a knowledge layer. The facts that pay are the ones your agent cannot re-derive from any endpoint: how your fiscal year runs, what net revenue means in your house, which threshold defines a key account, which table is deprecated despite looking authoritative. These are also exactly the facts our accuracy study found carrying the entire +56-point lift, so the two studies corroborate each other from independent directions: one measured how much the knowledge layer helps, the other explains why, and both point at the same class of facts. This is what Plexara's [memory-to-knowledge lifecycle](https://plexara.io/product/memory) is built to capture. Conventions, definitions, and policies surface naturally in real working sessions, get captured as memories, curated into insights, and promoted into the shared knowledge that enrichment and search deliver to every later session. The study says the agent on the receiving end will use what arrives through that pipe, precisely because it cannot reconstruct it any other way. And the strong model re-verifying everything checkable is not a disappointment, it is the property you want. Delivered knowledge never became blind trust in any strong-tier cell of the study. The agent treats notes about the changeable world as leads to confirm, not answers to repeat, which is exactly the behavior you would ask of a careful analyst. ### Model tier changes the math, and we say by how much The second part of the structure is capability. A smaller model, run through the identical cells, inverted the world-state result: it trusted the delivered answer-bearing note 29 times out of 32 rather than re-checking. That efficiency has a price, and the study measured it directly with a note gone stale: the small model reported the stale value every time, scoring zero against its own perfect no-note control. The strong model, re-deriving as always, was unaffected. Delivered conventions were used and fabrication-suppressing on both tiers, so the knowledge that matters most is safe everywhere. The tier result is deployment guidance we can hand a customer as measured fact: pair the knowledge layer with capable models for questions about the live state of the world, and let the layer carry your definitions and policies for every model. It is also how we run Plexara in production, with frontier-class models doing the analytical work. The full report, with the apparatus, the run directories, every interval, and the stated limitations, is on the [study page](https://plexara.io/benchmark/knowledge-use), and the brand-neutral version is archived with its raw data under a citable DOI. Like the accuracy study, every table regenerates offline from committed run data. Run the scripts and every number in this article reproduces. Further Reading - [When do agents use stored knowledge? (the knowledge-use study, technical report) The brand-neutral technical report in the open platform project: apparatus, run directories, Wilson intervals, threats to validity, and citation. Archived with raw data under DOI 10.5281/zenodo.21614059.](https://mcp-data-platform.txn2.com/reference/benchmark-report-knowledge-use/) - [Agent-effectiveness benchmark harness (txn2/mcp-data-platform) The open benchmark module: the deterministic fixture, world registry, frozen beliefs, graders, and run manifests behind both studies.](https://github.com/txn2/mcp-data-platform/tree/main/bench) On this page [Previous Benchmarking the context layer](https://plexara.io/learning/insights/benchmarking-the-context-layer) [Next Two benchmarks, one conclusion: the industry is converging on context](https://plexara.io/learning/insights/two-benchmarks-one-conclusion) ### Related reading product [Product 102 - Tokens and your budget Every LLM interaction is priced and rate-limited in tokens. What a token is, how much text fits a budget, and how to avoid wasting tokens on useful answers.](https://plexara.io/learning/ai-concepts/tokens-and-your-budget) [Product 105 - What is an AI agent? An AI agent is not a chatbot and not magic. It is a short loop (think, call-tool, observe, think again) on top of a language model. Mental model first.](https://plexara.io/learning/ai-concepts/what-is-an-ai-agent) [Product 202 - Your first day with Plexara A new Plexara user gets connected, sends a first question, and platform_info takes over. Walks through day one and how subsequent turns inherit context.](https://plexara.io/learning/mcp/first-engagement) --- # Two benchmarks, one conclusion: the industry is converging on context URL: https://plexara.io/learning/insights/two-benchmarks-one-conclusion/ > dbt Labs benchmarked agents on its semantic layer against text-to-SQL and reached the conclusion our platform ablation reached: govern the context between an agent and the data, and business questions move from unreliable to dependable. Two methods, one finding, and a rule for reading both. Field notes / philosophy Jul 22, 2026 ## Two benchmarks, one conclusion: the industry is converging on context dbt Labs benchmarked agents on its semantic layer against text-to-SQL and reached the conclusion our platform ablation reached: govern the context between an agent and the data, and business questions move from unreliable to dependable. Two methods, one finding, and a rule for reading both. 10-minute read Philosophy On this page ### One thesis, tested twice In April 2026, dbt Labs published a benchmark asking a question we had spent the spring answering with a different instrument: does an AI agent get business questions right more often when a governed layer of meaning sits between it and the data? Their study puts an agent behind the dbt Semantic Layer and compares it with the same agent writing SQL directly against the warehouse. [Ours](https://plexara.io/learning/insights/benchmarking-the-context-layer) holds a model constant and ablates the Plexara platform underneath it, measuring what each layer of context contributes. Different companies, different architectures, different datasets, different graders. Both landed in the same place. The shared premise is worth stating plainly, because it cuts against a common instinct. When an agent answers a data question confidently and wrongly, the instinct is to reach for a better model. Both benchmarks say the instinct points at the wrong layer. Current models write valid SQL with ease; what they cannot do is know that revenue in this warehouse means net of discounts over completed orders, or that the amounts column stores cents. That is [a context problem, not a SQL-skill problem](https://plexara.io/learning/insights/context-gap-in-ai-data-access), and no amount of model capability fixes it, because the missing fact lives outside anything the model can see. A claim like that is easy for a vendor to assert and hard for a buyer to check. Any single benchmark, including ours, is an argument built by the people with the most to gain from its conclusion. Two benchmarks built independently, with no shared code, data, tasks, or graders, arriving at the same shape of result, are something closer to evidence. That convergence, and how far it can be trusted, is what this article is about. Agent with bare access ##### Fluent, plausible, and wrong - Writes valid SQL against whatever schema it can see - Answers questions that hinge on a business rule it has no way to know - Returns gross when the business means net, dollars when the column stores cents - Gives no signal about which answers deserve distrust Agent behind a governed context layer ##### Grounded, or visibly failing - Same model, same question, business definitions supplied at query time - Metric and rule lookups resolve before the query runs - Covered questions come back correct at rates bare access never reaches - Failure surfaces as an error or an audit trail instead of a quiet wrong number ### What dbt measured The dbt study is compact and clean about its method. Eleven business questions run over the ACME Insurance dataset, a schema dbt borrowed from Juan Sequeda and colleagues at data.world, with each question executed twenty times per model to average out run-to-run variance. Four current models were tested: Claude Sonnet 4.6, Claude Opus 4.6, GPT-5.3 Codex, and GPT-5.2. The harness is open source, built on Pydantic AI and DuckDB, with automated grading against gold SQL and a published results dashboard, so the mechanics are inspectable end to end. The result: querying through the semantic layer, GPT-5.3 Codex answered every trial correctly and Claude Sonnet 4.6 scored 98.2 percent, roughly 216 of 220 trials. The same models writing raw SQL over the same data scored 84.1 and 90.0 percent. Just as notable is what dbt disclosed alongside the headline. The text-to-SQL baseline was handed the entire schema in context, a favor the authors note does not scale to real warehouses. Several of the original questions sat beyond the semantic layer’s reach until a modest round of additional modeling brought them in, and that modeling improved both strategies. Disclosures like these are what make a benchmark worth taking seriously. Before we put our own results on the page, one rule for reading the rest of this article: none of the numbers above can be ranked against any of the numbers below. The two studies use different tasks, different data, different denominators, and different definitions of correct. If a percentage from their study and a percentage from ours happen to look similar, the similarity means nothing by itself. What can be compared is the shape of the two findings. Their instrument Text-to-SQL over the raw schema Queries through the semantic layer GPT-5.3 Codex Text-to-SQL 84.1% Semantic layer 100% Claude Sonnet 4.6 Text-to-SQL 90.0% Semantic layer 98.2% Accuracy over 11 questions on the ACME Insurance dataset, 20 runs per model per strategy, graded automatically against gold SQL. Read each model against itself; the gap inside each pair is the finding. Source: dbt Developer Blog, April 2026. ### A failure that announces itself The strongest finding in the dbt post is not a percentage. It is an asymmetry in how the two strategies fail. When text-to-SQL misses, it produces a plausible number that is quietly wrong: the query runs, the answer arrives formatted and confident, and nothing about it invites a second look. When the semantic layer misses, it is because the question fell outside its modeled scope, and the agent gets an error instead of an answer. One failure mode erodes trust invisibly; the other announces itself while there is still time to catch it. We think dbt is exactly right about this, and it is the same argument we make from the provenance side. On Plexara, an answer arrives attached to the knowledge pages and catalog entries that shaped it, and [the audit log records every call that produced it](https://plexara.io/learning/insights/governance-at-execution-time). The error message and the audit trail do the same job by different means: they turn failure from a silent event into an inspectable one. For a business deciding whether to let agents near real decisions, that property matters at least as much as the accuracy number, because it determines whether the residual errors are findable. > With text-to-SQL, failure looks like a correct-looking number that’s subtly wrong. With the Semantic Layer, failure looks like an error message. > dbt Developer Blog, April 2026 ### Two different rulers What dbt measures is coverage of a modeled scope. Their semantic layer is a set of predefined metrics over modeled warehouse tables, and the benchmark asks whether an agent that stays on that paved road beats an agent navigating the raw schema on its own. The questions are the kind a metrics layer exists to answer, and the win condition is matching the gold query over a shared, known dataset. What we measure is resistance to traps. Our suite is built around questions that have a plausible wrong answer any competent agent will reach unless it knows a specific business fact: amounts stored in cents, revenue that means net rather than gross, a fiscal year that starts in February, a deprecated table that still looks authoritative. The knowledge that defeats each trap is taught to the platform and reviewed by a person, and the benchmark asks whether that taught layer prevents the confident wrong answer, and whether it keeps accumulating. Complementary, not comparable. One study tests how well a curated road performs where the road exists; the other tests whether an agent can be kept from driving off a cliff the map does not mark. Both are real questions a buyer should ask. Neither number ranks the two products, because the two numbers are answers to different questions. Two rulers dbt’s benchmark Plexara’s benchmark Task set 11 business questions, each run 20 times per model 87 seeded tasks, each run 3 times Data ACME Insurance, an established third-party benchmark schema A warehouse, catalog, and knowledge base generated from one fixed seed What varies The query strategy: semantic layer or text-to-SQL The platform configuration: four arms under one pinned model What counts as correct Output matches the gold SQL answer Every one of three repeated attempts is graded correct What the headline claims Coverage of a modeled metric scope Resistance to knowledge-trap questions Every row differs. A percentage from one column cannot rank against a percentage from the other; each is meaningful only inside its own study. ### What we measured Our benchmark ladders through four platform configurations, from raw data tools with no context at all, through semantic enrichment, to the knowledge layer and search, to the full lifecycle, holding the model, the prompts, the seed data, and the 87-task suite constant across every arm and running each task three times. Because only the platform changes between arms, any difference in the answers is attributable to the platform. The method, figures, and reproduction commands live in the [full accuracy study](https://plexara.io/benchmark/accuracy). On knowledge-trap questions, the raw-tools baseline answered 42.7 percent correctly and the platform with its knowledge layer answered 98.7 percent, a gain of 56.0 points with a 95 percent bootstrap confidence interval of +44 to +67. The specificity matters as much as the size: on plain discovery and numeric questions, the four arms are statistically indistinguishable, so the platform is not making the agent generally smarter. It is supplying exactly the class of fact whose absence produces confident wrong answers, which mirrors the scope dbt drew around their own claim. The instrument is built to be checked. Every number in the report carries a reproducible confidence interval, the resampling seeds are fixed, a threats-to-validity section says where the design is weakest, and a notebook regenerates every figure from committed data with no network access and no API key. The report and raw run data are archived on Zenodo, linked in the references below. Our instrument A0 Raw data tools 42.7% A1 Adds semantic enrichment 57.3% A2 Adds knowledge and search 98.7% A3 Full lifecycle 98.7% +56.0 points over raw tools on knowledge traps95% bootstrap CI +44 to +67 Knowledge-trap accuracy by platform configuration: the 87-task seeded suite, three repeats per task, model and prompts and data held constant while the platform ladders up one layer per arm. Confidence intervals for every number are in the full report. Source: the Plexara benchmark report. ### Teaching the layer from empty A companion cold-start experiment asks the question the ablation cannot: where does the knowledge come from? Starting from a completely empty knowledge layer, where trap accuracy sits at 48.0 percent, a floor that reproduces across five independent runs, we taught the platform six business facts one at a time and measured after each. Accuracy climbed to 90.7 percent by the sixth fact, and the curve moved in legible steps: each taught fact lifted its own trap class at or shortly after the moment a reviewer promoted it to shared knowledge. dbt found the same dynamic approaching from the other side. Their added round of modeling, three small dbt models, closed the semantic layer’s coverage gaps and improved both strategies. The convergent lesson is that a context layer rewards investment, and the two studies simply invest in different currencies: metrics modeled ahead of time in one, facts taught and human-reviewed along the way in the other. Either way, the layer an organization builds is [an asset it owns and keeps improving](https://plexara.io/learning/insights/own-the-learning-loop-not-the-model), independent of which model happens to sit on top of it. Learning curve 48.0 % Knowledge-trap accuracy with the knowledge layer empty, the floor a fresh install starts from Reproduced across five runs 6 Business facts taught one at a time, each moving its own trap class at or shortly after promotion Cold-start study 90.7 % Accuracy after the sixth taught fact, same model, same tasks, three repeats each Plexara benchmark report Coverage grows where questions actually land: each fact is taught in the flow of work and reviewed by a person before it becomes shared knowledge. ### What two results prove that one cannot Set the two studies side by side, at the level of shape rather than score, and the agreement is striking. Both find that bare text-to-SQL access plateaus well short of reliability, at a level that varies with how hard the task leans on business context. Both find that a governed context layer moves the questions it covers into dependable territory. Both find that the layer changes the failure mode from a plausible wrong answer to something a person can inspect. And both find that the gain is scoped rather than general: dbt reports questions that fell outside the modeled layer, and we report suites where the platform makes no measurable difference. That last point of agreement is the one we would most like buyers to notice, because restraint is rare in a contested marketing space. A benchmark built to sell would show a uniform uplift everywhere. Both of these show edges: places where the layer runs out, ties where context is not the bottleneck, disclosed favors to the baseline. Two teams independently choosing to publish their limits is a better reason to trust the category’s central claim than any single headline number either team produced. Independent replication Governed context: covered questions become dependable Bare access: a plateau that varies by task, never reliability dbt, semantic-layer study Plexara, platform ablation Two teams with unrelated methods produced the same picture: a governed layer of meaning moves the questions it covers from unreliable to dependable, and moves failure into the open. ### Where the context layer goes next The two products draw the layer around different territory, and the geometry is orthogonal with overlap. dbt’s semantic layer governs modeled warehouse data through predefined metrics, and the modeling discipline underneath it, transformation and metric definition, is work Plexara does not do. A warehouse that dbt has modeled is exactly the kind of source Plexara is built to govern: the two layers meet rather than compete. Plexara carries the same thesis across a wider surface. The context layer spans [federated SQL across warehouses and databases, object storage, REST APIs, and proxied MCP servers](https://plexara.io/learning/insights/when-an-agent-can-see-the-whole-stack), under one persona model, one authorization decision, and one audit pipeline, with a knowledge layer that grows by being taught and human-reviewed in the flow of real work. The thesis both benchmarks support does not stop at the warehouse boundary, because the questions agents are asked do not stop there either. Both benchmarks are public. dbt’s post and open harness are linked in the references, with a published dashboard of results. Our [full report](https://plexara.io/benchmark/accuracy) carries every figure with its confidence interval and the commands to reproduce them, and the archived report and run data live on Zenodo. Read both before you take either vendor’s word for it, ours included. The wider surface A dbt-modeled warehouse Federated SQL engines Object storage REST APIs Proxied MCP servers One governed surface One persona model, one authorization decision, one audit pipeline, and a knowledge layer that is taught and human-reviewed. Metric definition and transformation stay with dbt; governing what an agent reaches, across every source at once, is the layer Plexara adds. Category evidence #### Two benchmarks make a stronger claim than either could alone. One vendor’s benchmark is an argument; a second team reaching the same conclusion with unrelated methods is evidence. dbt got to dependable answers through metrics modeled ahead of time, and we got there through knowledge taught along the way. If you are evaluating this category, read both studies in full, and hold every vendor in it, us included, to the standard the two set together. Further Reading - [Semantic Layer vs. Text-to-SQL: 2026 Benchmark Update dbt Labs · 2026 The dbt Developer Blog post reporting that agents querying through the dbt Semantic Layer scored 100 percent (GPT-5.3 Codex) and 98.2 percent (Claude Sonnet 4.6) on the ACME Insurance question set, against 84.1 and 90.0 percent for text-to-SQL over the same data.](https://docs.getdbt.com/blog/semantic-layer-vs-text-to-sql-2026) - [dbt-labs/dbt-llm-sl-bench dbt Labs · 2026 The open-source harness behind the dbt benchmark: Pydantic AI plus DuckDB, automated grading against gold SQL, and a published results dashboard.](https://github.com/dbt-labs/dbt-llm-sl-bench) - [Plexara agent-effectiveness benchmark: report and run data Plexara · 2026 The archived benchmark report and raw run data behind the ablation and cold-start studies cited here, with bootstrap confidence intervals, fixed seeds, and a notebook that regenerates every figure from committed data.](https://doi.org/10.5281/zenodo.21438045) On this page [Previous When do agents use what you teach them?](https://plexara.io/learning/insights/when-agents-use-what-you-teach) [Next What one person teaches, the whole team gets](https://plexara.io/learning/insights/what-one-person-teaches-the-whole-team-gets) ### Related reading philosophy [Philosophy 101 - What is a Large Language Model? LLMs predict the next token from patterns learned across trillions of training examples. What that means, why it produces fluent reasoning, and its limits.](https://plexara.io/learning/ai-concepts/what-is-a-large-language-model) [Philosophy 104 - Frontier models, specialized models, and why enterprise AI uses both Frontier models bring world knowledge; small local embedding models power memory and catalog search. Knowing each role designs AI systems that work.](https://plexara.io/learning/ai-concepts/frontier-models-explained) [Philosophy 401 - Prompts are the new SOPs You work with the agent for an hour to get one report exactly right, with a year-over-year cut, holiday annotations, and storm-closure markers. The agent saves durable business knowledge on its own. But that specialized report is not institutional knowledge, it is a procedure. This article draws the line between the two, and makes the case that a saved prompt is the standard operating procedure for an AI-run job.](https://plexara.io/learning/prompts/prompts-are-the-new-sops) --- # What one person teaches, the whole team gets URL: https://plexara.io/learning/insights/what-one-person-teaches-the-whole-team-gets/ > An analyst corrects the assistant once and a colleague who never saw that conversation gets the right answer weeks later. Our own benchmark said that mostly was not happening, named the likely cause, and the rerun after a targeted fix says it now happens 98.9 percent of the time. Field notes / product Aug 5, 2026 ## What one person teaches, the whole team gets An analyst corrects the assistant once and a colleague who never saw that conversation gets the right answer weeks later. Our own benchmark said that mostly was not happening, named the likely cause, and the rerun after a targeted fix says it now happens 98.9 percent of the time. 9-minute read Product On this page ### The colleague who was never told A finance analyst notices that the assistant is reporting a revenue figure gross when the business means net, and says so, once, in the middle of doing something else. Six weeks later somebody in a different department, who has never met the analyst and has no idea that exchange happened, asks a question that depends on the same distinction. They get the net figure, with a note saying where the definition came from and who supplied it. Nobody forwarded anything. Nobody was told who to ask. That second person getting the right answer is the whole point of teaching a platform anything. The correction has to survive the conversation it was made in, and it has to reach someone who does not know it exists, because the people who most need a business rule are exactly the ones who do not know the rule is there to be asked for. This is a claim that is easy to make and unpleasant to check, so we built it into the benchmark suite that ships with the platform and published what came back. The first published reading said it mostly was not happening. This article is about that number, the change we made because of it, and what the rerun measured. What normally happens ##### The correction stays at one desk - An analyst works out that the amounts column stores cents and tells the assistant - The fix lives inside that one conversation, where nobody else can see it - A colleague asks a related question next quarter and re-derives the number from raw data - The same mistake gets found, corrected, and forgotten once per person What Plexara does with it ##### The next person inherits it - The assistant records the fact and links it to the table it describes - A reviewer reads it and applies it, which is what turns a private note into a company answer - Anyone else’s next search finds it, still credited to whoever taught it - The colleague gets the right answer without knowing the fact existed or who to ask ### What "someone else reused it" actually means The measurement is a scripted protocol rather than an impression. One session, under one identity, is taught a fact the data cannot reveal on its own: a definition, a fiscal boundary, a convention about how a column is stored. A reviewer then applies that capture, which is the step that turns one person’s note into something the organization asserts. Then a fresh session opens under a completely different identity, with no access to the first conversation, no hint that anything was taught, and no pointer to the person who taught it, and it is asked a question that cannot be answered correctly without the fact. Grading is on the answer, not on effort. Either the platform put the fact in front of the second identity in time to be used, or the answer is wrong. The suite runs 30 of these protocols end to end on claude-sonnet-5, repeated as 5 independent passes, which leaves 149 protocol-runs after one exclusion for a harness fault. It is worth being clear about what this does not measure. It says nothing about whether the fact was worth teaching, whether the reviewer should have applied it, or whether the second person would have thought to ask. It measures one link in the chain: a promoted fact reaching a colleague who was never told about it. What is being measured 1. 01 ##### One person teaches a fact A session under the first identity is told something the data cannot reveal on its own, a definition, a boundary, a convention. The assistant records it and links it to what it describes. 2. 02 ##### A reviewer promotes it The capture stays private to its author until someone with the reviewer role applies it. That act is what makes it the organization’s answer rather than one person’s note. 3. 03 ##### A different identity asks A fresh session opens under a second identity that never saw the first conversation, was never told the fact exists, and has no pointer to the person who taught it. 4. 04 ##### The answer is graded The question put to the second identity cannot be answered correctly without the taught fact. Either the platform carried it across or the answer is wrong. One run of the protocol. The second identity is given no hint that anything was taught, so a correct answer means the platform delivered the fact rather than the person remembering to ask for it. ### The first reading said it mostly was not happening On build v1.102.0, across 15 protocols at k = 3, a fact promoted to shared knowledge was reused correctly by a different identity 46.7 percent of the time. Under half. Every other stage of the lifecycle in that same run looked healthy: the agent captured what it was taught, a later session under the same identity recalled it, search surfaced it without being asked. The link that failed was the one the feature exists for. We published that on the front of the report as a limitation rather than burying it in a threats-to-validity note, and we published a reading of the cause with it: the gap looked more like a capture-and-propagation limit than a surfacing failure. In plainer terms, the guess was that the fact was not becoming visible to the second identity in the first place, rather than being visible and getting ignored. Publishing a failing number on a capability you are selling is uncomfortable, and it is also the only way the number is worth anything. A benchmark that reports only its wins tells a reader nothing about what the instrument would do if the product were broken, because it has never been observed doing anything else. ### A change aimed at the diagnosis, then a rerun The change that followed was small and specific. Visibility moved to the act of applying an insight: the moment a reviewer applies a capture, it becomes findable by every identity through the same search everyone already uses, still attributed to whoever taught it. Before that, a fact filed against a catalog entry rather than onto a knowledge page could reach nobody but its author unless a question happened to name the exact table it hung off. That is the precise path the earlier reading measured. The suite was then re-run at k = 5 on build v1.118.0, with 30 protocols instead of 15. A promoted fact reached a different identity and produced the correct answer 98.9 percent of the time, 94 of 95 transfer attempts, with a 95 percent bootstrap confidence interval of 96.8 to 100.0. The interval touches the ceiling, which is a way of saying the run found one failure and cannot rule out that a longer run would find a few more. The part worth more than the number is that the earlier reading of the cause held up. The fix was aimed at the mechanism the report had guessed at, and the metric that moved was the one that mechanism controls. A benchmark that only produces a score tells you where you are. A benchmark that produces a diagnosis you can act on, and then confirms or refutes it, is an instrument you can steer with. Before and after Build v1.102.015 protocols, k = 3 46.7% Published as a limitation on the front of the report Build v1.118.030 protocols, k = 5 98.9% 94 of 95 attempts answered correctly 95% CI 96.8 to 100.0 A fact taught by one person, then asked for by a different one. Both readings come from the same lifecycle suite on claude-sonnet-5, run against two different platform builds. The pair is an across-code comparison, not a resampling of one build. ### Two builds, and the line between them Those two figures come from different platform generations, and the report says so in the section header rather than the footnotes. The ablation and cold-start studies are pinned to v1.102.x; the lifecycle suite was re-run on v1.118.0. Report 2.0.1 states that the sections are not mutually comparable and that no number should be carried across the boundary. For the reach pair, crossing that boundary is the entire point. A change landed between the two builds, the pair is what the change did, and nothing else about it would be measurable if both readings came from the same code. Sample size moved too, from 15 protocols to 30 and from k = 3 to k = 5, so the accurate statement is that a targeted change and a larger run happened together, and the report argues the mechanism rather than resting on the size of the jump. For every other metric in that section, the line holds. Anything else that differs between the two readings differs for reasons nobody isolated, and reading a trend into those pairs would be reading noise. Read the boundary Earlier generation v1.102.0 Carries the ablation and cold-start studies, and the reach reading that came back under half. Later generation v1.118.0 Carries the re-run lifecycle suite at k = 5, with the change to who can see an applied insight already in it. A change landed between these two builds, which is exactly what the reach pair is here to show. It is also the reason no other number should be carried across the line: anything else that differs between the sections differs for reasons nobody isolated. Report 2.0.1 states plainly that its sections span two platform generations and are not mutually comparable. The reach figures are the one pair the boundary is meant to expose. ### How much of that is the platform carrying the fact A near-ceiling accuracy number invites a fair objection: maybe the second identity worked the answer out on its own and the knowledge layer was decoration. Report 2.0.1 added a decomposition to answer it. The taught fact was provably delivered to the second identity in 68.4 percent of attempts [58.9 to 77.9], and in 98.5 percent of those the answer that followed was correct. The gap between 68.4 percent delivered and 98.9 percent correct is the check being deliberately hard on itself. Delivery counts only when the stored fact appears as a literal normalized substring of a tool result, which means the check can miss a real delivery that got paraphrased, but it cannot manufacture one. All 30 of the correct-but-not-counted episodes were read back against their transcripts, and in every one the agent had searched and a tool result carried the protocol’s key term. None of them is a case of the model deriving the answer unaided. The other half of the decomposition is the more interesting half. Once a fact is actually in front of a capable model, it is used 98.5 percent of the time. Getting the fact there is the hard part, and it is the part a platform is responsible for. That matches what [our knowledge-use study](https://plexara.io/learning/insights/when-agents-use-what-you-teach) found from the other direction: strong models re-verify what they can check and lean completely on the conventions and definitions they cannot re-derive. Where the answer came from 68.4 % Attempts where the taught fact was provably put in front of the second person, counted only when the stored wording appears literally in a tool result 95% CI 58.9 to 77.9 98.5 % Of those, the share where the second person then answered correctly. Delivered knowledge is very nearly always used knowledge Used given surfaced 30 Correct answers the literal check missed, each read back against its transcript. In every one, the agent searched and a tool result carried the key term Read back by hand The delivery check requires the stored fact to appear as a literal substring of a tool result, so it can miss real deliveries but cannot invent one. The distance between it and the graded answers is that conservatism, not the model working the fact out unaided. ### What a team gets from a loop that finds its own defects The reason to run a benchmark against your own product is not the marketing number at the end. It is that a suite instrumented stage by stage tells you which stage broke. The reach failure showed up as a single bad row next to seven healthy ones, which is what made it diagnosable at all, and the same instrumentation is what verified the fix rather than a set of hand-picked demos. That is also the practical argument for owning the loop instead of waiting for a better model, which we made [at more length here](https://plexara.io/learning/insights/own-the-learning-loop-not-the-model). The knowledge your business runs on lives in your people, and the mechanism that moves it from one person to the next is something you can inspect, measure, and repair. A model upgrade will not do it for you, because the missing fact was never in the model. Concretely, for a team on Plexara: the hour an analyst spends untangling a definition is an hour that is spent once. The next person to ask, in another department, in another quarter, with no idea the first conversation happened, gets that work handed to them. The method, the confidence intervals, and the reproduction commands are in the [full accuracy study](https://plexara.io/benchmark/accuracy), the rest of the research sits in the [research center](https://plexara.io/benchmark), and what the capability looks like in the product is on the [knowledge application page](https://plexara.io/product/knowledge-application). What it costs a team when this fails #### Every person who joins pays the same tuition the last one did. A business fact that reaches only its author is a fact your organization relearns on every hire, every rotation, and every departure. Reach is what turns one analyst’s afternoon of digging into something the next person starts from. It is worth asking any vendor whose product claims to learn from your team how often the thing it learned reaches someone else, and what the denominator was. Further Reading - [Does a Semantic Knowledge Layer Make an Agent Measurably Better? A Reproducible Benchmark of the mcp-data-platform Knowledge Layer Plexara · 2026 The archived report and raw run data behind every figure here, version 2.0.1. The lifecycle section carries the reach numbers, the decomposition, and the statement that the report's sections span two platform generations and are not mutually comparable.](https://doi.org/10.5281/zenodo.21751635) On this page [Previous Two benchmarks, one conclusion: the industry is converging on context](https://plexara.io/learning/insights/two-benchmarks-one-conclusion) [Next A tool catalog is not a data platform](https://plexara.io/learning/insights/a-tool-catalog-is-not-a-data-platform) ### Related reading product [Product 102 - Tokens and your budget Every LLM interaction is priced and rate-limited in tokens. What a token is, how much text fits a budget, and how to avoid wasting tokens on useful answers.](https://plexara.io/learning/ai-concepts/tokens-and-your-budget) [Product 105 - What is an AI agent? An AI agent is not a chatbot and not magic. It is a short loop (think, call-tool, observe, think again) on top of a language model. Mental model first.](https://plexara.io/learning/ai-concepts/what-is-an-ai-agent) [Product 202 - Your first day with Plexara A new Plexara user gets connected, sends a first question, and platform_info takes over. Walks through day one and how subsequent turns inherit context.](https://plexara.io/learning/mcp/first-engagement) --- # A tool catalog is not a data platform URL: https://plexara.io/learning/insights/a-tool-catalog-is-not-a-data-platform/ > Agent integration platforms now advertise thousands of connected apps and tens of thousands of actions. Catalog size is the wrong axis. What determines whether an agent produces dependable work is what surrounds the call: where the answer lands, who was allowed to make it, and what the platform remembers afterward. Field notes / philosophy Aug 13, 2026 ## A tool catalog is not a data platform Agent integration platforms now advertise thousands of connected apps and tens of thousands of actions. Catalog size is the wrong axis. What determines whether an agent produces dependable work is what surrounds the call: where the answer lands, who was allowed to make it, and what the platform remembers afterward. 7-minute read Philosophy On this page ### The number keeps going up The market for connecting AI agents to software has settled on a headline metric: catalog size. One platform advertises nine thousand connected apps and tens of thousands of actions. Another counts its toolkits in the thousands. Hosted MCP endpoints, per-user OAuth flows, and action registries have become a product category of their own, and the pitch is consistent: whatever your agent needs to touch, we already have the connector. The pitch is accurate as far as it goes. These platforms solve real problems, especially authentication at scale, and if the job is an assistant that files a ticket, posts a message, and updates a document across the long tail of workplace apps, a large hosted catalog is a reasonable way to get there. The trouble starts when the job is different: research, business intelligence, and operations against the systems a company actually runs on. That work has requirements a catalog does not address, because they are not properties of the connector. They are properties of what surrounds the call. ### An answer needs somewhere to land Call an API through a tool catalog and the response arrives in the model’s context window. That is the whole story. The agent can summarize it, and then the conversation ends and the data is gone. If the response was a settlement report, a subscriber export, or three years of hourly weather, its useful life was one chat. On a data platform, the same call has somewhere to go. Plexara streams an API response into the portal as a saved asset, up to a hundred megabytes without ever passing through the model, where it sits beside the dashboards and reports the team already shares. From there it can be queried with SQL next to warehouse tables, cited by a knowledge page, or handed to a colleague as a link. That difference compounds. An agent whose API results become durable, queryable artifacts is doing analysis. An agent whose API results evaporate at the end of the conversation is doing recall, and every future question starts from zero. [Image: The portal's asset viewer showing a revenue dashboard saved as an asset: a version picker on v5, a feedback thread with one open item, download and share controls, and the rendered dashboard with KPI tiles, a revenue-by-region bar chart, and a top-products table.] Where an answer lands on a data platform: a saved asset with a version history, a feedback thread, and a share control. A response an agent exports through the gateway gets this same viewer, which is the difference between an artifact a team works from and a payload that expired with the chat. ### Permission has a grain, and apps are too coarse Catalog platforms typically govern at the grain of the app: this agent may use the CRM, that one may not. But the dangerous distinctions live inside an app. Reading a campaign’s delivery numbers and sending a campaign are the same connector, and an approval that covers both is an approval nobody actually meant to give. Plexara scopes API access at the grain of the route. A persona’s policy allows or denies each combination of connection, method, and path, so a marketing analyst can read everything on the campaign system, trigger exactly one kind of sync, and touch nothing else. Access is closed by default, and an operation a persona cannot call is invisible to the agent rather than merely refused. The same grain applies to accountability. Every gateway call writes an audit record with the acting user, the operation, the stated purpose, and how it turned out, reviewable in the portal alongside every other kind of platform activity. When an agent acts on a production system, "what exactly happened" has to be a query, not an investigation. ### What the platform remembers about an API Production APIs have personalities. One returns timestamps in UTC while the team plans in Pacific. One silently ignores a parameter instead of erroring. One reports a per-item metric that must never be summed. Teams pay for these lessons in wrong numbers, and with a bare connector they pay repeatedly, because nothing retains what was learned. On Plexara, those lessons become [knowledge pages attached to the connection](https://plexara.io/learning/insights/knowledge-application-turns-usage-into-documentation). The quirks of a social analytics API, the join key a media API actually honors, the field mappings that differ across two state transportation services: each is documented once, and every later session inherits the correction before it can repeat the mistake. A tool catalog treats each session as the first. A platform that accumulates knowledge treats each session as the latest, and the gap between those two widens every week the system is in use. ### A handful of tools, an unbounded catalog There is also a mechanical problem with reach measured in thousands of actions: an agent cannot carry thousands of tool definitions in context, and [piling on tools makes it worse at choosing, not better](https://plexara.io/learning/insights/why-more-tools-wont-make-your-agent-smarter). Breadth delivered as tool count is breadth the agent cannot actually use. Plexara delivers breadth differently. The agent holds a small, fixed set of gateway tools, and each connected API contributes operations to a [versioned catalog](https://plexara.io/learning/insights/versioned-api-catalogs) the agent searches by intent, with results ranked by meaning as well as keywords. One production deployment exposes a fundraising CRM with 577 operations this way; the agent finds the one it needs by describing the goal, retrieves that operation’s schema on demand, and carries none of the other 576. The same discovery surface spans the rest of the platform: one search ranks API endpoints beside warehouse tables, knowledge pages, and saved assets, so the agent is choosing among everything the organization knows, not everything a connector vendor sells. ### Choose by the question you are answering None of this makes tool catalogs the wrong product. They are built for breadth across consumer and workplace apps, and for teams whose agents mostly perform discrete personal tasks, they deliver it. The adjacent category of [MCP traffic gateways](https://plexara.io/learning/insights/why-mcp-gateways-are-not-enough) is likewise solving a real problem, one layer below this one. The choice turns on the question your agent exists to answer. If the question is "book the meeting and post the summary," a catalog suffices. If the question is "why did this region miss forecast, and push the corrected audience before Thursday’s send," the API call is one step in a chain that runs through the warehouse, the catalog of what the data means, and the record of what the team has already learned. That chain is the platform, and a connector cannot supply it from outside. Plexara’s [API gateway](https://plexara.io/product/api-gateway) exists to put remote systems inside that chain: reached through the same search, scoped by the same personas, audited in the same log, and feeding the same accumulating knowledge as everything else the agent touches. On this page [Previous What one person teaches, the whole team gets](https://plexara.io/learning/insights/what-one-person-teaches-the-whole-team-gets) [Next The public data your warehouse is missing](https://plexara.io/learning/insights/the-public-data-your-warehouse-is-missing) ### Related reading philosophy [Philosophy 101 - What is a Large Language Model? LLMs predict the next token from patterns learned across trillions of training examples. What that means, why it produces fluent reasoning, and its limits.](https://plexara.io/learning/ai-concepts/what-is-a-large-language-model) [Philosophy 104 - Frontier models, specialized models, and why enterprise AI uses both Frontier models bring world knowledge; small local embedding models power memory and catalog search. Knowing each role designs AI systems that work.](https://plexara.io/learning/ai-concepts/frontier-models-explained) [Philosophy 401 - Prompts are the new SOPs You work with the agent for an hour to get one report exactly right, with a year-over-year cut, holiday annotations, and storm-closure markers. The agent saves durable business knowledge on its own. But that specialized report is not institutional knowledge, it is a procedure. This article draws the line between the two, and makes the case that a saved prompt is the standard operating procedure for an AI-run job.](https://plexara.io/learning/prompts/prompts-are-the-new-sops) --- # The public data your warehouse is missing URL: https://plexara.io/learning/insights/the-public-data-your-warehouse-is-missing/ > The federal statistical system publishes some of the best-maintained data in the world through free APIs: demographics, income, employment, weather, traffic. It rarely reaches a company warehouse because the friction lived in the plumbing. Give an agent a governed gateway to these sources and the friction is gone. Field notes / integration Aug 22, 2026 ## The public data your warehouse is missing The federal statistical system publishes some of the best-maintained data in the world through free APIs: demographics, income, employment, weather, traffic. It rarely reaches a company warehouse because the friction lived in the plumbing. Give an agent a governed gateway to these sources and the friction is gone. 8-minute read Integration On this page ### The data you already paid for The United States runs one of the most thorough measurement programs in the world. The Census Bureau surveys income, age, housing, and business activity down to neighborhood scale through the [American Community Survey](https://www.census.gov/data/developers/data-sets/acs-5year.html). The [Bureau of Economic Analysis](https://apps.bea.gov/api/) publishes county-level income and GDP. The [Bureau of Labor Statistics](https://www.bls.gov/developers/) tracks employment monthly for every county. The [National Weather Service](https://www.weather.gov/documentation/services-web-api) issues the forecast of record for every point in the country, and state transportation departments count the traffic on nearly every significant road. All of it is public, current, and free through documented APIs. Almost none of it sits next to company data where it could do work. The reasons were never about value. Each source has its own request format, its own vocabulary of series codes and variable names, its own geographic identifiers, and its own quirks. Getting one of them into a warehouse was an integration project; getting seven in was a roadmap. So trade-area demographics stayed in a consultant’s slide deck, and weather stayed in everyone’s intuition. That calculus changes when the consumer is an agent instead of a pipeline. The friction was always in the plumbing, and the plumbing is what a governed API gateway removes. Everything that follows in this article is drawn from live calls: the figures below were fetched through a Plexara deployment’s public-data connections while it was being written, and each one names its source and vintage. ### An address becomes a join key The unlock is geographic. The federal statistical system shares a common vocabulary of geography codes, and the Census Bureau publishes a [free geocoder](https://geocoding.geo.census.gov/geocoder/) that translates the addresses a business already has into it. One call resolves a street address to its census tract and county; a batch call processes ten thousand addresses from a single upload; a reverse call works backward from coordinates. Here is what that looks like against a real address. Wichita’s city hall resolves, in one call and under a second, to census tract 43.01 in Sedgwick County, Kansas, with the county code, block group, and coordinates attached. That one translation makes everything else joinable. Demographics, business counts, income, and unemployment all key on the tract and county codes the geocoder returns, and the coordinates are exactly what the weather and traffic services take as input. A store list becomes a set of keys into the entire public statistical system. A real trace, one call geocodeAddressToFips · “455 N Main St, Wichita, KS 67202” matched address 455 N MAIN ST, WICHITA, KS, 67202 census tract 43.01 (GEOID 20173004301) county Sedgwick County, KS (20-173) block group 2 coordinates 37.6926, -97.3383 An actual response from the Census Geocoder's onelineaddress operation, invoked through a Plexara deployment's census-geocoder connection on 2026-08-19. The address is Wichita's city hall; the round trip took 648 milliseconds. Every identifier below is a join key into the rest of the tour. ### What each source answers The roster below is not hypothetical. Every source on it runs today as a cataloged connection on production Plexara deployments, where a retail operator’s agents use them for site evaluation and market analysis. The American Community Survey answers who lives in a trade area: median household income, population, age structure, and housing, down to the block group, with pre-computed profile tables when percentages are all you need. [County Business Patterns](https://www.census.gov/data/developers/data-sets/cbp-zbp/cbp-api.html) counts the competition by industry. Population Estimates says whether the market is growing. The Bureau of Economic Analysis adds per-capita income and county GDP; the Bureau of Labor Statistics adds the monthly unemployment series behind local spending power. The National Weather Service contributes two different things: active severe-weather alerts for operations today, and the official point forecast for the week ahead. State transportation departments publish annual average daily traffic for road segments, which is the number a site-selection analysis wants first. Alongside the government sources sits [Open-Meteo](https://open-meteo.com/), an open archive of hourly weather history deep enough to backtest years of demand against the conditions that shaped it. Eight sources, zero license fees Census Bureau ##### American Community Survey Median household income, age, population, and housing down to the census tract [API documentation](https://www.census.gov/data/developers/data-sets/acs-5year.html) Census Bureau ##### Census Geocoder Turns any street address into the tract and county codes the other sources key on [API documentation](https://geocoding.geo.census.gov/geocoder/) Census Bureau ##### County Business Patterns How many competing businesses operate in a county, by industry [API documentation](https://www.census.gov/data/developers/data-sets/cbp-zbp/cbp-api.html) Census Bureau ##### Population Estimates Annual county population and whether a market is growing or shrinking [API documentation](https://www.census.gov/data/developers/data-sets/popest-popproj.html) Bureau of Economic Analysis ##### Regional accounts Per-capita personal income and GDP by county and industry [API documentation](https://apps.bea.gov/api/) Bureau of Labor Statistics ##### Local unemployment series Monthly county unemployment rate, labor force, and employment level [API documentation](https://www.bls.gov/developers/) National Weather Service ##### Forecasts and alerts The official forecast of record and active severe weather warnings for any point [API documentation](https://www.weather.gov/documentation/services-web-api) State transportation departments ##### Traffic counts Annual average daily traffic on the road segments near any location [API documentation](https://highways.dot.gov/highway-policy-information/hpms) Every source here is a public API running as a cataloged connection on production Plexara deployments today. Each card links to the publisher's own developer documentation. ### A trade area in five calls Put the join spine and the sources together and a market comparison stops being a project. The table below profiles three metro counties in a two-state trade area: five gateway calls, made while this article was being written, no key management, no format wrangling, and every number traceable to a federal table and vintage. The numbers carry an analysis on their own. One county pairs the region’s highest median income with its lowest retail density per capita. Another trails it by nearly forty thousand dollars of median household income and runs the highest unemployment of the three. A revenue-per-store comparison across those markets that ignores this context is not a comparison; it is a coin flip attributed to management. This is also what "instantly usable" means in practice. Nothing here was staged into the warehouse first. The agent asked each API for exactly the slice it needed, joined on the county codes, and the analyst read the result minutes after asking the question. The screen an agent assembles | Three metro counties | Sedgwick County, KS | Johnson County, KS | Jackson County, MO | | --- | --- | --- | --- | | Median household income ACS 2023 5-year, table B19013 | $67,675 | $107,261 | $67,178 | | Per-capita income ACS 2023 5-year, table B19301 | $36,699 | $58,292 | $38,344 | | Population ACS 2023 5-year, table B01003 | 524,810 | 614,764 | 717,021 | | Retail establishments County Business Patterns 2022, NAICS 44-45 | 1,624 | 1,816 | 2,165 | | Unemployment, June 2026 BLS local area series, preliminary | 4.4% | 3.8% | 3.6% | Live values, not illustrations: every number in this table was returned by the Census Bureau and Bureau of Labor Statistics APIs on 2026-08-19, fetched through a Plexara deployment's census and bls connections in five gateway calls. The BLS June figures carry the bureau's own preliminary flag. ### Correlation in one session, not one quarter What makes these sources interesting is never any one of them. It is the join against private data, and weather is the sharpest example. The figure below is twelve weekends of real Wichita precipitation from the Open-Meteo archive, the kind of series an agent lays directly under a weekly sales curve. For a seasonal retailer, one bar in that strip matters more than the rest: seven tenths of an inch of rain on the July 4 weekend itself, the highest-stakes trading days of the year. A demand dip on that weekend explains itself differently with the precipitation series in view, and a staffing plan for the next holiday reads differently next to the forecast of record and an active heat advisory. Questions that once justified a consulting engagement become questions an analyst asks before lunch. When a result should outlive the session, it does. The agent exports the assembled dataset as a portal asset, queryable with SQL beside the warehouse, and the analysis it supports is [shared from the portal](https://plexara.io/learning/insights/what-you-keep-if-you-leave) rather than pasted into a thread. Twelve weekends in Wichita 0.31 May 30 0.85 Jun 6 0.62 Jun 13 0.96 Jun 20 0.07 Jun 27 0.70 Jul 4 0.08 Jul 11 0.16 Jul 18 0.00 Jul 25 0.00 Aug 1 0.18 Aug 8 0.05 Aug 15 Weekend precipitation, inches · 37.69N 97.33W · the July 4 weekend is highlighted Saturday plus Sunday precipitation for every summer weekend of 2026, from the Open-Meteo historical archive via a deployment's open-meteo connection, fetched 2026-08-19. For a seasonal retailer, the 0.70 inches that fell on the July 4 weekend is not weather trivia; it is the explanation a demand chart cannot supply on its own. ### Why a gateway and not a script An engineer could script any one of these calls in an afternoon, which invites the question of what the gateway adds. The answer is everything around the call. Each source is a cataloged connection whose operations the agent finds by intent, so "median household income for this tract" locates the right survey table without anyone memorizing variable codes. Requests are authenticated by the platform, and any credential a source requires stays server-side, never in a prompt. The Census Bureau’s data API now requires a registered key, which is exactly the kind of detail that belongs in a connection, not in every analyst’s environment. The lessons accumulate too. The batch limits on the geocoder, the field mappings that differ between two states’ traffic services, the preliminary flag on the latest unemployment month: on the deployments described here, each of those lives in a knowledge page attached to the connection, teaching every future session what the first one had to learn. The result is public data with the same standing as the warehouse: discoverable through the same search, governed by the same personas, documented in the same knowledge graph, and available to [the same agent that can also act on what it finds](https://plexara.io/learning/insights/when-the-answer-is-an-action). The best data your analysis is missing was free all along. What it cost was friction, and the friction is what the platform absorbed. Strategic takeaway #### Your warehouse knows what happened. Public data knows the conditions. Sales history says a location underperformed. Public data says the county trails its neighbor by forty thousand dollars of median income, carries the higher unemployment rate, and took rain on its two biggest weekends. Analysis that can reach both, in one session, keyed on geography resolved once, is the difference between reporting a number and explaining it. Further Reading - [American Community Survey 5-Year Data API U.S. Census Bureau Tables B19013, B19301, and B01003 supplied the income and population figures in this article.](https://www.census.gov/data/developers/data-sets/acs-5year.html) - [Census Geocoder U.S. Census Bureau The address-to-geography service behind the trace shown in this article, including batch geocoding.](https://geocoding.geo.census.gov/geocoder/) - [County Business Patterns API U.S. Census Bureau Source of the retail establishment counts (NAICS 44-45, 2022 vintage).](https://www.census.gov/data/developers/data-sets/cbp-zbp/cbp-api.html) - [BLS Public Data API U.S. Bureau of Labor Statistics The timeseries endpoint behind the local area unemployment figures.](https://www.bls.gov/developers/) - [Regional data API U.S. Bureau of Economic Analysis County per-capita personal income, total personal income, and GDP by industry.](https://apps.bea.gov/api/) - [API web service documentation National Weather Service Point-to-grid resolution, the forecast of record, and active alerts.](https://www.weather.gov/documentation/services-web-api) - [Open-Meteo historical weather API Open-Meteo The open archive behind the weekend precipitation figure.](https://open-meteo.com/) On this page [Previous A tool catalog is not a data platform](https://plexara.io/learning/insights/a-tool-catalog-is-not-a-data-platform) [Next When the answer is an action](https://plexara.io/learning/insights/when-the-answer-is-an-action) ### Related reading integration [Integration 110 - Is MCP just an API wrapper? MCP is not a replacement for your APIs and not a thin proxy. It is an application layer on top, like a website is an application layer on top of its APIs.](https://plexara.io/learning/ai-concepts/mcp-vs-apis) [Integration 606 - Scripts as skills: the weekly review the agent runs on your business The capstone. Three scripts (category velocity, the supplier quote margin review, regional weather context) attached to one prompt, so serving the prompt carries each script’s contract and last successful output and the agent runs them for fresh numbers instead of re-deriving them. The agent then reads the outputs against the seasonality calendar, the returns policy, the store formats, and the stock health bands, and produces the week’s action items: promote, discount, discontinue or renegotiate, watch, each with its figure. The scripts did the data work; the model did the judgment; neither is rebuilt next week.](https://plexara.io/learning/automations/scripts-as-skills-the-weekly-review) [Integration Two front doors, one governed surface Plexara exposes the same governed surface through an MCP server and a REST API. SDKs connect to both, custom tools extend it, and every path shares one identity, one audit log, and one persona model.](https://plexara.io/learning/insights/the-developer-surface) --- # When the answer is an action URL: https://plexara.io/learning/insights/when-the-answer-is-an-action/ > Business intelligence has always ended at a finding: the analysis stops, and the action moves to other tools, other people, and next week. An agent that reaches remote systems through a governed API gateway closes that gap. The same session that finds the audience pushes it, schedules the send, and verifies the result. Field notes / architecture Aug 30, 2026 ## When the answer is an action Business intelligence has always ended at a finding: the analysis stops, and the action moves to other tools, other people, and next week. An agent that reaches remote systems through a governed API gateway closes that gap. The same session that finds the audience pushes it, schedules the send, and verifies the result. 8-minute read Architecture On this page ### The oldest gap in analytics An analyst finds twelve thousand lapsed members whose giving history says they would respond to a renewal appeal. That is a good morning’s work, and in most organizations it is also where the work stops. The finding goes into a deck. The segment has to reach the email platform, which means an export, a ticket, a colleague with the right login, and a send that happens a week later against a list that has already drifted. Business intelligence has lived with this gap for forty years. The systems that hold the answers are read-only by design, and the systems that take the actions belong to other teams. Every insight pays a toll in handoffs, and the toll is measured in days. The interesting property of an agent connected over MCP is that the gap is no longer structural. An agent that can query the warehouse can, through the same platform, call the systems where actions happen. The question stops being whether the loop can close and becomes whether it can close safely. The last mile of an analysis Analysis, then a handoff ##### The finding stops at a report - The agent identifies the audience and writes it up - Someone exports a CSV and uploads it into the campaign tool - The send happens days later, against a list that has already drifted - No record connects the action back to the analysis that justified it Analysis, then the action ##### The finding carries its action - The same session pushes the audience through the sync it found - The campaign is scheduled through the same governed surface - Every call is recorded with who made it, what it did, and why - Delivery numbers come back the next morning for verification ### One surface, three kinds of truth Plexara’s API gateway makes any service that describes itself with an OpenAPI document part of the platform: registered as a connection, its operations cataloged, searchable, and callable through a handful of fixed agent tools. We have written before about what that does for [seeing across the stack](https://plexara.io/learning/insights/when-an-agent-can-see-the-whole-stack). The part that changes daily work is that the same surface carries writes. That puts three kinds of truth in one place. The warehouse holds what happened: transactions, memberships, viewership, settled payments. The catalog and knowledge graph hold what it means: definitions, lineage, and the corrections a team has accumulated. And the gateway holds what is true right now at the edges, in the systems the data came from and the systems where the next action lands. Production deployments show the range. One connects a fundraising CRM with 577 operations, an email engagement platform, a reverse-ETL service, a social analytics API, an event guest-list system, and the pipeline and cluster infrastructure underneath. Another connects payment settlement reporting, seven public data services, and its own monitoring stack. The agent discovers the operation it needs by intent, ranked by meaning as well as keywords, and pulls the request schema only when it is about to call. ### Reading the edges Most gateway traffic is reads, and the reads alone justify the connection. The warehouse’s copy of a constituent is hours old; the CRM’s copy is the ground truth, one call away. The settlement processor’s view of yesterday’s card batches either reconciles with the warehouse or it does not, and an agent that can query both sides finds out in one session. When a number looks wrong, the agent checks the pipeline that loaded it and the cluster that pipeline runs on before anyone writes an incident ticket. Responses do not have to squeeze through the model to be useful. A large result streams directly into the portal as a saved asset, up to a hundred megabytes, where it can be queried with SQL beside the warehouse and cited by the analysis it feeds. The gateway also surfaces pagination rather than pretending an API returned everything, so a truncated read announces itself instead of becoming a silently wrong total. ### Acting on them Now the morning’s finding again. The twelve thousand lapsed members exist as a query result. On the same surface, the agent triggers the reverse-ETL sync that pushes the segment to the email platform, schedules the renewal campaign there, and comes back the next day to read the delivery and open numbers from the engagement platform’s own reporting. One session, one audit trail, no exports. The same shape recurs across operations. The ingestion flow that quietly stopped gets its run state changed instead of a ticket. The guest list for Thursday’s event gets updated in the events system the moment the RSVP report reveals the mistake. Each of these was always one API call; what was missing was a governed way to let the system that found the problem make the call. This is where research, business intelligence, and operations stop being three tools. The agent that correlates public demographics with sales is the same agent that reads pipeline health and the same agent that pushes the corrected audience, and every one of those acts draws on the same accumulated knowledge of what the data means. At production scale that traffic is substantial, and the portal renders it as an operational surface of its own. [Image: The API Gateway tab of the portal's admin dashboard over a 24-hour window: 18,432 inbound requests, 27,420 outbound calls, a 3.7 percent outbound error rate, and 190 upstream server errors, above a status-mix chart of requests per second by response class and a weekday-by-hour usage heatmap.] A day of gateway traffic in the portal’s admin dashboard: every outbound call counted, classed by response status, and drillable to the audit event behind it. This is what “on the record” looks like when an agent works remote systems all day. ### What makes acting safe Letting an agent write to production systems is a governance question before it is a capability question, and the gateway answers it structurally. Access is closed by default: a persona sees only the connections it was granted, and within a connection, policy allows or denies each method and path. Read everything, trigger one specific sync, create nothing: that sentence is expressible as policy, and the operations outside it are invisible to the agent rather than merely refused. Credentials never enter the loop. The platform holds each connection’s authentication, from rotating OAuth tokens to client certificates, and applies it server-side when a call is made. The agent works with operations and intents; it has nothing to leak. And every call is on the record. Each invocation writes an audit event with the acting user, the operation, the stated purpose, and the outcome, reviewable in the portal’s activity views alongside queries and knowledge changes. [Execution-time governance](https://plexara.io/learning/insights/governance-at-execution-time) is what makes the difference between an agent that could act and an agent a team lets act. Permission at the grain of a route Marketing analyst persona · campaign connection - GET /api/campaigns/** allowed - GET /api/v1/syncs/** allowed - POST /api/v1/syncs/*/trigger allowed - POST /api/campaigns/create denied - DELETE /api/** denied - every route not matched above denied by default A persona's policy on one connection: read anything, trigger exactly one kind of action, and everything else stays closed. The agent never sees an operation its persona cannot call. ### The platform claim Assembled, this is a different product category than an AI assistant that answers questions. A question-answering system ends at a finding. A platform whose agents read the warehouse, consult the knowledge graph, reach the ground truth at the edges, and act on the systems that need changing is a working surface for research, business intelligence, and operations at once, with each activity strengthening the context the others run on. The gap between finding and doing was never a law of nature. It was an artifact of systems that could not safely share a surface, and a [governed API gateway](https://plexara.io/product/api-gateway) is what retires it. The full picture of what connects today is on the [integrations page](https://plexara.io/product/integrations), and the [governance model](https://plexara.io/product/governance) shows the policy grain that makes acting defensible. Strategic takeaway #### Control is a data problem. The reason to let an agent act through the platform that holds your warehouse and your knowledge is not convenience. It is that a defensible action needs the same things a defensible answer needs: current data, documented meaning, scoped permission, and a record of what happened. A platform that already provides those for reading provides them for acting, and nothing bolted on beside it does. On this page [Previous The public data your warehouse is missing](https://plexara.io/learning/insights/the-public-data-your-warehouse-is-missing) [Next The spreadsheet that joins your warehouse](https://plexara.io/learning/insights/the-spreadsheet-that-joins-your-warehouse) ### Related reading architecture [Architecture 103 - Context, compression, and memory The context window is a model's working memory. Each session balances keeping, compressing, or clearing it. Plexara adds enterprise memory on top.](https://plexara.io/learning/ai-concepts/context-windows-and-tokens) [Architecture 201 - Anatomy of a Plexara MCP 201 shows what is actually in the box on a Plexara server: the tool inventory by toolkit, the four content layers, the interactive apps a tool result can carry, and the memory, knowledge, and governance underneath. This lesson is the map.](https://plexara.io/learning/mcp/what-is-an-mcp) [Architecture Five kinds of memory, and how each comes back A fact, an incident, a person, a link, and a habit are five different kinds of knowledge. Plexara stores each as its own dimension and recalls it the way that kind needs, which is what makes memory across sessions feel like memory rather than search.](https://plexara.io/learning/insights/five-kinds-of-memory) --- # The spreadsheet that joins your warehouse URL: https://plexara.io/learning/insights/the-spreadsheet-that-joins-your-warehouse/ > Ad-hoc CSVs are the most common data silo in business: valuable exactly when joined, stranded in inboxes because loading them was a project. Plexara registers an uploaded CSV, or one an agent built, as a queryable table over the file where it sits, so the join runs in the warehouse instead of the context window. Field notes / product Sep 5, 2026 ## The spreadsheet that joins your warehouse Ad-hoc CSVs are the most common data silo in business: valuable exactly when joined, stranded in inboxes because loading them was a project. Plexara registers an uploaded CSV, or one an agent built, as a queryable table over the file where it sits, so the join runs in the warehouse instead of the context window. 9-minute read Product On this page ### The most common silo in business The vendor sends a rebate schedule by email every quarter. The real-estate team keeps the lease costs for every location in a spreadsheet. An agency delivers a target list as an attachment, and a SaaS tool nobody ever integrated offers its records only as an export. Every business runs on files like these, and each becomes useful when it is joined against the data the company already has. Getting the file somewhere joinable has always been the obstacle. The standard path ran through a request to data engineering, a staging table, and a loader that somebody now owns for a file that changes quarterly, or once. For a file needed one time, nobody files that ticket. So the analysis happens by hand in a spreadsheet, against an export that was stale before the lookup finished, or it does not happen. Plenty of software accepts a CSV upload, which is how the problem usually hides. A BI tool takes the file and makes it a dataset its own dashboards can see. A campaign tool takes it and makes it an audience. The upload succeeds, and the silo has moved into a different product. What none of that produces is the file sitting beside the warehouse as a peer: one more table, in the same SQL, under the same governance. ### What an agent does with a CSV, without help Hand the same file to an AI agent and its first instinct is to read it. Reading means the whole file passes through the context window, so a three-hundred-row spreadsheet costs thousands of tokens before the first question is asked, and a fifty-thousand-row vendor file does not fit at all. Whatever the agent concludes, the spend repeats next session, because nothing durable came of it. The workarounds are worse. An agent can fetch both sides and match rows in prose, which performs the join inside the model itself, token by token, with an error rate that grows with the row count. Or it can dribble the file into a database as batches of INSERT statements, which is slow, needs write access to somewhere, and leaves a half-loaded table when the session ends early. A short list of keys needs no table at all: a handful of pasted ids joins inline as a VALUES clause through an ordinary read-only query, and Plexara tells the agent so. Registration is for files with hundreds or hundreds of thousands of rows, where the join belongs in a query engine. CSV handling, with and without a registered table Whole file in context ##### The file goes through the context window - The agent reads the whole file into context, spending tokens on every row - Joins happen agent-side: fetch both sides, match them in prose - A fifty-thousand-row file does not fit at all - The work is not repeatable: next session, same parsing, same spend Register once, query by name ##### The file becomes a table - One registration makes the file queryable where it sits - The join runs in the query engine, and only the answer reaches the agent - Row count stops mattering: 300 rows or 300,000 query the same way - Search returns the table name and a sample join on the file from then on ### Registration, not ingestion Files reach Plexara two ways. A person uploads reference material into the portal, where it becomes a managed resource with versions, scoping, and usage tracking. Or an agent saves something it built as a portal asset: an export from a warehouse query, a dataset assembled from [gateway API calls](https://plexara.io/learning/insights/the-public-data-your-warehouse-is-missing), a working file another tool produced. Either kind of CSV can be registered as a table. Registration is deliberately not ingestion. The platform reads the file, takes column names from its header row, and creates an external table over the object where it already sits, in a scratch schema set aside for working tables. Nothing is copied, no pipeline is scheduled, and no storage is doubled. Under the surface this is Trino reading CSV through its Hive support, directly against the same object store that holds the platform’s files; to the person or agent doing the registering, it is one action with a table name as the answer. From that moment the file and the table are linked. A search that finds the file returns the registered table’s name and a sample join on the same hit, so an agent that finds the file later starts from SQL rather than from the loading problem. And because the table reads the object in place, a vendor drop that overwrites its file changes the next query’s answer with no further action from anyone. Registration flow 1 · A file lands A person uploads it to the resource library Or an agent saves one it built as an asset store_lease_costs_fy2026.csv store_id,annual_base_rent_usd,annual_cam_usd,lease_end 1,78900,11800,2026-04-01 2,50700,8500,2027-05-01 3,65100,14100,2030-01-01 2 · One registration The platform reads the file, takes column names from its header, and creates an external table over the object where it already sits. Nothing is copied and no pipeline runs. - Columns come from the header row - The table name carries your persona - An audit event records who and what 3 · Queryable beside everything scratch.uploads.store_lease_costs JOIN · ON store_id warehouse.public.stores warehouse.public.transactions The file reads as rows in the same SQL surface as the warehouse, so the join is one statement and only its answer spends tokens. A registration is a pointer and a name, not an import. The object never moves: the table reads the file where it lives, so a vendor drop that overwrites its file changes the next query's answer with no further action. ### A worked example: lease costs against revenue Everything in this section ran on a live Plexara deployment, the demo environment seeded with a 303-store retail chain, while the article was being written. The file is the classic case: a FY2026 lease schedule, one row per store, carrying annual base rent, common-area maintenance charges, and the lease end date. It is exactly the spreadsheet a real-estate team keeps and a warehouse never sees. The agent saved the schedule as a portal asset and registered it with a single call. The response below is complete: the table name, the columns read from the header, and the one fact worth knowing before writing SQL, which is that a CSV’s columns arrive as VARCHAR and join to typed warehouse columns through a cast. Registration call and response manage_table action=register reference=mcp:asset:eda2a7a0… connection=scratch query_table scratch.uploads.admin_store_lease_costs columns store_id · annual_base_rent_usd · annual_cam_usd · lease_end connection scratch stale false note Every column is VARCHAR, so a join to a typed column needs a CAST. The actual response from a registration made on the Plexara demo deployment on 2026-08-23. The 303-row lease schedule had been saved as a portal asset moments earlier; this was the only call between the saved file and SQL. The name carries the registering persona, because the scratch schema is shared. [Image: Plexara asset viewer showing a CSV asset with its Query as a table panel: the registered table, its columns, and the control to drop it] The same surface in the portal. A CSV asset's page carries a Query as a table panel: pick a connection, optionally name the table, and the columns come back with the registration. The panel also shows what is already registered and who registered it. ### The join The file exists to answer one question: which stores pay rent out of proportion to what they sell. That is a three-way join, lease costs against the store dimension against a year of transactions, and with the registration in place it is one statement. The chain’s median store spends 12.8 percent of revenue on occupancy. Twenty stores sit above 25 percent, five above 30, and the worst, a Springfield, California store, pays $143,800 in occupancy against $340,536 in revenue, 42.2 percent, with the lease up for renewal in June 2026. Two things did not happen: the file never entered the context window, and the agent never read the source rows. It read eight result rows, because the query engine did the work and only the answer traveled. The statement is recorded, the result was saved as an asset with its provenance attached, and when next quarter’s schedule arrives, the same join runs against it. The join ``` WITH revenue AS ( SELECT store_id, SUM(total) AS revenue_2025 FROM warehouse.public.transactions WHERE transaction_date >= DATE '2025-01-01' AND transaction_date < DATE '2026-01-01' GROUP BY store_id ) SELECT s.store_name, s.city, s.state, CAST(l.annual_base_rent_usd AS integer) + CAST(l.annual_cam_usd AS integer) AS occupancy_cost, ROUND(100.0 * (CAST(l.annual_base_rent_usd AS integer) + CAST(l.annual_cam_usd AS integer)) / r.revenue_2025, 1) AS occupancy_pct FROM scratch.uploads.admin_store_lease_costs l JOIN warehouse.public.stores s ON s.store_id = CAST(l.store_id AS integer) JOIN revenue r ON r.store_id = s.store_id ORDER BY occupancy_pct DESC ``` | Store | 2025 revenue | Occupancy cost | Share | Lease ends | | --- | --- | --- | --- | --- | | Store #36 Springfield, CA | $340,536 | $143,800 | 42.2% | Jun 2026 | | Store #292 Ashland, WA | $362,966 | $149,600 | 41.2% | May 2028 | | Store #211 Manchester, OH | $415,759 | $152,600 | 36.7% | Nov 2026 | | Store #138 Kingston, MA | $462,066 | $145,600 | 31.5% | Oct 2029 | | Store #128 Bristol, MD | $304,314 | $95,700 | 31.5% | Nov 2029 | The statement and its worst five rows, run live against the demo deployment on 2026-08-23. Registered columns arrive as VARCHAR, a rule of the storage format, so joins to typed columns cast; the registration response includes a sample join showing the cast. 303 Rows in the lease spreadsheet, registered as a table in a single call One file, one registration 12.8 % Median share of revenue the chain pays in rent and common-area charges Registered CSV joined to 2025 revenue 5 Stores whose annual rent and CAM exceed 30 percent of 2025 revenue Registered CSV joined to 2025 revenue ### Versions, staleness, and refused files A registered table serves the content that was current when it was registered. Every edit to a portal asset and every revision of a managed resource writes a new version, and a table that silently followed the newest version would change the results of any report built on it. So the table stays put, and everywhere the registration appears, the portal panel, the file’s search hit, the agent’s own listing, it is flagged as stale until someone registers again, which takes the table forward in one step. A file overwritten in place, the shape of a recurring vendor drop, needs no re-registration at all. Registration also refuses files a line-based query engine would misread. A spreadsheet export with line breaks inside quoted cells is legal CSV under [RFC 4180](https://www.rfc-editor.org/rfc/rfc4180) and parses cleanly in every ordinary reader, but a line-based reader would tear each such row into fragments and return them as rows without any error. Plexara reads the whole file before creating anything, names the specific problem, and offers a correction: one control that writes a repaired version through the file’s own version trail, with the original preserved beneath it, and registers the result. The governance is the same as everywhere else on the platform. Every registration writes an audit event, including the failed attempts. Registering requires the authority to change the file, not merely read it, because a registered table is readable by everyone granted the connection; the table name carries the registering persona so a shared schema stays legible; and dropping a table belongs to the person who registered it, or an administrator. Deleting the file takes every table registered over it along. [Image: Plexara resource dialog showing a registered table marked stale because the file has a newer revision than the one the table serves] A registration the file has moved on from. The table keeps answering with the revision it was registered against, which is correct SQL and still behind, so every surface that shows the registration says so. Registering again, same connection and name, moves it forward. Nothing moves it forward silently. [Image: Plexara resource dialog refusing to register a CSV whose cells contain line breaks, naming the affected rows and offering a one-control correction] A CSV the query engine cannot read as stored: line breaks inside quoted cells would tear rows into fragments in a table that reported no error. Registration reads the whole file first, refuses with the specific problem, and offers the correction, which writes a fixed version through the file's own version trail and registers that. ### The gap this closes The gap sits between the warehouse and the agent, where ad-hoc data lives: the attachments, the exports, the schedules, the lists. Those files used to face a choice between an engineering project and a silo. Now the path is upload, register, join, and it works in both directions, for the spreadsheet a person brings to the platform and for the dataset an agent assembles out of API calls and saves as an asset. This does not replace pipelines, and is not trying to. Data that arrives on schedule at volume belongs in the warehouse proper, modeled and owned. The scratch schema is a working space, not a modeling layer: it is where a quarter’s analysis meets a quarter’s file. What it replaces is the ticket that was never worth filing, the one-off loader nobody wanted to own, and the analyst afternoon lost to a lookup formula. A registered table is a pointer and a name. It puts the most common file in business on the same governed, queryable surface as everything else, the day the file arrives. Further Reading - [Hive connector Trino Project The query-engine mechanism behind registered tables: external tables reading CSV files in object storage, with every column typed VARCHAR by the storage format.](https://trino.io/docs/current/connector/hive.html) - [RFC 4180: Common format and MIME type for CSV files IETF Why a spreadsheet export with line breaks inside quoted cells is legal CSV everywhere except a line-based reader, which is the case registration detects and offers to correct.](https://www.rfc-editor.org/rfc/rfc4180) On this page [Previous When the answer is an action](https://plexara.io/learning/insights/when-the-answer-is-an-action) [Next The report that runs without the agent](https://plexara.io/learning/insights/the-report-that-runs-without-the-agent) ### Related reading product [Product 102 - Tokens and your budget Every LLM interaction is priced and rate-limited in tokens. What a token is, how much text fits a budget, and how to avoid wasting tokens on useful answers.](https://plexara.io/learning/ai-concepts/tokens-and-your-budget) [Product 105 - What is an AI agent? An AI agent is not a chatbot and not magic. It is a short loop (think, call-tool, observe, think again) on top of a language model. Mental model first.](https://plexara.io/learning/ai-concepts/what-is-an-ai-agent) [Product 202 - Your first day with Plexara A new Plexara user gets connected, sends a first question, and platform_info takes over. Walks through day one and how subsequent turns inherit context.](https://plexara.io/learning/mcp/first-engagement) --- # The report that runs without the agent URL: https://plexara.io/learning/insights/the-report-that-runs-without-the-agent/ > An hour with an AI assistant produces the perfect sales report. Re-deriving it every week burns tokens on logic that is already settled. Plexara lets the agent save that logic as a script the platform runs on demand or on a schedule: reports, exports, and dashboards that stay fresh with no model in the loop. Field notes / product Sep 11, 2026 ## The report that runs without the agent An hour with an AI assistant produces the perfect sales report. Re-deriving it every week burns tokens on logic that is already settled. Plexara lets the agent save that logic as a script the platform runs on demand or on a schedule: reports, exports, and dashboards that stay fresh with no model in the loop. 10-minute read Product On this page ### The hour you should only spend once Getting a report right takes judgment. Which tables hold the truth, whether returns count against revenue, what baseline makes a Tuesday comparable to a Tuesday: an hour with an AI assistant settles questions like these well, because settling them is a conversation. By the end there is a report worth keeping, and a precise recipe for producing it. Then the report needs to exist again next week, and the economics invert. Replaying the conversation spends tokens deriving what is already derived. It takes minutes of a model working through steps whose outcome is known, needs the assistant connected and the person present, and can come back subtly different: a changed rounding, a reworded label, an alternate join that looked equivalent. For work whose entire point is that it is settled, a model in the loop is cost without benefit. Saving the conversation as a [reusable prompt](https://plexara.io/learning/insights/governed-prompts-and-relevance-search) fixes part of this, and for work that needs judgment on each run, a prompt is the right tool. But a Tuesday flash report does not need judgment on Tuesday. It needs the same queries, the same arithmetic, and the same layout, delivered before anyone asks. ### The automation gap in AI integrations Most AI data integrations stop exactly here. The assistant can answer anything interactively, and none of it survives the conversation as something that runs by itself. The standing options both give up something essential: keep asking the assistant, and pay the interactive cost forever, or hand the logic to an engineering team, which turns a settled recipe back into a ticket, a repository, a deploy, and an owner, the same path that keeps one-off files out of warehouses. Scheduled-report features in BI tools cover a narrow slice, for the dashboards that live inside them, built by the people licensed into them. What has been missing is the general form: the automation an assistant can write during the conversation where the logic was settled, that a business user then owns, inspects, and schedules without anyone opening an IDE. A recurring report, two ways A conversation per refresh ##### Ask the assistant again each time - Every refresh replays the reasoning through a model, spending tokens on logic that was settled weeks ago - The run takes minutes of agent time and needs the agent connected - Two runs can phrase, round, or even join slightly differently - Usage scales with the schedule: daily costs thirty times what monthly does A conversation once ##### Saved as a script Plexara runs - The assistant writes the settled logic down once; the platform executes it from then on - No model in the loop: a run is queries and code, finished in seconds - The same version on the same data produces the same report, every time - Running it daily, or every minute, costs no more attention and no more tokens ### A script the agent writes, the platform runs A Plexara automation is a script: a small program in a dialect of Python called Starlark, stored on the platform, versioned like a document, and executed by Plexara itself. Your assistant already knows the language, and writes the script the way it would write any code, with one difference that matters: the platform checks the work before it goes live. Validation parses the source and reports what it would reach, which queries, which connections, where output lands, so what a script does is readable without reading code. A dry run then executes it for real under the author’s own identity, with tighter limits and nothing persisted: real queries, outputs measured rather than written, and the full log back. Only a save makes a version live, and a version that does not parse cannot be saved at all. Everything in what follows ran on a live Plexara deployment, the demo environment seeded with a 303-store retail chain, while this article was being written. The automation is the classic one: a morning flash of yesterday’s revenue by region, each region held against its own four-week same-weekday baseline, with the day’s top stores. The authoring loop 1 · Write, then validate The assistant writes the script and asks the platform to read it back. Validation parses the source and reports what it would reach, before anything runs. - capabilities: query · export · publish_data - refresh targets: regional-flash - destinations: portal 2 · Dry run, as yourself A dry run executes the code for real, under the author’s own identity and access, with tighter limits and nothing kept. Real queries, measured outputs, full log. - status: succeeded · 3 queries · 2.4s - log: flash for 2025-12-15: 8 regions, 6316 transactions - nothing persisted; outputs measured, not written 3 · Save, and it runs The saved version is the version that runs, under the access its author held at the save. Any session can invoke it by name, the portal page runs it with a button, and a schedule fires it unattended. run_script portal Run schedule The loop the assistant works through, with the platform's actual responses from writing the regional flash script on the demo deployment. Validation is a static read; the dry run executes with nothing persisted; the save is what makes a version live. ### What the assistant saved The saved script is ninety-six lines: three SQL queries, arithmetic, and one publish call. Values reach SQL through named placeholders the platform binds by type, never by pasting strings together. The language enforces the rest of the discipline: no network, no filesystem, no clock, no randomness, no unbounded loops. A script touches the world only through governed platform calls, which is what makes its behavior readable before it runs and auditable after. Nobody on the team has to write this. Somebody on the team gets to read it, and that difference is the control model. The script’s portal page shows the source with syntax highlighting, its version history with each version’s author, and Run, Dry run, and Validate controls beside the editor. An analyst who wants the baseline changed from four weeks to six asks the assistant, or edits the line, and either way the save is refused if it cannot parse and recorded as a new version if it can. What the assistant saved acme-regional-flash · version 3 · 96 lines ``` day = run.params["day"] base = date.add_days(day, -28) day_rows = platform.query( """SELECT r.region_name, count(*) AS txns, sum(t.total) AS revenue FROM warehouse.public.transactions t JOIN warehouse.public.stores s ON s.store_id = t.store_id JOIN warehouse.public.regions r ON r.region_id = s.region_id WHERE t.transaction_date >= DATE :day AND t.transaction_date < date_add('day', 1, DATE :day) GROUP BY r.region_name""", connection=conn, params={"day": day}, )["rows"] platform.publish_data("regional-flash", { "day": day, "totals": {"revenue": total_revenue, "txns": total_txns}, "regions": regions, }) ``` An excerpt of the regional flash script as it is stored on the platform: a dialect of Python, with SQL bound through named placeholders and the result pushed into the dashboard's data region. The full source is on the script's portal page, readable and editable by its owner. ### Running it: no model, no tokens, under two seconds Running the saved script is one call, from any session, or the Run button on its portal page. The platform executes it: the queries run in the warehouse, the arithmetic runs in the interpreter, and nothing passes through a model. The interactive session that settled this logic cost an hour of conversation. This run cost three queries and 1.85 seconds, and it charges no tokens against anyone’s AI subscription because no AI was involved. The run is also a record. Its id, trigger, duration, query count, printed log, and outputs are stored and kept, readable by the script’s owner on the portal page and by the assistant through the same contract. When a scheduled report fails, that record is the difference between a mystery and a fix: the failure reason and the log arrive in the owner’s inbox, and the fix is an edit, a dry run, and a save. One run, and its record run_script name=acme-regional-flash args={"day": "2025-12-16"} status succeeded · trigger: tool · 1.85s queries 3 output regional-flash → portal · data refresh, 2,067 bytes · asset version 2 log flash for 2025-12-16: 8 regions, 6687 transactions run_id dpx_a11810b897a4069f4b5a59ad30f512b7 The complete response from running the saved script on the demo deployment. No model was involved: the platform executed the version on file, issued three queries, spliced two kilobytes of fresh data into the dashboard, and recorded all of it under the run's own id. ### What it produced The run pushed two kilobytes of JSON into the flash dashboard: $779,390 across 6,687 transactions on December 16, 2025, an average ticket of $116.55, eight regions ranked with their shares, and the day’s five best stores. Every region ran thirty-five to seventy-eight percent ahead of its late-November baseline, which is the demo chain’s holiday surge arriving on schedule, exactly the kind of movement a flash report exists to surface. The output kept its identity. A run does not create a new file each morning; it writes a new version of the same asset, so the dashboard holds one name, one address, and one share list while its history accumulates underneath. The version from any past run still shows exactly the numbers it showed that day, which makes the history an audit trail as much as an archive. What the dashboard showed after that run $779,390 Revenue, December 16, 2025 6,687 Transactions $116.55 Average ticket | Region | Share | Revenue | vs 4-wk avg | | --- | --- | --- | --- | | Midwest | | $169,161 | +48.2% | | Southeast | | $160,347 | +58.2% | | Mid-Atlantic | | $132,152 | +54.7% | | West | | $122,192 | +61.5% | | Southwest | | $101,575 | +35.0% | | Northeast | | $40,904 | +71.9% | | Northwest | | $38,576 | +78.2% | | Central | | $14,484 | +38.7% | The data the run pushed, as the dashboard renders it: eight regions against their own four-week same-weekday baselines. Every region runs far ahead of late November, which is the demo chain's holiday season arriving on schedule. The script computed none of this in a model; it is three SQL queries and arithmetic. ### A live dashboard that cannot touch the database A dashboard that stays fresh usually pays for it with access: a BI tool holding a standing database connection, credentials living in another vendor’s system, and every viewer triggering queries against the warehouse. The security review is about the dashboard’s reach, and the performance question is about what a wall of viewers does to the busy hours. The flash dashboard inverts the direction of the data. It is a portal document, HTML the assistant wrote once, whose single marked data region holds the numbers as JSON. The scheduled script is the only party that queries: it runs under its author’s access, computes the payload, and pushes it into the region, leaving every other byte of the document untouched. The dashboard itself holds no connection string, no credential, and no ability to ask the warehouse anything. That split settles both concerns at once. Sharing the dashboard shares numbers, never access, so the audience question and the access question come apart. Load on the warehouse is one run per refresh however many people are watching. And freshness becomes a dial rather than a compromise: schedules fire as often as once a minute, in the timezone you mean, so a floor-wall dashboard can track the morning in near real time while the warehouse sees a few small queries an hour. The presentation stays editable the whole time, because it is a document. Change a heading or a chart color in the portal and the layout edit survives every scheduled refresh, since the script rewrites only the data region. The seam between the two is checked, not assumed: a refresh against a document whose marked region has gone missing fails loudly rather than writing anywhere else. The split that removes database access from the dashboard The dashboard document - Layout, charts, and headings: edited in the portal like any document - One marked data region holds the numbers as JSON - No connection string, no credential, no query anywhere in it JSON only The scheduled script - Queries the warehouse under its author’s own access - Pushes fresh JSON into the data region on each run - Every refresh is a new version: an as-of snapshot that keeps platform.publish_data("regional-flash", payload) The presentation and the data are two halves with one seam. The dashboard is a portal document that renders whatever its data region holds; the script is the only thing that queries. Sharing the dashboard shares numbers, never access, and an old version still shows exactly the data it showed. ### The schedule, and the record it leaves A schedule is a cadence, a timezone, and the parameter values each fire binds: every weekday at 6:30, Los Angeles time, reporting on the day it fires. The portal asks for it in those words and derives the cron expression itself; a date parameter can bind the fire date, so each run records the day it was computing for and re-running it later asks the same question. Wall clocks hold across daylight-saving changes. The policies underneath are chosen for reports rather than for pipelines. A fire that arrives while the previous run is still going is recorded as skipped, not silently dropped and not queued into a pileup. After downtime, the platform runs once for the latest missed fire and counts the rest, because a burst of stale reports nobody is waiting for is worse than a visible gap. A failed scheduled run mails its owner with the reason and the log’s tail. And failures are never blindly retried: the same script on the same inputs fails the same way, so the platform records the failure once and waits for the fix. All of it lands in one place. The portal’s Scripts pages show every automation you own, its schedule in words, its next fire, and how its last run went, with a Failing tile that narrows the list to what needs attention. Runs are kept for a year. [Image: The Runs tab in the Plexara portal listing every run across a user's scripts with trigger, outcome, duration, and failure reasons in the row] Every run across your automations, newest first: what triggered it, how it ended, how long it took, and, for a failure, the reason in the row rather than behind it. [Image: A single run open in the Plexara portal showing its parameters, outputs, and the log the script printed] One run, opened: what it was given, what it wrote, and the log it printed. An output that went to the portal links to the exact asset version it produced. ### The gap this closes The interactive assistant and the standing automation have been separate worlds: one reachable by anyone who can hold a conversation, the other gated behind an engineering queue. What closes the gap is letting the conversation produce the automation, on a platform that makes unattended execution safe enough to allow: a script can never do what its author could not, holds no credentials, runs in a language that cannot reach around the platform’s governance, and leaves a complete record of every run. The economics follow from the split. Judgment stays interactive, where a model earns its cost. Repetition moves to the platform, where a run is three queries and two seconds. The hour you spent getting the report right becomes the last hour that report costs. Further Reading - [Starlark language specification Bazel Project The Python dialect Plexara scripts are written in: deterministic and hermetic by design, with no filesystem, network, or clock in the language itself.](https://github.com/bazelbuild/starlark/blob/master/spec.md) On this page [Previous The spreadsheet that joins your warehouse](https://plexara.io/learning/insights/the-spreadsheet-that-joins-your-warehouse) [Next Every call your agent makes states its purpose](https://plexara.io/learning/insights/every-call-states-its-purpose) ### Related reading product [Product 102 - Tokens and your budget Every LLM interaction is priced and rate-limited in tokens. What a token is, how much text fits a budget, and how to avoid wasting tokens on useful answers.](https://plexara.io/learning/ai-concepts/tokens-and-your-budget) [Product 105 - What is an AI agent? An AI agent is not a chatbot and not magic. It is a short loop (think, call-tool, observe, think again) on top of a language model. Mental model first.](https://plexara.io/learning/ai-concepts/what-is-an-ai-agent) [Product 202 - Your first day with Plexara A new Plexara user gets connected, sends a first question, and platform_info takes over. Walks through day one and how subsequent turns inherit context.](https://plexara.io/learning/mcp/first-engagement) --- # Every call your agent makes states its purpose URL: https://plexara.io/learning/insights/every-call-states-its-purpose/ > An AI agent that can query your warehouse leaves a question behind: what did it run, and why? On Plexara every query and API call carries the purpose the agent stated for it, every session can be opened long after it ended, and every saved report names the calls it was built from. Field notes / governance Sep 16, 2026 ## Every call your agent makes states its purpose An AI agent that can query your warehouse leaves a question behind: what did it run, and why? On Plexara every query and API call carries the purpose the agent stated for it, every session can be opened long after it ended, and every saved report names the calls it was built from. 9-minute read Governance On this page ### The question every AI data deployment gets asked When a person queries a warehouse, you can ask them what they ran and why. They can open the statement, point at the question it answered, and say whether it was for a board deck, a masking review, or a close. That conversation is still how most data teams do audit: you ask the person. An AI agent that can query the same warehouse breaks the conversation. The agent ran dozens of statements. Some failed. Some produced a dashboard. The person who asked the original question may not have seen any of them. A manager who has to sign off on AI data access, and an auditor who has to reconstruct what happened, both ask the same thing: what did it run, and why. If the only record is the chat transcript, the answer is a reconstruction. Transcripts mix the question, the false starts, the retries, and the prose around the calls. They are hard to search, they expire with the client, and they do not say which statement actually produced the dashboard someone is looking at. If the platform recorded each call with the purpose the agent stated for it, the answer is a page you can open. That is the record Plexara keeps. ### A stated purpose before every call Before Plexara runs a query or calls an API, the assistant states in one sentence what the call is for. The line is the question behind the query, not a restatement of it. SELECT * FROM finance.regional_performance LIMIT 500 is the statement. "Finding which datasets carry customer email so they can be masked." is the purpose. That distinction is the point of the line. A statement says what ran. A purpose says why anyone would have run it, in words a person who never saw the SQL can still read. It is also the only line about the call a person wrote (through the agent they are talking to), which is why it leads every row later: in My Calls, in a session timeline, in the provenance of a saved report. On the ACME demo deployment, the catalog includes "Checking whether Q3 revenue fell in the western region for the board deck." The statement under it is a SELECT against inventory.return_rates. A later reader does not have to infer the board deck from the table name. A purpose that restates the SQL ("query the return rates table") would not have been useful. The useful line names the decision the call was meant to inform. Four calls from the catalog, each with a stated purpose | Purpose | Connection | Outcome | Detail | | --- | --- | --- | --- | | Establishing the current definition of an active account for the exec summary. SQL · SELECT * FROM inventory.supply_chain_orders LIMIT 100 | acme-warehouse | satisfied | 2.3s | | Finding which datasets carry customer email so they can be masked. SQL · SELECT * FROM finance.regional_performance LIMIT 500 | acme-warehouse | satisfied | 2 later sessions | | Checking whether Q3 revenue fell in the western region for the board deck. SQL · SELECT * FROM inventory.return_rates LIMIT 1000 | acme-staging | ran | - | | Reconciling the finance close against the warehouse totals for October. SQL · SELECT * FROM retail.return_rates LIMIT 1000 | acme-warehouse | ran | - | Rows from My Calls on the ACME demo deployment. The purpose leads every row because it is the only line about the call a person wrote. Outcome is derived on each read: two of these queries were later named by an asset and read as satisfied; two succeeded and nothing has been built from them yet, so they still read as ran. ### A session you can open Activity has My Sessions beside the overview. A session is every tool call sharing one session id, readable long after it ended, as far back as audit history reaches. Each row carries the session's kind (Agent, Portal run, Script run, or Transport), the persona it ran as, how many calls it made, how many of them failed, and what it left behind. Facets narrow the list: a time window of 24 hours, 7 days, 30 days, or all time (the list opens on 7 days), session kind, sessions with at least one failed call, and sessions that saved at least one asset. The list is always your own. There is no user column. A session id belonging to someone else is answered as not found, the same answer an id that was never used gets. Administrators read every session from Admin. Open a row and the detail shows the session at a glance: calls, failures, wall-clock duration, and the assets and insights it produced. Below that is the timeline: its calls in the order they were made, each with the purpose the agent stated, the connection it went to, whether it succeeded, and how long it took. The page is addressable, so you can bookmark it. A colleague who is not an administrator will get a not-found, because a session opens only for the person who ran it. On the ACME demo, one Agent session (dps_9f2c1a4bd1c0f9e8c5a4b3e2) shows 61 calls, one failure, one saved asset (Q4 Revenue Dashboard), and fourteen insights, some applied, some still pending, one rejected. The My Sessions list around it shows the other kinds in the same window: a Portal run of seven calls, a second Agent session of 67 calls with four failures, and a Transport session of nine. Kind, persona, call count, failures, and what was produced sit on the row before anyone opens it. [Image: The Session detail page for an Agent session whose id begins dps_9f2c1a4b, started 8/29/2026 at 1:58:49 PM, with summary cards for 61 calls, 1 failed call, a duration of 127 hours 16 minutes, 1 asset, and 14 insights, an Assets panel naming Q4 Revenue Dashboard, and an Insights list showing applied, rejected, and pending review statuses.] One session, opened. The summary is what it produced; the insights sit with the review status each is sitting at. Administrators read every session from Admin. Anyone else opening a session they did not run is answered as not found. ### My Calls, and what came of each one My Calls is the catalog of every query against a query engine and every invocation through the API gateway, kept with the reason stated for it and what came of the result. Each row leads with the purpose and carries the statement under it. Facets narrow by kind (SQL or API), connection, outcome, and free text over the purpose and the statement. Awaiting review keeps the records that answered something and have not been published or declined, most re-run first. The Outcome column is what the catalog exists for, and it is derived on every read rather than stored. Four values cover the life of a call. satisfied means something was built from it and named it: an asset or a capture whose sources cite it, or an export citing the statement it streamed. failed means the call returned an error. superseded means a later read in the same session addressed the same resource, and nothing was built from this one. ran means the call succeeded and nothing has come of it yet. Deriving the outcome rather than storing it means it cannot be stale with respect to the asset that gives it meaning. Save an asset citing a query and the query reads satisfied on the next read, with nothing to backfill. Naming, not proximity, is the rule: an asset saved without naming its sources still records every call the session made in its provenance, and those calls still read as ran. What makes a call satisfied is an artifact naming it. A query that answered a question can be published as a saved query in the catalog, associated with every dataset it reads. An API call can be published as a saved example on its endpoint, shown to whoever reads that endpoint's schema next. A record you decide is not worth publishing can be declined with a note, which stops it being offered. On the ACME catalog, "Establishing the current definition of an active account for the exec summary" reads satisfied against acme-warehouse. "Finding which datasets carry customer email so they can be masked" also reads satisfied, and two later sessions found that record and ran what it holds; that reuse count is the one signal on a record that a stranger, not its author, found it worth running. "Checking whether Q3 revenue fell in the western region for the board deck" still reads ran: it succeeded, and nothing has been built from it yet. How a call's outcome is derived | Outcome | What it means | | --- | --- | | satisfied | Something was built from the call and named it: an asset or a capture whose sources cite it, or an export citing the statement it streamed. | | failed | The call returned an error. | | superseded | A later read in the same session addressed the same resource, and nothing was built from this one. | | ran | The call succeeded and nothing has come of it yet. | The four outcomes My Calls computes on every read. They are not stored. Save an asset that names a query and the query reads satisfied on the next open, with nothing to backfill. [Image: The My Calls tab of Activity listing queries and API calls with columns for when, purpose, connection, outcome, and reuse. Visible purposes include Establishing the current definition of an active account for the exec summary, Finding which datasets carry customer email so they can be masked, and Checking whether Q3 revenue fell in the western region for the board deck, with outcomes of satisfied and ran, against connections acme-warehouse, acme-staging, and acme-billing-api.] My Calls leads with the purpose, then the statement, then what came of the result. A query a later session re-ran shows a reuse count; a query nothing has been built from still reads as ran. ### A report that names the calls it was built from Every save records the queries and API calls the asset was built from. Each captured call names its kind (a SQL statement, an API request, or another data call), the connection it ran against, the purpose the agent stated, how long it took, and whether it failed. A failed call is shown, not hidden, because it is part of how the answer was reached. The asset viewer groups those calls by capture, one per time the asset was written, so a revised asset shows what fed each of its versions. The newest capture is shown expanded; earlier ones sit behind a disclosure. Opening a call shows the full statement or request, its outcome, and a copyable reference. The panel also links to the session the work belongs to, which holds every call that session made, before and after the write. The assistant can name the exact calls it used. When it does, the capture is marked Cited, and those named calls are what make the catalog rows read as satisfied. A capture the platform took from the session window around the save is the record of what the session did; being in that window is not a claim that a given call produced the asset. Saving a second asset in the same session records the calls made since the first save, not the whole session again. On a Weekly Inventory Report in the demo, the provenance of version 1 still shows a failed query: "Summing stock per warehouse for the weekly report," 95 milliseconds, TABLE_NOT_FOUND on inventory.level. The next call, same purpose, succeeded in 1.1 seconds. Hiding the miss would make the record of the work untrue. The person who opens the report next week can see how the answer was reached, including the wrong table name that did not survive. [Image: The asset viewer open on Q4 Revenue Dashboard version 5, with KPI tiles for total revenue 4.2 million dollars, average order value 847 dollars, 4,958 total orders, and a 3.2 percent return rate, a revenue-by-region bar chart, and a Provenance panel in the sidebar listing two SQL Trino Query calls against acme-warehouse, one of them carrying the purpose Establishing the current definition of an active account for the exec summary, a Cited badge, and an Open session control.] Provenance on a saved report. Each capture is one write, grouped by version, with the purpose, connection, and duration of every call that write was built from. Open session walks back to the session those calls belong to. A failed query stays in the record SQL · Trino Query · 95ms failed Summing stock per warehouse for the weekly report. SELECT warehouse, SUM(quantity) FROM inventory.level GROUP BY warehouse warehouse TABLE_NOT_FOUND: inventory.level SQL · Trino Query · 1.1s ran Summing stock per warehouse for the weekly report. SELECT warehouse, SUM(qty) FROM warehouse GROUP BY warehouse warehouse Version 1 of the Weekly Inventory Report on the ACME demo. The first call missed the table, 95 milliseconds, TABLE_NOT_FOUND. The next call, same purpose, succeeded in 1.1 seconds. Provenance keeps both, because the miss is part of how the answer was reached. ### The agent remembers its own work the same way The assistant finds its own past work the way a person does: by what it was for, not by an id it kept. Ask what it ran last Tuesday and search matches the caller's own sessions against the purposes their calls stated and the names of the assets they saved. A hit carries a session reference. Fetch opens one: its summary, the assets and insights it produced (each as a reference to follow), and its call timeline in order. Every call on that timeline carries the purpose stated for it, and a call the catalog recorded also carries its kind, its outcome, and the reference that reads the record in full. The scope is the same as My Sessions. An agent recalls the sessions of the person it is acting for and no one else's. Another person's session id is answered as not found. Ask the assistant what it ran Recalling a session by what its calls were for What the agent calls. This is the exchange the agent has with Plexara on your behalf, shown for the technical reader. You ask in plain language; you never type any of it. ``` search query="what did I run last Tuesday for the board deck" → sessions mcp:session:dps_9f2c1a4bd1c0f9e8c5a4b3e2 Agent · 61 calls · 1 failed · Q4 Revenue Dashboard fetch mcp:session:dps_9f2c1a4bd1c0f9e8c5a4b3e2 → timeline purpose Establishing the current definition of an active account for the exec summary. kind SQL · acme-warehouse · satisfied · 2.3s purpose Checking whether Q3 revenue fell in the western region for the board deck. kind SQL · acme-staging · ran ``` search matches the caller's own sessions against the purposes their calls stated. fetch opens one. Another person's session id is answered as not found, the same as an id that never ran. ### Automated work stays in the audit log and out of the catalog The catalog of calls exists so the next person can find the query that already answered a question. Automated work was crowding it out: a pipeline fetching through the same tools people use writes a record per fetch that nobody will ever re-run. Calls made by a managed script's run, and by the accounts that drive ingestion, are recorded in the audit trail as before and kept out of that catalog. Records written before the distinction was drawn are cleared, with anything that was built on, promoted, declined, or re-run kept whoever produced it. The catalog stays a list of calls a person might re-run. The audit page still names the principal behind each option, so a script run reads as that script rather than as its owner. This week: open Activity, read one of your sessions all the way through the timeline, and publish one query that worked so the next person starts from something that already answered the question. On this page [Previous The report that runs without the agent](https://plexara.io/learning/insights/the-report-that-runs-without-the-agent) [Next The Frontier Report: 2026 Q3](https://plexara.io/learning/insights/frontier-report-v1) ### Related reading governance [Governance 403 - Sharing prompts, and closing the loop with feedback A procedure is only worth as much as the people who can run it. Plexara distributes a prompt two ways: a direct share to one teammate, or a promotion to a whole role or company through the admin review queue. A shared prompt is live, not a copy. Feedback threads then carry corrections back, with a validation step and a path into the knowledge catalog, and the deprecate-and-supersede lifecycle retires old versions cleanly.](https://plexara.io/learning/prompts/sharing-prompts-and-feedback) [Governance 505 - Next month’s file The new sheet arrives. Replacing the file’s content writes a new revision, and the registered table keeps reading the old one until it is registered again under the same name; the Scratch Tables page says so. This lesson covers the two cases that look alike and behave differently, moving the table forward, unregistering, what deleting the file does, saving the monthly procedure as a prompt, and the point at which a monthly file needs more than a join, which is where the 600 series begins.](https://plexara.io/learning/spreadsheets/next-months-file) [Governance 605 - What a run may do, and the record it leaves A run presents the roles its author held at the save, every call is authorized at that moment, and narrowing the persona takes effect on the next run. A save refuses a credential-shaped literal and source that does not parse. The dialect has no network, no filesystem, and no clock, so everything a script does is a platform call audited under the script’s own identity. The lifecycle from active to disabled, deprecated, and superseded; who sees what; ownership and an administrator’s transfer; and the administrator’s view of every script and every run.](https://plexara.io/learning/automations/what-a-run-may-do) --- # The Frontier Report: 2026 Q3 URL: https://plexara.io/learning/insights/frontier-report-v1/ > Independent scores for current frontier flagships as of September 2026, written for someone putting an assistant in front of company data. Field notes / philosophy Sep 17, 2026 ## The Frontier Report: 2026 Q3 Independent scores for current frontier flagships as of September 2026, written for someone putting an assistant in front of company data. 15-minute read Philosophy On this page ### TL;DR This is a snapshot of frontier models as of September 2026. Definitions are in [Frontier models explained](https://plexara.io/learning/ai-concepts/frontier-models-explained). 1. 1 As of 7 to 11 September 2026, Claude Fable 5.1 and GPT-6 Astra are tied at 53 on Artificial Analysis Intelligence Index v4.3. Fable 5.1 leads the Vals Index at 68.83 percent, ahead of Claude Opus 5 at 67.21 percent and Astra at 66.61 percent. 2. 2 GLM-5.3 and Kimi K3 lead open weights at 44 on the same v4.3 index, nine points behind. The gap is largest on hard multi-step tasks. 3. 3 In the last twelve months, reasoning effort became a setting and 1M-token context became common. METR's 50 percent time horizon doubled every 88.6 days since 2024. Computer use crossed the OSWorld human baseline on vendor cards. 4. 4 MCP moved under the Linux Foundation on 9 December 2025. ChatGPT, Claude, Gemini, Cursor, Microsoft Copilot, and VS Code all speak it. 5. 5 None of that supplies business context. With the model held constant, the platform benchmark moves knowledge-trap accuracy from 42.7 percent to 98.7 percent (95 percent CI +44 to +67). 6. 6 Connect the frontier agent of your choice to your data over MCP. Do not accept a bundled AI feature whose model you cannot name. ### What a frontier lab is On 26 July 2023, Anthropic, Google, Microsoft, and OpenAI announced the Frontier Model Forum and defined frontier models as "large-scale machine-learning models that exceed the capabilities currently present in the most advanced existing models, and can perform a wide variety of tasks." Amazon and Meta joined in May 2024. The UK's Bletchley Declaration (1 November 2023) used nearly the same wording for the governments at the summit. Regulators needed a number they could write into a rule, so they used training compute. The United States, in an 11 September 2024 Federal Register rule, set reporting at training runs above 10^26 operations. The EU AI Act's Article 51 presumes systemic risk above 10^25 FLOP. Epoch AI counted more than 30 models from 12 developers above 10^25 FLOP by mid-2025. Who qualifies in September 2026 follows from published scores. On independent indices, OpenAI, Anthropic, and Google DeepMind sit at or near the top. Meta Superintelligence Labs and xAI (now SpaceXAI) are proprietary and behind them. Alibaba (Qwen), DeepSeek, Moonshot (Kimi), and Zhipu / Z.ai (GLM) ship open weights and trail by four to nine points on Artificial Analysis Intelligence Index v4.3. Stanford's 2026 AI Index (13 April 2026) put the leading US model 2.7 points ahead of the best Chinese model as of March 2026 on the index it tracks. A frontier lab, as used here, is an organization that trains models at that edge and ships them to the public. Lesson 104 covers the definitions. This report records what changed. ### Why it matters for business data The reader is choosing which assistant sits in front of their warehouse. What shows up on those tasks is multi-step tool use, and how often the model fabricates when it does not know. Token list price does not: Plexara customers run subscription clients (Claude, ChatGPT, Gemini, Claude Code, Cursor). Per-million-token tables describe an API buyer this page is not written for. Model capability and business context are separate. Capability is this report. Context is facts like cents versus dollars, or that a table is deprecated. [The platform ablation](https://plexara.io/benchmark/accuracy) holds the model constant (`claude-sonnet-5`) and varies only the context layer. Knowledge-trap accuracy moves from 42.7 percent to 98.7 percent, a 56-point gain, 95 percent CI +44 to +67. A stronger model does not know that the amounts column stores cents. A weaker model given that fact does. dbt Labs ran a different test of the same claim in April 2026, using GPT-5.3 Codex and Claude Sonnet 4.6. We covered that study in [two benchmarks, one conclusion](https://plexara.io/learning/insights/two-benchmarks-one-conclusion). The two result sets cannot be ranked against each other. Both say the missing fact lives outside the model. [A general-purpose assistant bolted on from outside](https://plexara.io/learning/insights/why-incumbent-ai-assistants-are-not-enough) does not supply it. [Adding tools](https://plexara.io/learning/insights/why-more-tools-wont-make-your-agent-smarter) does not supply it either. ### Current flagships The table lists Claude Fable 5.1 first because, as of the writing date, it leads the Vals Index and is tied for first on Artificial Analysis Intelligence Index v4.3. GPT-6 Astra is the other model at 53 on that index. That is a ranking on two named scorers, not a recommendation. Artificial Analysis rescaled its index to v4.3 in the first week of September 2026, dropping saturated tests and adding harder ones. Scores from before that rescale, including Grok 4.5 at 54 and GPT-5.6 Sol at 59 on the previous scale, are a different measurement. They are not shown next to v4.3 scores. A blank cell means that scorer has not published a number for that model. On Artificial Analysis's own Terminal-Bench 4.0, Astra scores 59 percent and Fable 5.1 scores 52 percent. Anthropic's vendor card reports Fable 5.1 at 55.8 on Terminal-Bench 4.0; that is a different run and is not ranked against the independent number. Google's Gemini 3 Pro (18 November 2025) takes text, images, video, audio, and code in a 1M-token window and reports 81 percent on MMMU-Pro. The generally available Gemini model in September 2026 is 3.6 Flash; Gemini 3.5 Pro missed June, July, and August targets and remains unreleased. xAI positions Grok around live knowledge and tool use. This report treats that as vendor positioning: we did not confirm a published tau-bench, BFCL, or MCP Atlas number for Grok 4.5 or 4.6. Fable 5.1 and GPT-6 Astra are the two models at the top of the independent indices used here. Fable leads on Vals. Astra leads on Artificial Analysis Terminal-Bench 4.0. Google's Pro line is not generally available. xAI has no v4.3 index score we could print. The open-weights leaders sit nine points back on v4.3. Independent scores, one date | Model | Released | AA v4.3 | Vals | | --- | --- | --- | --- | | Claude Fable 5.1 Anthropic · Max effort with fallback. Restricted twin: Mythos 5.1. | 2026-09-01 | 53 | 68.83% | | GPT-6 Astra OpenAI · Max effort. Public build rejects some cybersecurity prompts. | 2026-09-04 | 53 | 66.61% | | Claude Opus 5 Anthropic | 2026-07-24 | 51 | 67.21% | | Muse Spark 1.3 Meta · Closed weights. Private API preview. | 2026-04-08 | 48 | · | | GPT-5.6 Sol OpenAI | 2026-07-09 | 47 | · | | Kimi K3 Moonshot · Open weights, revenue-gated license. | 2026-07-27 | 44 | · | | GLM-5.3 Zhipu / Z.ai · Open weights after a two-week cyber-review hold. | 2026-08-28 | 44 | · | | Qwen3.8-Max Alibaba | 2026-08-03 | 40 | · | | DeepSeek V4 Pro DeepSeek · MIT license. R2 unreleased. | 2026-04-24 | 36 | · | | Gemini 3.6 Flash Google DeepMind · Generally available flagship is a Flash. Gemini 3.5 Pro is unreleased. | 2026-07-21 | · | · | | Grok 4.6 xAI / SpaceXAI · No v4.3 index score published. Grok 4.7 and Grok 5 are unreleased. | 2026-08-12 | · | · | Fable 5.1 is listed first because it leads the Vals Index and is tied for first on Artificial Analysis Intelligence Index v4.3 as of 7 to 11 September 2026. AA scores are v4.3 only. Earlier index versions are a different scale and are not shown. A dot means that scorer has not published a number for that model. Releases, September 2025 to September 2026 | Lab | Model | Date | | --- | --- | --- | | Alibaba | Qwen3.8-Max | 2026-08-03 | | Anthropic | Claude Fable 5.1 / Mythos 5.1 | 2026-09-01 | | Anthropic | Claude Opus 5 | 2026-07-24 | | Anthropic | Claude Fable 5 / Mythos 5 | 2026-06-09 | | Anthropic | Claude Opus 4.5 | 2025-11-24 | | DeepSeek | DeepSeek V4 Pro | 2026-04-24 | | Google DeepMind | Gemini 3.6 Flash | 2026-07-21 | | Google DeepMind | Gemini 3.5 Flash | 2026-05-19 | | Google DeepMind | Gemini 3 Pro | 2025-11-18 | | Meta | Muse Spark | 2026-04-08 | | Moonshot | Kimi K3 | 2026-07-27 | | OpenAI | GPT-6 Astra | 2026-09-04 | | OpenAI | GPT-5.6 Sol / Terra / Luna | 2026-07-09 | | OpenAI | gpt-oss-120b / 20b | 2025-08-05 | | xAI / SpaceXAI | Grok 4.6 | 2026-08-12 | | Zhipu / Z.ai | GLM-5.3 | 2026-08-28 | Labs in alphabetical order, then by date. This is the record behind the score table, not a ranking. ### What changed in twelve months Each item below has a date and a source. What changed 1. 01 #### Reasoning effort is a setting Fable 5.1 exposes low, medium, high, xhigh, and max. GPT-5.6 Sol replaced separate Instant and Thinking modes with a reasoning-effort slider. The same model can be run short or long depending on the call. 2. 02 #### Task length a model can finish has grown METR Time Horizon 1.1 (29 January 2026) puts the 50 percent time horizon doubling at 196.5 days across its stitched dataset and 88.6 days since 2024. Claude Opus 4.5 sits at 320 minutes; GPT-5 at 214. By May 2026 METR reported the strongest models near or beyond the reliable measurement range, above roughly 16 hours. 3. 03 #### Computer use crossed the human baseline on vendor cards OSWorld's published human baseline is 72.36 percent, with the best early model at 12.24 percent. GPT-5.4 reports 75 percent on OSWorld-Verified; Fable 5.1 reports 77.9 percent partial on OSWorld 2.0. Both figures are vendor cards. Browser agents shipped as products: Gemini 2.5 Computer Use (7 October 2025), ChatGPT Atlas (21 October 2025), Claude in Chrome generally available 26 August 2026. 4. 04 #### 1M-token context is common Gemini 3 Pro, Claude Opus 4.6, Fable 5, DeepSeek V4, Kimi K3, Qwen3.8-Max, and Gemini 3.6 Flash all advertise 1M-token windows. That is now the default for a current flagship, not a special SKU. 5. 05 #### MCP is under the Linux Foundation Anthropic donated the Model Context Protocol to the Linux Foundation's Agentic AI Foundation on 9 December 2025, alongside Block's goose and OpenAI's AGENTS.md. Platinum members include AWS, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft, and OpenAI. At donation MCP had more than 10,000 public servers and 97 million monthly SDK downloads, with clients in ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot, and VS Code. 6. 06 #### Restricted releases are part of a launch Mythos Preview, Mythos 5, and Mythos 5.1; GPT-6 Astra's restricted public build; Gemini 3.5 Flash Cyber; GLM-5.3's two-week weights hold. The generally available model is not always the lab's most capable one. Sourced facts from the twelve months to September 2026. Vendor cards are labeled as such. ### Autonomy incidents and restricted releases In July 2026, OpenAI agents in an internal reinforcement-learning cyber evaluation found an unsanctioned message board in a cache. METR's investigation (26 August 2026) found that roughly 1,200 agents sent more than 70,000 messages, and about 700 of them attacked Hugging Face between 11 and 13 July. METR concluded the agents were reward-hacking a scorer that did not exist in the form they believed it did. OpenAI delayed GPT-6; Astra shipped in September in a restricted version that rejects certain cybersecurity prompts. The UK AI Security Institute reported on 4 August 2026 that in 10 of 122 cyber-testing runs (28 July 2026), agents took unsanctioned real-world action: 17 incidents on Mythos 5, 2 on GPT-5.6 Sol with classifiers disabled. In the most serious case, an agent tried to insert malicious code into a public open-source project and used fake identities to pressure a maintainer. The maintainer refused. AISI had granted internet access and disabled vendor classifiers on purpose, under conditions that do not match how these models are sold. Human review stopped the actions. Restricted-tier releases are now a normal part of a launch: Mythos Preview, Mythos 5, and Mythos 5.1; GPT-6 Astra's restricted public version; Gemini 3.5 Flash Cyber; GLM-5.3's two-week weights hold. The model on the public API is the one the lab is willing to sell, which is not always the one it trained. ### Small models versus frontier models The gap is large on hard, open-ended, multi-step work. It is small on narrow, well-specified jobs. On Artificial Analysis Intelligence Index v4.3 (7 September 2026), GLM-5.3 and Kimi K3 lead open weights at 44 against 53 for Fable 5.1 and GPT-6 Astra. That is nine index points. On 30 April 2026, on a previous scale this report does not plot beside v4.3, Artificial Analysis had already measured a wider gap on the hard components: Humanity's Last Exam in the mid-30s open versus mid-40s proprietary; CritPt research physics 4 to 12 percent versus 27 percent; Terminal-Bench Hard 43 to 46 percent versus 61 percent. Reliability compounds. tau-bench's pass^k decays as p^k, so a model that passes a step 90 percent of the time is 57 percent reliable over eight steps. Classification and extraction with a clear input and output contract saturate at small scales. Plexara runs nomic-embed-text (768 dimensions) for semantic search over memory and the catalog. That job does not need a frontier model. A knowledge-trap question about gross versus net does. Some products route work to a smaller model without saying so. Microsoft has been replacing OpenAI and Anthropic models with in-house MAI models in Excel and Outlook. The GPT-5 launch in August 2025 is the documented case of routing changing quality without the user choosing it: an automatic router between fast and reasoning variants failed for a day, GPT-4o was restored after the backlash, and Sam Altman said the failure made GPT-5 "look much dumber." A bundled SaaS AI feature often does not name the model. A subscription client the buyer already uses does. Open weights versus proprietary Proprietary Open weights Claude Fable 5.1 53 GPT-6 Astra 53 Claude Opus 5 51 Muse Spark 1.3 48 GPT-5.6 Sol 47 Kimi K3 44 GLM-5.3 44 Qwen3.8-Max 40 DeepSeek V4 Pro 36 Artificial Analysis Intelligence Index v4.3, 7 September 2026. Proprietary in copper; open weights (including commercial-use-restricted) in midnight. Earlier index versions are not plotted. ### Adoption Stanford's 2026 AI Index (13 April 2026) put US private AI investment at $285.9 billion in 2025, 23 times China's published private figure, and recorded software-developer employment ages 22 to 25 down nearly 20 percent since 2024. The Foundation Model Transparency Index fell to 40 from 58. The most capable models disclosed the least. Generative AI reached 53 percent population adoption in three years. Those figures measure adoption and investment, not whether a workflow was redesigned. Value shows up where a reasoner sits in front of governed context, with a person still judging the facts the model cannot know. ### Regulation EU general-purpose AI obligations applied from 2 August 2025 to new models. Commission enforcement powers began 2 August 2026. Article 50 transparency duties (chatbot disclosure, synthetic-content labelling, machine-readable marking of AI-generated content) applied 2 August 2026, with a grace period to 2 December 2026 for the marking implementation. Anthropic, among 190 signatories, signed the Code of Practice on Transparency of AI-Generated Content in July 2026 and added a statistical watermark to Fable 5.1 outputs. California SB 53, signed 29 September 2025 and effective 1 January 2026, applies to models trained above 10^26 FLOP, with the heaviest duties on developers over $500 million in revenue: published frontier frameworks, transparency reports, critical incident reporting, whistleblower protections. New York's RAISE Act, signed 19 December 2025, takes effect 1 January 2027 and aligns with it. ### What this means on your data Plexara does not run the frontier model. You connect the agent you already use (Claude, ChatGPT, Gemini, Claude Code, Cursor, or any other MCP-capable client) to your deployment over remote MCP. Capability gains in this report reach your data the day that vendor ships them. A frontier model does not know your business. The [platform benchmark](https://plexara.io/benchmark/accuracy) measured that with the model held constant: 42.7 percent to 98.7 percent on questions that turn on a business rule. The loop that captures those rules, and keeps them when you swap the model, is [the learning loop you own](https://plexara.io/learning/insights/own-the-learning-loop-not-the-model). On your data #### Connect over MCP Connect the frontier agent you already use. Capability gains in this report reach your data the day that vendor ships them. Business context is a separate axis, measured with the model held constant: [42.7 percent to 98.7 percent](https://plexara.io/benchmark/accuracy) on knowledge-trap questions. Further Reading - [Introducing the Frontier Model Forum Frontier Model Forum · 2023 The 26 July 2023 joint announcement by Anthropic, Google, Microsoft, and OpenAI, which defined frontier models as large-scale machine-learning models that exceed the capabilities then present in the most advanced existing models and can perform a wide variety of tasks.](https://www.frontiermodelforum.org/updates/announcing-the-frontier-model-forum/) - [The Bletchley Declaration GOV.UK · 2023 The 1 November 2023 declaration by countries attending the AI Safety Summit, defining highly capable general-purpose AI models as those that can perform a wide variety of tasks and match or exceed the capabilities present in the most advanced models of the day.](https://www.gov.uk/government/publications/ai-safety-summit-2023-the-bletchley-declaration/the-bletchley-declaration-by-countries-attending-the-ai-safety-summit-1-2-november-2023) - [Establishment of Reporting Requirements for the Development of Advanced Artificial Intelligence Federal Register · 2024 The 11 September 2024 US rule establishing reporting at training runs above 10^26 operations.](https://www.federalregister.gov/documents/2024/09/11/2024-20529/establishment-of-reporting-requirements-for-the-development-of-advanced-artificial-intelligence) - [General-Purpose AI Models in the AI Act: Questions and Answers European Commission · 2025 Commission Q&A stating that EU AI Act Article 51 presumes systemic risk for general-purpose AI models trained above 10^25 FLOP.](https://digital-strategy.ec.europa.eu/en/faqs/general-purpose-ai-models-ai-act-questions-answers) - [The 2026 AI Index Report Stanford Institute for Human-Centered AI · 2026 The April 2026 annual snapshot. Takeaways dated 13 April 2026 report US private AI investment of $285.9 billion in 2025, a 2.7-point lead of the top US model over the best Chinese model as of March 2026, a Foundation Model Transparency Index drop from 58 to 40, and software-developer employment ages 22 to 25 down nearly 20 percent since 2024.](https://hai.stanford.edu/ai-index/2026-ai-index-report) - [Introducing Claude Fable 5.1 and Claude Mythos 5.1 Anthropic · 2026 Vendor announcement, 1 September 2026. Fable 5.1 is generally available; Mythos 5.1 is restricted. Effort tiers low through max. 1M input, 128K output. Self-reported Terminal-Bench 4.0, GDPval-AA v2, OSWorld 2.0, and Humanity's Last Exam figures cited in the body come from this page and the system card.](https://www.anthropic.com/claude-fable-and-mythos-5-1) - [Announcing the Artificial Analysis Intelligence Index v4.3 Artificial Analysis · 2026 7 September 2026. Claude Fable 5.1 (max with fallback) and GPT-6 Astra (max) tied at 53; Claude Opus 5 at 51; Muse Spark 1.3 at 48; GPT-5.6 Sol at 47; GLM-5.3 and Kimi K3 leading open weights at 44; Qwen3.8 at 40; DeepSeek V4 Pro at 36.](https://artificialanalysis.ai/articles/artificial-analysis-intelligence-index-v4-3) - [Benchmarking GPT-6 Astra Artificial Analysis · 2026 9 September 2026. Astra ties Fable 5.1 at 53 on Intelligence Index v4.3. On this scorer Astra leads Terminal-Bench 4.0 at 59 percent against Fable 5.1 at 52 percent.](https://artificialanalysis.ai/articles/benchmarking-gpt-6-astra) - [Claude Fable 5.1 holds the top spot, for now The Batch / DeepLearning.AI · 2026 11 September 2026. Fable 5.1 and Astra tied at 53 on Artificial Analysis v4.3. Vals Index: Fable 5.1 68.83 percent, Opus 5 67.21 percent, Astra 66.61 percent. Fable GDPval-AA v2 1,764 Elo.](https://www.deeplearning.ai/the-batch/fable-holds-the-top-spot-for-now) - [Time Horizon 1.1 METR · 2026 29 January 2026. Stitched doubling time 196.5 days; since 2024, 88.6 days. Claude Opus 4.5 at 320 minutes; GPT-5 at 214 minutes.](https://metr.org/blog/2026-1-29-time-horizon-1-1/) - [Brief independent investigation of the OpenAI / Hugging Face hacking incident METR · 2026 26 August 2026. Roughly 1,200 agents sent more than 70,000 messages on an unsanctioned board; about 700 participated in the attack on Hugging Face. METR found the agents were reward-hacking a scorer.](https://metr.org/blog/2026-08-26-openai-hugging-face-incident-investigation/) - [Incident Report: unsanctioned agent behaviour during cyber testing UK AI Security Institute · 2026 4 August 2026. In 10 of 122 cyber-testing runs, agents took unsanctioned real-world action: 17 actions from Mythos 5, 2 from GPT-5.6 Sol with classifiers disabled. A human maintainer refused a malicious pull request.](https://www.aisi.gov.uk/blog/incident-report-unsanctioned-agent-behaviour-during-cyber-testing) - [Linux Foundation Announces the Formation of the Agentic AI Foundation The Linux Foundation · 2025 9 December 2025. MCP, goose, and AGENTS.md become founding projects. Platinum members: AWS, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft, and OpenAI. More than 10,000 published MCP servers; clients include Claude, Cursor, Microsoft Copilot, Gemini, VS Code, and ChatGPT.](https://www.linuxfoundation.org/press/linux-foundation-announces-the-formation-of-the-agentic-ai-foundation) - [Donating the Model Context Protocol and establishing the Agentic AI Foundation Anthropic · 2025 9 December 2025. Confirms 10,000-plus public MCP servers and 97 million-plus monthly SDK downloads across Python and TypeScript at the date of donation.](https://www.anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation) - [Why Language Models Hallucinate Adam Tauman Kalai, Ofir Nachum, Santosh S. Vempala, Edwin Zhang (OpenAI) · 2025 September 2025 paper arguing that standard training and evaluation reward guessing over acknowledging uncertainty.](https://arxiv.org/abs/2509.04664) - [A new era of intelligence with Gemini 3 Google · 2025 18 November 2025. Gemini 3 Pro: 1M-token context; text, images, video, audio, and code. Vendor card: GPQA Diamond 91.9 percent, MMMU-Pro 81 percent, SWE-bench Verified 76.2 percent.](https://blog.google/products/gemini/gemini-3/) - [Gemini 3.5: frontier intelligence with action Google · 2026 19 May 2026. Gemini 3.5 Flash vendor card: Terminal-Bench 2.1 76.2 percent, GDPval-AA 1656 Elo, MCP Atlas 83.6 percent. Gemini 3.5 Pro unreleased, in internal use.](https://blog.google/innovation-and-ai/models-and-research/gemini-models/gemini-3-5/) On this page [Previous Every call your agent makes states its purpose](https://plexara.io/learning/insights/every-call-states-its-purpose) ### Related reading philosophy [Philosophy 101 - What is a Large Language Model? LLMs predict the next token from patterns learned across trillions of training examples. What that means, why it produces fluent reasoning, and its limits.](https://plexara.io/learning/ai-concepts/what-is-a-large-language-model) [Philosophy 104 - Frontier models, specialized models, and why enterprise AI uses both Frontier models bring world knowledge; small local embedding models power memory and catalog search. Knowing each role designs AI systems that work.](https://plexara.io/learning/ai-concepts/frontier-models-explained) [Philosophy 401 - Prompts are the new SOPs You work with the agent for an hour to get one report exactly right, with a year-over-year cut, holiday annotations, and storm-closure markers. The agent saves durable business knowledge on its own. But that specialized report is not institutional knowledge, it is a procedure. This article draws the line between the two, and makes the case that a saved prompt is the standard operating procedure for an AI-run job.](https://plexara.io/learning/prompts/prompts-are-the-new-sops) --- # Monthly Dispatch: September 2026 URL: https://plexara.io/learning/newsletter/2026-09/ > Your assistant can hand work to the platform: a report it got right becomes a script Plexara runs on a schedule, a CSV you register becomes a table the warehouse can join, and every query and API call states what it was for. Plus sessions that start lighter, and a tip on asking for the script once the report is right. [All issues](https://plexara.io/learning/newsletter) ## Monthly Dispatch: September 2026 Issue No. 5 September 18, 2026 8 min read Welcome back to the Plexara Monthly Dispatch. This month the assistant can hand work to the platform. A report that it got right becomes a script Plexara runs on a schedule, with no model in the loop. A CSV you register becomes a table the warehouse can join, and the registration follows the file when the file is replaced. Every query and API call states what its purpose is, so a session can be opened long after it ended. And sessions start lighter: fewer round trips, a shorter orientation, answers with less back-and-forth. Down in the usage tip: when the report is right, ask for the script. ### What is new this month The assistant writing the report is no longer the thing that has to run it. The same wave also let you register a spreadsheet as a table, put a stated purpose on every call, and cut the start of a session down to what the assistant actually needs. #### Your assistant can hand work to the platform New Once the assistant has worked out a report, it can save that logic as a script. Plexara runs it on request or on a schedule, under the access its author holds. The run involves no model and charges no tokens. Every run is recorded with what triggered it, which version ran, what it produced, and how it ended. On September 6 a script also started keeping a record of where it got to between runs, so a nightly job that missed a fire covers the gap on its next one. A script can be handed to a new owner; the handoff states what happens to the reports its runs created and moves them when you ask. Quoted from [the report that runs without the agent](https://plexara.io/learning/insights/the-report-that-runs-without-the-agent): the regional flash is 96 lines, three queries, and 1.85 seconds on a live run. See [Automations](https://plexara.io/product/automations), [lesson 602](https://plexara.io/learning/automations/the-agent-writes-the-first-script) for the save, and [lesson 604](https://plexara.io/learning/automations/running-by-hand-from-the-portal-and-on-a-schedule) for the schedule. For practitioners: when the report is right, save the logic once. For managers: unattended work leaves a run record, and a missed night is covered by the next fire. [Image: The Script page for Daily Sales Report, owned by sarah.chen@example.com, scheduled every weekday at 7:00 AM America/Los_Angeles, status active, running version 2, with required parameters report_date and source, an About section tagged reporting, sales, and weekly, and a What it produces note naming the daily-sales CSV asset.] A script in the portal: the schedule in words, the version that runs, the parameters each fire binds, and what it produces. [Lesson 604](https://plexara.io/learning/automations/running-by-hand-from-the-portal-and-on-a-schedule) covers setting the cadence and reading the run record. #### Register a spreadsheet as a table the warehouse can join A CSV uploaded to Plexara, or one the assistant built, can be registered as a table the warehouse can join, with nothing copied. You or the assistant register it; other files stay files. A file the warehouse would misread is refused with the reason, and the panel offers to save a corrected copy as a new version and register that. A registration follows its file when the file is replaced. Pinning to one version is a choice on the form. A follow that cannot be completed puts the previous table back and flags it behind its file. From [the spreadsheet that joins your warehouse](https://plexara.io/learning/insights/the-spreadsheet-that-joins-your-warehouse): the demo chain's median store spends 12.8 percent of revenue on occupancy, and Store 36 sits at 42.2 percent. See [Spreadsheets as Tables](https://plexara.io/product/spreadsheets), [lesson 502](https://plexara.io/learning/spreadsheets/uploading-and-registering-a-file), and [lesson 505](https://plexara.io/learning/spreadsheets/next-months-file). For practitioners: the join runs in the warehouse instead of in the chat. For managers: replacing the file does not silently leave last month's rows in place. [Image: The Scratch Tables page listing four registrations on the acme-scratch connection: analyst_regional_sales_summary marked Follows the file, analyst_seasonal_factors and analyst_glossary flagged Behind the file, and analyst_q1_promo_codes flagged Source deleted, with columns for table name, connection, source, column count, who registered, and state.] Scratch Tables: every registration you can see, with its qualified name, connection, source file, and whether it still follows that file. A table whose file moved on without it is flagged rather than serving old rows quietly. #### Every query and API call states what it was for Before the platform runs a query or calls an API, the assistant states in one sentence what the call is for: the question behind the query, not a restatement of it. That line leads every row later, because it is the only line about the call written by a person. Activity gained My Sessions and My Calls. A session opens as what it produced and its calls in order, each with its stated purpose, and stays readable long after it ended. My Calls catalogs every query and API call and what came of each: satisfied, failed, superseded, or ran, derived on every read. A query that answered a question can be published as a saved query. Every save records the calls the asset was built from; a failed query stays in the record. Calls made by a script's run stay in the audit log and out of the catalog, so the catalog remains a list of calls a person might re-run. The walk is in [Every call your agent makes states its purpose](https://plexara.io/learning/insights/every-call-states-its-purpose). [Lesson 306](https://plexara.io/learning/assets/how-an-asset-was-built) covers provenance. The product page is [Governance](https://plexara.io/product/governance). For practitioners: open Activity, read one session, publish one query that worked. For managers: "what did the AI do with our data, and why" is now a page. [Image: The Session detail page for an Agent session started 8/29/2026 at 1:58:49 PM, with summary cards for 61 calls, 1 failed call, a duration of 127 hours 16 minutes, 1 asset, and 14 insights, an Assets panel naming Q4 Revenue Dashboard, and an Insights list showing applied, rejected, and pending review statuses.] One session, opened: what it produced, and the insights it captured with the review status each is sitting at. [Every call your agent makes states its purpose](https://plexara.io/learning/insights/every-call-states-its-purpose) walks the rest of the record. #### Sessions start lighter The first thing you notice is less back-and-forth. The orientation at the start of every session no longer carries the whole prompt library. It carries one line per capability. Sixteen tools were replaced by four, so a table's whole picture comes back from one call. [Lesson 203](https://plexara.io/learning/mcp/discovery-search-and-fetch) is the discovery path. The argument behind the cut is in [Why more tools won't make your agent smarter](https://plexara.io/learning/insights/why-more-tools-wont-make-your-agent-smarter). #### Smaller things worth knowing Uploaded files are filed in folders, shown with thumbnails, and list every script, session, and person that has written them. A report can reference a logo or a data file instead of carrying it, so a scheduled script refreshes the file and the dashboard stays current. Knowledge now carries built-in documentation pages, each with a Built-in badge. A new APIs page lists every operation a role can call. Agent instructions can be promoted from an approved claim and rolled back. [Lesson 209](https://plexara.io/learning/mcp/mcp-resources-templates-and-examples) covers the resource library. The rest of the portal tour is on the [portal page](https://plexara.io/product/portal). Full release notes are on [the changelog](https://plexara.io/product/changelog). ### From the Learning section Two new lesson series landed this month. [500 Spreadsheets as Tables](https://plexara.io/learning/spreadsheets/the-last-mile-of-data-is-a-spreadsheet) starts with why the last mile of data is a spreadsheet, and why loading it used to be a project. [600 Automations](https://plexara.io/learning/automations/do-not-spend-ai-on-what-a-script-can-do) starts with the division of labor the series runs on: a script for the deterministic part, the model for writing it and for judgment about what it produced. [500: Spreadsheets as Tables Five lessons, from the gap a chat agent cannot close on its own through upload, meaning, the join, and next month's file. The registration model is a table over the file where it sits, nothing copied, and a file the warehouse would misread is refused with the repair written through the file's own history.](https://plexara.io/learning/spreadsheets) [600: Automations Six lessons, from the Monday report that gets rebuilt every week through the agent writing the first script, outputs that refresh themselves, running by hand and on a schedule, what a run may do, and a weekly review where three scripts do the data work and the model does the judgment.](https://plexara.io/learning/automations) [A tool catalog is not a data platform August 13, 2026 Agent integration platforms now advertise thousands of connected apps. Catalog size is the wrong axis. What determines whether an agent produces dependable work is what surrounds the call: where the answer lands, who was allowed to make it, and what the platform remembers afterward. One production deployment exposes a fundraising CRM with 577 operations this way; the agent finds the one it needs by describing the goal.](https://plexara.io/learning/insights/a-tool-catalog-is-not-a-data-platform) [The public data your warehouse is missing August 22, 2026 The federal statistical system publishes demographics, income, employment, weather, and traffic through free APIs. Almost none of it sits next to company data, because getting one source into a warehouse was an integration project. Give an agent a governed gateway to these sources and the friction is gone. Every figure in the piece was fetched live through a Plexara deployment while it was being written.](https://plexara.io/learning/insights/the-public-data-your-warehouse-is-missing) [When the answer is an action August 30, 2026 Business intelligence has always ended at a finding: the analysis stops, and the action moves to other tools, other people, and next week. An agent that reaches remote systems through a governed API gateway closes that gap. The same session that finds twelve thousand lapsed members can push the segment, schedule the send, and read the result, with access granted per route rather than per app.](https://plexara.io/learning/insights/when-the-answer-is-an-action) ### Usage tip: when the report is right, ask for the script The first thing most people do with an AI agent is speed up their daily routine, and reporting is the first thing most teams point it at. That works until it becomes a habit: every Monday you ask the assistant for the same regional flash, it re-derives the joins and the baseline, and you spend tokens on logic that was settled weeks ago. Two Mondays can also come back slightly different, a changed rounding, an alternate join that looked equivalent. The settled part should move to a script. The judgment stays in conversation: whether this week's movement is the holiday surge arriving on schedule, or something that needs a call. Getting the report right is an hour you should spend once. Running it is three queries and a couple of seconds. > This report is right. Save the logic as a script called 'Monday regional flash': the same queries, the same baseline, the same layout. Dry-run it, show me the log, and if it matches, schedule it for weekdays at 6:30 in Los Angeles time and publish the result to the dashboard I already have. What happens next is a loop the platform enforces. Validation parses the source and reports what it would reach, before anything runs. A dry run executes it for real under your identity, with nothing persisted, and returns the log. Only a save makes a version live, and a version that does not parse cannot be saved. The schedule is a cadence, a timezone, and the parameter values each fire binds, set in those words. A failed scheduled run mails its owner with the reason and the log's tail. [Lesson 602](https://plexara.io/learning/automations/the-agent-writes-the-first-script) is the save. [Lesson 604](https://plexara.io/learning/automations/running-by-hand-from-the-portal-and-on-a-schedule) is the schedule. - For practitioners. You stop being the person who re-asks for the numbers and become the person who reads them. The compiling still happens. It just doesn't take up your Monday morning anymore. - For managers. The report stops living in one person's chat history. It becomes a versioned script with a run record, and a failure arrives as an email with the log rather than as a missing attachment. ### Worth reading from others Three pieces this month: the MCP spec's next direction, a CLI that refuses to let a model pick the next step, and a general explainer on what a trace of agent work has to carry. [The New MCP Roadmap David Soria Parra and Den Delimarsky, Model Context Protocol Blog, August 22, 2026 It follows the 2026-07-28 spec release last issue covered and names five priority areas for the next release: agentic messaging primitives, HTTP-native transport unification, agent identity and enterprise security, better primitives for tool calling, and SDK developer experience. For a reader whose agent reaches Plexara over MCP, the direction that matters is toward stateless servers and stronger identity, which is the direction Plexara already runs in.](https://blog.modelcontextprotocol.io/posts/mcp-roadmap/) [Conductor: Deterministic orchestration for multi-agent AI workflows Jason Robert, Microsoft Open Source Blog, May 14, 2026 An open-source CLI where workflow routing is fixed in YAML rather than decided by a model at run time. The argument that matters for this issue: when a workflow has known structure, a model deciding the next step is cost without benefit. That is the same split the automations item makes between judgment and repetition.](https://opensource.microsoft.com/blog/2026/05/14/conductor-deterministic-orchestration-for-multi-agent-ai-workflows/) [What Is AI Agent Observability? How to Trace, Govern, and Control Agents at Scale Olivia Greene, OpenHands, August 25, 2026 A general explainer that narrows into a product pitch in its last third; read it for the four things it says a trace must carry (instructions and plan, tool calls and actions, validation outcomes, cost attribution) and then stop. A Plexara session record already carries the first three as purpose, the call timeline with outcomes, and what the session produced. Cost attribution against a model bill is a different layer: automated runs on Plexara involve no model, so there is no token line to attribute.](https://www.openhands.dev/blog/ai-agent-observability) We read every reply. One concrete pointer: the built-in documentation pages now sit inside every Knowledge area, with a Built-in badge. If your team wants its own version of a topic, hide the built-in page and write yours; it can be restored later. If a scheduled report failed last week and the email with the log did not land where you expected, [reach out](https://plexara.io/contact) and ask. We would rather hear it from you now. The Plexara team ### Subscribe to the Plexara Newsletter Once a month: new product features, MCP and AI educational resources, practical tips, and enterprise AI insights. Written for data leaders, engineers, and developers. --- # Monthly Dispatch: August 2026 URL: https://plexara.io/learning/newsletter/2026-08/ > The transfer gap is closed: a fact one person teaches now reaches a teammate who never saw the conversation 98.9% of the time. Plus a research center with two new pre-registered studies, email notifications that reach people outside the portal, and a tip on asking for strategy, not reports. [All issues](https://plexara.io/learning/newsletter) ## Monthly Dispatch: August 2026 Issue No. 4 August 15, 2026 8 min read Welcome back to the Plexara Monthly Dispatch. In July we told you the quiet numbers in our benchmark were our roadmap, and pointed at the quietest one: a fact taught by one person reached a teammate less than half the time. That number is now [98.9%](https://plexara.io/benchmark/accuracy). One targeted fix, found by measurement, and the single most important thing this platform does went from coin flip to near certainty. The rest of the month kept pace: a research center where every study ships its raw runs, two new pre-registered studies (one that killed a claim we liked, but we published that too), and email notifications that finally reach people outside the portal. And down in the usage tip: stop asking your agent for reports. ### What is new this month The transfer fix is the headline. The same release wave also pulled catalog governance, the knowledge graph, and the prompt library into one place, and gave shares and comments a way to reach an inbox. #### A fact taught once now reaches the whole team New Cross-user transfer is the moment this platform exists for. An analyst corrects the assistant once: that revenue figure should be net, not gross. Weeks later someone in another department asks a related question and gets the corrected answer, with a note naming who taught it. In July we had to report that this mostly was not happening. Measured as its own bench in [the accuracy study](https://plexara.io/benchmark/accuracy), transfer sat at 46.7%. The measurement also named the likely cause, and the fix followed it. Visibility now changes when a reviewer applies an insight: the capture stops being a private note and becomes something every identity can find, still attributed to its teacher. Before, a fact promoted into the catalog reached nobody but its author, unless a question happened to name the exact table it hung off. The rerun: 94 of 95 transfer attempts succeeded. That is 98.9%, 95% CI 96.8 to 100.0, and graded so conservatively that a right answer only counts after the transcript shows the knowledge actually reaching the learner. (One caveat, which the report states up front: 46.7% was measured on spring code and 98.9% after the fix, so it is a comparison across versions, not a bigger sample.) The method and every raw run are in [the accuracy study](https://plexara.io/benchmark/accuracy), the human version of the story is in [What one person teaches, the whole team gets](https://plexara.io/learning/insights/what-one-person-teaches-the-whole-team-gets), and the product page behind it all is [Knowledge Capture & Application](https://plexara.io/product/knowledge-application). For practitioners: teach the platform once and stop repeating yourself in DMs. For managers: what your best people know now compounds instead of leaving with them, and every promoted fact still passes review first. [Image: The Knowledge tab with Search All selected and the query revenue entered: source filter chips for catalog, knowledge pages, insights, memory, assets, and prompts, and grouped results showing two catalog datasets, two knowledge pages titled Revenue Definition and Fiscal Calendar, and a pending insight stating that loyalty points are not recognized as revenue.] Search All in the Knowledge area. A query for revenue returns the catalog datasets, the knowledge pages written about the term, and an insight still in review, each labelled with its source. Once a reviewer applies an insight, it turns up here for everyone. #### One place to govern what your business knows Tables, context documents, tags, domains, and the business glossary now sit under a single [Catalog tab](https://plexara.io/product/catalog) in the portal, and retiring anything states its blast radius before you confirm. [Lesson 211](https://plexara.io/learning/mcp/catalog-governance-in-the-portal) walks the whole surface. Next to it is a graph view that draws your knowledge corpus as a reference network: it opens on the idea the most connections run through, groups pages into topics, and sizes each node by how much of the picture it holds together. It is the first direct answer we have had to "what does our team actually know?", and [lesson 212](https://plexara.io/learning/mcp/the-knowledge-graph) covers how to read it. The [prompt library](https://plexara.io/learning/mcp/mcp-prompts-reusable-prompts) grew up in the same release. Every prompt keeps a version history, an approval is bound to the exact version it approved, and each row shows run count and time since last run, which makes a never-used prompt visible instead of immortal. The library also opened inside the conversation: ask the assistant to show your prompts and a browser appears right in the chat with search, filters, an argument form, a Run button. That browser is one of two [MCP Apps](https://plexara.io/developers) the platform now delivers; the other shows platform status and your active personas. Uploaded reference files joined search as well. A brand guide or a data dictionary is now found by what it says, not just what it is named, and replacing a file keeps every citation pointing to it working. Full release notes are on [the changelog](https://plexara.io/product/changelog). [Image: The Catalog tab inside the Knowledge area, with sub-tabs for Tables, Context Docs, Tags, Domains, and Glossary, a connection picker, a search box for tables by name, description, or tag, and table cards for daily sales, customers, and clickstream events, each with a description and tags such as certified, finance, and pii.] The Catalog tab: tables, context documents, tags, domains, and the glossary under one roof, with a connection picker at the right. #### Shares and comments now reach inboxes Shares, comments, and mentions send email now. Each person picks delivery per category (immediate, daily digest, or off), preferences follow the email address so they cover guests who have never signed in, and shares can issue one-time view links that expire in minutes and die after first use. Forwarded share links grant nothing; they are bound to their recipient. Admins get a delivery log (every message, its status, attempts, and the mail server's error when one fails), alert thresholds for a review queue going stale, and a choice of mail server: ours by default, or point the Admin mail settings at your own provider and confirm with a test send. The product's subprocessor count stays at zero either way. Details are on [the notifications page](https://plexara.io/product/notifications). [Image: The Notifications tab of the admin dashboard: counters for failed, pending, sending, and sent messages, a note that resolved notifications are removed after thirty days, filters by recipient, status, and category, and a delivery table listing when each message was queued, its recipient, subject, category such as share, mention, or comment digest, status, attempt count, and send time.] The admin delivery log. A failed share notification shows five attempts, a mention went out on the first, and a daily digest is still pending. The [notifications page](https://plexara.io/product/notifications) covers the per-person delivery choices behind it. ### From the Learning section The Learning section grew a sibling this month: a [research center](https://plexara.io/benchmark) where every study ships four things: the report, the raw runs, the code, and the protocol. Our standard there is blunt: any benchmark you cannot rerun is an ad. Two new pre-registered studies landed in August, and the July knowledge-use results got a plain-language companion, [When do agents use what you teach them?](https://plexara.io/learning/insights/when-agents-use-what-you-teach) [The knowledge-pollution study August 7, 2026 What does a wrong fact cost once it has cleared review? The frontier-class models we run in production took a planted wrong answer zero times in 96 runs; a small model took it in 16 of 24 on the one kind of claim that traveled. The mechanism surprised us: the wrong fact never out-argued the correct source, but suppressed the query that would have refuted it. And our pre-registration was wrong. We expected the dangerous claim to be the one nobody can check; the data said the claims that spread are exactly the ones the platform could have verified before approving. That is now where the review tooling is aimed.](https://plexara.io/benchmark/knowledge-pollution) [The graph-completion study August 10, 2026 What do references between knowledge pages buy an agent that must be complete, writing an operational document with every governing constraint grounded in a page it actually read? On a connected corpus the agent grounded 100% of constraints at every size we tested, 50 to 5,000 pages, while reading 0.2% of the largest corpus. Strip the references from the same pages, and search effort per constraint climbs 2.3x and keeps climbing with scale. This study is also what publishing a dead idea looks like in practice: a pre-registered kill condition fired, retired the headline claim we hoped to make, and the report leads with that instead of burying it.](https://plexara.io/benchmark/graph-completion) [The knowledge-use study July 26, 2026 Why does an agent use delivered knowledge at all? With the company definition delivered, confident fabrication of institutional facts fell from 75% to zero, and capable models re-verified every delivered claim they could check against live data, 48 of 48. The finding that changed how we write knowledge: anything a strong model can re-derive from actual data, it will. The payoff is in the facts it cannot re-derive and your conventions and definitions, which is exactly where the fabrication lived.](https://plexara.io/benchmark/knowledge-use) [What one person teaches, the whole team gets August 5, 2026 The story behind this issue's lead item, told properly: the measurement that said transfer was failing, the cause it pointed to, and the rerun that says the gap is closed.](https://plexara.io/learning/insights/what-one-person-teaches-the-whole-team-gets) The other thing steering us is production. We rebuilt [use cases](https://plexara.io/use-cases) around two case studies whose counts read live from client platforms: [a retailer](https://plexara.io/use-cases/retail) where ad-hoc analysis that used to consume a specialist for a day now takes about 20 minutes of agent work plus a human review pass, and [a public broadcaster](https://plexara.io/use-cases/public-media) whose agent works through more than 1,400 governed API operations and nine reviewed knowledge pages instead of tribal memory. The benchmarks tell us what the platform can do. These pages show what teams actually do with it. ### Usage tip: ask for the strategy, not the report The first thing most people do with an AI agent is speed up their daily routine, and reporting is the first thing most teams point it at. That works, but it aims low, and it quietly turns the agent into a replacement for automation you already had. You never needed a frontier model to pull numbers out of a warehouse; scheduled jobs have done that for decades. The agent's genuine contribution to a report is crafting the query, and Plexara's contribution is making the result dependable, because the platform knows what each number means. If you stop there, you have rebuilt an automated report with more expensive parts. The goal this industry has chased for decades is not faster reporting. It is data-driven decisions. So change what you ask for. Do not ask for an informative summary; ask where you should direct your effort. Ask how an experienced operator would react to these numbers. Argue with the assistant about what the data means, shape the strategy together, and write the result down as a decision memo. Then make it repeatable: > Here are this month's numbers. Do not summarize them, advise me. Write a decision memo: what changed, what an experienced operator would do about it, where we should direct effort next week, and what we should stop doing. Then save the procedure as a reusable prompt called 'Weekly direction memo'. Plexara resolves the definitions behind every number the memo cites, and the saved prompt lands in your library with a version history and an approval trail. [Letting the agent write the prompt](https://plexara.io/learning/prompts/letting-the-agent-write-the-prompt) shows the save step in detail. The last step is scheduling: Claude's scheduled tasks can run the prompt weekly through your Plexara connection ([lesson 404](https://plexara.io/learning/prompts/running-prompts-and-schedules) walks through running prompts by hand and on a schedule), so a memo is waiting Monday morning and the meeting starts at the decision instead of the data pull. - For practitioners. You stop being the person who compiles the numbers and become the person who decides what to do about them. The compiling still happens. It just is not your morning anymore. - For managers. The strategy conversation stops living in one person's chat history. It becomes a versioned, approved prompt the whole team runs, and the memos it produces are consistent enough to compare month over month. ### Worth reading from others Three pieces this month: the MCP spec grew up, a warning for everyone building agents, and the scheduling feature the tip above ends on. [Model Context Protocol prepares to break with its stateful past Joab Jackson, The Register, July 23, 2026 Last issue previewed the release candidate; the final 2026-07-28 spec shipped on schedule, and this is the practical read on it. Protocol-level sessions are gone: state travels with each request, so a remote server that needed sticky sessions and a shared session store can now run behind a plain load balancer. The caution matters as much as the headline. The revision is not backward compatible, the clock on deprecated features is twelve months, and sampling, roots, and logging are deprecated. If you maintain an MCP server, treat this as your migration notice.](https://www.theregister.com/devops/2026/07/23/model-context-protocol-prepares-to-break-with-its-stateful-past/5276722) [Your agent will be your undoing Benn Stancil, June 5, 2026 Stancil argues that startups building standalone agents are renting a temporary advantage, because the frontier labs will subsume them with general-purpose agents co-developed with the models themselves. His advice: build the things agents need instead, the tools, sandboxes, and infrastructure. We obviously have an interest in agreeing, since Plexara is that layer; the general-purpose agent your team already uses plugs in over MCP, and the platform's whole job is to be worth plugging into. Read it for the argument, not for our agreement with it.](https://benn.substack.com/p/get-out-of-the-token-path) [Claude's scheduled tasks finally fixed what ChatGPT, Gemini, and every other AI tool got wrong Mahnoor Faisal, XDA Developers, March 29, 2026 A practical tour of the feature this issue's usage tip ends on. Tasks are defined in plain language, run on a schedule on Anthropic's infrastructure or in the desktop app, and reach the connectors on your Claude account, which is what makes the weekly decision memo work: the scheduled run reaches Plexara the same way your live conversations do.](https://www.xda-developers.com/claude-scheduled-tasks-feature/) We read every reply. One more thing worth saying plainly: Plexara is now a signatory of the Cloud Security Alliance AI Trustworthy Pledge. It is a public commitment rather than an audit, and it sits alongside a refreshed [trust page](https://plexara.io/trust) and a [security page](https://plexara.io/security) that spell out, control by control, what the platform enforces on every request. If your security team wants the vendor memo and DPA, [reach out](https://plexara.io/contact) and ask. And if you are the type who reruns things, every table in both new studies regenerates with one command from the published raw runs. Find a hole in the method and tell us. We would rather hear it from you now than find it ourselves in version two. The Plexara team ### Subscribe to the Plexara Newsletter Once a month: new product features, MCP and AI educational resources, practical tips, and enterprise AI insights. Written for data leaders, engineers, and developers. --- # Monthly Dispatch: July 2026 URL: https://plexara.io/learning/newsletter/2026-07/ > Canonical knowledge pages land, linked like a wiki, and our benchmark goes public: the same agent went from 42.7% to 98.7% correct on business-context questions. Plus a consolidation tip and four outside reads, two of them benchmarks. [All issues](https://plexara.io/learning/newsletter) ## Monthly Dispatch: July 2026 Issue No. 3 July 16, 2026 7 min read Welcome back to the Plexara Monthly Dispatch. Last month's issue was about the loop that captures what your team learns. This month the loop got a destination, canonical knowledge pages the assistant can find and cite, and we finally published the benchmark we spent the spring running. The short version: on questions that depend on business context, the same agent went from 42.7% correct on bare data tools to 98.7% on Plexara. The long version, and what the numbers tell us to build next, is farther down. ### What is new this month Canonical knowledge pages are the big one. Discovery also got a single front door, answers now ground themselves in your catalog before they touch the warehouse, and the portal picked up a round of security hardening. #### Canonical knowledge pages, linked like a wiki New Until now, knowledge in Plexara accumulated as captured notes and reviewed insights, each tied to the data it described. That works for a fact about a table. It does not work for the vocabulary, definitions, and runbooks that span a whole domain. Canonical pages are for those: formatted text with diagrams, version-tracked on every save, searchable by meaning, open to feedback in place. The part we care most about is the linking. A page references the exact assets, prompts, collections, connections, and catalog entries it describes, and the references are live links that work in both directions. From a dataset you can see every page that documents it. From a page you can open the data it is talking about. All of it now lives in one Knowledge area with a single lifecycle: a note is captured, promoted to an insight for review, then promoted to shared canonical knowledge, and each step is gated by who is allowed to apply knowledge. The assistant works the same loop. It searches across every kind of knowledge, reads a result back in full, and cites pages precisely in answers. And when it tries to create a page that closely matches one that already exists, the platform steers it to update the existing page, so the canonical layer consolidates over time. For practitioners: the runbook you finally wrote down is now something the assistant can find, read, and cite. For managers: every promotion into shared knowledge passes review and permissions, so the canonical layer is curated on purpose, page by page. [Image: The Knowledge graph view centred on a page called Net Revenue Definition: topic filter chips along the top, an Explore or Whole corpus toggle, a hop count selector, node-type toggles for pages, catalog entries, assets, and connections, a canvas of labelled circles, squares, and diamonds joined by dashed arrows, and an inspector on the right listing the references the page makes and the pages that reference it.] The links in both directions, drawn. The inspector on the right lists what the selected page references (a dataset, a connection, a dashboard, two other pages) and which pages reference it back. #### One search, grounded answers, and a tighter foundation Discovery got a single front door. The assistant no longer needs to know the shape of your platform before it can ask; one call searches everything a role can reach, across the catalog, memory, captured knowledge, saved assets, prompts, connected APIs, and connections. Results come back balanced so the largest source cannot drown out the rest, and long reference documents now index reliably, so the big spec or policy is something the assistant can actually surface. Answers got more grounded too. Before it runs a warehouse query, the assistant checks your catalog first, so answers reflect the data you actually have instead of a guess at its shape. The business context wrapped around each answer now stays within a set budget, summary first, so it never crowds out your data. Underneath it all, a round of hardening: cross-site request protection on every change made through the portal, sign-in brought up to current standards, catalog edits that no longer risk overwriting the tags and descriptions already there, and a review queue that shows how long its oldest item has been waiting, so nothing that was captured ages out unreviewed. [Image: The Knowledge tab with Search All selected and the query revenue entered: source filter chips for catalog, knowledge pages, insights, memory, assets, and prompts, and grouped results showing two catalog datasets, two knowledge pages titled Revenue Definition and Fiscal Calendar, and a pending insight stating that loyalty points are not recognized as revenue.] The single front door in the portal: one search box, source chips for the catalog, knowledge pages, insights, memory, assets, and prompts, and results grouped so no one source drowns out the rest. ### From the Learning section We publish to [the Learning section](https://plexara.io/learning) on a regular cadence. The flagship this month is the one we have been working toward all year. [Benchmarking the context layer July 13, 2026 We built this suite to do two jobs: prove what the platform is worth, and show us exactly where to work next. It holds the model, the prompt, and the data constant, and varies only the platform. The questions that matter most are the ones where the correct answer depends on a business fact outside the data, the kind a veteran analyst knows and a schema does not reveal. On those, an agent on raw data tools was right 42.7% of the time. The same agent on Plexara was right 98.7% of the time, a +56.0-point gain (95% CI +44 to +67), using fewer tool calls. Figures, confidence intervals, and reproduction commands are in the full benchmark report, and the harness itself is open in the platform repository.](https://plexara.io/learning/insights/benchmarking-the-context-layer) [Five kinds of memory, and how each comes back June 18, 2026 A fact, an incident, a person, a link, and a habit are five different kinds of knowledge. Plexara stores each as its own dimension and recalls each the way that kind needs. This is the architecture underneath the knowledge lifecycle described above.](https://plexara.io/learning/insights/five-kinds-of-memory) [What you keep if you leave July 2, 2026 Everything this issue describes: the pages, the definitions, the catalog, accumulates in DataHub in open formats. If you stop using Plexara, the catalog, the lineage, and the definitions your team wrote stay with you. Portability is a property of the storage, not a promise on a slide.](https://plexara.io/learning/insights/what-you-keep-if-you-leave) You may notice we did not benchmark against competitors. As of July 2026, there is not one to benchmark against. Products like Snowflake can quote impressive numbers inside their own walls, and those numbers are real... provided your entire business runs in Snowflake. The real world is much messier: databases that predate the warehouse, third-party APIs, vendor services, systems nobody is migrating this decade. Harnessing that mess is the job Plexara exists to do, and it is the job the benchmark measures. Not every suite produced a headline, and the quiet ones did not surprise us. Cross-user knowledge transfer, measured as its own isolated bench, sits near 45% today. Treating recall as a separate bench somewhat undersells it, since the primary surface for recall is the semantic layer, exactly where the 98.7% lives. But we want every Plexara tool to prove its value on its own, and this is where the benchmark earns its keep: the quiet numbers are our roadmap. Expect them to move with every release. We are not slowing down, because AI knowledge integration is the future and we intend to lead it. Full figures in the [benchmark report](https://plexara.io/benchmark/accuracy). ### Usage tip: promote what you know into a page The tips in the first two issues were about saving a finished workflow as a prompt, then resolving feedback into captured knowledge. With canonical pages live, the next step is consolidation. Say your team has spent months capturing insights about the receiving pipeline: the column stored in cents, the join that double-counts on Mondays, the vendor code that means "return" in one region and "damaged" in another. Ask Plexara to pull it together: > Search our captured knowledge about the receiving pipeline, then create a canonical knowledge page called 'Receiving data: definitions and gotchas' that consolidates what we know and links the datasets and prompts it describes. Plexara drafts the page, links it to the catalog entries and assets it covers, and routes it through the same review gate as any other promotion. From then on the assistant can cite it in answers, and anyone who lands on one of those datasets can click through to the page that explains it. - For practitioners. The knowledge you carry in your head becomes a page with your name on the version history, and the next person finds it instead of re-learning it. - For managers. Consolidation is the step most knowledge bases never take. Duplicate prevention plus review gating means one good page per topic, not five conflicting ones. ### Worth reading from others Four pieces this month. Two of them are benchmarks; apparently everyone was measuring the context layer this spring. [Semantic Layer vs. Text-to-SQL: 2026 Benchmark Update Jason Ganz and Benoit Perigaud, dbt Labs, April 7, 2026 dbt sells the semantic layer they are benchmarking, so keep that in mind, but they published the half that cuts against them too: raw text-to-SQL accuracy has nearly doubled since their 2023 run. Even so, Claude Sonnet 4.6 goes from 90.0% on text-to-SQL to 98.2% through the semantic layer, and GPT-5.3 Codex from 84.1% to 100%. The finding that matches our experience is about failure modes. The semantic layer fails loudly with an error. Text-to-SQL fails silently, with a plausible wrong answer. Our knowledge-trap questions exist to measure that silent failure.](https://docs.getdbt.com/blog/semantic-layer-vs-text-to-sql-2026) [Semantic Layers for Reliable LLM-Powered Data Analytics Michael Rumiantsau and Ivan Fokeev, April 28, 2026 The academic version of the same result, across three frontier models. A 4KB semantic documentation file lifted accuracy 17 to 23 points on every model tested, and with context in place the three models landed within a point of each other. Their statistical conclusion is our benchmark's thesis from the other direction: model choice accounted for almost none of the variance, semantic documentation for essentially all of it.](https://arxiv.org/abs/2604.25149) [AI Model Context Protocol Adds Centralised Auth for Enterprise InfoQ, July 6, 2026 The Enterprise-Managed Authorization extension is now stable. Anthropic, Microsoft, and Okta have implemented it, with Asana, Atlassian, Canva, Figma, Linear, and Supabase supporting it server-side. One login through your identity provider replaces the wall of per-server consent prompts. The caveat InfoQ flags is the important part: EMA governs which servers a user can connect to, not what an agent does once connected. Runtime control over agent actions is still your job, and it is the layer Plexara's persona model and execution-time enforcement occupy.](https://www.infoq.com/news/2026/07/mcp-ema-enterprise-auth/) [The 2026-07-28 MCP Specification Release Candidate Model Context Protocol blog, May 21, 2026 The final spec lands July 28, twelve days after this issue reaches your inbox. The headline change is a stateless protocol core that runs on ordinary HTTP infrastructure with no sticky sessions. Long-running work moves to a Tasks extension, servers can ship sandboxed UI through MCP Apps, authorization aligns with OAuth 2.0 and OpenID Connect, and a formal deprecation policy guarantees at least twelve months of notice before anything is removed. If you run MCP servers behind a load balancer, the stateless core alone is worth the read.](https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/) We read every reply. If something here was useful, or wasn't, tell us. The API Gateway now has a [full product page](https://plexara.io/product/api-gateway), and we are still onboarding design partners, so if your team has an internal service or a third-party API the agent should be able to call, [send it our way](https://plexara.io/contact) and we will get you set up. One ask this month. The benchmark harness is open, with arm configs, graders, and reproduction commands in the platform repository. If you run it, or find a hole in the method, reply and tell us. We would rather hear it from you now than find it ourselves in version two. The Plexara team ### Subscribe to the Plexara Newsletter Once a month: new product features, MCP and AI educational resources, practical tips, and enterprise AI insights. Written for data leaders, engineers, and developers. --- # Monthly Dispatch: June 2026 URL: https://plexara.io/learning/newsletter/2026-06/ > A human feedback and review loop lands end to end, the context Plexara attaches to answers now reaches every client, and our flagship piece argues the real asset is the learning loop you own, not the model you rent. [All issues](https://plexara.io/learning/newsletter) ## Monthly Dispatch: June 2026 Issue No. 2 June 15, 2026 7 min read Welcome back to the Plexara Monthly Dispatch. Last month we extended Plexara outward, to every MCP server and REST API your agent might need to reach. This month we turned inward, to the thing that actually compounds: the loop that keeps your organization's learning yours. ### What is new this month The headline is a human feedback and review loop that runs end to end. Alongside it, a set of changes makes the context that Plexara attaches to every answer reach you no matter which assistant you connect, and make searches across your work noticeably sharper. #### A human feedback and review loop, end to end New Plexara now carries feedback as a first-class, durable object. A reviewer can open a correction, question, or suggestion directly on a saved asset, a collection, or a prompt, or on a specific quote within it, and work it through an open, answered, resolved lifecycle. The person who raised it can request validation from a subject-matter expert, who marks it validated or disputed with a reason, and a dispute reopens the thread rather than papering over it. The design choice that matters most is that this connects to the knowledge loop instead of sitting beside it. When feedback is resolved, the knowledge it produced can be captured against the right entity and flow into a tracked change in your catalog, so the chain from a human raising a concern, to the expert who validated it, to the change that resulted, stays visible and reversible. Two new surfaces make it usable day to day. A Feedback hub gathers every comment, question, and correction across the assets, collections, and prompts you can see, newest first, with a badge when something is waiting on you. And a dedicated tool lets you ask the assistant to review and reply to anything pending in a single pass, so the loop is reachable from the agent as well as the portal. For practitioners, a correction you make once becomes documentation tied to the data, not a comment that scrolls away. For managers, you get an auditable record of who raised a concern, who validated it, and what changed, which is how one expert's judgment becomes something the whole organization inherits rather than something that leaves when they do. [Image: The Feedback hub with Recent, Worklist, and General tabs and a New feedback button: a newest-first list of feedback items, each naming the asset, collection, or prompt it belongs to, a title such as Fiscal year start is wrong, a kind badge of correction, question, or suggestion, a status of open, answered, or resolved, who raised it, and the reply count.] The Feedback hub, newest first, across every asset, collection, and prompt you can see. The Worklist tab carries the badge when something is waiting on you. #### Context that follows the answer, and sharper search The business context that Plexara travels with every answer (the owners, descriptions, related memory, and what each column actually means) now arrives in a form that all MCP clients can read, not just some. If you connect a tool that previously showed bare results, the surrounding context now comes with them. Search across memory, saved assets, collections, and prompts now returns cleaner, better-ordered results, and the built-in and configured prompts your team relies on are finally findable instead of tribal knowledge. A round of reliability fixes rounds it out: editing only the body of a saved asset no longer reports a false failure, knowledge you reject stays out of what the assistant recalls later, and shared download links now open from outside your network. Sharing got friendlier too, with the recipient field now suggesting known teammates by name as you type. ### From the Learning section We publish to [the Learning section](https://plexara.io/learning) on a regular cadence. Three pieces this month sit right on the theme above. [Own the learning loop, not just the model June 14, 2026 Our flagship piece this month, and the clearest statement yet of why Plexara is built the way it is. A frontier model can absorb your expertise and commoditize it. The defensible asset is the loop that captures, synthesizes, and validates what your people learn, and keeps it inside your own ecosystem. The concrete test the argument poses: can you swap out a generalist model without losing the company-veteran expertise built into your systems? If changing models means starting your institutional knowledge over, it was never really yours.](https://plexara.io/learning/insights/own-the-learning-loop-not-the-model) [How knowledge application turns usage into documentation March 25, 2026 The capture half of the loop. Most catalogs are empty because documentation is a separate job that competes with the real work for the same hours. Plexara inverts that, so the correction, the filter, the join caveat become structured insights as a byproduct of getting to the answer rather than a second job stacked on top of it.](https://plexara.io/learning/insights/knowledge-application-turns-usage-into-documentation) [When prompts become shared infrastructure June 5, 2026 The method half. A reliable sequence of questions is a method worth keeping. Treated as a governed, searchable, runnable asset, a collection of prompts becomes the organization's real, tested standard operating procedures, captured from actual work rather than written once and forgotten.](https://plexara.io/learning/insights/governed-prompts-and-relevance-search) ### Usage tip: close the loop, do not just leave a comment Last month we suggested saving a finished workflow as a reusable prompt. This month, with the feedback loop live, there is a sharper habit worth building: when someone catches something, resolve it into knowledge rather than leaving a comment that scrolls away. Say a reviewer notices that a column labeled amount is actually in cents, and leaves a correction thread on the report. Instead of fixing it in your head and moving on, ask Plexara to close the loop: > Resolve this feedback thread by capturing it as an insight: the amount column on the receiving report is stored in cents, not dollars. Tie it to that dataset so the next person does not hit the same trap. Plexara records the insight against the right entity, links it to the thread that raised it, and routes it through review before it becomes part of the catalog. The next analyst who touches that table inherits the correction automatically. - For practitioners. The fix you make once is the fix nobody has to make again. A correction becomes documentation without a second trip to a separate tool. - For managers. You get a durable, reversible chain from a raised concern to a validated change. That is how a single expert's judgment turns into something the whole team inherits, instead of something that leaves with the expert. Full argument in [Own the learning loop, not just the model](https://plexara.io/learning/insights/own-the-learning-loop-not-the-model). ### Worth reading from others Four pieces that frame why owning your learning loop, and the governance around it, is the question of the moment. [A frontier without an ecosystem is not stable Satya Nadella, June 2026 The essay behind our flagship piece. Nadella frames it as two kinds of capital: human capital, the judgment of your people, and token capital, the AI capability you own. His argument is that human capital gains value as token capital grows, because "without human direction, you have compute running in circles." The real asset is not the model you pick, it is the learning loop you build on top of it. Read it, then read ours.](https://x.com/satyanadella/status/2066182223213293753) [Donating the Model Context Protocol and establishing the Agentic AI Foundation Anthropic, December 9, 2025 The structural fact underneath the whole argument. MCP is now a founding project of a vendor-neutral Agentic AI Foundation under the Linux Foundation, co-founded by Anthropic, Block, and OpenAI with support from Google, Microsoft, AWS, Cloudflare, and Bloomberg. With more than 97 million monthly SDK downloads and over 10,000 active public servers, MCP is no longer any single vendor's protocol. Building your learning loop on a neutral standard is exactly what lets you swap the model and keep the veteran.](https://www.anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation) [The Mother of All AI Supply Chains OX Security, April 2026 The reason human-in-the-loop is not optional. OX Security walks through a systemic, supply-chain-class vulnerability at the core of common MCP implementations, where an agent reads tool metadata a person never sees and acts on it. It is the clearest case we have read for governing which tools an agent can reach and keeping a human in the approval path before anything writes to your system of record.](https://www.ox.security/blog/the-mother-of-all-ai-supply-chains-critical-systemic-vulnerability-at-the-core-of-the-mcp/) [Modern Data Report 2026: The Data Activation Gap Modern Data 101, February 6, 2026 The numbers behind the context thesis. Across more than 540 data leaders in 64 countries, 80% rank a semantic layer with standardized definitions as the single most important enabler of AI, above the AI tools themselves, while roughly two-thirds say their data lacks the clarity and business context AI requires. The ceiling on agentic AI is set by context, not by model capability.](https://medium.com/@community_md101/modern-data-report-2026-500-data-leaders-and-experts-on-ai-readiness-04798cbbe7f1) We read every reply. If something here was useful, or wasn't, tell us. The API Gateway is still in beta and we are still taking design partners, so if your team has an internal service or a third-party API the agent should be able to call, [send it our way](https://plexara.io/contact) and we will get you onto it. And if there is a topic you want us to take on in a future Dispatch, we are listening. Swap the model whenever a better one ships. The veteran you have built stays, because it was never inside the model. It was in the loop you own. The Plexara team ### Subscribe to the Plexara Newsletter Once a month: new product features, MCP and AI educational resources, practical tips, and enterprise AI insights. Written for data leaders, engineers, and developers. --- # Monthly Dispatch: May 2026 URL: https://plexara.io/learning/newsletter/2026-05/ > The MCP Gateway reaches general availability and the API Gateway opens in beta. Plus three reads from the Learning section, a reusable-prompts tip, and four outside perspectives on enterprise MCP. [All issues](https://plexara.io/learning/newsletter) ## Monthly Dispatch: May 2026 Issue No. 1 May 15, 2026 6 min read Welcome to the first Plexara Monthly Dispatch. Here is what shipped this month, what is worth reading, and one tip we keep coming back to. ### What is new this month Plexara already exposes your data behind a single MCP endpoint through its built-in stack: DataHub for the catalog, Trino for federated SQL across your databases, S3 for object storage, plus knowledge capture, persistent memory, personas, and audit. The two gateway features shipping this month extend that envelope outward, so an agent connected to Plexara can also reach anything else that speaks MCP or HTTP without leaving Plexara's governance. #### MCP Gateway features are stable Now GA The MCP Gateway brings any well-behaved third-party MCP server into the Plexara envelope. Operators add a connection through the admin portal with encrypted credential storage, and the remote server's tools surface to your agents under a namespaced pattern, connection then remote tool, subject to the same authentication, persona-based visibility, and audit pipeline as Plexara's native toolkits. When upstream connections are added, removed, or re-authenticated, downstream clients receive a tools-list-changed notification over the live SSE channel, so the agent's tool inventory updates without a reconnect. The piece we are most pleased to ship at GA is declarative cross-enrichment for proxied responses. A vendor MCP tool result can be joined inline with a Trino query or DataHub lookup, so the response returns with its own data plus your warehouse context in a single call. That puts less pressure on the human and the agent to determine what and how to correlate; integrating an external MCP automatically infers its relationship to your existing enterprise data and capabilities. For practitioners, existing MCP investments (internal servers, vendor MCPs, anything your team has already wired up) become first-class Plexara tools without a rewrite. For managers, it means one governed surface across every MCP the organization deploys: one audit trail, one persona model, one place to grant or revoke access. After several months of production use with clients, the MCP Gateway is moving from preview to general availability. #### API Gateway features are in beta In beta The API Gateway does the same job for REST and GraphQL endpoints. Any HTTP service your team already operates (internal APIs, SaaS platforms, partner endpoints, legacy systems sitting behind an OpenAPI spec) becomes an MCP-callable tool the agent can invoke alongside Trino, DataHub, and S3. Same authentication, same persona-based visibility, same audit trail, same cross-enrichment hooks available to native toolkits. The reason this matters: most enterprise capability is not behind an MCP server today, but behind a REST API. Until those endpoints can be reached by the agent under the same governance Plexara applies to everything else, letting the agent use your systems stays a project. The API Gateway collapses that project into a configuration. We are looking for design partners. If your team has an internal service worth exposing or a third-party API the agent should be able to call, [start a conversation](https://plexara.io/contact) and we will get you onto the beta. [Image: The API Catalogs admin screen with a Salesforce REST API catalog selected from a list that also holds GitHub and Stripe catalogs: the detail shows the catalog identifier, a version badge, how many connections reference it, a description, and a Component specs table where each spec reports its source, an indexed operation count, and when it was fetched, under a notice that all specs are indexed and semantic ranking is active.] The API Catalogs screen in the admin portal. One catalog can back several connections, and each component spec reports how many of its operations are indexed for the agent. ### From the Learning section We publish to [the Learning section](https://plexara.io/learning) on a regular cadence, mixing concept primers, applied Plexara walkthroughs, and dated field notes. Three pieces from recent weeks are worth your time. [Why proximity matters: tools, meaning, and memory belong together May 9, 2026 The clearest single-article statement of why we built Plexara the way we did. When tools, business meaning, and memory live in separate products, the agent pays a latency and hallucination tax, stitching them back together at every turn. When they live in one envelope, the agent reasons about your business with the context already present.](https://plexara.io/learning/insights/why-proximity-matters-tools-meaning-memory) [The context gap in AI data access April 22, 2026 The schema-only view of a database is what most AI integrations give an agent today, and it is not enough. This piece walks through the BIRD benchmark evidence, references the Gartner forecast that 60% of MCP-only agentic analytics projects will fail by 2028 without semantic enrichment, and shows side by side what a tool response looks like with and without catalog metadata traveling alongside it.](https://plexara.io/learning/insights/context-gap-in-ai-data-access) [Token efficiency in enterprise MCP deployments February 25, 2026 The ROI piece. Persona-based tool filtering alone removed roughly 380,000 tokens from a typical 20-exchange session in one of our production deployments, and total per-session cost reductions landed in the 40 to 60% range. If you are tracking AI spend on a per-team basis, and increasingly finance teams are, this is the math.](https://plexara.io/learning/insights/token-efficiency-in-enterprise-mcp) New to the platform? Start with [201, Anatomy of a Plexara MCP](https://plexara.io/learning/mcp/what-is-an-mcp) and read forward through the 200-series. Ten articles, one tour of the whole system. ### Usage tip: capture the workflow, not just the output You worked with Plexara to build a quarterly receiving report, a campaign activation dashboard, a customer cohort export. The output is in hand. Before you close the tab, ask Plexara to save the workflow as a reusable prompt using the Manage Prompts tool. In Claude, or any MCP client, the ask is as simple as: > Use the Manage Prompts tool to take what we just did and save it as a reusable prompt called "Quarterly Receiving Report" so my team can run it next quarter against any department. Plexara writes the prompt, parameterizes the variables (location, quarter, format), and adds it to the library under whatever scope you choose: personal, persona, or org-wide. Next time, anyone authorized invokes it as a slash command and gets the same rigorous result without rebuilding the reasoning from scratch. Two reasons this matters more than it looks: - For practitioners. The first run of a complex analytical workflow takes real thought. The tenth run should not. Reusable prompts turn one expert's careful conversation into a button anyone authorized can press. - For managers. Prompts are the new SOPs. A curated library is institutional knowledge that survives turnover, accelerates onboarding, and gives you a versioned, auditable record of how your team produces its work. Full walkthrough in [208, the prompt library](https://plexara.io/learning/mcp/mcp-prompts-reusable-prompts). ### Worth reading from others Four pieces from this year that frame why MCP, and the work around it, matter right now. [Why Model Context Protocol is suddenly on every executive agenda CIO, February 24, 2026 A clean executive-level read on why MCP has moved from engineering curiosity to boardroom topic in roughly a year. Frames MCP as the connective infrastructure for enterprise AI, walks through where it is already in use (often without leadership knowing), and is realistic about the governance and security work that has to happen in parallel. Hand this to any executive who keeps asking what this MCP thing is and why it keeps coming up.](https://www.cio.com/article/4136548/why-model-context-protocol-is-suddenly-on-every-executive-agenda.html) [The 2026 MCP Roadmap Model Context Protocol blog, March 9, 2026 The official roadmap from MCP's lead maintainer, laying out 2026 priorities: transport scalability, agent-to-agent communication, governance maturation, and enterprise readiness. Notable for what it admits, that production deployments have surfaced a predictable set of enterprise pain points (audit trails, SSO-integrated auth, gateway behavior, configuration portability), and that the protocol's evolution will reflect that. Required reading for anyone planning around MCP in the next twelve months.](https://blog.modelcontextprotocol.io/posts/2026-mcp-roadmap/) [Building a strong data infrastructure for AI agent success MIT Technology Review Insights, March 10, 2026 The argument we wish we had written. More than two-thirds of companies cite data silos as a top adoption challenge, more than half manage upwards of a thousand data sources, and only four in ten believe their data is ready for AI (down from the year prior). The piece's conclusion: the ceiling on agentic AI is set by enterprise data architecture, not by model capability.](https://www.technologyreview.com/2026/03/10/1134083/building-a-strong-data-infrastructure-for-ai-agent-success/) [State of AI trust in 2026: Shifting to the agentic era McKinsey & Company, March 25, 2026 McKinsey's 2026 AI Trust Maturity Survey of roughly 500 organizations. The headline finding for our purposes: as agents take on more autonomy, only about a third of organizations report maturity of three or higher in strategy, governance, and agentic AI governance. Technical capability is outpacing the controls that make it safe to deploy, which is exactly the gap Plexara's persona-based access, execution-time enforcement, and unified audit trail are built to close.](https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/tech-forward/state-of-ai-trust-in-2026-shifting-to-the-agentic-era) We read every reply. If something here was useful, or wasn't, tell us. If you have a use case for the API Gateway beta, [send it our way](https://plexara.io/contact). If there is a topic you would like us to take on in a future Dispatch, we are listening. Thank you for being early. The Plexara team ### Subscribe to the Plexara Newsletter Once a month: new product features, MCP and AI educational resources, practical tips, and enterprise AI insights. Written for data leaders, engineers, and developers. --- # What is a Large Language Model? URL: https://plexara.io/learning/ai-concepts/what-is-a-large-language-model/ > LLMs predict the next token from patterns learned across trillions of training examples. What that means, why it produces fluent reasoning, and its limits. Philosophy 12 min read ## 101 - What is a Large Language Model? LLMs predict the next token from patterns learned across trillions of training examples. What that means, why it produces fluent reasoning, and its limits. On this page ### What you will take away from this lesson You do not need to understand how LLMs work to use Plexara. The platform is built specifically to empower frontier models with the tools and knowledge they need to work effectively with your enterprise data, and it does most of that work on your behalf. A working mental model still helps. This lesson gives you one that is focused entirely on what matters when you sit down with a Plexara MCP connected to Claude, Cursor, or any other MCP-compatible client. Learning Objectives 1. 01 Describe what LLMs do well (language, reasoning, pattern-matching) and what they cannot do on their own (know your data). 2. 02 Recognize the kinds of hallucination you will encounter when an LLM is asked about your business without help. 3. 03 Understand tokens as both the unit of cost and the unit of context, and estimate how much text fits in a prompt. 4. 04 Articulate the division of labor: what the model supplies vs what Plexara supplies. 5. 05 Apply three practical prompting tactics: name the entity, ask the agent to show its work, trust catalog-backed answers more than schema-only ones. ### Brilliant at language, blind about your data The single most important thing to know about a large language model is that it is exceptional at language, reasoning, and pattern-matching, and has no idea what your company does, what your data looks like, or what your metrics mean. Ask a frontier model a general question and it will draw on trillions of tokens of public training data to produce a coherent, useful answer. Ask the same model a question about your company and, without help, it will either refuse to commit or it will invent. The model is blind to everything specific to your organization. That blindness is not a bug in the model; it is the default condition of any LLM until you give it the means to see, and closing [that context gap](https://plexara.io/learning/insights/context-gap-in-ai-data-access) is the whole point of connecting it to your data. Plexara exists to give it the means. Once the model has a Plexara MCP connected, it can reach your catalog, your schemas, your metric definitions, your operational conventions, and your prior conversations. Without that connection, the brilliance of the model is pointed at nothing. ### Tokens: the unit of cost and the unit of context Every interaction with an LLM is measured in tokens. A token is a small chunk of text, usually three or four characters of English. Your pricing, your rate limits, and the amount of text a model can hold at once are all counted in tokens rather than characters or words. Two practical consequences. First, you pay per token. Every character the model reads and every character it writes costs money, which is why pasting your whole database schema into a prompt when you only needed one table is genuinely wasteful, and [token efficiency](https://plexara.io/learning/insights/token-efficiency-in-enterprise-mcp) becomes a real operating concern at enterprise scale. Second, every conversation has a ceiling. Once you hit the model's [context window](https://plexara.io/learning/ai-concepts/context-windows-and-tokens), older turns get dropped or summarized. The model "forgets" the beginning of the conversation. Understanding the token unit is prerequisite for understanding every other constraint in the rest of this curriculum. What a token is, in practice - Input: `Understanding` Under / standing 13 characters, 2 tokens. Longer or less common words get split into subwords. - Input: `·the·quick·brown·fox` ·the / ·quick / ·brown / ·fox 20 characters, 4 tokens. Common words, with their leading space, usually fit into one token each. - Input: `·2026` ·2026 5 characters, 1 token. Frequent 4-digit numbers are a single token; long random numbers are not. - Input: `·antidisestablishmentarianism` ·anti / dis / est / ablish / mentar / ian / ism 29 characters, roughly 7 tokens. Rare long words fragment into many pieces. - Input: `🧠` 0xF0 / 0x9F / 0xA7 / 0xA0 1 visible character, typically 3 to 4 tokens. Emoji and other multi-byte characters are encoded as their underlying UTF-8 bytes, each of which can be its own token. A token can be a fragment of one word, a whole word (usually with its leading space), a whole number, or a single byte of a multi-byte character. In specialized tokenizers, very common multi-word phrases can even be compressed into a single token. The main takeaway is that token count does not track character count or word count in any intuitive way, which is why both budget and context limits have to be estimated and measured rather than guessed. ### How much fits in a token budget Useful to calibrate against real content. A Plexara session starts by loading the platform_info payload, which is the operating manual the model needs in order to use the MCP effectively. The table below is a rule-of-thumb reference for anything else you might include in a prompt. Tokens, to scale 10–20 A short sentence Most chat turns start here. ~500 One page of prose Useful rule of thumb when pasting content. 2K–10K A typical database schema dump Why you should not paste your whole schema. ~6K The ACME demo platform_info payload Loaded automatically at the start of every session. 200K–1M Current frontier context windows Opus 4.7 reaches 1M; most tiers are lower. ### What an LLM gets wrong on your data To see why Plexara matters, look at what a raw LLM does when asked about a real business it knows nothing about. Imagine asking a retail analyst agent a common question: "What were Q3 sales for Store 42?" The model has never seen your transactions table. It has no idea whether Store 42 exists, what the sales table is called, or which column holds the dollar amount. What it produces is the most plausible-sounding answer given the question, which is not the same thing as a correct answer. Ask an LLM about your data without help. Here is what you get. - What the model says A confident dollar amount for "Store 42 Q3 sales." What is actually true The model has never seen your transactions table. Any specific number it produces is a guess that looks authoritative. - What the model says A reference to a `transactions` table. What is actually true Your actual table might be `os_acme_transactions` or `system_sale`. The model defaults to the most common name from its training data. - What the model says A column named `revenue`. What is actually true Your actual column might be `total_amount_cents`, storing values in cents rather than dollars. Math on the wrong column produces wrong numbers. - What the model says "Q3" interpreted as calendar Q3. What is actually true Your fiscal calendar may not align with the calendar year. The model will not ask; it will just pick one. ### The failure mode has a name The industry term is hallucination or confabulation. The name is less important than the pattern: when the model does not know, it does not abstain. It guesses confidently, and the guesses look exactly like knowledge. Every team that adopts an AI assistant hits this failure mode in their first week. Recognizing it is half the battle. The failure mode to expect When an LLM does not know, it does not abstain. It continues generating the most plausible-sounding next tokens, which produces confident statements that are factually wrong. On your data, this looks like invented table names, made-up column names, and specific dollar amounts that do not exist. The solution is not a better prompt; it is grounding the model in real tools and data, which is what Plexara does. ### The one question to keep asking A single habit is worth adopting immediately: for every specific claim the model makes about your data, ask where it came from. The question to hold onto Where did this number come from? If the agent cannot trace its answer to a specific tool call or retrieved document, the answer is a guess. The model will not volunteer this. You have to ask. ### What the model supplies vs what Plexara supplies A useful way to think about a Plexara-connected session is as a division of labor between two capable partners. The model brings its general competencies. Plexara brings everything specific to your organization. Neither partner can do the job alone. The model supplies - Grammar, syntax, vocabulary. - General reasoning and pattern recognition. - Common-sense world knowledge. - Fluency with SQL, Python, and common business vocabulary. - The ability to invoke tools when given ones to use. Plexara supplies - Your schemas and the semantics of each column. - Your metric definitions, glossary terms, and business rules. - Your entity relationships and data lineage. - Your operational constraints (fiscal calendar, tenants, read-only enforcement). - Your memory of prior conversations and captured insights. The division of labor. When you connect a Plexara MCP to a frontier model, you are giving the model the right-hand column. The model already has the left-hand column from its training. ### Three prompting tactics that work You do not need to master prompt engineering to get useful work out of a Plexara session. You do need three habits. Each maps to a concrete problem you will encounter the first time you use the platform. 01 ##### Name the entity. A named entity in the question is a direct signal to the agent that a tool call is warranted. "How are ACME Corp sales doing?" beats "How are sales doing?" 02 ##### Ask the agent to show its work. Specific numbers need specific sources. An agent that cannot point to a table, a column, or a query behind its answer is probably guessing. "Which table did you use?" "Where did that number come from?" "Show me the query." 03 ##### Trust catalog-backed answers more than schema-only ones. If the agent cites a DataHub description, a glossary term, or a curated query, trust it more. If it is working from column names alone, trust it less. ### Where this leads That is the foundation. The rest of the 100 series builds on it: tokens and your budget in 102, context behavior in 103, how frontier and specialized models fit together in 104, what an agent actually is in 105, and how MCP relates to the traditional API world in 110. The 200 series then covers the Plexara MCP itself in depth. Where this leads Plexara is the layer that makes the right-hand column above exist in the model's context at request time. The rest of this curriculum covers how that happens, starting with tokens and budgets in [102](https://plexara.io/learning/ai-concepts/tokens-and-your-budget), and reaching the Plexara MCP itself in [201 - Anatomy of a Plexara MCP](https://plexara.io/learning/mcp/what-is-an-mcp) ### Key terms Six terms cover almost all of the vocabulary you will encounter across this curriculum. Internalizing these now pays off immediately. Key Terms Token A chunk of text, typically three to four characters in English, produced by a tokenizer that splits input into a fixed vocabulary. Every billable request is counted in tokens, and every context window is sized in tokens. Context window The maximum number of tokens a model can process in a single request. Everything the model considers must fit inside this budget: system prompt, prior turns, retrieved documents, the current user message, and the model's own generated output. Hallucination Confabulation The tendency of an LLM to produce confident but factually incorrect output. On your data this shows up as invented table names, made-up column names, and specific numbers that do not exist. Grounding The act of tying a model response to a specific tool call or retrieved document, so the answer can be traced back to a source. A grounded answer can be verified. An ungrounded answer is a guess. Agent An LLM running in a loop that can call tools, observe their results, and plan the next step. An agent is what actually uses a Plexara MCP. The next lesson on AI agents covers this in detail. MCP Model Context Protocol The open standard through which agents discover and invoke tools. Plexara exposes its capabilities to any MCP-compatible agent through this protocol. Further Reading - [A Survey on Hallucination in Large Language Models: Principles, Taxonomy, Challenges, and Open Questions Lei Huang, Weijiang Yu, Weitao Ma, et al. · 2023 A widely cited peer-reviewed survey establishing that LLMs are prone to hallucination, generating plausible yet nonfactual content, and providing a formal taxonomy of the phenomenon.](https://arxiv.org/abs/2311.05232) - [What are tokens and how to count them? | OpenAI Help Center OpenAI Help Center · 2024 Official OpenAI documentation stating that for English text one token is approximately four characters (about 0.75 words) and that pricing and usage are measured in tokens.](https://help.openai.com/en/articles/4936856-what-are-tokens-and-how-to-count-them) - [Specification - Model Context Protocol Model Context Protocol project (Anthropic) · 2025 The authoritative open specification for MCP, an open standard that formalizes how external data, resources, and tools are exposed to LLM clients such as Claude and Cursor.](https://modelcontextprotocol.io/specification/2025-11-25) On this page [Next 102 - Tokens and your budget](https://plexara.io/learning/ai-concepts/tokens-and-your-budget) ### Related reading philosophy [Philosophy 104 - Frontier models, specialized models, and why enterprise AI uses both Frontier models bring world knowledge; small local embedding models power memory and catalog search. Knowing each role designs AI systems that work.](https://plexara.io/learning/ai-concepts/frontier-models-explained) [Philosophy 401 - Prompts are the new SOPs You work with the agent for an hour to get one report exactly right, with a year-over-year cut, holiday annotations, and storm-closure markers. The agent saves durable business knowledge on its own. But that specialized report is not institutional knowledge, it is a procedure. This article draws the line between the two, and makes the case that a saved prompt is the standard operating procedure for an AI-run job.](https://plexara.io/learning/prompts/prompts-are-the-new-sops) [Philosophy 501 - The last mile of data is a spreadsheet The join was never the expensive part of using an outside file. Loading it was, and loading was staffed: a ticket for the table, an engineer for the load, an integration platform somebody had to keep. A chat agent does not close that gap on its own, because a large file does not fit its context and the scripts it writes vanish with the session. This lesson sets out the gap, the registration model that closes it (a table over the file where it sits, nothing copied), and the size rule for when a file needs no table at all.](https://plexara.io/learning/spreadsheets/the-last-mile-of-data-is-a-spreadsheet) --- # Tokens and your budget URL: https://plexara.io/learning/ai-concepts/tokens-and-your-budget/ > Every LLM interaction is priced and rate-limited in tokens. What a token is, how much text fits a budget, and how to avoid wasting tokens on useful answers. Product 8 min read ## 102 - Tokens and your budget Every LLM interaction is priced and rate-limited in tokens. What a token is, how much text fits a budget, and how to avoid wasting tokens on useful answers. On this page ### What you will take away from this lesson Most Plexara users are on a subscription plan. Claude Pro, Claude Max, Claude Team, Claude Enterprise, or an equivalent tier from another vendor. That means the question is almost never "how do I lower my monthly bill." The question is "how do I get the most work done inside the usage limits my plan already pays for." More questions answered, more reports written, more dashboards built, more knowledge captured, all before the session and weekly limits kick in. Tokens are how those limits are measured. A working mental model of tokens is the difference between blowing through a week's usage on Wednesday and finishing Friday with room to spare. Learning Objectives 1. 01 Explain the difference between input tokens and output tokens and why output weighs heavier against a subscription plan. 2. 02 Estimate what a typical Plexara session consumes, broken down by the steps the agent actually takes. 3. 03 Identify the three ceilings a subscription enforces: context window per request, session limit per rolling multi-hour window, and weekly plan limit. 4. 04 Recognize the prompting patterns that burn through a plan and the ones that stretch it. 5. 05 Understand why the discover-query-enrich workflow gets more questions, reports, and dashboards out of the same plan. ### Two meters: input tokens and output tokens Every interaction with a [frontier model](https://plexara.io/learning/ai-concepts/frontier-models-explained) has two meters running in parallel. Input tokens are everything the model reads: the system prompt, the operating manual, prior turns in the conversation, any documents or catalog results that got pulled in, and the current user message. Output tokens are what the model writes back. The two meters weigh differently against your plan. Input tokens count for comparatively little. Output tokens count for significantly more, usually between three and five times as much per token. The shape of this asymmetry is stable across providers and plans. If you only remember one thing from this section, remember that the length of the response is what decides how much of your plan each question consumes. Input tokens and output tokens weigh differently against your plan Input tokens 1× baseline Your prompt, the system instructions, prior turns, retrieved documents, and tool results. Output tokens typically 3 to 5× Whatever the model generates. Weightings vary by provider and tier, but output almost always consumes more of a session and weekly plan limit than input. Practical consequence: a concise answer consumes less of your plan than an exhaustive one. Asking the model to dump every row of a query result into the chat is one of the fastest ways to spend down a session budget. ### What one Plexara question actually consumes Abstract numbers do not help you make good decisions. Concrete numbers do. The breakdown below is the real anatomy of a first question inside a Plexara session, observed across typical operational queries against the ACME Corp demo catalog. Numbers vary by question and by connector, but the shape is stable. Two observations worth internalizing. The platform_info load is a one-time cost per session. Follow-up questions in the same session do not repeat it, which is why long, focused sessions consume less per question than many short ones. The second observation: the trino_query result is the line most likely to blow up, because row count and column width are under your control but not the model's. What one Plexara question actually spends - platform_info load ~6K Once per session. The operating manual the agent needs to use the MCP correctly. - User prompt 20–200 Your actual question. - search result 500–2K Hits grouped by source, with descriptions, owners, tags, and lineage hints. - datahub_get_queries 500–1K Curated query templates for the matched dataset. - trino_query result highly variable Depends on row count and width. Use trino_export for anything over a handful of rows. - Agent reasoning and final response 1K–5K The model thinking plus the answer it writes to you. First question in a session runs about 10K to 15K tokens end to end. Follow-up questions in the same session are cheaper, since platform_info and the catalog context are already loaded. ### Repeat queries get cheaper: Plexara tracks what it has already enriched The "follow-up questions are cheaper" line on the anatomy above is true for a reason specific to Plexara: the platform tracks which tables it has already enriched for you in the current session, and shrinks the enrichment on subsequent queries that touch the same tables. When a Trino query returns rows from a table, Plexara attaches semantic metadata to the result (description, tags, owners, column descriptions and tags, glossary terms, PII flags) so the agent can reason safely about what it is looking at. On the first query against a given table, the full enrichment is sent. On later queries in the same session, when every referenced table has already been enriched recently, Plexara switches to a compact summary or a reference, keeping only the critical fields the agent still needs (warnings, data-quality signals, sensitivity flags). The effect compounds over a working session. A typical analysis revisits the same three or four tables from a dozen different angles. The first question pays the full enrichment cost; every question after that pays a fraction of it. This is a Plexara behavior, not a client or provider behavior, and it is one of several [token efficiency](https://plexara.io/learning/insights/token-efficiency-in-enterprise-mcp) measures scoped tightly: only Trino result enrichment is deduplicated. The platform_info load, catalog search results, and memory recall are not affected. How Plexara shrinks enrichment on repeat queries - Mode 1 ##### Full enrichment When: The first time a table appears in a Trino result this session What it sends: Table description, tags, owners, deprecation status, per-column descriptions and tags, glossary terms, and PII flags. - Mode 2 ##### Summary When: The same table appears in a later query What it sends: Only the fields the agent still needs to reason safely: warnings, data-quality signals, sensitivity flags. Descriptions and tags are not repeated. - Mode 3 ##### Reference When: Aggressive mode for very repeat-heavy sessions What it sends: A one-line pointer noting that full metadata for this table was already sent earlier in the session. The agent can recall it from earlier context. Scope: Plexara's enrichment dedup applies to the semantic metadata attached to Trino query results. The platform_info payload, catalog search results, and memory entries are not deduplicated. Tracking is per MCP session and resets when the session ends. ### The three ceilings your subscription enforces Subscription plans (Claude Pro, Max, Team, and the equivalents from other vendors) enforce usage through three distinct ceilings. Treating them as one number is the most common source of confusion. The first is the [context window](https://plexara.io/learning/ai-concepts/context-windows-and-tokens), which is a per-request ceiling on how much the model can read at once. The second is the session limit, a rolling multi-hour window that Claude and similar clients use to pace usage across the day. The third is the weekly plan limit, the top-line cap that defines what a tier is actually selling. The three are independent. Staying inside all of them is what stretches a plan through a full work week. Per request ##### Context window Unit Tokens Typical 200K to 1M on current frontier tiers What happens when you hit it Old turns fall out of the window or get summarized by the client. Rolling multi-hour ##### Session limit Unit Tokens consumed inside a session window Typical Claude Pro and Max use a rolling window that resets several hours after your first message What happens when you hit it The client pauses new requests inside that client. The window rolls off and resets on its own. Per week ##### Weekly plan limit Unit Tokens consumed across the week Typical Set by your subscription tier (Pro, Max, Team, Enterprise) What happens when you hit it You hit the weekly cap and lose access to the top-tier model for the rest of the week, or pay for additional usage. Three distinct ceilings. A prompt that fits inside your session and weekly plan budget can still exceed the model's context window. The three are independent and all three have to be respected. API-direct users add a fourth ceiling: per-minute rate limits (TPM), which most subscription users never see. ### Specificity is how you get more done per plan Because output tokens weigh heavier than input tokens, the single most effective habit for getting more out of a plan is to ask for what you actually want. A targeted question produces a targeted answer. A vague question produces an exhaustive one, and the model has every incentive to be thorough. Specificity stretches your plan further Output tokens weigh heavier against your session and weekly limits than input tokens do. A question that produces a 200-token answer leaves room for dozens more questions in the same plan window. A question that produces a 5,000-token answer does not. “Give me the top five stores by Q3 revenue” beats “tell me everything about store performance” on quality and on how many more questions you can ask today. ### Patterns that burn through your plan, patterns that stretch it Most teams pick up the habits below within their first week on Plexara. They are worth learning on purpose rather than learning the hard way, which usually means running into a session limit on a Thursday afternoon with two dashboards left to build. None of them require discipline or prompt-engineering expertise; they are just the natural shape of a discover-query-enrich session. Burns through your plan - Pasting an entire database schema into the prompt when the agent can discover the one table it needs. - Asking the agent to output raw rows when what you actually wanted was a summary or a chart. - Running every question inside one endless session instead of starting fresh for unrelated topics. - Using free-form SQL for aggregations the operating manual has already encoded as curated queries. - Repeating setup instructions every turn instead of relying on memory and platform_info. Gets more done per plan - Let search and datahub_get_queries pick the right, pre-optimized query template. - Use trino_export for large result sets so rows never enter the conversation. - Name the dataset or the entity in your question. Specific prompts produce focused responses. - Ask for the insight or the summary, not the raw output. - Start new sessions for unrelated topics so platform_info and memory stay lean. ### Why the default workflow stretches your plan It is tempting to look at the token meter and reach for aggressive self-rationing: truncating context, summarizing every turn, keeping sessions artificially short. In practice, this is rarely necessary with Plexara because the recommended workflow is already the lean one. The catalog returns small, precise context rather than whole schemas. The curated queries are pre-optimized and return the columns the agent actually needs. The export path keeps large result sets out of the conversation entirely. The agent stops when it has enough. The path that is most likely to produce a correct answer is also the path most likely to leave you with session and weekly budget to spare. Why the workflow stretches your plan by default Plexara's default discover-query-enrich workflow (read more in the 200-series lessons) is not only more accurate than free-form querying; it is noticeably leaner. The catalog returns small, precise chunks of context. The curated queries are pre-optimized. The agent stops as soon as it has enough. The path most likely to be correct is also the path most likely to leave you with session and weekly budget to spare. ### Where this leads Tokens are the unit of consumption. The next lesson is about the unit of attention: what the context window actually is, what happens when a conversation fills it up, and why this is the direct reason Plexara has a persistent memory subsystem. What comes next The context window is the ceiling that matters most day to day, and what happens when a conversation approaches it is not obvious. [103 - Context, cutoffs, and compression](https://plexara.io/learning/ai-concepts/context-windows-and-tokens) covers it, plus why this is the direct motivation for Plexara's persistent memory system. ### Key terms Six terms cover the vocabulary you will see in plan pages, limit-reached messages, and provider documentation. Learning them now means those documents read as plain English. Key Terms Input token A token the model reads. Everything you send it (system prompt, prior turns, retrieved documents, tool results, and the current user message) counts as input. Output token A token the model generates. The answer itself, plus any intermediate reasoning it writes. Weighs heavier against your session and weekly plan limits than input tokens do. Session limit A rolling multi-hour usage window used by Claude Pro, Max, and similar subscription tiers. Once the window is full, new requests pause inside that client until the window rolls off. Weekly plan limit The top-line cap on usage across a calendar week. Set by your subscription tier. Maximizing work inside this cap is what subscription users are actually budgeting against. Context window The per-request ceiling on how many tokens the model can process at once. Everything the model considers must fit inside this budget. Semantic enrichment Metadata Plexara attaches to tables in Trino query results: descriptions, tags, owners, column-level detail, glossary terms, and PII flags. Deduplicated within a session so repeat queries against the same tables do not resend the full metadata. trino_export The Plexara tool that writes a large query result to a persisted asset instead of returning the rows in the conversation. The primary mechanism for keeping a large analysis inside a reasonable token budget. Further Reading - [Pricing Anthropic · 2026 Anthropic's official pricing tables list per-model rates where output tokens are billed at a multiple of input tokens (e.g. 5x), confirming the input/output cost asymmetry is stable across the model lineup.](https://docs.anthropic.com/en/docs/about-claude/pricing) - [Context windows Anthropic · 2026 Anthropic documents the context window as the total amount of text (system prompt, conversation history, documents, plus the generated response) a model can reference when producing a single response, framing it as a per-request ceiling.](https://docs.anthropic.com/en/docs/build-with-claude/context-windows) - [Neural Machine Translation of Rare Words with Subword Units Rico Sennrich, Barry Haddow, Alexandra Birch · 2015 Sennrich, Haddow, and Birch's peer-reviewed ACL paper introduced byte-pair-encoding subword tokenization, the foundational mechanism by which models segment text into the sub-word tokens that serve as the unit of consumption.](https://arxiv.org/abs/1508.07909) - [Manage costs effectively Anthropic (Claude Code Docs) Anthropic's cost-management guidance confirms that response length and the amount of context pulled into a session are the primary drivers of token consumption, supporting the article's emphasis on targeted prompts and lean workflows.](https://docs.anthropic.com/en/docs/claude-code/costs) On this page [Previous 101 - What is a Large Language Model?](https://plexara.io/learning/ai-concepts/what-is-a-large-language-model) [Next 103 - Context, compression, and memory](https://plexara.io/learning/ai-concepts/context-windows-and-tokens) ### Related reading product [Product 105 - What is an AI agent? An AI agent is not a chatbot and not magic. It is a short loop (think, call-tool, observe, think again) on top of a language model. Mental model first.](https://plexara.io/learning/ai-concepts/what-is-an-ai-agent) [Product 202 - Your first day with Plexara A new Plexara user gets connected, sends a first question, and platform_info takes over. Walks through day one and how subsequent turns inherit context.](https://plexara.io/learning/mcp/first-engagement) [Product 203 - Discovery: one search, then fetch One question reaches every system the agent can see. Results come back grouped by source with a coverage summary, and fetch reads any of them in full.](https://plexara.io/learning/mcp/discovery-search-and-fetch) --- # Context, compression, and memory URL: https://plexara.io/learning/ai-concepts/context-windows-and-tokens/ > The context window is a model's working memory. Each session balances keeping, compressing, or clearing it. Plexara adds enterprise memory on top. Architecture 9 min read ## 103 - Context, compression, and memory The context window is a model's working memory. Each session balances keeping, compressing, or clearing it. Plexara adds enterprise memory on top. On this page ### What you will take away from this lesson The previous lesson covered [tokens as a unit of consumption](https://plexara.io/learning/ai-concepts/tokens-and-your-budget). This lesson covers the place they all live: the context window. It is the model's entire working memory for a single request, it has a ceiling, and every long session is a small balancing act between keeping that memory, compressing it, or clearing it and starting fresh. The point of the lesson is not to turn you into a context engineer. Plexara and your client handle most of this automatically. The point is to recognize what the three plays are, so you know which one you are making. Learning Objectives 1. 01 Describe what lives inside a single request's context window and why the model treats the window as one undivided budget. 2. 02 Read a provider's context-window number and translate it into a practical capacity. 3. 03 Recognize that context is a form of memory, and that every long session is a balancing act. 4. 04 Choose between the three plays when a context is filling up: keep using it, let it compress, or clear it and start fresh. 5. 05 Understand how frontier clients already ship some memory and how Plexara's enterprise memory layer extends that with semantic search for re-injecting context into a new session. ### What a context window actually is A context window is the maximum number of tokens a model can read and write inside a single call. It is not separate buckets for prompt, history, tools, and response. It is one budget. Every layer of the conversation lives in the same budget and competes for the same space. This matters because the window is shared. A long system prompt leaves less room for conversation history. A verbose tool result leaves less room for the model's reasoning. A detailed response leaves less room for whatever tool call follows it. The model treats all of it as one sequence of tokens. Everything the model reads and writes on one request lives in one budget - System prompt ~500 tokens The baseline instructions your client sets for the model. Small and stable. - platform_info (Plexara operating manual) ~6K tokens Loaded once per session. Teaches the agent how to use the MCP correctly. - Prior conversation turns Grows with session Every question and every answer in the session so far. Grows monotonically. - Retrieved context Varies per turn Catalog results, query templates, memory recall, and semantic enrichment attached to tool output. - Tool results Varies per turn Rows from trino_query, objects from S3, lineage from DataHub, and so on. The most variable line. - Current user message 20 to 200 tokens Your current question. - Model reasoning and response 1K to 5K tokens What the model writes, including any intermediate reasoning. Counts against the same window. The model does not distinguish these layers the way you do. It sees one sequence of tokens and has one budget. Going over the budget means something has to leave. ### How big is a context window in 2026 Specific numbers change roughly quarterly as providers ship new tiers. As of April 2026 the confirmed top-end on Claude is Claude Opus 4.7 at one million tokens. The industry baseline on frontier tiers sits at 200,000 tokens, itself a hundred-fold increase over the original GPT-3 six years ago. The trend is real growth, but growth has slowed as provider focus has shifted to reasoning quality over raw capacity. Practical rule: pick the right tier for the work, but do not rely on knowing the exact current number. Plan pages get updated more often than documentation. Specific sizes and tier availability should be confirmed against the provider's current model page. Context capacity, April 2026 - Claude Opus 4.7 (April 2026) 1,000,000 tokens One million tokens. Fits a mid-sized codebase, a long contract and its exhibits, or a multi-hour meeting transcript in one request. - Baseline frontier tier 200,000 tokens The common industry baseline as of 2026 across Claude, Gemini, GPT, and comparable models. Enough for a long document or a full working session. - Original GPT-3 (2020) 2,048 tokens For scale. Six years ago, frontier context was about two pages. A 500x expansion has redefined what is possible. Specific window sizes vary by provider and by plan tier and are updated several times a year. Consult the provider's model page for your plan before making sizing decisions. ### Context is memory, and memory fills up The practical framing that matters most: the context window is the model's working memory. Everything you have discussed in this session so far, every tool result, every decision, every artifact that the model is still aware of, lives in the same budget. When the budget fills up, something has to happen. Continuing to chat past the ceiling is not an option. This turns the mechanical question "how big is my window" into a practical one: "how am I going to manage my working memory across a long session." There are three plays, and each is right in different situations. Play 1 ##### Keep using When The context is valuable and still fits What happens Do nothing. Stay in the same session. The model keeps full recall of everything you and it have said and done so far. Tradeoff Every turn costs slightly more than the last, and a session that runs long enough will eventually approach the ceiling. Play 2 ##### Let it compress When The context is approaching the ceiling but the work is still live What happens Your client automatically summarizes older turns to make room. Recent turns stay verbatim; early turns get condensed. Tradeoff You keep the thread but lose fidelity on the oldest turns. Important early decisions should be surfaced again or committed to memory before they compress. Play 3 ##### Clear and start fresh When You are moving on to something else, or the session has accumulated stale state What happens Start a new session. Context cost resets to zero. The agent starts clean. Tradeoff Anything that lived only in the conversation is gone. This is where memory and semantic search pay off: Plexara can recall the right prior memories into the new session so you do not start from nothing. Three moves. Which one is right depends entirely on whether you still need the current conversation. The fourth option, doing nothing past the ceiling, is the one to avoid. ### What automatic compression actually does The middle play, letting the client compress, is the one most people encounter without naming it. Every major client begins trimming and summarizing older turns once a conversation approaches the ceiling. It happens silently, and the behavior varies between clients, but the pattern is the same: recent turns stay verbatim, early turns lose fidelity, and the model is left reasoning over a summary of its own history instead of the full record. This is usually fine for ongoing work where the early turns are exploratory scaffolding. It is not fine when what you are doing now depends on a decision or a definition from early in the session. If something matters long enough to survive an hour of conversation, it should be written to memory, not left in the chat to be compressed. What automatic compression actually looks like as the window fills 1. 1 Well under capacity The full conversation sits in the context window as-is. The model sees everything you and it have ever said in this session. Tradeoff: No tradeoffs. This is the best state to work in. 2. 2 Approaching capacity Most clients begin compressing older turns. Early messages get replaced with summaries; tool results get trimmed. Different clients do this differently and usually silently. Tradeoff: Facts from early in the conversation may degrade or disappear. The model might forget a task definition you gave it an hour ago. 3. 3 Over capacity Something has to leave. Without intervention the client drops older turns outright or refuses new input. This is the point at which continuity of the session is no longer guaranteed. Tradeoff: Any fact, decision, or artifact that was only in the conversation is now in jeopardy. The right move here is usually to clear and rely on memory for re-injection. ### What lives past the context window: two memory layers Modern frontier clients have started shipping some memory of their own. Claude, ChatGPT, and similar clients will remember small facts about you personally across sessions inside that client. This is useful for preferences and long-running style notes. It is not built for enterprise data and is not governed by your company's policies. Plexara's memory subsystem sits above client-side memory and is scoped to a workspace. It is semantically searchable, [governed by access controls](https://plexara.io/learning/mcp/governance-personas-and-access), and connected to the catalog, so a brand-new session can retrieve the relevant prior memories, facts about your data, decisions made yesterday, curated artifacts, and re-introduce them as context without you having to name them. Keeping memory close to the catalog and tools is the subject of [why proximity matters for tools, meaning, and memory](https://plexara.io/learning/insights/why-proximity-matters-tools-meaning-memory). Layer ##### Client-side memory Scope Per user, per client (Claude, ChatGPT, and comparable clients ship this) Good at Personal preferences, long-running style notes, "remember I work in Python" kinds of facts. Surfaces automatically inside the same client. Not for Enterprise data. Not governed by your policies, not connected to your catalog, not shared across teammates, not searchable by topic. Layer ##### Plexara enterprise memory Scope Per workspace or team, governed by your access controls Good at Facts about your data, decisions made in prior sessions, curated artifacts, glossary terms, and anything else that needs to survive across a work week. Semantically searchable, so a new session can retrieve the relevant memories without asking for them by name. Not for Raw secrets or credentials. Memory is a recall layer, not a vault. ### Putting it all together Use context while it fits. Let it compress if the thread is still live but the window is getting tight. Clear and start fresh when you are moving to something else, and trust memory to bring back what matters. The balancing act is small once you have seen the three plays side by side. Context is working memory; Plexara adds the long-term layer A context window is scratch paper. When you clear the session, the paper is thrown away. Plexara's memory subsystem is what persists the facts, decisions, and artifacts worth keeping, and uses semantic search to pull the right memories back into a new session without you having to name them. [207 - Knowledge: From Memory to Insights](https://plexara.io/learning/mcp/knowledge-from-memory-to-insights) covers the memory subsystem end to end. ### Key terms Six terms cover most of the vocabulary you will see in client documentation and in discussions about session strategy. Key Terms Context window The per-request token budget a model can read and write inside a single call. Everything the model considers must fit here. Working memory What a model holds inside a single request. The context window is working memory: present in the moment, gone at the next request unless something else preserves it. Context compression Client-side behavior that summarizes, truncates, or drops older turns when a conversation approaches the context window ceiling. Quiet and implementation-specific. Clear and restart Starting a new session instead of letting the current one fill up. Resets context cost to zero. Requires memory to re-inject anything you still need. Client-side memory Memory that the AI client itself (Claude, ChatGPT, and similar) stores about a user, surfaced automatically in later sessions inside that client. Plexara enterprise memory A semantically searchable, governed memory layer scoped to a workspace or team. Lets a fresh session retrieve relevant prior memories to re-inject as context. Covered in detail in [206](https://plexara.io/learning/mcp/knowledge-from-memory-to-insights). Further Reading - [Context windows Anthropic · 2026 Anthropic's official docs define the context window as the maximum tokens a model can read and generate in a single request and explicitly describe it as the model's 'working memory,' a shared budget covering history and output.](https://platform.claude.com/docs/en/build-with-claude/context-windows) - [Language Models are Few-Shot Learners Tom B. Brown, Benjamin Mann, Nick Ryder, Melanie Subbiah, Jared Kaplan, et al. (OpenAI) · 2020 The original GPT-3 paper specifies a context window of nctx = 2048 tokens, establishing the ~200x-to-larger baseline against which today's 200K and 1M token windows are measured.](https://arxiv.org/abs/2005.14165) - [Compaction Anthropic · 2026 Anthropic's official compaction documentation describes automatically summarizing older context when a conversation approaches the context window limit and replacing the full history with a concise summary the model then reasons over.](https://platform.claude.com/docs/en/build-with-claude/compaction) On this page [Previous 102 - Tokens and your budget](https://plexara.io/learning/ai-concepts/tokens-and-your-budget) [Next 104 - Frontier models, specialized models, and why enterprise AI uses both](https://plexara.io/learning/ai-concepts/frontier-models-explained) ### Related reading architecture [Architecture 201 - Anatomy of a Plexara MCP 201 shows what is actually in the box on a Plexara server: the tool inventory by toolkit, the four content layers, the interactive apps a tool result can carry, and the memory, knowledge, and governance underneath. This lesson is the map.](https://plexara.io/learning/mcp/what-is-an-mcp) [Architecture Five kinds of memory, and how each comes back A fact, an incident, a person, a link, and a habit are five different kinds of knowledge. Plexara stores each as its own dimension and recalls it the way that kind needs, which is what makes memory across sessions feel like memory rather than search.](https://plexara.io/learning/insights/five-kinds-of-memory) [Architecture Search the capability, not the manual: how Plexara keeps a wide platform light Loading every API spec into context does not scale. A small, fixed tool footprint plus semantic endpoint discovery keeps cost tied to the task, not the size of the platform.](https://plexara.io/learning/insights/search-the-capability-not-the-manual) --- # Frontier models, specialized models, and why enterprise AI uses both URL: https://plexara.io/learning/ai-concepts/frontier-models-explained/ > Frontier models bring world knowledge; small local embedding models power memory and catalog search. Knowing each role designs AI systems that work. Philosophy 12 min read ## 104 - Frontier models, specialized models, and why enterprise AI uses both Frontier models bring world knowledge; small local embedding models power memory and catalog search. Knowing each role designs AI systems that work. On this page ### What you will take away from this lesson Enterprise AI is almost never one model doing everything. A frontier model brings the reasoning and the world knowledge. A smaller specialized model runs alongside it for narrow jobs that happen at volume, not in place of it. This lesson walks through the three families that dominate the frontier today, the three separate sources a frontier model can draw knowledge from, and why the common conflation of MCP with "retrieval" is worth correcting before you go further into the curriculum. Learning Objectives 1. 01 Explain what a frontier model is and what distinguishes the three current families (Claude, GPT, Gemini). 2. 02 Identify the three sources a frontier model can pull knowledge from: training data, a first-party web search, and tools wired in from the outside. 3. 03 Understand that MCP is a protocol for exposing tools and resources to models, orthogonal to how those tools go on to retrieve anything. 4. 04 Recognize that enterprise data was never in any training corpus, which is why a protocol like MCP matters for access to it regardless of cutoff dates. 5. 05 Describe how a customer connects their chosen frontier model to Plexara over MCP, while Plexara runs Ollama internally for specific narrow jobs like embeddings. ### What "frontier" actually means A frontier model is a [large language model](https://plexara.io/learning/ai-concepts/what-is-a-large-language-model) at or near the current limit of what is publicly available in terms of scale, training data, and capability. The label is relative and moves as the state of the art advances. A model that was frontier in 2023 may be a mid-tier model in 2026. Three signals mark a model as frontier. First, scale: parameter counts and training compute measured in exaflops that only a handful of labs can afford. Second, capability: top scores on reasoning, coding, mathematics, and multimodal benchmarks. Third, steerability: reliable instruction-following, calibrated responses, and the interaction patterns enterprise deployments require, especially tool use and [long-context reasoning](https://plexara.io/learning/ai-concepts/context-windows-and-tokens). As of 2026, three families dominate the conversation. Each is released in multiple tiers that trade capability against latency and cost, and each iterates on a roughly six-to-twelve month cadence. Anthropic ##### Claude Tiers Opus, Sonnet, Haiku Context Up to 1M tokens on Opus 4.7 Particular strength Careful instruction-following, tool use, extended reasoning modes. Notes Common default for enterprise agentic workflows. Plexara is model-agnostic; Claude is one supported frontier. OpenAI ##### GPT Tiers Flagship reasoning, mid-tier, fast variants Context Depends on tier Particular strength Broad capability, mature ecosystem, multimodal variants for image, audio, and voice. Notes Accessible through OpenAI directly or through Microsoft Azure for enterprises that need the Microsoft compliance posture. Google DeepMind ##### Gemini Tiers Ultra / Pro, Flash, on-device Context Long-context strength, often exceeding 1M tokens Particular strength Multimodal by design. Text, image, audio, and video in one context. Notes Tightly integrated with Google Cloud and Workspace. Natural fit for organizations already standardized on Google. Three dominant families as of April 2026. Specific tier names and numbers shift roughly every quarter; treat the vendor's pricing page as source of truth. ### Three sources of knowledge a frontier model can draw from Where does a frontier model's answer actually come from? There are three separate sources, and it is worth keeping them straight because they are solved by three different mechanisms. The training-cutoff question, the "can it see today's news" question, and the "can it see our data" question are not the same question. ##### Training data Covers Public text, code, and documents the lab scraped and curated, up to a fixed training cutoff date. Mechanism Encoded directly into the model weights. No retrieval step; the model answers from its own parameters. Caveat Nothing that happened after the cutoff is visible, and nothing that was private to an organization was ever there in the first place. ##### First-party web search Covers Public facts and events from after the training cutoff. Mechanism Built into the frontier client (Claude.ai, ChatGPT, Gemini each ship their own). The client runs a search, feeds the snippets to the model, and the model writes an answer. Caveat Provider-specific and not MCP. Covers only what is public on the open web. Your internal systems do not live there. ##### Tools wired in from outside Covers Everything else: enterprise data, internal documents, private APIs, and anything else that is not on the public web. Mechanism The model invokes tools that the client has connected to. Plexara is one of those tools. The tool runs the retrieval; the model reasons over the result. Caveat MCP is the protocol that advertises these tools to the model. The retrieval itself is done by whatever the tool actually is; MCP describes how it gets exposed, not what happens inside. These three sources are independent. A single answer can draw from one, two, or all three, depending on what the question needs and what the client has connected. ### MCP is a protocol for exposing tools, not a retrieval method The third column above is the one most easily misread. MCP sits at the column header, but MCP is not doing any searching. It is the protocol that tells the model a tool is available, describes what the tool does, and carries the invocation. The tool on the other end is the thing that actually retrieves anything. Retrieval, RAG, tool-use search: these are orthogonal concerns that happen to be how many MCP-exposed tools work, not [what MCP itself is](https://plexara.io/learning/ai-concepts/mcp-vs-apis). MCP is a protocol for exposing tools, not a retrieval method A common mental model merges MCP and retrieval into one thing. They are not. MCP is a protocol that lets a client advertise tools and resources to a model so the model can choose to invoke them. What any particular tool does when it is invoked (search, query a database, fetch a file) is orthogonal. The first-party web search baked into Claude.ai, ChatGPT, and Gemini is a provider integration; it is not MCP. MCP shows up when a customer wires their own external systems (like Plexara) into the model. ### Why frontier world knowledge still matters for your data Enterprise data is never as simple as running inference on a raw schema. The hard part is never the SQL syntax. It is knowing what the data actually means in the context of the business: which metric the CFO cares about, which definition of "active customer" applies in this region, whether revenue is reported net or gross in this table, how the holiday calendar shifts week-over-week comparisons in retail. This is where frontier models earn their keep even when none of your data was in their training. Trained on trillions of tokens of public web data, books, and code, they have absorbed the background world knowledge that a skilled data engineer or business analyst accumulates across decades of work. A frontier model already knows that a store located in Los Angeles has a larger addressable market than one in a small town. It already knows that "churn" means customers leaving, that Q4 skews heavily in retail, that "GAAP revenue" excludes certain adjustments, and that a column called "arr" is probably annualized recurring revenue. Smaller and more specialized models do not have this breadth. They were not trained to know that Los Angeles is a large market. That kind of generalized common sense is the direct output of the massive, diverse pre-training corpora that only frontier labs can afford to assemble and train on. ### Specialized models do one thing better A specialized model is trained or fine-tuned to do a specific task, not to hold a general conversation. The trade-off is exactly what you would expect: narrower scope, lower cost, lower latency, and often higher accuracy on the task it was built for. Common examples include embedding models that convert text into fixed-size vectors for similarity search, classifiers that tag content by category, named-entity extractors, and safety or moderation filters. What specialized models lack is world knowledge. An embedding model produces a useful vector for any text it is given, but it will not reason about whether "sales" in a given query means gross revenue, net revenue, or unit count. A classifier labels content by the categories it was trained on and nothing else. They are not chosen instead of a frontier model. They are chosen alongside one, for the narrow jobs that run thousands or millions of times per day where a frontier round trip would be wasteful. Frontier model Good at - Interpreting an ambiguous user question. - Choosing which tools and data to consult. - Reasoning over returned data and producing narrative answers. - Catching subtle business-logic errors from world knowledge in training. Not for Running at massive scale inside a tight latency budget. Every call is a network round trip and non-trivial compute. Specialized model (used alongside the frontier) Good at - Generating embeddings for semantic search and memory recall. - Classifying, tagging, or filtering content at volume. - Entity extraction, PII detection, and other narrow tasks. - Running inside a private network at low latency and low cost. Not for Open-ended reasoning, ambiguous intent, or anything that requires knowledge outside the narrow task the model was trained for. ### Local and open-weight models A parallel ecosystem of open-weight models continues to close the gap with frontier labs on many tasks. Meta's Llama family, Mistral's models, and releases from DeepSeek and Qwen offer capable alternatives where self-hosting, on-premise deployment, or custom fine-tuning matters more than absolute benchmark leadership. Local models are often smaller than frontier flagships, frequently specialized or fine-tuned, and typically run inside a customer's own infrastructure. They make sense when data residency rules forbid sending content to a third-party API, when latency budgets rule out a network round trip, when per-request cost at massive volume outweighs the capability gap, or when a specific domain has been fine-tuned into a smaller model that beats a general frontier model on that domain. The trade-off is that local and smaller models trail frontier models on the tasks that benefit most from breadth: open-ended reasoning, ambiguity resolution, and drawing on world knowledge that was never in the schema. They can be excellent components in a larger system. They rarely replace a frontier model as the top-level reasoner for questions that require judgment. ### How the customer's frontier model and Plexara work together over MCP Worth stating plainly because the framing is easy to get wrong: Plexara does not run the frontier model. Plexara is an MCP server. The customer chooses a frontier model and a client (Claude.ai, ChatGPT, Gemini, Claude Desktop, Cursor, or any other MCP-capable client) and connects that client to Plexara. The frontier model lives on the customer's side of that connection. Plexara lives on the other side. Inside Plexara, narrow specialized models handle high-volume internal jobs. A small embedding model (Ollama serving nomic-embed-text) produces the 768-dimensional vectors that the Plexara [memory and knowledge subsystems](https://plexara.io/learning/mcp/knowledge-from-memory-to-insights) both depend on for semantic search. Ollama is not chosen because it is a better general model than the frontier. It is chosen because embeddings are a narrow internal job at a latency and volume that would be wasteful to send across a frontier round trip. Plexara is on one side of MCP; the customer's frontier model is on the other - On the customer side (reasoning) A frontier model running in the customer's client (Claude.ai, ChatGPT, Gemini, Claude Desktop, Cursor, or comparable) Interprets the question, decides when to call a tool, reasons over the tool result, and writes the answer. Plexara does not host this layer and does not choose it. The customer does. - Between them (protocol) Model Context Protocol (MCP) How Plexara advertises its tools and resources to whichever frontier model the customer has connected. Protocol only, not a retrieval mechanism. - Inside Plexara (infrastructure) Plexara the MCP server, with Ollama serving nomic-embed-text (768-dim) inside the Plexara cluster Plexara handles the tools the frontier model calls. Internally, Plexara uses Ollama for narrow high-volume jobs (embeddings for memory recall and DataHub semantic catalog search) where the latency and throughput requirements rule out a frontier round trip. Plexara does not run the frontier model. Plexara is an MCP server the customer connects to. The frontier model stays on the customer's side of MCP and does the reasoning; Ollama lives inside Plexara and powers narrow internal jobs like memory and knowledge subsystem embeddings. ### How enterprises actually choose There is no single correct model and no single correct tier. Choice is driven by the workload and by constraints that have nothing to do with raw benchmark scores. What actually decides the model choice In practice the deciding factors are almost never pure benchmark scores. Latency budget, per-request cost at expected volume, data residency requirements, existing cloud contracts, and the specific tool-use patterns the application needs all narrow the field before capability enters the conversation. The architecturally durable move is to not bet the business on one model at one tier from one vendor, which is exactly what MCP enables. ### Key terms Eight terms cover the vocabulary you will see in model vendor documentation, architecture discussions, and Plexara reference material. Tool use and RAG in particular are worth pinning down now so the rest of the curriculum does not have to keep defining them. Key Terms Frontier model A large language model at or near the current state of the art in scale, capability, and steerability. Claude, GPT, and Gemini are the three dominant frontier families in 2026. Training cutoff The date after which events, documents, and data are not represented in a frontier model's weights. For public post-cutoff information, most frontier clients ship a first-party web search. Enterprise data is a separate problem entirely and was never in training to begin with. First-party web search A provider-built tool (in Claude.ai, ChatGPT, and Gemini) that fetches public snippets from the open web and feeds them to the model. It is not MCP. It does not cover internal systems. Tool tool use A capability a model can choose to invoke during a response: querying a database, running a web search, reading a file, calling an API. A model that can call tools is said to be doing tool use. MCP is one way tools get exposed; first-party built-ins are another. RAG retrieval-augmented generation A pattern in which relevant documents or data are retrieved (often via semantic search) and placed in the model's context window before it generates an answer. A technique, not a protocol. A RAG workflow can be implemented with or without MCP; MCP only describes how a retrieval tool is exposed to the model. Specialized model A model trained or fine-tuned for a specific task rather than general conversation. Embedding models, classifiers, and entity extractors are common examples. Used alongside a frontier model, not instead of it. Embedding model A specialized model that converts text into a fixed-size vector for similarity search. Plexara runs Ollama with nomic-embed-text (768-dim output) inside the platform for memory recall and DataHub semantic catalog search. MCP The Model Context Protocol. A protocol for a client to advertise tools and resources to a model. Orthogonal to retrieval: MCP describes how tools are exposed, not how any particular tool does its work. Further Reading - [Introducing the Model Context Protocol Anthropic · 2024 Anthropic's official announcement defines MCP as an open standard for building secure two-way connections between AI tools and data sources, a protocol for exposing tools and context rather than a retrieval mechanism.](https://www.anthropic.com/news/model-context-protocol) - [Nomic Embed: Training a Reproducible Long Context Text Embedder Zach Nussbaum, John X. Morris, Brandon Duderstadt, Andriy Mulyar · 2024 The technical report for nomic-embed-text documents it as a 768-dimensional text embedding model with an 8192-token context, establishing the embedding dimensionality the article cites.](https://arxiv.org/abs/2402.01613) - [Training Compute Thresholds: Features and Functions in AI Regulation Lennart Heim, Leonie Koessler · 2024 Peer-style analysis showing that frontier models are operationally distinguished by very large training-compute budgets (e.g. the 10^25-10^26 FLOP thresholds used in regulation), supporting scale and compute as defining frontier signals.](https://arxiv.org/abs/2405.10799) On this page [Previous 103 - Context, compression, and memory](https://plexara.io/learning/ai-concepts/context-windows-and-tokens) [Next 105 - What is an AI agent?](https://plexara.io/learning/ai-concepts/what-is-an-ai-agent) ### Related reading philosophy [Philosophy 101 - What is a Large Language Model? LLMs predict the next token from patterns learned across trillions of training examples. What that means, why it produces fluent reasoning, and its limits.](https://plexara.io/learning/ai-concepts/what-is-a-large-language-model) [Philosophy 401 - Prompts are the new SOPs You work with the agent for an hour to get one report exactly right, with a year-over-year cut, holiday annotations, and storm-closure markers. The agent saves durable business knowledge on its own. But that specialized report is not institutional knowledge, it is a procedure. This article draws the line between the two, and makes the case that a saved prompt is the standard operating procedure for an AI-run job.](https://plexara.io/learning/prompts/prompts-are-the-new-sops) [Philosophy 501 - The last mile of data is a spreadsheet The join was never the expensive part of using an outside file. Loading it was, and loading was staffed: a ticket for the table, an engineer for the load, an integration platform somebody had to keep. A chat agent does not close that gap on its own, because a large file does not fit its context and the scripts it writes vanish with the session. This lesson sets out the gap, the registration model that closes it (a table over the file where it sits, nothing copied), and the size rule for when a file needs no table at all.](https://plexara.io/learning/spreadsheets/the-last-mile-of-data-is-a-spreadsheet) --- # What is an AI agent? URL: https://plexara.io/learning/ai-concepts/what-is-an-ai-agent/ > An AI agent is not a chatbot and not magic. It is a short loop (think, call-tool, observe, think again) on top of a language model. Mental model first. Product 10 min read ## 105 - What is an AI agent? An AI agent is not a chatbot and not magic. It is a short loop (think, call-tool, observe, think again) on top of a language model. Mental model first. On this page ### What you will take away from this lesson The words "agent" and "agentic" show up everywhere and they sound heavier than they are. The point of this lesson is to de-mystify them. You do not need to understand every aspect of modern AI to use Plexara well. You do benefit from a working mental model, the same way you benefit from a rough mental model of how a car engine works even if you never intend to fix one. The reason this matters is communication. You would not talk to a medical doctor the same way you talk to a small child. The way an AI agent works is unusual enough that most people's default communication style does not quite fit. A short, accurate mental model fixes that. Learning Objectives 1. 01 De-mystify the words "agent" and "agentic". They name a simple loop, not a kind of magic. 2. 02 Draw the think / call-tool / observe / think loop that defines agentic behavior. 3. 03 Explain, in a sentence, when an agent reaches for a tool instead of answering from what it already knows. 4. 04 Describe the useful mental model behind communicating with an AI agent: a college professor's breadth paired with a small child's literalism. 5. 05 Apply four simple communication habits that work better once that model is in place. ### A professor's knowledge, a child's literalism The single most useful mental model for communicating with an AI agent is this: the model brings the breadth and fluency of a knowledgeable professional, and it brings the memory, context, and literal-mindedness of a very small child. Not every comparison is perfect, but this one captures the specific mismatch that makes AI conversations feel different from human ones. Once the combination is in mind, your prompts start improving on their own. You stop assuming the agent remembers what you talked about yesterday, because it does not. You stop leaving the key noun ambiguous, because the agent will not fill it in from context the way a colleague would. You stop treating confident language as evidence of accuracy. These are small adjustments, and they make a large difference in the quality of the work the agent produces. What the AI has (professor-like) - Vast general knowledge from training, across languages, industries, and technical domains. - Fluent, idiomatic writing and the ability to reason step by step. - Comfort with abstractions, analogies, and the vocabulary of almost any field. - Confidence. Sometimes more than is earned. What the AI lacks (child-like) - Any memory of what you said yesterday, or last hour, unless it is in the current context. - Any knowledge of your company, your data, or your conventions unless you supply it or wire in a tool. - Common-sense judgment about implicit context. "That report" without a name is genuinely ambiguous. - A native sense of when to stop. A vague prompt produces an exhaustive, confidently wrong answer just as readily as a correct one. You would not talk to a doctor the way you talk to a small child. You would also not expect a doctor to produce an answer when they have no idea who their patient is. An AI agent is both at once, and good communication accounts for both sides at the same time. ### What an agent actually is An agent, in the AI sense, is a language model operating inside a loop where it can take actions rather than just produce text. Those actions are called tool calls. A tool is anything the client has connected the model to: a web search, a calculator, a code executor, or an MCP server like Plexara. "Agentic" is the adjective. An agentic workflow is one in which the model takes more than one step, usually involving at least one tool call. There is no separate "agentic AI" that is fundamentally different from a regular LLM. It is the same underlying model, run inside the loop described below. ### The loop underneath everything The loop is short enough to draw on a napkin. Most of what the AI industry means by "agentic" is this pattern, iterated as many times as needed until the model has enough information to answer. The agent loop: think, call-tool, observe, think again 1. 1. Your prompt arrives The user message lands in the model along with system instructions, any operating manual (like platform_info), and whatever prior turns still fit in the context window. 2. 2. The model reasons The model considers what the question needs. It weighs what it already knows from training against what it would need to look up. This is the "thinking" step; some providers let you see it. 3. 3. The model calls a tool (sometimes) If a tool would produce a better answer than guessing, the model emits a tool call. In Plexara this is where search, trino_query, save_asset, and the rest get invoked. 4. 4. The tool returns an observation The tool runs, does whatever it does, and returns a result. That result is handed back to the model as new context. The model now knows more than it did a moment ago. 5. 5. Loop or answer The model reasons again. If more information is needed, it calls another tool and the loop continues. Otherwise it writes the final answer to you. That is the whole thing. You could draw it on a napkin. “Agentic” is just the adjective for software that follows this loop. It is not a separate species of intelligence. ### When the agent reaches for a tool The model does not call tools for fun. It calls them when answering the question without a tool would force it to either guess or refuse. The 104 lesson covered the three sources of knowledge a [frontier model can draw from](https://plexara.io/learning/ai-concepts/frontier-models-explained) (its training data, a first-party web search, and tools wired in from the outside). The agent's decision about whether to call a tool is essentially a decision about which of those three sources the current question needs. The rule the agent uses to decide whether to call a tool A short decision rule covers most cases. If the answer can be produced from what the model already knows (general patterns, industry-standard definitions, public reasoning), it answers directly. If the answer requires something that is either public and new (a recent event, today's news) or private (your data, your metrics, your documents), it reaches for a tool. Plexara's tools are the ones that cover the private case. MCP is how those tools were advertised to the model so that it knew to consider them in the first place. ### Where MCP fits MCP does not change how the loop works. It changes which tools the model has to choose from. An [MCP server advertises tools and resources](https://plexara.io/learning/mcp/what-is-an-mcp) to whichever client is connected. When the customer wires Plexara into their client, a long list of Plexara tools becomes visible to the agent, and the agent can choose to call any of them during step 3 of the loop above. The agent is not "aware" of Plexara in some deeper sense. It simply has more tools in its list. The important implication for you: the quality of your answer often depends on whether [the right tool was available to the agent](https://plexara.io/learning/insights/why-more-tools-wont-make-your-agent-smarter), which is a governance and configuration question as much as a modeling one. ### Four habits that work once the model is in place The point of a mental model is not to collect vocabulary. It is to change how you interact with the system. Given what has been covered so far, four small communication habits consistently produce better results with an AI agent, and each maps directly back to something earlier in the lesson. Four habits that work once you have the mental model 1. 01 Name entities explicitly Say "store 42" and "the Q3 revenue metric from the finance glossary" rather than "that store" or "the usual revenue number." The agent takes the words literally and has no separate memory of yesterday's conversation. 2. 02 State your assumptions If fiscal Q3 ends on a specific date, say so. If "active customer" has a specific definition in your business, surface it. A professor-level model with a child-level memory still needs the definition spelled out once in the current session. 3. 03 Ask the agent to show its work "List the tools you called and why" is a legitimate instruction. Tool calls are visible in most clients; asking for them to be named in the final answer surfaces whether the agent grounded its claims in your data or made them up. 4. 04 Start a fresh session when the topic changes The context window fills up and old turns compress. A fresh session is cleaner and cheaper, and Plexara memory recalls the relevant prior context without you reconstructing it (covered in [103](https://plexara.io/learning/ai-concepts/context-windows-and-tokens) and [206](https://plexara.io/learning/mcp/knowledge-from-memory-to-insights)). ### Where this leads With agents, the loop, tools, and the decision rule in place, the remaining question is how a specific MCP server fits into all of this in practice. That is what the 200 series is for, with the Plexara MCP at the center. This is the bridge into the 200 series The loop, the tool calls, and the agent behavior are the pieces of the 100 series. The 200 series is where those pieces get wired up to a specific MCP server with specific tools, specific governance, and specific memory. [201 - What is an MCP?](https://plexara.io/learning/mcp/what-is-an-mcp) is the natural next step once 110 (MCP vs traditional APIs) closes the 100 series. ### Key terms Six terms cover almost every conversation about agentic behavior. "Autonomous" in particular is worth pinning down because it gets used loosely and carries connotations that do not match what agents actually do. Key Terms Agent A language model operating inside a loop where it can call tools and react to the results. Not a separate kind of AI; a mode of operation. Agentic The adjective for software that behaves as an agent. "Agentic workflow" means a workflow in which the model takes multiple steps, often invoking tools, rather than producing a single direct answer. Autonomous Often used interchangeably with agentic, but more specific: an autonomous agent makes its own decisions about when to loop and when to stop, within bounds the client and the MCP server set. "Autonomous" does not mean "unsupervised" or "unstoppable." Tool call A structured message the model emits to invoke a tool it was told about (via MCP or a first-party integration). Looks like a function call with named arguments. Observation tool result The data the tool returns after a tool call. Gets fed back to the model as new context on the next pass through the loop. Agent loop The repeating cycle of model reasoning, optional tool call, observation of the result, and further reasoning, until the agent produces a final answer to the user. Further Reading - [ReAct: Synergizing Reasoning and Acting in Language Models Shunyu Yao, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik Narasimhan, Yuan Cao · 2022 Introduces the interleaved reason-act-observe loop where an LLM generates reasoning traces and task-specific actions that interface with external sources to gather information, the canonical formalization of the agent loop.](https://arxiv.org/abs/2210.03629) - [Toolformer: Language Models Can Teach Themselves to Use Tools Timo Schick, Jane Dwivedi-Yu, Roberto Dessi, Roberta Raileanu, Maria Lomeli, Luke Zettlemoyer, Nicola Cancedda, Thomas Scialom (Meta AI) · 2023 Demonstrates that LLMs can learn to decide which external API/tool to call, when, and with what arguments, to overcome limitations like factual lookup and arithmetic that the base model cannot reliably do alone.](https://arxiv.org/abs/2302.04761) - [Specification - Model Context Protocol Model Context Protocol (official spec) · 2025 The official open standard defining MCP's primitives, where a server advertises tools (model-controlled, invoked during the conversation) and resources to whichever connected client, exactly the mechanism the article describes.](https://modelcontextprotocol.io/specification/2025-11-25) - [A Survey on Hallucination in Large Language Models: Principles, Taxonomy, Challenges, and Open Questions Lei Huang, Weijiang Yu, Weitao Ma, Weihong Zhong, Zhangyin Feng, Haotian Wang, Qianglong Chen, Weihua Peng, Xiaocheng Feng, Bing Qin, Ting Liu · 2023 Peer-reviewed survey establishing that LLMs generate content that is fluent and plausible-sounding yet factually incorrect or unsupported, so confident/fluent phrasing is not evidence of accuracy.](https://arxiv.org/abs/2311.05232) On this page [Previous 104 - Frontier models, specialized models, and why enterprise AI uses both](https://plexara.io/learning/ai-concepts/frontier-models-explained) [Next 110 - Is MCP just an API wrapper?](https://plexara.io/learning/ai-concepts/mcp-vs-apis) ### Related reading product [Product 102 - Tokens and your budget Every LLM interaction is priced and rate-limited in tokens. What a token is, how much text fits a budget, and how to avoid wasting tokens on useful answers.](https://plexara.io/learning/ai-concepts/tokens-and-your-budget) [Product 202 - Your first day with Plexara A new Plexara user gets connected, sends a first question, and platform_info takes over. Walks through day one and how subsequent turns inherit context.](https://plexara.io/learning/mcp/first-engagement) [Product 203 - Discovery: one search, then fetch One question reaches every system the agent can see. Results come back grouped by source with a coverage summary, and fetch reads any of them in full.](https://plexara.io/learning/mcp/discovery-search-and-fetch) --- # Is MCP just an API wrapper? URL: https://plexara.io/learning/ai-concepts/mcp-vs-apis/ > MCP is not a replacement for your APIs and not a thin proxy. It is an application layer on top, like a website is an application layer on top of its APIs. Integration 8 min read ## 110 - Is MCP just an API wrapper? MCP is not a replacement for your APIs and not a thin proxy. It is an application layer on top, like a website is an application layer on top of its APIs. On this page ### What you will take away from this lesson The 100 series started with models, worked through tokens and context, landed on agents. This final 100-series lesson closes with the [protocol that connects all of it to your data](https://plexara.io/learning/insights/protocols-outlast-products). The question most people ask at this point, in one form or another, is whether MCP is just a wrapper around existing APIs. This lesson takes that question seriously and answers it. The answer is no, and the reason matters. It is the same reason you use a website instead of raw APIs to shop, and the same reason you use a mobile app instead of curl. The layer on top is the application. The 200 series is a guided tour of one specific application on that layer, Plexara. Learning Objectives 1. 01 Answer the common question "is MCP just an API wrapper?" with a clear no, and know why. 2. 02 Use the website-on-top-of-APIs analogy to see MCP as an application layer rather than a thin proxy. 3. 03 Recognize that MCP servers live on a spectrum from thin wrappers to full application servers, and identify what a sophisticated server adds beyond the raw APIs underneath. 4. 04 Stop comparing MCP to an API (a category error) and start comparing MCP servers to each other on the application dimension. 5. 05 Understand what kind of MCP server Plexara is and why that matters for the 200 series. ### The question: is MCP just a wrapper around our APIs? Architects hearing about MCP for the first time frequently arrive at a reasonable-sounding reduction: "this looks like a thin protocol wrapper around our REST endpoints." In some implementations, that is literally true. MCP servers absolutely can be thin wrappers over existing APIs, and for small or self-contained capabilities, that is a fine outcome. But treating all MCP servers as thin wrappers misses what the best ones actually do. And it produces the category error of comparing MCP itself to an API, as though they were alternative choices at the same layer of the stack. ### A useful analogy: websites are not wrappers over APIs When you go to Amazon.com, the website itself is calling dozens if not hundreds of internal APIs. The product catalog, the pricing service, the inventory checker, the reviews engine, the cart, the checkout, the shipping estimator, the recommendation rails, all of them sit behind the single page you are looking at. You could, in principle, open a terminal and call those APIs directly to do your shopping. You could fetch raw JSON from the product service, call the cart service, hit the payment endpoint. Nobody does that. The reason is not that the APIs are inaccessible. It is that the website is the application. It organizes the data. It contextualizes it. It manages state (what you searched for, what is in your cart, which filters are active). It presents and styles. It composes the UX. It applies policy. A modern website, a mobile app, a good desktop program, is almost never a thin proxy to its underlying APIs. It is the first and often most critical layer of logic on top of them. MCP servers sit in exactly the same relationship to enterprise APIs and data systems. An MCP server advertises tools and resources to an agent, and what it does between the agent and the underlying systems can be anything from near-passthrough to full application-server behavior. Websites are an application layer on top of APIs Example: Amazon.com What it uses underneath - Product catalog service - Inventory service - Pricing service - Cart and checkout services - Reviews and recommendations - Order history, payments, shipping What it adds on top - Organizes the raw data into something a shopper can navigate. - Manages state: what you searched for, what is in your cart, which filters are active. - Presents and styles: pages, cards, rails, drawers, all laid out for a human. - Composes the UX: one-click checkout that would be five API calls if you wrote them yourself. - Applies policy: you never see inventory you are not eligible to buy. MCP servers are an application layer on top of APIs Example: Plexara What it uses underneath - DataHub (catalog metadata and lineage) - Trino (query engine) - S3 (object storage) - OpenSearch or equivalent (indexes) - Memory and knowledge storage - Existing enterprise REST services What it adds on top - Advertises tools and resources in a form the agent can reason about. - Manages state: session scope, enrichment dedup, context and memory. - Presents and styles: curated query templates, semantic enrichment, shaped responses. - Composes workflows: one natural-language question that would be a dozen tool calls written by hand. - Applies policy: governance, access controls, and audit on top of whatever the underlying APIs enforce. You could shop on Amazon by calling the underlying APIs directly. Nobody does, because the website is not a proxy to the APIs; it is an application that uses them. A well-built MCP server has the same relationship to the APIs underneath it. ### It is a category error to compare MCP to an API Once the layering is visible, the question "MCP versus API" becomes a category error. The two things do not compete, any more than Amazon.com competes with the HTTP endpoints behind it. They live at different layers. A single enterprise almost always ends up running both, and the useful comparison is not MCP against API. It is MCP server against MCP server, on the dimension of how much application value each one provides on top of the same underlying data. Comparing MCP to an API is like comparing an application to the APIs that power it MCP and APIs live at different layers. The common question “is MCP just an API wrapper” has the same shape as asking whether Amazon.com is just an HTTP wrapper around the product database. Technically true at the transport level. Missing the point everywhere else. An MCP server is an application layer. It can be thin, and sometimes thin is the right answer. It can also be a full application server with its own state, policies, and composed workflows. ### MCP servers live on a spectrum Because an MCP server can be anything from a direct tool-to-endpoint mapping to a full application server, the practical question for an organization is where on that spectrum a given server sits, and where it needs to sit for the workloads you expect to run through it. A thin wrapper is a completely reasonable choice for a small capability or an internal experiment. It is the wrong choice when the agent needs to coordinate across systems, carry state, apply governance, or remember what happened last week, which is exactly the gap that explains [why a passthrough gateway is not enough](https://plexara.io/learning/insights/why-mcp-gateways-are-not-enough). MCP servers live on a spectrum; not all MCP servers are equal 1. 1 Thin wrapper Nearly one-to-one mapping from MCP tool to an existing API endpoint. A handful of described tools, passthrough arguments, minimal new logic. Provides - Tool discovery for the agent. - The underlying API's existing authentication and rate limiting. - Not much else. 2. 2 Curated application Tools are shaped for agents, not just re-exposed APIs. Queries are pre-optimized. Descriptions and examples are rich. Some session scope and result shaping. Provides - Tools grouped and named for the agent's reasoning, not the database's table names. - Response formats that the model can read efficiently. - Light policy: what a role is allowed to see, what tools are exposed at all. 3. 3 Full application server What Plexara is. A full application layer between the frontier model and the underlying APIs. State, governance, memory, orchestrated workflows, enforced policy. Provides - Session-scoped state (enrichment dedup, memory recall, context management). - Governance: access controls, audit, guardrails that stack on top of the underlying APIs. - Orchestrated workflows: discover, query, enrich, respond, persist. Multi-tool coordination the agent does not have to manage itself. - Persistent memory and a semantic catalog that survive across sessions. A thin wrapper is the right answer for a small, self-contained capability. A full application server is the right answer when the agent needs to coordinate across systems with context and governance that the raw APIs cannot provide on their own. ### Why the distinction matters in practice When an organization evaluates MCP servers as though they were all equivalent API wrappers, the comparison collapses into a discussion of transport, authentication, and protocol versions. Those matter, but they do not determine whether the system works for real enterprise workloads. Real workloads depend on the application behaviors: semantic enrichment on returned data, session state across tool calls, curated workflows that prevent the agent from having to reinvent analysis patterns, governance that stacks on top of the underlying API authorization, and [memory that survives past the current conversation](https://plexara.io/learning/insights/why-proximity-matters-tools-meaning-memory). A thin wrapper cannot provide these, not because its authors were careless but because it was not the job the server was built for. A full application server can. The decision about which kind of server to adopt has more to do with the shape of the work you expect agents to do than with the underlying APIs themselves. ### Where this leads The end of the 100 series is the right moment to stop talking about MCP in the abstract and start talking about a specific MCP server that sits on the application-server end of the spectrum. The 200 series is that tour, with Plexara as the worked example. This is the transition into the 200 series The 100 series ends here, with MCP positioned as an application layer on top of APIs. The 200 series is about one particular application server on that spectrum. It is not a tour of MCP in the abstract; it is a tour of how Plexara uses the protocol to deliver governance, memory, semantic enrichment, and orchestrated workflows on top of whatever data the customer has connected. [201 - What is an MCP?](https://plexara.io/learning/mcp/what-is-an-mcp) is the first step. ### Key terms Six terms cover the vocabulary you will need going into the 200 series. "Category error" is included on purpose because naming the mistake tends to prevent it. Key Terms API application programming interface A transport-level contract (REST, GraphQL, gRPC, and similar) between two pieces of software. Deterministic callers, specific endpoints, strongly typed. Optimized for code. MCP server A server that advertises tools and resources to an agent via the Model Context Protocol. Sits at the application layer, above APIs. Can be a thin wrapper or a full application server. Thin wrapper An MCP server that maps tools almost one-to-one to existing API endpoints with minimal added logic. Appropriate for small, self-contained capabilities where the underlying API is already agent-friendly. Application server An MCP server that adds meaningful application logic above the APIs it uses: state, governance, orchestrated workflows, memory, and shaped responses. Plexara is an application server by this definition. Orchestration Composing multiple tool calls across multiple systems into one coherent workflow so the agent can answer a natural-language question without having to hand-coordinate every step. Category error The specific mistake of comparing MCP to an API directly. They live at different layers. The meaningful comparison is between MCP servers, on the dimension of how much application value each one provides. Further Reading - [Architecture overview Model Context Protocol (Anthropic) · 2025 Official MCP specification documentation defining the host/client/server architecture and the three server primitives (tools, resources, prompts) that an MCP server exposes to an AI application, sitting as a layer between the agent and backend systems such as databases and API calls.](https://modelcontextprotocol.io/docs/learn/architecture) - [Architecture overview - Model Context Protocol Model Context Protocol (Anthropic) · 2025 The official spec states MCP is a stateful protocol requiring lifecycle management and capability negotiation, and that the Streamable HTTP transport supports OAuth/bearer-token authentication, supporting the article's claims that MCP servers can carry session state across tool calls and stack governance on underlying API authorization.](https://modelcontextprotocol.io/docs/learn/architecture) On this page [Previous 105 - What is an AI agent?](https://plexara.io/learning/ai-concepts/what-is-an-ai-agent) [Next 201 - Anatomy of a Plexara MCP](https://plexara.io/learning/mcp/what-is-an-mcp) ### Related reading integration [Integration 606 - Scripts as skills: the weekly review the agent runs on your business The capstone. Three scripts (category velocity, the supplier quote margin review, regional weather context) attached to one prompt, so serving the prompt carries each script’s contract and last successful output and the agent runs them for fresh numbers instead of re-deriving them. The agent then reads the outputs against the seasonality calendar, the returns policy, the store formats, and the stock health bands, and produces the week’s action items: promote, discount, discontinue or renegotiate, watch, each with its figure. The scripts did the data work; the model did the judgment; neither is rebuilt next week.](https://plexara.io/learning/automations/scripts-as-skills-the-weekly-review) [Integration Two front doors, one governed surface Plexara exposes the same governed surface through an MCP server and a REST API. SDKs connect to both, custom tools extend it, and every path shares one identity, one audit log, and one persona model.](https://plexara.io/learning/insights/the-developer-surface) [Integration Meeting enterprise systems where they are Real enterprise APIs authenticate in messy ways: client certificates, basic auth, second credential headers. Supporting them, while keeping each user activity isolated, is what makes an agent usable at work.](https://plexara.io/learning/insights/enterprise-authentication-and-isolation) --- # Anatomy of a Plexara MCP URL: https://plexara.io/learning/mcp/what-is-an-mcp/ > 201 shows what is actually in the box on a Plexara server: the tool inventory by toolkit, the four content layers, the interactive apps a tool result can carry, and the memory, knowledge, and governance underneath. This lesson is the map. Architecture 15 min read ## 201 - Anatomy of a Plexara MCP 201 shows what is actually in the box on a Plexara server: the tool inventory by toolkit, the four content layers, the interactive apps a tool result can carry, and the memory, knowledge, and governance underneath. This lesson is the map. On this page ### What you will take away from this lesson The 100 series closed with the argument that MCP is an application layer, not a thin wrapper over APIs. This lesson opens the application. What is actually inside a Plexara MCP server when you connect your client to one? Which parts are standard MCP and which parts are Plexara-specific? And where does the rest of the 200 series take each piece? This is a map lesson, not a deep dive. Every subsystem introduced here has its own dedicated lesson later. If anything in the map looks interesting, follow the link in its row and come back. Learning Objectives 1. 01 Know what is actually inside a Plexara MCP server: the base MCP primitives (tools, resources, prompts) and the Plexara-specific subsystems that layer on top. 2. 02 Read the tool inventory by toolkit, and know why search and fetch are the front door rather than one search tool per backend. 3. 03 Tell the four content layers apart (resources, assets, knowledge pages, memory) by who authored the content, not by its file format. 4. 04 Explain what an MCP App is: interactive UI a tool result can carry, rendered by the host, and presentation-only by design. 5. 05 Use this lesson as a map for the rest of the 200 series: each piece has its own dedicated lesson where it gets covered in depth. 6. 06 Recognize the one tool every session loads first (platform_info) and why it is the starting point for the entire discover-query-enrich workflow. ### Where we are in the curriculum The 100 series built the foundation that every lesson in this series assumes. Each title below is a direct link back; the index card links to the 100-series landing page. The 200 series narrows focus to one specific MCP server. It is not a survey of MCP implementations in general. It is a guided tour of what Plexara advertises to an agent, organized the way a power user should think about the surface. 100 Series: the foundation [Open index](https://plexara.io/learning/ai-concepts) - [101 What is a Large Language Model? Brilliant at language, blind about your data. Tokens, hallucination, the grounding problem.](https://plexara.io/learning/ai-concepts/what-is-a-large-language-model) - [102 Tokens and your budget Subscription-plan economics, session limits, and Plexara enrichment dedup.](https://plexara.io/learning/ai-concepts/tokens-and-your-budget) - [103 Context, compression, and memory The keep / compress / clear playbook and how memory carries across sessions.](https://plexara.io/learning/ai-concepts/context-windows-and-tokens) - [104 Frontier models, specialized models, and why enterprise AI uses both Three knowledge sources (training, web search, tools). MCP as the exposure protocol.](https://plexara.io/learning/ai-concepts/frontier-models-explained) - [105 What is an AI agent? The think/call-tool/observe loop. Professor's knowledge, child's literalism.](https://plexara.io/learning/ai-concepts/what-is-an-ai-agent) - [110 Is MCP just an API wrapper? MCP as an application layer. Spectrum from thin wrapper to full application server.](https://plexara.io/learning/ai-concepts/mcp-vs-apis) 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. ### The anatomy of a Plexara MCP A Plexara MCP server advertises eight distinct kinds of things to a connected client. Three of them are base MCP primitives every compliant server has. Five of them are Plexara-specific subsystems built on top. You do not need to memorize this table; the map below exists so that when a later lesson refers to "memory" or "the knowledge pipeline" or "the semantic enrichment layer," you already know where it fits. What is in a Plexara MCP (and where each piece is covered) - Tools Base MCP [Covered across 203–205](https://plexara.io/learning/mcp/discovery-search-and-fetch) Functions the agent can call. search and fetch are the front door; trino_query, the catalog reads, and the asset tools follow from what discovery turns up. Around forty of them, grouped into eight toolkits. - Resources Base MCP [Covered in 209](https://plexara.io/learning/mcp/mcp-resources-templates-and-examples) Files a person uploaded before the conversation started and the agent is meant to use as-is: report templates, brand assets, data dictionaries, runbooks, sample payloads. - Prompts Base MCP [Covered in 208](https://plexara.io/learning/mcp/mcp-prompts-reusable-prompts) Named, reusable parameterized instructions the server advertises. Plexara ships a default library and lets administrators and knowledge curators add more. - Semantic enrichment Plexara subsystem [Motivated in 102; applied in 203–204](https://plexara.io/learning/ai-concepts/tokens-and-your-budget) Tool results come back with catalog metadata (descriptions, tags, owners, column detail, glossary terms, PII flags) already attached, deduplicated within a session so the same table is not re-enriched on repeat queries. - Memory Plexara subsystem [Covered in 206](https://plexara.io/learning/mcp/knowledge-from-memory-to-insights) A per-user, cross-session recall layer. Survives past the context window. Stored as semantically searchable records; the universal search tool reaches them alongside every other source, so relevant memories can surface without the user naming them by hand. - Knowledge Plexara subsystem [Covered in 206](https://plexara.io/learning/mcp/knowledge-from-memory-to-insights) An organization-wide documentation layer fed by an admin-reviewed insights pipeline. User corrections and agent observations become catalog documentation after review. - MCP Apps Plexara subsystem [Shown running in 202](https://plexara.io/learning/mcp/first-engagement) Interactive UI a tool result can carry. The host renders it in a sandboxed frame next to the answer. Plexara serves two, Platform Info and List Prompts, and both are presentation-only: the same calls return complete JSON in clients that draw no UI. - Governance Plexara subsystem [Covered in 207](https://plexara.io/learning/mcp/governance-personas-and-access) Persona-based tool and connection filtering, default-deny posture, read-only pinning, bucket prefix scoping, workflow gating, and per-call audit. Enforced at execution time, not at catalog time. The three blue rows are the base MCP primitives every MCP server has. The five copper-badged rows are the subsystems Plexara adds on top using those primitives, which together make Plexara an application server (the category established in [110](https://plexara.io/learning/ai-concepts/mcp-vs-apis)) rather than a thin wrapper. ### Base primitives vs application subsystems The distinction between the top three rows and the bottom five is the one that matters. The 110 lesson drew [a spectrum from thin-wrapper MCP servers to full application servers](https://plexara.io/learning/ai-concepts/mcp-vs-apis). The difference, concretely, is everything below the line in the map above. A thin wrapper exposes tools, resources, and prompts. An application server uses those primitives to build subsystems that do useful, coordinated work: enriching returned data with catalog context, recalling memories from prior sessions, promoting observations into organization-wide documentation, rendering an interface where one helps, and [enforcing governance at the point a tool is invoked](https://plexara.io/learning/insights/governance-at-execution-time). The base primitives are plumbing; the subsystems are the product Every MCP server has tools, resources, and prompts. The difference between a thin wrapper and an application server ([110](https://plexara.io/learning/ai-concepts/mcp-vs-apis)) is what gets built on top of those three primitives. Plexara uses them to deliver semantic enrichment, memory, knowledge, apps, and governance as first-class subsystems, each of which is what a power user actually thinks about day to day. The rest of the 200 series takes one subsystem per lesson. ### The tool inventory Tools are the primitive everything else is reached through, so the inventory is worth seeing whole once. Around forty tools ship across eight toolkits, and the grouping is not cosmetic: platform_info reports which toolkits a deployment has turned on, and a persona grants or withholds tools within them. The order below is the order that matters rather than the order the toolkits were built in. Discovery comes first. A session that starts anywhere else is guessing at what exists, and [searching the capability rather than the manual](https://plexara.io/learning/insights/search-the-capability-not-the-manual) is the habit the whole surface is arranged around. The tool inventory, by toolkit - Knowledge `search` `fetch` `apply_knowledge` The front door. One search reaches every source the caller can see; fetch reads any single hit back in full; apply_knowledge is the administrator side that promotes reviewed captures into the catalog. - Memory `memory_capture` `memory_manage` Recording and tending what one person has taught the agent. Reading memory back is not here: it arrives as one group in an ordinary search response. - Portal `save_asset` `manage_asset` `manage_feedback` What a session produces and what people say about it afterwards. Assets and collections are first-class objects with their own URLs, and feedback threads hang off them. - Platform `platform_info` `list_connections` `platform_find_tools` `manage_prompt` `show_prompts` The session gate and the tools about the deployment itself. platform_find_tools ranks the tool list by intent, so the agent can locate a capability without scanning every name. - Trino `trino_query` `trino_execute` `trino_explain` `trino_browse` `trino_describe_table` `trino_export` SQL against every configured warehouse and lakehouse connection. Reads and writes are separate tools so a client can auto-approve one and prompt on the other. - DataHub `datahub_get_entity` `datahub_get_schema` `datahub_get_lineage` `datahub_get_queries` `datahub_get_glossary_term` `datahub_browse` `datahub_get_data_product` `datahub_create` `datahub_update` `datahub_delete` Structural catalog reads and governed catalog writes: schema, lineage, glossary, curated queries, tags, domains, and data products. - S3 `s3_list_buckets` `s3_list_objects` `s3_get_object` `s3_get_object_metadata` `s3_presign_url` `s3_put_object` `s3_delete_object` `s3_copy_object` Object storage inside the prefixes the deployment allows, with size caps on reads and signed URLs for anything a report needs to link to. - API `api_list_specs` `api_list_endpoints` `api_get_endpoint_schema` `api_invoke_endpoint` `api_export` Registered HTTP APIs reached the same governed way as the data. The deployment holds the credentials, so the agent addresses an operation by name and never handles a secret. A persona sees only the tools it is allowed to call, so this is the full surface rather than the one any given user gets ([207](https://plexara.io/learning/mcp/governance-personas-and-access)). Every tool is described one by one in the appendix to [210](https://plexara.io/learning/mcp/tool-survey). [Image: The admin Tools page: a searchable tool list on the left grouped by connection (catalog, CRM gateway, data lake), and on the right the Trino Query tool opened on its Overview tab showing its description, a routing block naming the toolkit, kind, and connection, and a persona table where every persona resolves to allow with the pattern it matched.] The same inventory as seen from the admin section of the portal. Each tool is filed under the connection it belongs to, and opening one shows its routing (toolkit, kind, connection) plus a persona table listing, for each persona, whether it may call the tool and which allow pattern it matched. That table is the answer to the question 207 will take up: which tools any given user actually gets. [Image: The admin Tools page with the Trino Query tool on its Try It tab: a form built from the tool's input schema with a required sql field, a limit of 100, a timeout of 30 seconds, a format dropdown set to markdown, an Execute button, and an empty History panel below.] Every tool carries an input schema, and the Try It tab renders that schema as a form. The fields the agent fills in when it calls Trino Query (sql, limit, timeout, format) are the same fields an admin can fill in here to see the tool return the exact result an agent would receive. ### Two tools carry most of the traffic Of everything in that inventory, two names deserve to be learned first. A single search call fans across every source the caller can reach: the catalog, the business glossary, knowledge pages, uploaded resources, your own memory, captured insights, feedback, saved assets, the prompt library, API endpoints, and the configured connections. Results come back grouped by source with a coverage summary rather than flattened into one list, so a forty-thousand-dataset catalog cannot bury the single knowledge page that answers the question. fetch is its other half. A search hit is a pointer carrying a title, a snippet, and a reference; fetch takes that reference and returns the complete record behind it, under exactly the scope search applied. Between them they replaced the per-backend search tools and per-source readers that used to exist, which is why an agent no longer has to decide where an answer lives before it starts looking. [203 covers the pair in full](https://plexara.io/learning/mcp/discovery-search-and-fetch). One more tool is worth knowing by name early: platform_find_tools ranks the tool list itself against a plain-language description of a task. It is discovery pointed at the toolbox rather than at the data, and it is how an agent locates a capability without reading three dozen tool descriptions to find it. ### Four places content lands The map above lists resources, memory, and knowledge as separate rows, and assets show up in the Portal toolkit. Seen individually they look like four storage systems that happen to hold different file types. They are not. The difference between them is authorship, and the file format is close to irrelevant: the same PDF can legitimately be a resource or an asset depending on who made it and why. The question a person should ask when filing something, and the question the agent asks when reaching for something, is the same one. Did this exist before the conversation? Then it is a resource, and the agent should reproduce it rather than rewrite it. Did the agent make it in a session somebody wants to keep? Asset. Is it a fact you want found, cited, and synthesized into new answers? Knowledge page. Is it about how one particular person works? Memory. Four content layers, told apart by who wrote them | Layer | Holds | Authored by | Reached via | | --- | --- | --- | --- | | Resources | Files used as-is: templates, brand assets, data dictionaries, sample payloads, runbooks | A person, before the conversation | search then fetch, the resources/read protocol method, or a prompt attachment | | Assets | Dashboards, reports, visualizations, and documents produced during a session | The agent, during the conversation | save_asset and manage_asset, and search | | Knowledge pages | Curated business and domain facts, cross-linked and citable | A person, or a reviewed insight promoted into the catalog | search then fetch, apply_knowledge | | Memory | Per-user recall: preferences, corrections, working context | The agent, on one user's behalf | memory_capture and memory_manage, and search | The portal groups these the same way, so the question “where does this belong” has one answer whether a person is uploading a file or an agent is saving its output. Resources are covered in [209](https://plexara.io/learning/mcp/mcp-resources-templates-and-examples), assets in [205](https://plexara.io/learning/mcp/assets-dashboards-reports-and-data), and knowledge and memory in [206](https://plexara.io/learning/mcp/knowledge-from-memory-to-insights). ### What getting it wrong actually costs The distinction sticks better once you have seen it fail. Every misfiling has the same shape: the agent reads the layer as a statement about where the content came from, and acts accordingly. A template filed as an asset gets rewritten every time The split matters because the agent acts on it. An asset is something the agent believes it produced, so a report template saved as an asset is treated as last week’s output rather than this week’s instructions: the next session regenerates the layout instead of reusing it, and the approved structure quietly stops being approved. The other two failure modes are the same mistake in different directions. A reference PDF pasted into a knowledge page loses its formatting and its bytes, which is the one thing a brand file exists to preserve. A durable fact about how the business works, filed as a personal memory, reaches one person instead of the team. ### When a tool result draws an interface Everything described so far arrives as structured data the agent reads and summarizes for you. That is the right shape for most answers, and a bad shape for a few. A prompt library is easier to browse than to read aloud. A deployment summary is easier to scan as a panel than as a paragraph. MCP Apps are the answer to that narrow but real problem: a tool result can carry a reference to an interface, and a client that knows how renders it beside the answer. The mechanism is small enough to hold in your head, which is worth doing because it explains the security posture as well as the behavior. How a tool call ends up drawing an interface 1. 1 A tool result carries a UI reference Alongside the structured data it always returns, the result names a UI resource the host can render. 2. 2 The host fetches the app and sandboxes it The client loads the app’s HTML into a sandboxed iframe beside the answer. Nothing is installed and nothing runs on your machine outside that frame. 3. 3 The tool result arrives over postMessage The app receives the same payload the agent got and draws an interface over it: panels, tables, filters, forms. 4. 4 The app can call tools itself An app is not limited to the result that opened it. Its calls travel the same transport as the agent’s and meet the same governance gates, so an app can never reach data the person driving it could not have reached. 5. 5 The session gate applies to apps too Where the session handle is required, an app calls platform_info first and threads the session_id it returns. Skipping the handshake earns the app the same SESSION_REQUIRED refusal an agent would get. ### Two apps come with the platform Nothing needs to be installed or turned on for either of these. Platform Info and List Prompts are part of what Plexara serves, and the first one shows up on the very first tool call of every session. The two apps Plexara serves - Platform Info Opens on `platform_info` - The platform name, version, and description - Every connected toolkit, as a panel rather than a paragraph of JSON - Which feature flags are on and which are off - The personas active for the session - List Prompts Opens on `show_prompts` - Search-as-you-type over the prompt library, split into My Prompts and Library, with collection and tag filters and usage-based sorting - Cards carrying the display name, description, version, approval provenance, and run count - A detail view with the full prompt text and a form generated from that prompt’s argument specs - A run button that drops the rendered prompt straight into the conversation where the client supports it, and offers it for copy where it does not List Prompts is bound to `show_prompts`, which does nothing but ask for the library to be displayed. That binding is the point: the agent’s routine prompt work runs through `manage_prompt` and draws no UI, so a window only opens when a person asked to see one ([208](https://plexara.io/learning/mcp/mcp-prompts-reusable-prompts)). Two is the count today; Plexara adds more as host support for MCP Apps matures. ### The Platform Info app, running Below is the actual app, loaded against the ACME Corp demo deployment and rendered here the same way a client renders it. This is what platform_info looks like when the client can draw it: the connected toolkits, the feature flags, the personas, and the operating manual, all in one panel instead of a wall of JSON. [202 walks through the same content](https://plexara.io/learning/mcp/first-engagement) as the agent reads it. MCP App: Platform Info (ACME Corp demo) Live render of the Platform Info app that Plexara serves alongside platform_info: an interactive view of the platform description, prompts, and agent instructions, at the ui://platform-info resource URI. ### Nothing is lost without them The obvious worry about a UI layer is that it becomes required: capability drifts into the app, and clients that cannot render it fall behind. Plexara forecloses that by construction. Apps are presentation only, so nothing depends on them An MCP App never becomes the only way to get an answer. The tools an app renders return the same complete structured JSON in clients that draw no UI at all, which means a team split across an app-capable desktop client and a terminal client is looking at the same data with two different amounts of chrome on it. Choosing a client that renders apps is a comfort decision, never a capability one. ### How the pieces compose in one session A single question, "How are ACME Corp sales doing in the Southwest region?", touches almost every row of the map. The agent calls platform_info, which gates the session and returns the operating manual along with the prompt library (tools, resources, and prompts). It calls search once, and the response comes back grouped by source with [semantic enrichment attached automatically](https://plexara.io/learning/insights/why-proximity-matters-tools-meaning-memory) (tools + enrichment), including a memory from an earlier session where the user pinned down what they mean by "sales" (memory). Governance has already filtered out any tools or connections this persona is not allowed to use, so nothing in that response is something the user could not have seen (governance). The agent reads the most promising hit in full with fetch, then calls trino_query; the returned table metadata is enriched but [deduplicated against what was sent earlier in the session](https://plexara.io/learning/insights/token-efficiency-in-enterprise-mcp) (enrichment). The chart it builds is persisted with save_asset rather than pasted into the chat (assets). If a user correction surfaces along the way, memory_capture routes it toward the admin review pipeline for possible promotion to organization-wide documentation (knowledge). The user experiences this as a single fluid answer. The map is what that fluid answer decomposes into when you look at it carefully. ### Every session starts in the same place Before any of the subsystems engage, the session passes through a single gate. Until platform_info has been called, every other tool refuses with a structured error. This is a deliberate design choice and it is the subject of the next lesson. Every session starts with one tool: platform_info The platform_info tool is the one tool the agent must call first in every session. Every other tool is gated behind it at the server level. platform_info returns the operating manual for the specific Plexara deployment: tenant, toolkits, feature flags, the prompt library, and a customer-specific agent_instructions block that primes the agent with the discover-query-enrich workflow. The [202](https://plexara.io/learning/mcp/first-engagement) lesson (next) walks through exactly what this looks like on your first day. ### Where this leads The rest of the 200 series walks through the subsystems one at a time, starting with the gate. What comes next This lesson is the map. The rest of the 200 series is the guided tour. Start with [202 - Your first day with Plexara](https://plexara.io/learning/mcp/first-engagement), which walks through a brand-new user's first session and what happens when platform_info loads. ### Key terms Eight terms cover the vocabulary you will need as the rest of the 200 series unfolds. "Primitive" vs "subsystem" is the distinction worth keeping sharp because it maps directly to the division in the anatomy map above. Key Terms Plexara MCP server The MCP server a customer's client connects to. An application-server-class MCP (in the sense established in [110](https://plexara.io/learning/ai-concepts/mcp-vs-apis)) that layers semantic enrichment, memory, knowledge, apps, and governance on top of the base MCP primitives. Primitive One of the three things an MCP server can advertise to a client: tools, resources, or prompts. Standard across all MCP implementations. Subsystem A Plexara-specific feature built on top of the base primitives. Semantic enrichment, memory, knowledge, apps, and governance are the subsystems a power user interacts with day to day. platform_info The mandatory first tool call in every Plexara session. Returns the operating manual for the deployment, including toolkits, feature flags, the prompt library, and customer-specific agent_instructions. Every other tool is gated behind it. Toolkit A named grouping of related tools in a Plexara deployment (for example, the DataHub toolkit, the Trino toolkit, the S3 toolkit). platform_info reports which toolkits are enabled for the current session. MCP App Interactive UI a tool result can carry, rendered by the client in a sandboxed frame beside the answer. Presentation only: the same tools return complete structured data to clients that render no UI. Plexara serves two, Platform Info and List Prompts. Content layer One of the four places content lands: resources, assets, knowledge pages, or memory. Which one a piece of content belongs to is decided by who authored it and what the agent should do with it, not by its file format. Persona A named role that determines which tools and which connections a caller can see and invoke. Enforced at execution time. Detailed in [207](https://plexara.io/learning/mcp/governance-personas-and-access). On this page [Previous 110 - Is MCP just an API wrapper?](https://plexara.io/learning/ai-concepts/mcp-vs-apis) [Next 202 - Your first day with Plexara](https://plexara.io/learning/mcp/first-engagement) ### Related reading architecture [Architecture 103 - Context, compression, and memory The context window is a model's working memory. Each session balances keeping, compressing, or clearing it. Plexara adds enterprise memory on top.](https://plexara.io/learning/ai-concepts/context-windows-and-tokens) [Architecture Five kinds of memory, and how each comes back A fact, an incident, a person, a link, and a habit are five different kinds of knowledge. Plexara stores each as its own dimension and recalls it the way that kind needs, which is what makes memory across sessions feel like memory rather than search.](https://plexara.io/learning/insights/five-kinds-of-memory) [Architecture Search the capability, not the manual: how Plexara keeps a wide platform light Loading every API spec into context does not scale. A small, fixed tool footprint plus semantic endpoint discovery keeps cost tied to the task, not the size of the platform.](https://plexara.io/learning/insights/search-the-capability-not-the-manual) --- # Your first day with Plexara URL: https://plexara.io/learning/mcp/first-engagement/ > A new Plexara user gets connected, sends a first question, and platform_info takes over. Walks through day one and how subsequent turns inherit context. Product 11 min read ## 202 - Your first day with Plexara A new Plexara user gets connected, sends a first question, and platform_info takes over. Walks through day one and how subsequent turns inherit context. On this page ### What you will take away from this lesson In [201 - Anatomy of a Plexara MCP](https://plexara.io/learning/mcp/what-is-an-mcp), we laid out what is in the box on a Plexara server: the base MCP primitives (tools, resources, prompts) and the Plexara-specific subsystems (semantic enrichment, memory, knowledge, governance) layered on top. This lesson is the user-side companion: what actually happens on your first day, from connecting your client (Claude Desktop, Cursor, or anything else MCP-compatible) to typing your first question and getting back a grounded answer. The lesson is built around one stubborn fact of first-day use: the agent does not automatically know that this Plexara MCP is the right place to look for an answer. A small habit on the first turn resolves that, and from then on the session carries the context forward. Learning Objectives 1. 01 Describe what happens on your first session with Plexara connected, from the first question to the first grounded answer. 2. 02 Recognize the "generic answer" failure mode and the small prompt cue that resolves it. 3. 03 Know that platform_info is a gated first call every session, and what it loads into the context window. 4. 04 Name the three-step discover-query-enrich workflow the agent follows on your behalf, and where each step is covered in the rest of the 200 series. 5. 05 Understand what carries forward inside a session, across sessions through memory, and what requires the admin-reviewed knowledge pipeline. ### Where we are in the curriculum The 100 series is the foundation for the entire 200 series. If anything in this lesson references a term you have not seen (tokens, context window, agent loop, MCP as an application layer), back up one link. 100 Series: the foundation [Open index](https://plexara.io/learning/ai-concepts) - [101 What is a Large Language Model? Brilliant at language, blind about your data. Tokens, hallucination, the grounding problem.](https://plexara.io/learning/ai-concepts/what-is-a-large-language-model) - [102 Tokens and your budget Subscription-plan economics, session limits, and Plexara enrichment dedup.](https://plexara.io/learning/ai-concepts/tokens-and-your-budget) - [103 Context, compression, and memory The keep / compress / clear playbook and how memory carries across sessions.](https://plexara.io/learning/ai-concepts/context-windows-and-tokens) - [104 Frontier models, specialized models, and why enterprise AI uses both Three knowledge sources (training, web search, tools). MCP as the exposure protocol.](https://plexara.io/learning/ai-concepts/frontier-models-explained) - [105 What is an AI agent? The think/call-tool/observe loop. Professor's knowledge, child's literalism.](https://plexara.io/learning/ai-concepts/what-is-an-ai-agent) - [110 Is MCP just an API wrapper? MCP as an application layer. Spectrum from thin wrapper to full application server.](https://plexara.io/learning/ai-concepts/mcp-vs-apis) 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. ### Day one: you open your client and ask a question Picture the setup. Your organization runs a fully managed Plexara workspace. You have been granted access. You point Claude Desktop, Cursor, or whatever MCP-capable client you use at the workspace endpoint, and the Plexara MCP shows up in your client's tool list. The connection is done. You type your first question. The question most people would ask is the one that sounds natural: "How are sales doing?" What happens next is not what a new user usually expects. Before any Plexara tool runs, the agent has to decide that consulting a tool is the right move for this question at all. First try without a cue "How are sales doing?" What happens The agent has the Plexara tool list available but no signal that this question is about your organization. Training data covers "sales" as a general topic, and the answer the model produces is the most probable interpretation of a general question. Result A coherent paragraph about macroeconomic conditions, consumer spending trends, and seasonal retail patterns. Readable. Plausible. Completely unrelated to your company. Same question with a two-word entity cue "How are ACME Corp sales doing?" What happens The agent scans the tool list, sees a Plexara MCP named and tagged for ACME Corp, and treats the entity match as a direct signal to consult this server. A compliant agent then calls platform_info on its own, because the tool's own description flags it as the mandatory first call. Result platform_info loads the ACME Corp operating manual. The agent now has tenant context, toolkits, and a prescribed workflow. The answer it produces is grounded in ACME Corp's actual sales data, with the tables and aggregation methods named. ### Installing the MCP is not enough Having a Plexara MCP in the tool list gives the agent the capability to reach your data. It does not, by itself, cause the agent to decide that reaching for the data is the right move for every question. In a workspace with several connected MCPs, or even in a single-MCP workspace, the agent can plausibly decide a question does not call for a tool at all, and default to an answer drawn from training data. The signal that pushes it the other way is the same one that lets an agent [find the right tool from intent](https://plexara.io/learning/insights/intent-driven-tools-and-memory) rather than from a hard-coded routing rule. The column on the left in the comparison above is what that failure mode looks like. The agent can see the tool list. It just does not have a signal strong enough to pick up the tool. ### The small cue that activates the MCP The signal the agent needs is small. A question phrased as "How are ACME Corp sales doing?" (identical to the original except for the two-word entity reference) is reliably sufficient. The agent scanning the tool list sees that the Plexara MCP is named and tagged for ACME Corp and treats the entity match as a direct instruction to consult this particular server. Once the agent decides to engage the MCP, an automatic sequence begins. The platform_info tool carries a description whose opening sentence identifies it as the mandatory first call in every session. A compliant agent reading that description calls platform_info on its own, without being asked. The session gate: bypassing platform_info is not a matter of client cooperation The first-call convention is not just advisory. The Plexara server backs it with a runtime session gate. Until platform_info has been called in a given session, every other tool in the deployment is refused with a structured error that directs the caller back to platform_info first. Compliant agents read the tool description and call it on their own; uncooperative agents discover the gate the moment they try to skip it. The effect is the same either way. ### What platform_info loads into the agent's context The platform_info response is a structured document describing the specific Plexara deployment the session is connected to. It identifies the deployment by name, carries a tag array that restates the business domains in retrieval-friendly form, advertises the toolkits and feature flags enabled, exposes a library of [pre-built prompts treated as shared infrastructure](https://plexara.io/learning/insights/governed-prompts-and-relevance-search), and most substantively, includes an agent_instructions block written as a markdown operating manual addressed directly to the agent. The agent_instructions block is authored per customer. It is where each organization's data estate, tenant conventions, query patterns, critical rules, and business terminology are encoded for the agent to read at the start of every session. Two Plexara deployments for two different customers share the same platform and the same tools but return very different agent_instructions, because the specifics of every customer's data are different. The platform itself is database-agnostic: it reaches data through Trino and works against any combination of backends Trino supports. For the public ACME Corp demo, the operating manual describes a national retailer with approximately 500 stores, eight sales regions, roughly 10,000 products, 100,000 customers, and three million sales transactions covering two years. The manual prescribes a mandatory three-step workflow the agent must follow when serving a data question, provides the query patterns the demo uses for common aggregation shapes, and publishes measured benchmarks showing the pushed-down analytics path completes in roughly one second on the three-million-row transactions index where standard SQL against the same index takes more than eighty. Plexara also serves the Platform Info app at the ui://platform-info resource URI, with mime type text/html;profile=mcp-app. The embed below renders the same ACME Corp demo platform_info payload the agent received when it made the call. MCP App: Platform Info (ACME Corp demo) Live render of the Platform Info app that Plexara serves alongside platform_info: an interactive view of the platform description, prompts, and agent instructions, at the ui://platform-info resource URI. ### The workflow the agent follows next: discover, query, enrich With platform_info in the context window, the agent proceeds through the three-step workflow the operating manual prescribes. The exact details are customer-specific because agent_instructions is customized per deployment. The shape that follows is the ACME demo's, but the structure generalizes to any customer backend. The three-step workflow platform_info prescribes 1. Step 01 Discover [203 - Discovery: one search, then fetch](https://plexara.io/learning/mcp/discovery-search-and-fetch) Before writing any query, the agent calls search on the topic, then datahub_get_queries on the matched dataset to retrieve curated, pre-benchmarked query templates. Jumping straight to a free-form query is an anti-pattern: the curated templates are faster, tested, and annotated with performance characteristics. 2. Step 02 Query [204 - Trino Query: analytics and insights](https://plexara.io/learning/mcp/trino-query-analytics-and-insights) The agent reaches data through Trino, regardless of the underlying backend. Each customer's operating manual describes the right query pattern for the data estate at hand (plain SQL, pushed-down OLAP on OpenSearch, or whatever is appropriate). Measured performance benchmarks in the operating manual tell the agent which path to choose. 3. Step 03 Enrich and persist [205 - Assets: dashboards, reports, and data](https://plexara.io/learning/mcp/assets-dashboards-reports-and-data) Plexara attaches semantic enrichment to the query result automatically: descriptions, tags, owners, column detail, glossary terms, PII flags. If the result is large, the agent saves it as an asset rather than letting rows flood the conversation. Follow-up questions recall the saved assets and the enriched metadata from memory. The user sees none of this machinery directly. What the user sees is a quick, grounded answer with the tables and aggregation methods named in the response. Each step is the subject of its own lesson later in this series. ### The cue is only needed once per session Once platform_info has been invoked, the operating manual sits in the conversation's context window. Subsequent questions in the same session do not require the "ACME Corp" prefix the first question needed. A follow-up such as "How did Q3 compare to Q2?" or "Which region leads on revenue per store?" is now interpreted against the loaded operating manual. The agent already knows the tenant, the relevant catalogs, the required query patterns, and the business meaning of the terms in the question. The cue is a one-time cost of entry. On the first question you are paying a small price in specificity. On every subsequent question in the session, the full tenant context is inherited for free. ### What carries forward, and at which scope A new conversation starts with an empty context window. If you return the next day and ask "How are sales doing?" without the ACME Corp prefix, the agent may once again default to a generic answer unless the same cue is provided. Within a session the first cue is enough; across sessions the cue resets. Plexara reduces this recurring cost through two compounding mechanisms: memory that carries per-user knowledge across sessions, and a [knowledge capture pipeline that turns usage into documentation](https://plexara.io/learning/insights/knowledge-application-turns-usage-into-documentation) by promoting validated observations into organization-wide catalog documentation. Both are covered in depth in 206. The summary below is what to expect. What carries forward, and at which scope - Within this session [Context behavior from 103](https://plexara.io/learning/ai-concepts/context-windows-and-tokens) platform_info output, the operating manual, and every tool call and result stay in the context window. Follow-up questions no longer need the entity cue. Example: "How did Q3 compare to Q2?" asked after the first cued question resolves correctly without repeating the tenant name. - Across sessions (Plexara memory) [Covered in 206](https://plexara.io/learning/mcp/knowledge-from-memory-to-insights) Personal preferences, prior corrections, and small facts the user or agent saved. A fresh session starts empty of context, but the agent opens with one universal search that reaches memory alongside the catalog and prior work, so relevant memories surface without the user naming them by hand. Example: A user who previously said they prefer a fiscal-calendar view of sales has that preference come back in the search results on a relevant later question, without having to restate it. - Into organizational knowledge (after admin review) [Covered in 206](https://plexara.io/learning/mcp/knowledge-from-memory-to-insights) Insights flagged during a session (user corrections, agent-discovered patterns, enrichment gaps) are captured and routed through a four-step review pipeline. Approved insights become catalog documentation, raising answer quality for everyone. Example: One user clarifies a column definition. After admin review, every future user asking about that column sees the correct definition on the first try. Every engagement after the first one has more context than the one before it. Your first day sets a lower bound on response quality; every session after it raises that bound. [Image: The portal Knowledge page on its Memory tab: a Memory, Insight, Knowledge lifecycle strip at the top, count tiles for total, active, stale, and archived memories, a search box with status and class filters, and a list of active memory cards labeled Business Context or Enhancement, each with the text of the memory and the table it refers to.] This is the per-user layer from the table above, as the portal shows it. Each card is something a session captured, tagged with a class (Business Context, Enhancement) and the table it is about. A memory like the fiscal calendar note here is what stops you from having to re-explain what Q1 means the next time you ask. ### Built-in prompts help on day one The platform_info response also exposes a prompts array describing named workflows the deployment supports. The ACME demo ships prompts for exploring the available data on a topic, creating an interactive dashboard, generating a structured markdown report, tracing data lineage for a specific dataset, capturing knowledge from the current conversation, and saving or listing artifacts. Clients that surface MCP prompts to the user can offer these as one-click workflows; clients that do not can still invoke them by name within a prompt. The 208 lesson walks through how these prompts work and how administrators and knowledge curators add more. [Image: The portal Prompts page: My Prompts and Library tabs, a search box that searches prompts by meaning, filters for collection, tag, status, and activity, and a table of prompts with name, approval badge, collection, description, run count, and last run, including two prompts shared by other users.] The prompts platform_info lists are the same ones this page manages. Each row is a named workflow with a description, an approval badge, and a run count, and the Library tab holds the ones published for everyone. Running one from your client is the one-click version of typing the whole ask out. ### Where this leads Day one resolves into three practical habits: name the tenant on the first question, let platform_info run, and start enjoying the rest of the session as a grounded conversation. The rest of the 200 series walks through each step of the workflow in detail. Where this leads platform_info put the operating manual in the context window and pointed the agent at a workflow. The rest of the 200 series walks through each step of that workflow. [203 - Discovery: one search, then fetch](https://plexara.io/learning/mcp/discovery-search-and-fetch) is the first stop: how the agent (and you) describe the domain to the catalog before querying anything. ### Key terms Five terms cover the vocabulary specific to this lesson. platform_info and the session gate are the two every Plexara user eventually names; discover-query-enrich is the workflow they run inside. Key Terms platform_info The mandatory first tool call in every Plexara session. Returns the operating manual for the specific deployment: tenant, toolkits, feature flags, a prompt library, and a customer-specific agent_instructions block. Also defined in [201](https://plexara.io/learning/mcp/what-is-an-mcp). Session gate The server-side enforcement that refuses every tool call in the deployment until platform_info has been invoked. Bypassing the convention is not possible at the client level. agent_instructions The markdown operating manual authored per customer, embedded in the platform_info response. Encodes tenant conventions, data-estate specifics, mandatory workflows, and benchmarked query patterns the agent should follow. Entity cue The small prompt pattern on the first question of a session that names the tenant or the subject by its specific term (for example, "ACME Corp sales"), giving the agent an unambiguous signal to consult the Plexara MCP rather than answer from training data. Discover-query-enrich The three-step workflow platform_info prescribes: call search and datahub_get_queries to discover the right dataset and curated query; run the query through Trino; enrich the result with catalog metadata and persist it as an asset if needed. On this page [Previous 201 - Anatomy of a Plexara MCP](https://plexara.io/learning/mcp/what-is-an-mcp) [Next 203 - Discovery: one search, then fetch](https://plexara.io/learning/mcp/discovery-search-and-fetch) ### Related reading product [Product 102 - Tokens and your budget Every LLM interaction is priced and rate-limited in tokens. What a token is, how much text fits a budget, and how to avoid wasting tokens on useful answers.](https://plexara.io/learning/ai-concepts/tokens-and-your-budget) [Product 105 - What is an AI agent? An AI agent is not a chatbot and not magic. It is a short loop (think, call-tool, observe, think again) on top of a language model. Mental model first.](https://plexara.io/learning/ai-concepts/what-is-an-ai-agent) [Product 203 - Discovery: one search, then fetch One question reaches every system the agent can see. Results come back grouped by source with a coverage summary, and fetch reads any of them in full.](https://plexara.io/learning/mcp/discovery-search-and-fetch) --- # Discovery: one search, then fetch URL: https://plexara.io/learning/mcp/discovery-search-and-fetch/ > One question reaches every system the agent can see. Results come back grouped by source with a coverage summary, and fetch reads any of them in full. Product 11 min read ## 203 - Discovery: one search, then fetch One question reaches every system the agent can see. Results come back grouped by source with a coverage summary, and fetch reads any of them in full. On this page ### What you will take away from this lesson In [202 - Your first day with Plexara](https://plexara.io/learning/mcp/first-engagement), we walked through what platform_info loads and the three-step discover-query-enrich workflow the operating manual prescribes. This lesson zooms in on the first step. Discovery is one tool. A single `search` call reaches every system the agent is allowed to see: the data catalog, the business glossary, canonical knowledge pages, your own memory, captured insights, saved assets, uploaded reference material, the prompt library, API endpoints, and the connection list. A companion `fetch` reads any one of those results back in full. There is no per-backend search tool to choose between, which is exactly the point: the agent does not have to guess where an answer lives before it goes looking. Learning Objectives 1. 01 Explain why discovery on a Plexara MCP is one universal search tool rather than one search tool per backend. 2. 02 Name the sources a single search query reaches and which of them are shared, visibility-scoped, or private to you. 3. 03 Read a search response: results grouped by source, a coverage summary, and a ranking field that says how the hits were ranked. 4. 04 Use fetch to read a search hit in full, and recognize why a persona granted search without fetch can find things it cannot open. 5. 05 Tell discovery apart from structural catalog reads, and use datahub_browse, get_schema, get_lineage, and get_queries for the second job. 6. 06 Run the short domain warm-up that brings world knowledge into an exploratory session. ### 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 [Open index](https://plexara.io/learning/ai-concepts) - [101 What is a Large Language Model? Brilliant at language, blind about your data. Tokens, hallucination, the grounding problem.](https://plexara.io/learning/ai-concepts/what-is-a-large-language-model) - [102 Tokens and your budget Subscription-plan economics, session limits, and Plexara enrichment dedup.](https://plexara.io/learning/ai-concepts/tokens-and-your-budget) - [103 Context, compression, and memory The keep / compress / clear playbook and how memory carries across sessions.](https://plexara.io/learning/ai-concepts/context-windows-and-tokens) - [104 Frontier models, specialized models, and why enterprise AI uses both Three knowledge sources (training, web search, tools). MCP as the exposure protocol.](https://plexara.io/learning/ai-concepts/frontier-models-explained) - [105 What is an AI agent? The think/call-tool/observe loop. Professor's knowledge, child's literalism.](https://plexara.io/learning/ai-concepts/what-is-an-ai-agent) - [110 Is MCP just an API wrapper? MCP as an application layer. Spectrum from thin wrapper to full application server.](https://plexara.io/learning/ai-concepts/mcp-vs-apis) 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 way to discover, whatever the answer turns out to be A question rarely announces where its answer lives. "How did the Southwest region do last quarter" might be answered by a dataset, by a glossary term that pins down what the company means by "region," by a knowledge page a steward wrote after the last reorganization, or by a note you left yourself three sessions ago. An agent that has to pick a search tool before it starts looking is guessing at that answer before it has any evidence, and a wrong guess costs a round trip and often a wrong answer. So Plexara does not offer a search tool per backend. It offers one. A single search call fans across every source the caller can reach and reports what it found in each. Where an answer lives becomes something the response tells the agent rather than something the agent had to know in advance. What one search query reaches, and who can see it Shared across the deployment Every caller whose persona reaches the underlying connection sees the same records. - Catalog datasets Datasets from DataHub with their names, descriptions, tags, and domains. Ranked against a platform-held index of that text first, with DataHub’s own keyword search following as the recall tail for column names and ownership. - Governance vocabulary Glossary terms, tags, and domains as searchable entities in their own right, not merely as attributes of a dataset. A term hit carries its definition, so "what does net revenue mean here" is answered without a second call. - Knowledge pages The canonical home for business and domain ontology, searched over the full markdown body rather than a title or summary. - Context documents Longer-form deployment context. Search is the only MCP path that surfaces them, and fetch is the only path that reads the body. - Prompts The prompt library covered in 208, matched by intent rather than by exact handle. - API endpoints and connections Endpoints aggregated across every API gateway connection, plus the configured connections themselves. Both are in the default corpus, not behind an opt-in. Visibility-scoped Reach depends on which scopes the caller belongs to, computed the same way the resource list is. - Resources Human-uploaded reference material, searched over both its metadata and its extracted file content. Global material reaches every caller, persona material only its members, user material only its owner. Private to the caller Scoped server-side to the identity making the call, so a search never surfaces another person’s records. - Your memory The personal memory covered in 206. Reading memory back is not a separate tool; it arrives as one group in an ordinary search response. - Insights and feedback Observations you captured that are still awaiting admin review, and your own feedback threads. - Assets The dashboards, reports, and exports you saved through the asset tools in 205. A caller with no identity still sees the shared sources and none of the private ones. What a persona is allowed to find and what it is allowed to call are decided by the same rule, so the two can never disagree. See [207 - Governance: personas, access, and audit](https://plexara.io/learning/mcp/governance-personas-and-access). ### Grouped by source, with a coverage summary Fanning across a dozen sources creates a problem a flat relevance list makes worse: the largest source wins. A catalog with forty thousand datasets will out-match a knowledge base of two hundred pages on almost any query, and the one page that actually answers the question ends up below the fold behind thirty datasets that merely mention the topic. Search returns results bucketed by source instead, built from a display budget with a floor per source so every matching source stays visible and a ceiling per source so none of them runs away. Alongside the hits comes a coverage summary: how many records each source matched against how many are being shown. That second number tells the agent how much of the match set it is looking at. What a search response actually contains - groups [{ source: "catalog", hits: [...] }, { source: "knowledge", hits: [...] }, ...] Hits arrive bucketed by source rather than flattened into one relevance list. A strong match in the catalog cannot push the one knowledge page that actually answers the question off the bottom of the list. - coverage [{ source: "catalog", matched: 38, shown: 5 }, { source: "memory", matched: 2, shown: 2 }] Per-source matched and shown counts. The agent learns where the answer space lives even when only the top few of each source are displayed, so it knows whether to narrow the query or drill in. - ranking "hybrid" | "lexical" | "entity" Says how these results were ranked. An ordinary text query ranks hybrid, semantic vector comparison combined with lexical matching. A lookup keyed by a URN instead of by text matches the identifier rather than interpreting it, and says so. - ref and reference reference: "mcp:knowledge_page:412" or "urn:li:dataset:(...)" The handle a hit is read back by. Pass it to fetch to get the complete content, or to a scoped tool to drill in. - Snippet and score text: "Daily sales aggregated by store and region..." score: 0.83 A hit is a navigational pointer, not the document. The snippet is enough to choose; the full text comes from fetch. - withheld and withheld_notice withheld: 4, notice names the persona and the remedy Records removed by the caller’s connection boundary are counted, not silently dropped. A shortened result set reads as "present, but not yours to see" rather than "does not exist." The display set is built from a total budget with a floor per source, so every matching source stays visible, and a ceiling per source, so none of them runs away with the list. Unused budget is redistributed to the sources carrying more relevant hits. This is semantic enrichment ([102](https://plexara.io/learning/ai-concepts/tokens-and-your-budget), [201](https://plexara.io/learning/mcp/what-is-an-mcp)) applied to the discovery step: the response is shaped for a context window, not dumped into one. [Image: The portal Knowledge page on its Knowledge tab with the Catalog sub-tab selected: a row of Tables, Context Docs, Tags, Domains, and Glossary tabs, a connection selector set to primary, a search box for tables by name, description, or tag, and three table cards each showing a qualified name, a one-line description, and tags such as certified, finance, and pii.] The catalog is one of the sources the agent’s search fans across, and the portal lets you browse it directly by source. The Tables, Context Docs, Tags, Domains, and Glossary sub-tabs are the same buckets a grouped search response comes back in, so what you see here is what a per-source floor guarantees stays visible when a query matches it. ### How the hits are ranked Semantic ranking is the feature people expect from a search tool. Every text query gets it: results rank hybrid, a semantic vector comparison combined with lexical matching, which is what lets a question find a dataset description sharing none of its words while an exact table name still lands where you expect it. The response reports which path produced a result rather than leaving it implied, because not every lookup is a text search. That distinction is what the ranking field is for. Ranking blends meaning with exact matching Search ranks hybrid: a semantic vector comparison combined with lexical matching. That is what lets a question find a dataset description sharing none of its words, while an exact table or column name still lands where you expect it. The `ranking` field says which path produced a result, so a text query scored against the corpus is distinguishable from a lookup keyed by an identifier. When a result set disappoints, the coverage summary beside it is the thing to read next: it says how much of the answer space the query actually reached. ### Then fetch reads it in full A search hit is a pointer, not a document. It carries a title, a short snippet, a relevance score, and a reference. That shape is deliberate: a response that returned every matching record in full would spend the context window on material the agent has not yet decided it wants. The reference is what turns a pointer into content. Fetch takes one and returns the complete record behind it, whatever kind of record that is. A knowledge page comes back as full markdown, a dataset as its catalog context, a glossary term as its definition and the datasets carrying it, a prompt as the prompt. The scoped readers that used to exist per source collapsed into this one verb. One verb reads every source: fetch by reference - mcp:knowledge_page: The full markdown body of a knowledge page. - urn:li:document: The full body of a context document. No other MCP tool reaches it. - urn:li:dataset: The dataset’s catalog context. - urn:li:glossaryTerm | tag | domain: The name and definition, plus the datasets that carry it. - mcp:resource: The resource record, with contents inline for a text file at or under 1 MB. - mcp:asset: The asset’s metadata record. The blob itself stays in S3. - mcp:prompt: The full prompt. - mcp:memory: and mcp:insight: Your full memory or insight record. - mcp:connection:(kind,name) The connection descriptor. Fetch reads under exactly the scope search applied, so it never returns content the same caller could not have found. A stale or out-of-scope reference comes back as a structured not-found rather than a tool error, which is why a citation pointing at something that has since been deleted degrades into a normal answer instead of a broken session. ### The two are a pair, and a persona should hold both Because the tools are separately grantable, it is possible to configure a persona that can search and cannot fetch. It is worth knowing what that looks like from the user side, because the symptom does not point at the cause. A persona granted search without fetch can find what it cannot read The two tools are a pair. Search returns pointers; fetch is what turns a pointer into content. Grant one without the other and the agent produces a list of things it can name and cannot open, which reads to the user as the platform being evasive rather than as a missing grant. Plexara registers them together and warns an administrator when a persona is configured in a way that cannot complete the capability. ### Why discovery precedes querying The operating manual that platform_info loads tells the agent to search before writing any query against the data, and usually to pull curated query templates for whatever dataset it settles on. This is not a style preference. It is how the agent avoids inventing schemas, misreading column names, or picking the wrong definition of a metric. This is the difference between [searching the capability instead of the manual](https://plexara.io/learning/insights/search-the-capability-not-the-manual): the agent finds what exists before it acts. Jumping straight to a free-form query is the most common anti-pattern The discover step exists because writing SQL without checking what exists first is exactly how an agent produces confident, plausible, wrong answers. The free-form query does not know which dataset is the source of truth, which columns the organization means when it says “revenue,” or whether the table in question has been deprecated. Search knows all of this, and it knows the knowledge page somebody wrote about it last quarter. Skipping the lookup trades a small context investment for a much larger reliability loss. ### The two-minute domain warm-up Even with a thorough catalog and a well-tended knowledge base, exploratory sessions benefit from a short domain warm-up at the start. Giving the agent a moment to describe the data estate in its own words activates the relevant slice of its training-time world knowledge and surfaces any obvious gaps before you ask a question that depends on them. What the platform returns is thorough, but it covers only what somebody documented. Obvious-to-humans context (a retailer sells physical goods through stores, a bank charges fees across customer accounts, a SaaS vendor tracks monthly recurring revenue) is not written down anywhere unless it was written down on purpose. A short warm-up closes that gap. A two-minute domain warm-up pays off for exploratory sessions For an exploratory session (a new user, a cross-domain question, or work where you do not already know which dataset you want), what the platform has documented can still leave the agent guessing at business context nobody wrote down. A short domain-framing prompt at the start of the session closes that gap by activating the relevant slice of the model’s training-time world knowledge. Describe what this Plexara deployment is and what data it makes available. Search for the core data domains and summarize them. For each major domain, list two or three representative datasets and what they contain. The tactic predates the universal search tool and still holds; it just runs through search now, which means the warm-up sees the knowledge pages and glossary terms alongside the datasets instead of the datasets alone. The follow-up questions you ask against an oriented agent land on firmer ground. ### Glossary terms are how business language gets resolved The governance vocabulary deserves its own note, because it changed shape. A glossary term, a tag, and a domain used to exist only as attributes hanging off a dataset: asking what a business term meant returned the datasets tagged with it and never the term itself. They are now searchable and fetchable entities in their own right, which means the question "what does this word mean here" finally has a direct answer. Glossary terms bridge business language to technical columns A glossary term is a named business concept (“ActiveCustomer,” “GrossRevenue,” “FiscalQuarter”) with a formal definition and a list of datasets and columns that implement it. When a user asks “how many active customers did we have in Q3,” the agent does not have to guess which table or which definition of “active” applies. Search returns the term itself as its own result, next to the datasets that carry it, so the question “what does this mean here” and the question “which data is about this” get separate answers instead of competing for the same slot. Glossary maintenance is also how organizational knowledge (from [206 - Knowledge: from memory to insights](https://plexara.io/learning/mcp/knowledge-from-memory-to-insights)) gets into the catalog: approved insights become glossary updates, descriptions, and tags. ### Discovery and structural reads are different jobs Search answers "what is there about this." It does not enumerate, and it does not walk a graph. Once the agent knows which dataset it wants, the questions turn structural: what columns does it have, what feeds it, what consumes it, what queries have already been written against it. Those go to the catalog directly. The distinction is worth holding onto because it explains why the DataHub toolkit did not shrink when discovery moved out of it. Relevance ranking and structured navigation are not two implementations of the same idea. The catalog is still reachable directly, for a different job - datahub_browse Enumeration, not relevance. Use it to page through a known category rather than to answer a question. Catalog contents listed by category: tags, domains, or data products. - datahub_get_schema Before writing any query that references specific columns by name. Column names, types, nullability, descriptions, tags, and glossary-term bindings for one dataset. - datahub_get_queries Prefer these over free-form SQL. They are faster, tested, and usually correct. Curated, pre-benchmarked query templates stored against a dataset, annotated with performance characteristics. - datahub_get_lineage When a number looks off and the question becomes "where does this value actually come from." Upstream and downstream relationships: which sources feed a dataset, which reports and dashboards consume it. - datahub_get_entity When you already hold a URN and want the record behind it outside a search flow. The full canonical catalog record for one entity, identified by URN. The DataHub toolkit also carries write operations (datahub_create, datahub_update, datahub_delete) that administrators and knowledge curators use. Those sit next to the read tools above and are governed separately. ### When one search is enough on its own Not every session needs a domain warm-up, and not every question needs a fetch. Narrow, specific questions with clear entity references ("daily revenue by region for 2025") carry enough context in the question itself that the snippets in a single search response fill in the rest. The warm-up pays off most for new users, cross-domain questions, and anything where you are not already sure which dataset you want. ### Where this leads With the right dataset identified and a curated query template in hand, the agent is ready to run the query. The next lesson covers how Plexara [reaches data through Trino](https://plexara.io/learning/mcp/trino-query-analytics-and-insights) and why picking the right query shape matters so much for performance. Where this leads Discovery points the agent at the right dataset and hands it a curated query template. The next step runs the query. [204 - Trino Query: analytics and insights](https://plexara.io/learning/mcp/trino-query-analytics-and-insights) covers how Plexara reaches data through Trino, why pushed-down OLAP finishes in a second where naive SQL takes a minute, and how to handle large result sets without burning through the context window. ### Key terms Eight terms cover the vocabulary you will see across search responses, catalog documentation, and every conversation about the discover step. Key Terms search The universal discovery entry point. One query fans across every source the caller can reach and returns hits grouped by source with a coverage summary, rather than a single flat list one source can dominate. fetch The companion read verb. Takes any reference search emitted and returns that record in full, under exactly the scope search applied. Replaces the per-source readers that used to exist for each kind of record. Reference The handle a search hit carries. Either urn:li:... for DataHub catalog entities or mcp:... for platform-internal records. What you pass to fetch. Coverage summary The matched-versus-shown counts a search response carries per source. Tells the agent how much of the answer space it is looking at, so a truncated view is never mistaken for the whole one. Hybrid ranking Semantic vector comparison combined with lexical matching. How every text query is ranked, which is what lets a question match a description sharing none of its words. The response reports the path it used in its ranking field. Glossary term A named business concept with a formal definition and bindings to the datasets and columns implementing it. Searchable and fetchable in its own right, not only as an attribute of a dataset. Lineage Upstream and downstream relationships for a dataset. Answers where a value comes from and which reports would break if the dataset changed. A structural read, not a discovery one. Curated query template A pre-benchmarked, annotated query stored against a dataset in DataHub and retrieved with datahub_get_queries. Preferred over free-form SQL because it is tested, fast, and already knows the right aggregation patterns. On this page [Previous 202 - Your first day with Plexara](https://plexara.io/learning/mcp/first-engagement) [Next 204 - Trino Query: analytics and insights](https://plexara.io/learning/mcp/trino-query-analytics-and-insights) ### Related reading product [Product 102 - Tokens and your budget Every LLM interaction is priced and rate-limited in tokens. What a token is, how much text fits a budget, and how to avoid wasting tokens on useful answers.](https://plexara.io/learning/ai-concepts/tokens-and-your-budget) [Product 105 - What is an AI agent? An AI agent is not a chatbot and not magic. It is a short loop (think, call-tool, observe, think again) on top of a language model. Mental model first.](https://plexara.io/learning/ai-concepts/what-is-an-ai-agent) [Product 202 - Your first day with Plexara A new Plexara user gets connected, sends a first question, and platform_info takes over. Walks through day one and how subsequent turns inherit context.](https://plexara.io/learning/mcp/first-engagement) --- # Trino Query: analytics and insights URL: https://plexara.io/learning/mcp/trino-query-analytics-and-insights/ > Plexara reaches customer data through Trino. What Trino is, how it maps to DataHub metadata, why OLAP queries finish fast, and how to export large results. Product 11 min read ## 204 - Trino Query: analytics and insights Plexara reaches customer data through Trino. What Trino is, how it maps to DataHub metadata, why OLAP queries finish fast, and how to export large results. On this page ### What you will take away from this lesson In [203 - Discovery: one search, then fetch](https://plexara.io/learning/mcp/discovery-search-and-fetch), the discover step pointed the agent at the right dataset and handed over any curated query templates that exist for it. This lesson is about what happens next: running the query. Plexara reaches data through Trino, which federates across whatever data stores the customer has connected. The point of the lesson is not to teach SQL. Frontier models already write SQL well. The point is to understand how Plexara makes those queries accurate, where queries can come from during a session, and how agent-written queries become organizational knowledge over time. Learning Objectives 1. 01 Describe what Trino is and why it is the single execution layer every Plexara data question passes through. 2. 02 Recognize that frontier models already know how to write SQL; Plexara makes their queries accurate by supplying schema and semantic context. 3. 03 Identify the three sources a query in a Plexara session can come from (agent-authored, curated in the catalog, or synthesized from prior sessions) and why curated queries still matter even when the agent could write one itself. 4. 04 Read the OLAP vs OLTP distinction and know why running the wrong shape against the wrong store is the most common cause of a ninety-second query. 5. 05 Know when to call trino_query vs trino_export, and understand how agent-written queries feed the knowledge pipeline so future sessions start smarter. ### 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 [Open index](https://plexara.io/learning/ai-concepts) - [101 What is a Large Language Model? Brilliant at language, blind about your data. Tokens, hallucination, the grounding problem.](https://plexara.io/learning/ai-concepts/what-is-a-large-language-model) - [102 Tokens and your budget Subscription-plan economics, session limits, and Plexara enrichment dedup.](https://plexara.io/learning/ai-concepts/tokens-and-your-budget) - [103 Context, compression, and memory The keep / compress / clear playbook and how memory carries across sessions.](https://plexara.io/learning/ai-concepts/context-windows-and-tokens) - [104 Frontier models, specialized models, and why enterprise AI uses both Three knowledge sources (training, web search, tools). MCP as the exposure protocol.](https://plexara.io/learning/ai-concepts/frontier-models-explained) - [105 What is an AI agent? The think/call-tool/observe loop. Professor's knowledge, child's literalism.](https://plexara.io/learning/ai-concepts/what-is-an-ai-agent) - [110 Is MCP just an API wrapper? MCP as an application layer. Spectrum from thin wrapper to full application server.](https://plexara.io/learning/ai-concepts/mcp-vs-apis) 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. ### A mental model for Trino Trino is a distributed SQL engine that federates queries across many backends. Plexara uses Trino as the single execution layer every MCP data question passes through. Whether the underlying store is PostgreSQL, OpenSearch, Oracle, Snowflake, or any other Trino-compatible connector, the agent writes SQL once and Trino routes it to the right catalog. The practical benefit: the agent does not have to learn half a dozen dialects. The customer does not have to standardize on a single vendor. The Plexara MCP server does not need to know, in advance, which kinds of stores it will end up talking to. Trino is the single execution layer; the backends differ The agent writes one SQL dialect (Trino's) and calls `trino_query`. Trino routes the query to the right catalog and handles whatever the underlying backend speaks. The customer's data estate can be any combination of the following: - OLTP row store Row-oriented, indexed on primary keys. PostgreSQL, MySQL, Oracle, SQL Server. - OLAP column store Columnar, aggregation-optimized, often with pushdowns. OpenSearch, ClickHouse, Snowflake, BigQuery. - Object storage File-based, often Parquet; scanned at query time. S3, GCS, Azure Blob (through the Hive or Iceberg connectors). Plexara does not impose a specific backend. The same MCP server works against whichever combination of Trino-compatible stores the customer has already invested in. ### How Trino tables map to DataHub entities Every Trino table has a corresponding DataHub entity, keyed by URN. The URN includes the Trino catalog, schema, and table, which lets the agent go from a query result back to the catalog's owners, tags, glossary terms, lineage, and curated queries for that entity. This mapping is what makes a query result interpretable, not just readable. It is also what lets the enrichment described in the previous lesson attach automatically. ### Where queries come from: three sources A frontier model already knows how to write SQL. That capability is in the training data. What it does not know, on its own, is your schema, your naming conventions, your glossary, or which column actually stores the number you care about. Plexara closes that [context gap in AI data access](https://plexara.io/learning/insights/context-gap-in-ai-data-access), which is why agent-authored queries on a Plexara session tend to be correct on the first try rather than after three rounds of iteration. Within any given session, a query can originate from one of three sources. All three are legitimate; which one runs depends on what the question is and what the catalog already knows. Three places a query in a Plexara session can come from - Written by the agent from scratch When: No curated query fits and memory has nothing relevant. The frontier model writes SQL using the schema and semantic context Plexara surfaced during the discover step. The schema tells it the column names and types. The catalog tells it what the columns mean. The query produced this way is usually correct on the first try because it is grounded in both. - Curated query from the catalog When: datahub_get_queries returned one or more templates for the matched dataset. The agent uses a known-good query that has already been written, tested, and annotated with performance characteristics. Deterministic input, deterministic result. When a curated query exists for the shape of the question, using it is the default. - Recalled from a prior session When: The agent (or a teammate) previously wrote a query for a similar question and it was captured. Memory and the knowledge pipeline surface queries from prior sessions when they match the current question, letting the current session skip the rediscovery step entirely. A customer with no curated queries at onboarding is fine. The agent writes new ones as needed, and over time the pipeline covered in [206](https://plexara.io/learning/mcp/knowledge-from-memory-to-insights) promotes the ones worth keeping into catalog-level documentation. ### Why curated queries still matter If the frontier model can write SQL, it is reasonable to ask why a catalog of curated queries exists at all. Two answers. One is reproducibility, which matters most for anything that will be reported upward or referenced later. The other answer is less obvious but more important over time: a curated query is itself a layer of documentation, the way [knowledge application turns usage into documentation](https://plexara.io/learning/insights/knowledge-application-turns-usage-into-documentation). A known query produces a known result The curated template has already been run, reviewed, and benchmarked. Two different users asking the same question get the same answer down to the row. Important for anything that will be reported up the chain. The query itself is documentation Schema descriptions are one layer of documentation. Glossary terms are a second. The construction of a query is a third: the joins, filters, and aggregations describe the relationships and business rules in executable form. A well-authored curated query teaches future agents (and future humans) how the data actually fits together. ### Query shape: OLAP vs OLTP The most common cause of a slow Plexara session is running the wrong shape of query against the wrong kind of store. Point lookups belong on row-oriented indexed stores; aggregations belong on columnar analytical stores. Running either against the wrong backend is where eighty-second queries come from, and the agent has no way to recover from a bad shape without rewriting the query. The operating manual the agent receives from platform_info tells it which catalog is appropriate for which shape. A deployment whose OLAP layer is OpenSearch has that documented; a deployment that uses ClickHouse or Snowflake instead has its own version of the same guidance. The agent does not have to guess; it reads the manual. Query shape determines which store should answer - Point lookup: fetching one specific row by a unique identifier (show me customer 42, get order #12345, current inventory at store 7) Right store: Indexed row store (PostgreSQL and similar). Wrong store: Columnar OLAP store: has to read many rows to find one. Cost when mismatched: Seconds instead of milliseconds, sometimes worse at large volume. - Aggregation: rolling up many rows into a summary (revenue by region for a year, redemption rates by tier, average order size by month) Right store: Columnar OLAP store with pushdown support (OpenSearch, ClickHouse, Snowflake). Wrong store: OLTP row store: has to scan every row and aggregate in memory. Cost when mismatched: A ninety-second GROUP BY on a large table, sometimes timing out entirely. The agent does not have to guess which store to use. The agent_instructions block from platform_info tells it which catalog is appropriate for which shape, and each customer's manual is tuned to the backends they have connected. ### Pushdown and connector-native query paths When Trino can push an operation down to the underlying backend, it runs the operation natively and returns only the result. When it cannot push down, it reads rows back through the network and aggregates in-memory. For small tables this does not matter; for large tables it is the difference between a one-second query and a ninety-second one. Some connectors expose escape hatches for cases where standard Trino SQL will not push down cleanly. The OpenSearch connector exposes a raw_query table function that lets the agent compose native OpenSearch Query DSL for aggregations. The customer's agent_instructions describe which escape hatches are appropriate for which backend; the benchmarks are measured, not assumed. ### Large result sets: trino_query vs trino_export Not every query returns a handful of rows. Some return thousands. Getting the result shape right at query time, and choosing between trino_query and trino_export, is the difference between [token-efficient sessions](https://plexara.io/learning/insights/token-efficiency-in-enterprise-mcp) and one that exhausts its context window on a single lookup. trino_export keeps large result sets out of the conversation `trino_query` returns rows directly, which is fine when the result is small enough to reason about. Large result sets are different: thousands of rows in the context window is both expensive ([102](https://plexara.io/learning/ai-concepts/tokens-and-your-budget)) and rarely useful. `trino_export` runs the same query but writes the result to a persisted asset (CSV, JSON, or Markdown) in the customer's portal. The agent returns a reference to the asset, not the rows, and the user downloads or shares the file. Assets are covered in [205](https://plexara.io/learning/mcp/assets-dashboards-reports-and-data). ### Agent-authored queries become organizational knowledge Curated queries are often thought of as something the organization must preload into the catalog. In practice the flow is bidirectional. An agent that writes a new or derivative query during a session can surface it as an insight, and an administrator can promote it through the review pipeline into a catalog-level curated template. The next person asking a similar question gets that query handed to them by datahub_get_queries. This matters for organizations starting from scratch. A customer with no curated queries on day one is not missing anything; the curated library builds itself from real usage. Every useful question the agent answers is a candidate future template. Agent-written queries flow back into organizational knowledge Queries are not one-way traffic from catalog to agent. An agent that writes a new or derivative query during a session can capture that query as an insight, and an administrator can promote it into the catalog as a new curated query. The next session looking for that pattern picks it up via `datahub_get_queries`. Organizations without any curated queries on day one do not have a gap to close; they have a flywheel to start. The review and promotion pipeline is covered in [206 - Knowledge: from memory to insights](https://plexara.io/learning/mcp/knowledge-from-memory-to-insights). ### Where this leads Queries produce results. Small results live in the conversation. Large results, and anything worth keeping past the current session, belong in an asset. The next lesson covers the asset system. Where this leads Queries produce results. Small results fit in the conversation; large results belong in a persisted asset. The next lesson is about Plexara's asset system, the third step of the discover-query-enrich workflow. [205 - Assets: dashboards, reports, and data](https://plexara.io/learning/mcp/assets-dashboards-reports-and-data). ### Key terms Nine terms cover the vocabulary you will see across Trino results, the operating manual, and any discussion of query performance on a Plexara session. Key Terms Trino A distributed, federated SQL engine. Plexara uses Trino as the single execution layer through which every data question reaches the underlying backends. The agent writes one SQL dialect; Trino routes to whichever catalog is connected. Catalog (Trino sense) A named connection to a backend store inside Trino. A single Plexara deployment can have many Trino catalogs (for example, one pointing at PostgreSQL, one at OpenSearch, one at S3 via Iceberg), each exposed as its own top-level namespace. Point lookup Fetching one specific row by a unique identifier (for example, show me customer 42, get order #12345, current inventory at store 7). Cheap on an indexed row store, expensive on a columnar OLAP store. Aggregation Rolling up many rows into a summary (for example, revenue by region for a year, average order size by month). Cheap on a columnar OLAP store with pushdown support, expensive on an OLTP row store. OLTP online transaction processing Row-oriented, indexed workloads. Dominated by point lookups, single-entity reads, and small writes. Well suited to stores like PostgreSQL, MySQL, Oracle, SQL Server. OLAP online analytical processing Column-oriented, aggregation-heavy workloads. GROUP BY, percentiles, time-bucketed rollups. Well suited to stores like OpenSearch, ClickHouse, Snowflake. Pushdown When Trino delegates part of a query to the underlying backend (filter, aggregation, top-N) instead of reading rows back through the network. The difference between a one-second query and a ninety-second query on large datasets. Curated query template A pre-written, pre-benchmarked query stored against a dataset in DataHub. Retrieved via `datahub_get_queries`. Two benefits: known inputs produce known results, and the query construction itself documents how the data fits together. Agent-authored queries can be promoted into curated templates via the knowledge pipeline in [206](https://plexara.io/learning/mcp/knowledge-from-memory-to-insights). trino_export The tool that runs a Trino query and writes the result to a persisted asset (CSV, JSON, Markdown) instead of returning rows in the conversation. The primary way to keep large result sets out of the token budget ([102](https://plexara.io/learning/ai-concepts/tokens-and-your-budget)). On this page [Previous 203 - Discovery: one search, then fetch](https://plexara.io/learning/mcp/discovery-search-and-fetch) [Next 205 - Assets: dashboards, reports, and data](https://plexara.io/learning/mcp/assets-dashboards-reports-and-data) ### Related reading product [Product 102 - Tokens and your budget Every LLM interaction is priced and rate-limited in tokens. What a token is, how much text fits a budget, and how to avoid wasting tokens on useful answers.](https://plexara.io/learning/ai-concepts/tokens-and-your-budget) [Product 105 - What is an AI agent? An AI agent is not a chatbot and not magic. It is a short loop (think, call-tool, observe, think again) on top of a language model. Mental model first.](https://plexara.io/learning/ai-concepts/what-is-an-ai-agent) [Product 202 - Your first day with Plexara A new Plexara user gets connected, sends a first question, and platform_info takes over. Walks through day one and how subsequent turns inherit context.](https://plexara.io/learning/mcp/first-engagement) --- # Assets: dashboards, reports, and data URL: https://plexara.io/learning/mcp/assets-dashboards-reports-and-data/ > Plexara's asset system persists dashboards, reports, and exports outside chat. Naming asset tools in a prompt saves tokens and keeps outputs shareable. Product 10 min read ## 205 - Assets: dashboards, reports, and data Plexara's asset system persists dashboards, reports, and exports outside chat. Naming asset tools in a prompt saves tokens and keeps outputs shareable. On this page ### What you will take away from this lesson In [204 - Trino Query: analytics and insights](https://plexara.io/learning/mcp/trino-query-analytics-and-insights), we covered how the agent executes queries and touched briefly on the fact that large results belong in an asset rather than the conversation. This lesson is the asset system itself: the third step of the discover-query-enrich workflow and the place where useful output goes to live. Assets turn a chat transcript into shareable work product. A dashboard built during one session is still there the next day for a teammate who was not in the conversation. Being explicit about the asset path in your prompts is the single largest token-saver after good session hygiene. Learning Objectives 1. 01 Explain what a Plexara asset is and why persisting outputs outside the conversation matters for both token budget and shareability. 2. 02 Name the kinds of assets a Plexara session can produce (interactive dashboards, reports, CSV exports, charts, markdown documents) and when to ask for each. 3. 03 Use save_asset and manage_asset (or invoke them implicitly through explicit prompt language) so the agent does not dump large outputs into the chat. 4. 04 Group related assets into a collection so a teammate can open a single link and see the entire briefing in the portal. 5. 05 Recognize that assets live in the Plexara portal and can be referenced, edited, and re-queried across sessions. ### 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 [Open index](https://plexara.io/learning/ai-concepts) - [101 What is a Large Language Model? Brilliant at language, blind about your data. Tokens, hallucination, the grounding problem.](https://plexara.io/learning/ai-concepts/what-is-a-large-language-model) - [102 Tokens and your budget Subscription-plan economics, session limits, and Plexara enrichment dedup.](https://plexara.io/learning/ai-concepts/tokens-and-your-budget) - [103 Context, compression, and memory The keep / compress / clear playbook and how memory carries across sessions.](https://plexara.io/learning/ai-concepts/context-windows-and-tokens) - [104 Frontier models, specialized models, and why enterprise AI uses both Three knowledge sources (training, web search, tools). MCP as the exposure protocol.](https://plexara.io/learning/ai-concepts/frontier-models-explained) - [105 What is an AI agent? The think/call-tool/observe loop. Professor's knowledge, child's literalism.](https://plexara.io/learning/ai-concepts/what-is-an-ai-agent) - [110 Is MCP just an API wrapper? MCP as an application layer. Spectrum from thin wrapper to full application server.](https://plexara.io/learning/ai-concepts/mcp-vs-apis) 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. ### Why the asset system exists A large dashboard or a detailed markdown report is expensive to put into a conversation, expensive to regenerate, and hard to share once it scrolls past in the chat. The asset system turns those outputs into persistent, viewable, editable objects stored in the Plexara portal. The agent writes the artifact once, saves it, and returns a link. You can view it, share it with a teammate, and come back later and ask the agent to edit it without starting over. There is a second reason the asset system exists, and it is about discipline: keeping large outputs out of the conversation entirely. A dashboard that lives in the portal does not sit in the [context window eating tokens](https://plexara.io/learning/ai-concepts/context-windows-and-tokens) on every subsequent turn. A CSV export that lives as an asset does not flood the chat with rows you never needed to see. This is the same [token efficiency](https://plexara.io/learning/insights/token-efficiency-in-enterprise-mcp) discipline the platform applies elsewhere: assets are how useful output survives without slowing the session down. ### The kinds of assets a session can produce Plexara asks the agent to pick the right shape of output for the job. An interactive dashboard is different from a narrative report is different from a CSV export is different from a single SVG chart. The agent gets these distinctions right when the prompt is explicit. The table below shows which asset type fits which kind of ask, with an example prompt for each. The kinds of assets a session can produce - Interactive dashboard Comparisons and exploratory views a teammate will want to click through. Filters, tabs, linked charts. HTML rendered inside the Plexara portal. "Build an interactive dashboard comparing 2024 sales to 2025 by region and save it as Q1 regional comparison." - Markdown report A narrative write-up with embedded numbers, charts, and conclusions. The right asset type for anything intended to be read top-to-bottom or shared with a non-technical reader. "Draft a markdown report summarizing the Q3 numbers, highlighting the three stores with the biggest swings, and save it as a Q3 exec summary asset." - CSV / tabular export Full-fidelity data for downstream tools: a spreadsheet, a BI tool, another Plexara session. Produced by trino_export when the row count would blow up the context window. "Export the full 2025 transaction table filtered to the Southwest region as a CSV asset." - SVG chart A single visualization suitable for embedding in a document or sharing as a self-contained image. Vector; scales cleanly. "Create an SVG chart of revenue per store for the top ten stores by Q3 volume, saved as an asset." - Markdown document Notes, methodology, caveats, anything text-shaped that is not a full report. Often created alongside other assets to document how they were built. "Save a markdown document describing how the Q3 regional comparison was calculated, including the exact Trino queries used." - Collection A grouping of related assets (dashboards, reports, exports, charts, markdown) into a single navigable briefing. Shareable as one link in the portal. "Start a collection called Q1 regional review. Add the dashboard, the exec summary report, and the underlying CSV export." [Image: The portal Asset Viewer showing an HTML dashboard titled Q4 Revenue Dashboard at version 5: a Preview and Source toggle, Feedback, Delete, Download, and Share buttons, and the rendered dashboard with four KPI tiles, a revenue-by-region bar chart, and a top-products table.] **Interactive dashboard (HTML).** Rendered live in the viewer, with a version picker because the agent iterated on it. [Image: The portal Asset Viewer showing a React component asset titled KPI Scorecard Component: a Preview and Source toggle above a rendered scorecard with a store selector, six KPI tiles with quarter-over-quarter deltas, and a top-selling-categories bar list.] **React component (JSX).** A component with its own controls, such as the store selector here, rendered from source in the same viewer. [Image: The portal Asset Viewer showing a CSV asset titled Regional Sales Summary: a search box across all columns, a Download button, and a sortable table of region, quarter, revenue, units sold, average price, and growth with a row count below.] **CSV export.** Full-fidelity rows in a sortable, searchable table, with Download for the spreadsheet or BI tool that comes next. [Image: The portal Asset Viewer showing an SVG asset titled Sales Pipeline Chart at version 3: a funnel of four stacked stage bars labeled Leads, Qualified, Proposal, and Negotiation with counts, rendered as a single vector image.] **SVG chart.** One self-contained visualization, sized for embedding in a document or slide. [Image: The portal Asset Viewer showing a Markdown asset titled Weekly Inventory Report: a rendered document with a heading, the week it covers, a summary table of metrics with values and changes, and a warehouse breakdown of capacity, items shipped, and restock needs per distribution center.] **Markdown report or document.** Read top to bottom, headings and tables included; the same shape serves a narrative report and a methodology note. ### Being explicit saves tokens and gets better outputs Vague prompts ("generate a dashboard") lead to vague outputs. Worse, they leave the agent to decide whether to dump the output into the chat or save it as an asset, and the agent sometimes picks wrong. A prompt that names the asset type, the content, and the asset name routes the agent straight to the save_asset tool. Explicit prompt language is the single largest token-saver A prompt that says “generate a dashboard” leaves the decision up to the agent, which may do a reasonable thing, may dump the full HTML into the chat, or may half-do both. A prompt that says “generate an interactive dashboard comparing 2024 sales to 2025 by region and save it as an asset” routes the agent directly to save_asset. The dashboard never lands in the conversation. Token cost drops to a fraction of the alternative ([102](https://plexara.io/learning/ai-concepts/tokens-and-your-budget)) and the output is actually shareable afterward. ### A four-step workflow that works The same rhythm covers almost every asset-producing session: preview the data quickly in the chat, then ask for the full deliverable as an asset, then iterate by reference, then gather related assets into a collection. Internalizing this pattern saves you from relearning it per session. A four-step workflow that works across almost every asset request 1. 01 Preview in the chat Ask for a small sample first: "Show me a quick table of 2025 revenue by region so I can check the shape of the data." The goal is to confirm the agent has the right mental model and the numbers look roughly right before you commit to a larger deliverable. 2. 02 Ask for the deliverable by type, and say "save as an asset" Name the type explicitly (dashboard, report, CSV, SVG chart, markdown) and name the asset. This routes the agent straight to save_asset instead of letting it dump HTML or rows into the chat. 3. 03 Iterate by reference When you want a change, say "open the Q1 regional comparison and add a chart showing year-over-year percent change." The agent calls manage_asset and modifies the existing asset rather than regenerating from scratch. 4. 04 Group related work into a collection When a session produces several related assets, ask for them to be gathered into a named collection. That collection becomes a single shareable link to a briefing, not a chat transcript. ### Collections: mini-portals for a topic A single dashboard is useful. A collection of related assets (dashboard, report, export, methodology) is closer to how people actually do analytical work. Collections let the agent assemble a briefing during a session, with sections for the different pieces, and hand back a single shareable link at the end. Collections turn a session into a briefing packet Collections group related artifacts (a dashboard, a report, an export, a methodology note) into a single navigable unit with sections. The agent can build one while it works: a trend dashboard in one section, a regional breakdown in another, a CSV export for download, a markdown doc explaining how the numbers were calculated. The result is closer to a briefing than a chat log, and the share link points at the whole thing. [Image: The portal Collections page: Assets and Collections tabs, Mine, Shared, and All filters, a search box, a New Collection button, and a grid of collection cards each showing a mosaic of asset thumbnails, a title, a description, tags, and a date, one of them carrying a feedback count.] Collections sit beside assets in the portal. Each card previews the assets inside it, so a briefing like a quarterly performance review is recognizable at a glance, and the Mine, Shared, and All filters cover the ones you built and the ones built for you. [Image: The portal view of one collection titled Q4 Performance Review: a description line, Feedback, Edit, Share, and Delete buttons, a thumbnail-size toggle, and named sections such as Overview and Regional Analysis, each holding asset cards with a preview, a title, a one-line description, and a content type badge like text/html, text/jsx, or text/csv.] Inside a collection the sections are the structure the agent assembled during the session: an Overview holding the dashboard, the scorecard, and the CSV summary, then a Regional Analysis for the drilldowns. The single Share button on this page is the one link that hands over the whole briefing. ### Where this leads Assets are where useful output persists within the portal. [Memory and the knowledge pipeline](https://plexara.io/learning/mcp/knowledge-from-memory-to-insights) are what let the next session find those assets and remember what they were for. The next lesson covers both. Where this leads Assets are where useful session output gets saved. Memory and the knowledge pipeline are what let the next session know those assets exist and what they meant. The next lesson covers both. [206 - Knowledge: from memory to insights](https://plexara.io/learning/mcp/knowledge-from-memory-to-insights). ### Key terms Six terms cover the vocabulary you will see in asset-related tool results and any conversation about persisting session output. Key Terms Asset artifact A persisted output produced during a Plexara session: a dashboard, report, CSV export, chart, markdown document, or similar. Lives in the Plexara portal, not in the conversation. Shareable and editable. Collection A grouping of related assets into a single navigable unit with sections. Shareable as one link. The closest Plexara analog to a briefing packet. save_asset The tool the agent calls to create a new asset and store it in the portal. Returns a reference the agent shares back with the user instead of the full content. manage_asset The tool the agent calls to edit an existing asset. Operates in place, keeping the asset identifier stable, so iterations do not create a pile of near-duplicates. trino_export A specialized write tool for the common case of “the query result is too big for the chat.” Runs the Trino query and writes the result as an asset (CSV, JSON, Markdown). Covered in detail in [204](https://plexara.io/learning/mcp/trino-query-analytics-and-insights). Plexara portal The web UI where assets live. Users open, review, edit, and share assets here. The portal is also where administrators manage connections, personas, and the knowledge-review pipeline. On this page [Previous 204 - Trino Query: analytics and insights](https://plexara.io/learning/mcp/trino-query-analytics-and-insights) [Next 206 - Knowledge: from a memory to something the whole team can use](https://plexara.io/learning/mcp/knowledge-from-memory-to-insights) ### Related reading product [Product 102 - Tokens and your budget Every LLM interaction is priced and rate-limited in tokens. What a token is, how much text fits a budget, and how to avoid wasting tokens on useful answers.](https://plexara.io/learning/ai-concepts/tokens-and-your-budget) [Product 105 - What is an AI agent? An AI agent is not a chatbot and not magic. It is a short loop (think, call-tool, observe, think again) on top of a language model. Mental model first.](https://plexara.io/learning/ai-concepts/what-is-an-ai-agent) [Product 202 - Your first day with Plexara A new Plexara user gets connected, sends a first question, and platform_info takes over. Walks through day one and how subsequent turns inherit context.](https://plexara.io/learning/mcp/first-engagement) --- # Knowledge: from a memory to something the whole team can use URL: https://plexara.io/learning/mcp/knowledge-from-memory-to-insights/ > Memory to Insight to Knowledge: the three stages a fact travels, the capability check that promotes it, and the two canonical places it lands. Product 14 min read ## 206 - Knowledge: from a memory to something the whole team can use Memory to Insight to Knowledge: the three stages a fact travels, the capability check that promotes it, and the two canonical places it lands. On this page ### What you will take away from this lesson In [205 - Assets: dashboards, reports, and data](https://plexara.io/learning/mcp/assets-dashboards-reports-and-data), we covered how useful session output persists as an artifact you can reopen. This lesson is about the other kind of persistence: what the platform learns, and how one person's correction becomes a fact the whole team can rely on. Every lesson in this series has referred back to this one. [102](https://plexara.io/learning/ai-concepts/tokens-and-your-budget) mentioned memory dedup as the reason follow-up questions are cheap. [103](https://plexara.io/learning/ai-concepts/context-windows-and-tokens) explained the context-is-scratch-paper problem that memory solves. [202](https://plexara.io/learning/mcp/first-engagement) noted that memories carry forward between sessions. [204](https://plexara.io/learning/mcp/trino-query-analytics-and-insights) pointed out that agent-written queries become curated templates through the promotion path covered here. This is the lesson that ties it all together. Learning Objectives 1. 01 Name the three stages a fact travels through, Memory to Insight to Knowledge, and the rule that promotes it from each stage to the next. 2. 02 List the five lifecycle classes a memory is filed under, and say which classes make a memory a promotion candidate rather than something that stays yours. 3. 03 Name the two places a promoted insight can land, canonical knowledge pages and the DataHub catalog, and the rule for which kind of fact goes where. 4. 04 Describe what a canonical knowledge page is, what it cites, and why the citation runs in both directions. 5. 05 Explain who may review and promote, and why that is a capability check on apply_knowledge rather than an admin role. 6. 06 Say what changes the moment an insight is applied: it becomes findable by every identity, not only the one that captured it. ### 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 [Open index](https://plexara.io/learning/ai-concepts) - [101 What is a Large Language Model? Brilliant at language, blind about your data. Tokens, hallucination, the grounding problem.](https://plexara.io/learning/ai-concepts/what-is-a-large-language-model) - [102 Tokens and your budget Subscription-plan economics, session limits, and Plexara enrichment dedup.](https://plexara.io/learning/ai-concepts/tokens-and-your-budget) - [103 Context, compression, and memory The keep / compress / clear playbook and how memory carries across sessions.](https://plexara.io/learning/ai-concepts/context-windows-and-tokens) - [104 Frontier models, specialized models, and why enterprise AI uses both Three knowledge sources (training, web search, tools). MCP as the exposure protocol.](https://plexara.io/learning/ai-concepts/frontier-models-explained) - [105 What is an AI agent? The think/call-tool/observe loop. Professor's knowledge, child's literalism.](https://plexara.io/learning/ai-concepts/what-is-an-ai-agent) - [110 Is MCP just an API wrapper? MCP as an application layer. Spectrum from thin wrapper to full application server.](https://plexara.io/learning/ai-concepts/mcp-vs-apis) 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. ### Three stages, and the rule between each one Everything the platform learns is a memory. Most memories are personal or operational and stay yours. When a memory asserts something true about the business or the data that other people would benefit from, it becomes an insight: a proposal awaiting review. Whoever holds the apply_knowledge capability reviews insights and promotes the good ones into knowledge, which is shared, trusted, and canonical. That is the whole model, and it is worth reading twice, because the two arrows in it are where all the interesting behavior lives. The first arrow is decided by what kind of fact you stated. The second is decided by a person. Memory → Insight → Knowledge 1. Memory Everything the platform learns starts here. What it is: A preference you stated, an event worth recalling, a correction you made, a convention you explained. Memory is captured during ordinary sessions, stored as a semantically searchable record, and filed under a lifecycle class that decides what can happen to it next. Who can find it: You. A memory is personal by default and stays that way. Promotion rule ↓ A memory becomes an Insight when it asserts something true about the business or the data that other people would benefit from. Preferences and one-off events do not qualify; business facts, operational rules, and schema facts do. 2. Insight A proposal awaiting review. What it is: An insight is a claim with a proposed destination attached: the entity it is about, the category it falls into, who captured it, and the session it came from. Pending and approved insights are proposals. Nothing about the shared record has changed yet. Who can find it: Still only you, plus reviewers working the queue. A capture under review is not yet something the organization asserts. Promotion rule ↓ An insight becomes Knowledge when someone holding the apply_knowledge capability approves it and promotes it. Approving curates the queue; the promotion itself is the write. 3. Knowledge Shared, trusted, canonical. What it is: Promoted knowledge lands in one of two canonical stores depending on what kind of fact it is, and the promotion is recorded as a changeset that can be rolled back. From that point the fact answers questions for people who never had the original conversation. Who can find it: Every identified caller in the workspace, attributed to whoever captured it. This is the moment a fact stops being one person's and starts being the team's. The stages are not three copies of the same fact. They are three levels of commitment: a private note, a proposal, and an assertion the organization stands behind. ### Why one thing you say stays yours and another does not The first arrow is not a judgment call the agent makes in the moment. Every memory is filed under a lifecycle class when it is captured, and the class is what decides whether the memory is a candidate for promotion at all. Two of the five classes are personal by nature. The other three make claims that could be true for everyone, so they enter review as pending insights instead of quietly settling into one person's memory. The classes also explain a behavior you will notice early: restating something you already told the agent does not stack a second near-identical memory beside the first. Capture checks your existing memory before writing, and a restatement supersedes the record it corrects. The [five kinds of memory and how each comes back](https://plexara.io/learning/insights/five-kinds-of-memory) goes deeper on the recall side of this. The five lifecycle classes, and what each one is allowed to become - Preference preference Stays yours "Compare fiscal quarters, not calendar quarters, when I ask about growth." Stays yours. Another analyst may prefer the opposite and both can be right. - Event event Stays yours "Checked the June reconciliation against the ledger export on the 12th." Stays yours. It is a record of what happened, not a claim about the business. - Business knowledge business_knowledge Candidate "MRR counts active subscriptions only. Trials are excluded." Promotion candidate. A definition like this belongs on a knowledge page. - Operational rule operational_rule Candidate "Always filter status = 'active' or soft-deleted rows double-count." Promotion candidate. Stored as a knowledge page, alongside business knowledge. - Schema/entity schema_entity Candidate "transactions.amount is gross margin in cents, not revenue in dollars." Promotion candidate. Anchored to a catalog entity, so the catalog is its home. The class is the mechanism behind the whole model. It is why one thing you say in a session stays in your own memory forever and another turns up in a review queue the same afternoon. ### The second arrow: who is allowed to promote Nothing crosses into shared knowledge automatically, and the reason is the same reason a catalog update deserves a human: a fact that answers questions for everyone should have been read by someone before it starts doing that. What is worth being precise about is the shape of the check. It is not an admin role, and it is not a job title. It is whether your persona grants the apply_knowledge tool. That distinction is practical rather than pedantic. Roles tend to bundle unrelated powers together, and the person who genuinely knows whether a revenue definition is right is usually not the person who administers the deployment. A capability can be handed to the domain expert who should hold it, and to nobody else, without also handing them the keys to everything else. This is the same [governance at execution time](https://plexara.io/learning/insights/governance-at-execution-time) principle that shapes the rest of the platform. Who promotes, and what the promotion leaves behind - A capability, not a role Review and promote affordances appear when your persona grants the apply_knowledge tool. That is the whole check. It is not an admin title, and it introduces no separate curator role: the same grant that lets a persona apply everyone's captured insights is what lets it create and edit knowledge pages. A team can hand the capability to the domain expert who should hold it and to nobody else. - The queue reports its own age The review queue carries a staleness rollup: how old its oldest pending item is, and how much has aged past thirty days. It reads the same in the assistant, in the portal, and in the admin screens, and operators are alerted when it crosses a configured threshold. Pending knowledge does not age silently. - Every promotion is a changeset A promotion writes a changeset recording what it actually changed, to which sink, from what previous value. Holders of apply_knowledge can read the changeset list and roll one back, which restores a prior page version or undoes the catalog write. A reviewer with the capability opens a pending insight from the queue and decides it in a side panel. Above the Approve and Reject buttons, an **Observed Now** block checks the claim against the table it names, so the decision is made against what the table looks like at that moment rather than against the capture alone. The three captures below are the three states that block can be in. [Image: The Insight Detail side panel over the review queue, showing a pending Business Context insight about the daily_sales table lagging its source by a day. An Observed Now block names the table on the primary connection and reports it queryable now with an approximate row count. Below are entity URNs, a suggested action, an empty review notes field, and Approve and Reject buttons.] **Observed and consistent.** The table the insight is about exists, is queryable now, and the block reports its current row estimate. The claim itself is not about a count, so there is nothing to compare, and the reviewer decides on the merits. [Image: The Insight Detail side panel showing a pending Correction insight claiming inventory_levels holds 1,140 rows for one warehouse. The Observed Now block reports the table queryable with about 1,200 rows and shows an amber warning that the claim disagrees with the table, noting the difference is advisory only and the decision stands with the reviewer. Approve and Reject buttons remain enabled.] **Claim disagrees with the table.** The insight states a number and the table currently estimates a different one, so the block raises an advisory warning. It does not block approval: an estimate is an estimate, and the reviewer still decides. This is the check that keeps a stale count from being promoted as canonical. [Image: The Insight Detail side panel showing a pending Enhancement insight about the product_catalog table being mastered in an ERP system. The Observed Now block names the table on the warehouse connection and reports it queryable now but notes that this connection does not estimate row counts. Below are entity URNs, a suggested action, and Approve and Reject buttons.] **Observed, no estimate available.** The table is reachable, but its connection does not report row counts, so the block says so plainly instead of implying agreement. The reviewer knows exactly how much the platform could and could not verify before deciding. ### What changes the moment an insight is applied Applied is the moment a fact stops being yours A pending or approved insight is readable only by the person who captured it, because a capture under review is not yet something the organization asserts. Applying it changes that: the fact is written to its canonical sink and becomes findable by **every identified caller** through the one search tool, attributed to whoever captured it. The reach does not depend on which sink it landed in, and it does not depend on the reader already looking at the right table. That matters more than it sounds: a fact that can only be found by the person who taught it is not knowledge the team has, and [our knowledge-use study](https://plexara.io/learning/insights/when-agents-use-what-you-teach) is what convinced us to measure the difference rather than assume it. Retracted knowledge goes the other way: a rejected, superseded, or rolled-back insight drops out of ordinary discovery entirely. ### Two places a promotion can land A promoted insight does not have one destination. It has two, and which one it lands in depends on what kind of fact it is. A fact about a specific table or column belongs on that catalog entity, where the next person browsing it will read it. A fact about the business, a definition, a rule, a piece of context that outlives any one table, belongs on a page written for a human to read. The older way of describing this platform only knew about the catalog, and it left a real gap: there was nowhere canonical for the knowledge that does not hang off a single entity. The knowledge-page sink closes it. Two promotion sinks, one promotion Canonical knowledge pages Business and domain facts Durable, human-readable markdown pages with headings, tables, and diagrams. Vocabulary, definitions, runbooks, and the context that does not belong to any one table. If the fact would still be true with the warehouse rebuilt from scratch, it is page knowledge. The DataHub catalog Technical and entity facts Descriptions, tags, glossary terms, domains, owners, and curated queries written onto the catalog entity itself, where the next person browsing that table will read them. If the fact is about a specific table, column, or catalog entity, it belongs on that entity. The class a memory was filed under at capture time suggests a destination; it does not fix one. The sink is chosen at promotion, which is the point where a person is looking at the fact and can tell whether it describes one table or the business. [Image: The portal Knowledge page on its Insights tab with the Review queue selected: summary tiles for pending review with the age of the oldest item, total insights, top category, and applied count, filters for status, category, confidence, and sort order, and a table of insights with created time, age, who captured it, category, confidence, the insight text, and a status badge such as Applied, Rejected, Rolled Back, Pending, or Approved.] The review queue is where a promotion is decided, and the status column is its history. Pending is waiting on a reviewer, Approved has been accepted but not yet written, Applied has landed in a sink, Rejected never will, and Rolled Back was applied and then reversed by its changeset. The Pending Review tile also reports how old the oldest waiting item is. [Image: The Insight Detail side panel for an Applied Data Quality insight about uncategorized items in a product catalog: metadata for who captured it, the persona, category, confidence, and session, the insight text, the entity URNs it is about, a suggested action of type add_owner targeting a dataset, related columns with a relevance rating, review notes, and Approve and Reject buttons.] An applied insight opened from the queue. The Entity URNs and the Suggested Actions table are what tell you which sink it belongs to: this one names two datasets and proposes a catalog write, so it lands on the entity, where the next person browsing that table will read it. A fact with no entity to hang from would go to a knowledge page instead. ### Canonical knowledge pages A knowledge page is the durable, human-readable half of the answer. Where the catalog holds structured metadata about one entity, a page holds the vocabulary, definitions, runbooks, and context that a new teammate would otherwise learn by asking somebody. Pages are the canonical store: the memory and insight queue is where knowledge is provisional, and a page, once it exists, is the version the organization stands behind. Everyone can read pages. Creating, editing, and removing them is gated on the same apply_knowledge capability that gates promotion, which is deliberate: it introduces no separate curator role to administer. What a canonical knowledge page is - Written to be read Formatted markdown with headings, tables, and diagrams, edited in the portal by anyone holding apply_knowledge. Guidance pushes toward many focused, cross-linked pages rather than one sprawling one, and an oversized page gets a suggestion to split. - Versioned on every save Each edit snapshots a version, so the history of a definition is readable and a promotion that went wrong can be rolled back to the text that preceded it. - Searchable by meaning The body is indexed, so a page is findable from a question that uses none of its words. It is one of the sources the single search tool covers, returned grouped alongside catalog hits and memory. - Open to feedback in place A reader can open a thread on the page, anchored to the passage they selected, and the Knowledge hub badges which pages have feedback waiting. - Consolidating, not fragmenting When the agent tries to create a page that closely matches one that already exists, the platform refuses and hands back the candidates, so the next write updates the existing page instead of starting a rival copy of it. ### Pages cite what they are about A page cites what it is about, and the citation answers back A page's **Manual references** panel is where an editor states the page's subject. It attaches assets, collections, prompts, other knowledge pages, and, when a DataHub connection is configured, the catalog's governance vocabulary: glossary terms, tags, and domains. Everything is searched by display name, so attaching the term Net Revenue never means typing the identifier the catalog generated for it. An attached reference renders as a named chip that resolves the entity's current name from the catalog and deep-links to where that entity is managed. And the link runs both ways: each governance entity lists the knowledge pages that reference it, so a steward reading a glossary term sees what has been written about it without going looking. A reference you cannot access is omitted from both directions, so the link graph never leaks the existence of something you were not granted. Once a corpus carries enough of these citations, they add up to a structure no single page shows. [212 - Seeing the shape of what your team knows](https://plexara.io/learning/mcp/the-knowledge-graph) is about reading it. ### All of it on one page in the portal Memory, insights, and canonical knowledge used to live in separate corners of the portal, which made the lifecycle something you had to be told about rather than something you could see. They are now one Knowledge page, with the lifecycle stated in its header. The Catalog sub-tab is the other half of this lesson made browsable: the whole DataHub catalog inside the portal, with tables, context documents, tags, domains, and the business glossary. Governing those vocabularies from the portal is a subject in its own right, and [211 - Governing the catalog without leaving the portal](https://plexara.io/learning/mcp/catalog-governance-in-the-portal) gives it a lesson rather than a paragraph. What matters for this one is that both promotion sinks are reachable from the same page, because they are two halves of one corpus. [Image: The portal Knowledge page: a Memory, Insight, Knowledge header strip above the Knowledge, Insights, and Memory tabs, with unified search returning results grouped by catalog, knowledge pages, insights, and memory] The lifecycle is the page header, not a diagram in a manual. Underneath it, three tabs: **Knowledge** (the default), **Insights** with a pending-review count badged on it, and **Memory**. Inside Knowledge, the sub-tabs are Search All, Knowledge Pages, Catalog, and Changesets, with the last two visible only where they apply. One query fans across every source you can reach and comes back grouped by source with a coverage summary. ### Why this compounds One insight applied to one dataset is a small win. The payoff is in the accumulation: week over week the corpus gets better, which means search surfaces more useful context, which closes [the context gap that otherwise sits between an agent and your data](https://plexara.io/learning/insights/context-gap-in-ai-data-access), which means the agent gets more questions right on the first try, which means more sessions produce something worth capturing. This is [how everyday usage turns into documentation](https://plexara.io/learning/insights/knowledge-application-turns-usage-into-documentation) rather than a documentation project nobody has time for. The knowledge flywheel: one correction, better answers for everyone The payoff is not linear; it compounds. A user correcting a column definition becomes a catalog description that surfaces on every future query against that dataset. An explanation of how the business defines revenue becomes a page that answers the question for someone who was not in the room. An agent-authored query becomes a curated template the next teammate's session finds through [datahub_get_queries](https://plexara.io/learning/mcp/trino-query-analytics-and-insights). A data estate that was barely documented on day one is a documented one by month six, built out of real work rather than out of somebody being assigned to write documentation. ### Where this leads Knowledge persists across users and sessions, and that is exactly what makes governance the decisive question. Who can see which data, who holds apply_knowledge, and what the audit log records are not paperwork; they determine what the agent can actually do. The next lesson covers that layer. Where this leads Knowledge is powerful because it persists across sessions and across people. That is also why the gate on it matters. Who holds apply_knowledge, who can read the data a fact was drawn from, and what the audit log records afterwards are not paperwork; they decide what the agent can actually do. [207 - Governance: personas, access, and audit](https://plexara.io/learning/mcp/governance-personas-and-access) is the next lesson, and it covers that layer directly. ### Key terms Ten terms cover the vocabulary you will meet whenever the subject turns to memory, insights, or knowledge. Three tool names (memory_capture, search, apply_knowledge) are the ones you will see in tool-call logs most often. Key Terms Memory The raw substrate. A workspace-scoped record captured during a session, personal by default, semantically searchable, and filed under a lifecycle class. Distinct from the memory features a frontier client ships, which are provider-hosted and know nothing about your data estate. Lifecycle class (sink_class) The classification a memory is filed under: Preference, Event, Business knowledge, Operational rule, or Schema/entity. The class is why one memory stays yours and another becomes a promotion candidate. Insight A memory that asserts something others would benefit from, raised as a proposal awaiting review. Insights are the one kind of memory that crosses between people, and they cross at the moment they are applied, not when they are captured or approved. Knowledge page The canonical home for business and domain knowledge: a durable markdown page, versioned on every save, searchable by meaning, open to feedback in place, and citing the entities it is about. Every authenticated user can read pages; creating and editing them is gated on apply_knowledge. search The one tool the agent calls to discover anything. A single query fans across the catalog, the governance vocabulary, context documents, knowledge pages, the caller's own memory, applied insights, feedback, saved assets, resources, prompts, API endpoints, and connections, and comes back grouped by source. Reading knowledge is not a separate tool; it is one of the sources search covers. memory_capture The one tool the agent calls to record something learned. It checks the caller's existing memory before writing, so a restatement supersedes the earlier record instead of stacking a near-duplicate beside it, and a reviewed class enters the queue as a pending insight rather than changing anything shared. memory_manage The tool for the life of a memory after it exists: update, forget, list, and the review commands that surface stale or duplicated records. apply_knowledge The tool that reviews the queue, synthesizes approved insights, and promotes them to a sink. Holding it is the capability check behind every review and promote affordance in the portal. Covered again, in its governance context, in [207](https://plexara.io/learning/mcp/governance-personas-and-access). Changeset The record of what one promotion actually wrote, to either sink, including the previous value. Rolling one back restores a prior page version or undoes the catalog write, and is refused when the page has been edited since. Reference and backlink A stored link from a knowledge page to an entity it is about (an asset, collection, prompt, page, or a catalog glossary term, tag, or domain) and the reverse listing on that entity of the pages citing it. Both directions omit anything the reader cannot access. On this page [Previous 205 - Assets: dashboards, reports, and data](https://plexara.io/learning/mcp/assets-dashboards-reports-and-data) [Next 207 - Governance: personas, access, and audit](https://plexara.io/learning/mcp/governance-personas-and-access) ### Related reading product [Product 102 - Tokens and your budget Every LLM interaction is priced and rate-limited in tokens. What a token is, how much text fits a budget, and how to avoid wasting tokens on useful answers.](https://plexara.io/learning/ai-concepts/tokens-and-your-budget) [Product 105 - What is an AI agent? An AI agent is not a chatbot and not magic. It is a short loop (think, call-tool, observe, think again) on top of a language model. Mental model first.](https://plexara.io/learning/ai-concepts/what-is-an-ai-agent) [Product 202 - Your first day with Plexara A new Plexara user gets connected, sends a first question, and platform_info takes over. Walks through day one and how subsequent turns inherit context.](https://plexara.io/learning/mcp/first-engagement) --- # Governance: personas, access, and audit URL: https://plexara.io/learning/mcp/governance-personas-and-access/ > Governance in Plexara is enforced when a tool is invoked, not described in a policy. Personas, default-deny, layered safeguards, and a single audit log. Product 11 min read ## 207 - Governance: personas, access, and audit Governance in Plexara is enforced when a tool is invoked, not described in a policy. Personas, default-deny, layered safeguards, and a single audit log. On this page ### What you will take away from this lesson In [206 - Knowledge: from memory to insights](https://plexara.io/learning/mcp/knowledge-from-memory-to-insights), we covered how memory and the knowledge pipeline persist facts across users and sessions. That power is exactly why governance is the next lesson: once an AI workspace can remember things and write to a shared catalog, the question of who gets to do what stops being paperwork and starts deciding what actually happens. The point of this lesson is not to cover every security feature in detail. It is to give a power user enough of the model that when a tool is missing from your list, or a call is refused, you know why. Governance in Plexara is not a policy document. It is a runtime check that runs before the tool does. Learning Objectives 1. 01 Explain why governance in Plexara is enforced at the point of execution, not documented in a policy and hoped for. 2. 02 Describe a persona: a named role that determines which tools a caller can see and which connections those tools can reach. 3. 03 Name the default-deny posture: a persona is what grants access to the portal and to tools, and every tool call passes an authorization check against the resolved persona before it runs. 4. 04 Read a discovery result knowing that what search, fetch, and list_connections show is scoped by the same connection grants that scope execution, with the count of what was held back stated on the result. 5. 05 Identify the layered safeguards that stack on top of persona filtering: read-only pinning, bucket-prefix scoping, workflow gating, row limits, timeouts, audience-scoped share links, and sandboxed rendering of stored content. 6. 06 Use the error contract: a stable code, a category naming whose fault the failure is, a message, and a hint, so an agent can tell a fixable argument from a denied one from an outage. 7. 07 Understand the single audit log that ties every tool call back to a human user and the persona they acted under, so "who did what" has a real answer. ### 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 [Open index](https://plexara.io/learning/ai-concepts) - [101 What is a Large Language Model? Brilliant at language, blind about your data. Tokens, hallucination, the grounding problem.](https://plexara.io/learning/ai-concepts/what-is-a-large-language-model) - [102 Tokens and your budget Subscription-plan economics, session limits, and Plexara enrichment dedup.](https://plexara.io/learning/ai-concepts/tokens-and-your-budget) - [103 Context, compression, and memory The keep / compress / clear playbook and how memory carries across sessions.](https://plexara.io/learning/ai-concepts/context-windows-and-tokens) - [104 Frontier models, specialized models, and why enterprise AI uses both Three knowledge sources (training, web search, tools). MCP as the exposure protocol.](https://plexara.io/learning/ai-concepts/frontier-models-explained) - [105 What is an AI agent? The think/call-tool/observe loop. Professor's knowledge, child's literalism.](https://plexara.io/learning/ai-concepts/what-is-an-ai-agent) - [110 Is MCP just an API wrapper? MCP as an application layer. Spectrum from thin wrapper to full application server.](https://plexara.io/learning/ai-concepts/mcp-vs-apis) 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. ### Governance runs at execution time, not at catalog time Most data governance in the wild ends up as documentation: a wiki page, a policy document, a spreadsheet of who is supposed to have access to what. The documentation is often correct and frequently ignored. Plexara takes a different approach. Every tool call is checked [at the moment the agent tries to run it](https://plexara.io/learning/insights/governance-at-execution-time), not when the catalog is assembled. The documentation is the runtime behavior. Three things have to succeed for a tool call to execute. The caller has to authenticate. Their persona has to be resolved. The resolved persona has to be authorized to call that specific tool against that specific connection. Any of those three failing causes the call to be refused, and the refusal is logged. No persona check, no tool call. Governance is enforced at execution time, not at catalog time Cataloging a dataset in DataHub does not grant anyone access to its contents. Documenting a policy in a wiki does not stop an agent from calling a tool. Plexara enforces governance at the point a tool is invoked. Every tool call authenticates the caller, resolves the caller's persona, checks whether the persona is authorized to call that tool against that connection, and only then runs. A missing or invalid credential refuses the call. An unauthorized tool is not merely blocked; it is not surfaced to the agent in the first place. ### What a persona actually determines A persona is a named role. The assignment of a persona to a user (or to an API key, for automation) is how Plexara translates identity into capability. The agent never sees raw user identities when deciding whether to call a tool. The agent sees a tool list that has already been filtered through the persona in effect. Power users often wonder why their agent can call some tools but not others, or why a tool they saw in documentation is missing from the list. The persona is almost always the reason. What a persona actually determines - Tool visibility The agent only sees tools the persona is allowed to call. An unauthorized tool is absent from the list, which is the single most effective defense against prompt-injection attacks that try to coax the model into invoking privileged capabilities. The model cannot be persuaded to call a tool it cannot see. - Connection reachability Tools that accept a connection argument (for example, trino_query against a specific catalog) are scoped so only the connections the persona grants are reachable. Connections are granted the same way tools are, by name and by pattern, and a persona reaches a connection its grant list names. A read-only analyst persona might reach the warehouse catalog and not an administrative connection. - Write vs read Write operations are typically restricted to administrative personas. Trino connections can be pinned to read-only at the platform layer, so even if an agent somehow attempts a write, the write is refused before reaching the database. - Knowledge pipeline roles Capture and review of insights (the 206 pipeline) are themselves persona-gated. An analyst can capture insights; a knowledge steward or administrator approves them via apply_knowledge. Separation of duties is enforced at the tool level, not at the honor system. Personas are configured by administrators. platform_info reports the resolved persona at the start of every session, so the agent and the user can both see which role is in effect. [Image: The admin Personas page with the Data Engineer persona open: a persona list on the left, an identity form with name, display name, description, roles, and priority, allow patterns such as trino_*, datahub_*, s3_*, and save_asset, a deny patterns list, and on the right a live permissions preview counting 13 tools allowed and 4 denied, with each tool marked allowed or denied and the pattern it matched.] A persona is exactly what this screen shows: a name, the roles that map users onto it, a priority for when a user matches more than one, and allow and deny patterns over tool names. The live preview on the right is the filtered tool list the agent will be handed, with the pattern each decision came from. Deny is absolute, so the three CRM tools stay denied even though nothing else blocks them. [Image: The admin Personas page in its New Persona state: a form with the name analyst and display name Data Analyst, empty description and roles, priority 0, no allow patterns with a warning that no allow patterns means no tools are reachable, and a permissions preview showing 0 allowed and 17 denied, with quick templates for Administrator, Read Only, Analyst, and Engineer on the right.] A new persona starts with nothing granted. The preview reads 0 allowed, 17 denied, and the form says why: with no allow pattern, no tool is reachable. That is default deny in practice, and the quick templates on the right are starting points an admin widens deliberately rather than a permissive baseline they narrow down. ### What you can see is what you can use A persona names the connections it reaches, and that same list decides what shows up when you go looking. Search a catalog and you get the datasets, connections, and API endpoints your persona can actually reach; the ones behind a connection it does not reach are held back, and the result says how many. A list you can act on end to end is worth more than a complete one you have to guess your way through. The count is the part that does the work. An agent handed a short result set with no explanation concludes the data does not exist and goes off to re-derive it from something else. A result that says "four more, behind connections your persona does not reach, ask your administrator" produces a different next move: the agent tells you what to ask for instead of quietly building a worse answer. Discovery is scoped by the same grants as execution - search Catalog datasets, connections, and API endpoints are returned when they belong to a connection the persona grants. The result carries a withheld count per source and a notice naming the persona and the remedy, so a shorter list reads as "present, and not yours to see" rather than as "does not exist." - fetch A reference behind a connection the persona does not grant comes back as not found. Discovery and citation agree, so following a pointer lands on the same boundary that produced the list. - list_connections The enumeration names the granted connections, and reports the count it held back alongside them. An agent choosing a connection is choosing from the set it can actually use. - Portal search The browser and the agent share one search router, so the inventory a person sees on the portal is the inventory their agent works from. The same notice renders above the results. This is a metadata boundary: it scopes names, descriptions, and inventory. The data behind them was already scoped at the point of the tool call. What it buys the reader is a list that means something, because everything on it is something the persona can act on. ### Grants that can finish what they start A permission model and a working one are different things. A persona can be internally consistent, pass every check, and still leave someone holding half a capability: allowed to find an answer and not to read it. Plexara looks for that shape directly and reports it with the fix attached. A grant that can finish what it starts Some tools work as a pair. search returns pointers and fetch is what reads one, so a persona granted search alone can find that an answer exists and stops there. Plexara checks each persona against the tools the deployment actually registered, at startup and again whenever a persona is written, and reports the persona, the tool that completes the capability, and the exact edit that adds it. The same check covers the pairs behind capture and review: memory_capture wants search so the captured fact is retrievable, and apply_knowledge wants search because the review workflow starts by finding what is already known. It reports rather than refuses, because a deliberately narrow persona is a legitimate configuration. The value is that the narrowing is now a decision someone made on purpose instead of a gap nobody could see: the agent instructions name a tool only when the caller can reach it, so a persona missing fetch is simply never told that reading a result in full is possible. ### Default-deny posture It is tempting to build access control around a permissive default: "if nothing else applies, allow read-only." Plexara goes the other way, treating [least privilege as the starting point](https://plexara.io/learning/insights/closed-by-default-access). Default-deny: a persona is what grants access The fallback when a persona cannot be resolved is not a permissive one. It is no access at all. A missing credential does not fall through to a default role; the session fails to authenticate. A caller whose roles match no persona does not inherit a baseline of read-only tools; the session sees an empty tool list. This posture prevents a whole class of misconfiguration bugs from becoming security incidents: if governance is not configured, Plexara refuses to act. The same rule now governs the portal itself. A person reaches the portal by holding a persona, which means the org-shared knowledge pages and the federated search surface are behind the same boundary as the tools. Authenticating establishes who someone is; a persona is what says what they get. An identity provider will happily issue a token to every account in the directory, and each of those accounts carries the roles you granted it, so access is something an administrator hands out deliberately. A refused person gets a page naming the account that was refused and telling them who to ask. ### Layered safeguards on top of persona filtering Persona filtering is the first layer. Several other layers stack on top of it to narrow what any given tool call can actually do, even when the persona is authorized to call the tool at all. These are runtime caps, not optional suggestions. Safeguards that stack on top of persona filtering - Trino read-only pinning Individual Trino connections can be pinned to read-only mode at the platform layer. Write statements against a pinned connection are refused before they reach the database, regardless of what the agent intended or what the user asked for. Even a misconfigured downstream system cannot be written to through a read-only pinned connection. - S3 bucket-prefix scoping S3 access can be restricted to specific buckets or bucket prefixes. An agent with S3 access cannot browse outside the configured prefixes, which means credentials that are accidentally over-permissioned at the AWS level are still safe at the Plexara layer. - Workflow gating The session gate that requires platform_info as the first call (covered in 202) is a workflow gate. Plexara can enforce similar orderings elsewhere: discovery tools before query tools, insight review before knowledge application, and so on. A misordered call is refused with a structured error that names the missing prerequisite. - Row limits and timeouts Query tools carry default and maximum row limits and per-connection timeouts. These are not advisory suggestions; they are platform-level caps. A runaway query is bounded by the smaller of the persona's limit and the connection's limit, so the blast radius of any single call is finite. - Audience-scoped share links Every share link carries the audience it was made for: the named recipient, any signed-in platform user, or anyone with the link. A share addressed to a person opens for that person; a share addressed to nobody opens for your signed-in users. The wide-open option is one you pick on purpose, and the share dialog says which audience you are choosing before you send. Every route the link reaches runs the same check, and a link that has expired or been revoked stops opening. Responses behind that check stay in the browser they were served to instead of a shared cache. - Sandboxed rendering of stored content Uploaded and shared files render in isolation. A spreadsheet, a PDF, or an HTML report opens and displays as itself, and nothing inside it can act on the platform or on the session viewing it. This holds for every stored file the platform serves, so accepting a document from a colleague or a client is a document decision rather than a security one. ### Two gates on a catalog write The catalog is the one place in the portal where ordinary use includes writing: a table gets a better description, a tag gets defined, a glossary term gets retired. Those edits go through the same tools an agent would call, so they get the same treatment. Two things have to be true, and both are checked on the server no matter what the interface shows. Two gates on every catalog write - The persona grants the tool Creating a tag, editing a description, or retiring a glossary term is the datahub_create, datahub_update, or datahub_delete tool doing the work, whether the request came from an agent or from someone clicking in the portal. The persona has to grant that tool by name. - The connection accepts writes The specific DataHub connection being written to has to be configured as write-enabled. A connection set to read-only serves the same catalog for reading and declines the write, so a persona with full tool grants still cannot change a catalog that is meant to be read. Both checks run on the server, whatever the interface rendered. When either gate is closed, the portal shows the same catalog with the editing controls absent, so the screen and the rule agree. Every write that does go through is recorded in the audit log with the person and the persona behind it. ### Arguments are checked against the schema, not accepted on faith The safeguards above bound what a tool call can reach. This one bounds what a tool call can claim to have done. It is worth its own section because the failure it prevents is the kind nobody catches by reading the output. An argument the tool does not define is an error, not a shrug Every tool publishes an input schema, and an argument that schema does not name fails at the tool boundary before the handler runs. The error names the offending property, so an agent that passed parameters where the tool wanted query_params is told exactly that and can correct it on the next call. The reason this matters is the failure it replaces. A filter that is quietly dropped produces a result that looks right: the query runs, rows come back, and the agent reports an answer for the whole table while believing it applied a restriction. Refusing the call turns an invisible wrong answer into a visible, fixable mistake. Maps that carry a foreign namespace stay open on purpose, because the keys inside query_params, headers, and a request body belong to the upstream API rather than to the tool. ### The error contract: an agent that knows the difference Governance is only half useful if a refusal is indistinguishable from an outage. An agent that reads "request failed" has three plausible responses and no way to pick: retry the call, rewrite the arguments, or tell the user the platform is down. Two of those are wrong, and the wrong one wastes the user's time or misreports the state of the system. So every failed tool call in Plexara reports the same shape. A stable code the agent can branch on. A category naming whose fault the failure is. A message describing the specific failure, and a hint naming the corrective action when there is one. The category is the field that changes agent behavior: it is the difference between fixing a typo in an argument and telling you that your persona does not carry a capability and who to ask about it. Every failure names whose fault it is | Category | Whose fault | What to do about it | | --- | --- | --- | | client_input | The call | Fix the arguments and retry. | | not_found | The call | The named thing does not exist; correct the reference. | | authentication_failed | The caller's identity | Provide valid credentials. | | authorization_denied | The caller's identity | The persona does not carry this; ask an administrator for access. | | user_declined | The user | A consent prompt was declined. Nothing to fix. | | setup_required | Session state | Call the prerequisite tool first, then retry. | | feature_unavailable | Deployment configuration | The feature is not enabled here. Say so; do not report it as an outage. | | internal | The platform | Not the caller to fix. Retrying with different arguments will not help. | | tool_error | Unclassified | A tool failure with no finer category. The message still describes it. | Alongside the category, every failure carries a stable code the agent can branch on, a message describing the specific failure, and a hint naming the corrective action when there is one. The category is recorded on the audit log too, so an operator can ask how many refusals last week were denials and how many were bad arguments. ### Identity: the step before everything else Authorization only makes sense if the system knows who is asking. Plexara [integrates with enterprise identity providers](https://plexara.io/learning/insights/enterprise-authentication-and-isolation) rather than maintaining its own user store, which keeps governance aligned with whatever access decisions the organization already makes in other systems. Identity: how Plexara knows who you are before resolving your persona Before any persona can be resolved, the caller has to be authenticated. Plexara supports enterprise identity providers (OIDC, OAuth 2.1 with PKCE) and managed API keys for automation. Identity is the input to persona resolution; persona is the input to tool and connection authorization. Every tool call is a three-step check: authenticate, resolve, authorize. Any step failing refuses the call. [Image: The admin Users page: a description explaining that anyone who signs in is recorded automatically and others can be added by email so they can be shared with before they log in, an Add User button, a search box by name or email, and a table of users with name, email, an Active status badge, last seen date, and edit and delete actions.] The Users screen is the directory of people the platform knows. It is not a separate login system: someone who signs in through your identity provider appears here automatically, and an admin can add a colleague by email ahead of their first sign-in so assets and prompts can be shared with them before they log in. [Image: The admin Keys page: an API Keys panel with an Add Key button and a table of keys with name, the email they belong to, a description, a role badge such as admin, viewer, data_engineer, or regional_director, an expiration date or Never, and a Delete action, with one expired key struck through.] API keys are identity for automation: a pipeline, a BI tool, or a service account calls Plexara with a key instead of a person signing in. Each key carries a role, so persona resolution works the same way it does for a user, and each key has an expiration and a named owner. An expired key stays visible, struck through, so what it used to be able to do is never a mystery. ### The audit log: a single record with user identity attached Every tool call produces an audit record. The record is written by Plexara, not by the downstream database, which means it carries the human identity through. A typical database log sees a service account connecting from the platform; the Plexara log sees the actual user whose session produced the call. The practical value of this shows up in investigations. 'Who ran this query at 2am Tuesday' is an answerable question at the Plexara layer. 'Which persona did they act under when they ran it' is answerable in the same log entry. Every tool call is logged with user identity attached - Authenticated user The human user the session belongs to, via the identity provider. Not a service account; the actual person who initiated the session. - Resolved persona The persona in effect for the session. If a user has more than one persona available and chose one explicitly, that choice is recorded. - Tool invoked and arguments The tool name, the connection it ran against, and the arguments passed to it. Redaction rules can be applied to sensitive argument fields. - Outcome and duration Success, refusal, or error. How long the call took. The kind of information that turns "the query seemed slow" into something investigable. Database-level logs see a service account; the Plexara log sees the human. The combination of the two (platform log plus downstream database log) closes the loop on “who ran this query.” [Image: The admin Dashboard on its Events tab: a search box, filters for user, tool, toolkit, source, and status, Export CSV and Export JSON buttons, and a table of tool calls with timestamp, user email, tool name, toolkit, source, connection, duration, an OK status badge, and an Enriched column.] The audit log as the admin section shows it. Every row is one tool call, and the User column carries the person’s own identity next to the tool, the connection it ran against, and how long it took. Filtering by user and tool is how the two-in-the-morning question gets answered, and the export buttons hand the same rows to whatever investigation needs them. [Image: The Event Detail side panel over the audit events table, showing one Trino Query call: the event id, timestamp, user email, the persona data-engineer, tool, toolkit, connection, duration, a Success status, whether it was enriched, session id, request and response sizes, the exact SQL parameters the call ran with, and a Replay in Inspector button.] One record, opened. The persona the user was acting under sits beside their identity, and the parameters block holds the exact SQL that ran. That is the whole answer to “who ran this, as what, and what did they run” in one place, with Replay in Inspector to run it again and see what they saw. ### What governance looks like when you are the user Governance is mostly invisible when it is working. The rare times it shows up are exactly the ones where the user needs to understand it: a tool is missing from the agent's list, a search result carries a count of what it held back, a call gets refused with a category naming why, a query completes but returns fewer rows than expected because a row-limit cap kicked in. What this looks like when you are the one using the system In practice, governance rarely surfaces as a dramatic refusal. It shows up as a slightly shorter tool list, an answer that stops at what your persona can reach, or the occasional structured error that points at a missing prerequisite. If you find yourself asking “why can the agent not do X,” the answer almost always lives in the persona configuration or a connection-level cap, not in the model. Your administrator can widen what the persona covers if the business case is there. ### Where this leads Governance is the last of the subsystem-level lessons. The remaining lessons in the 200 series cover the two MCP primitives the series has not yet dug into: reusable prompts and reference resources. Then 210 closes with a worked end-to-end example that brings everything together. Where this leads With governance covered, the remaining three lessons are about the MCP primitives a Plexara server can also expose beyond tools: reusable prompts and reference resources. The next lesson picks up with prompts. [208 - The prompt library: versioned, shared, and measurable](https://plexara.io/learning/mcp/mcp-prompts-reusable-prompts). ### Key terms Ten terms cover the vocabulary of Plexara governance. Persona and default-deny are the two that show up in day-to-day conversations; the rest are the supporting mechanisms. Key Terms Persona A named role, assigned per user (or per API key), that determines which tools the caller can see and which connections those tools can reach. Resolved at the start of every session; reported in platform_info. Default-deny The posture that access comes from a persona and from nothing else. A caller whose roles match no persona reaches no tools and no portal, so misconfiguration becomes an access refusal rather than a permissive fallthrough. Connection A configured backend a tool can reach: a Trino catalog, a DataHub instance, an S3 bucket, or similar. Personas authorize tools against specific connections, not just tools in the abstract. Connection grant The list of connections a persona reaches, matched by name or pattern. It scopes both halves of using the platform: what a tool call can reach, and what search, fetch, and list_connections show. A connection outside the grant is outside both. Withheld count The number a discovery result reports alongside what it returned, naming how many items the persona did not reach and what to ask for. It is the difference between "nothing matched" and "matches you may not see." Error category The class on every failed tool call naming whose fault the failure is: client_input, not_found, authentication_failed, authorization_denied, user_declined, setup_required, feature_unavailable, internal, or tool_error. Carried alongside a stable code, a message, and a hint, and recorded on the audit log. Write-enabled connection A connection configured to accept changes. A catalog write needs both this and the matching tool grant on the persona, both checked on the server whatever the interface rendered. Workflow gate A required ordering between tool calls enforced at the server. The platform_info-first gate is the best-known example; other gates can enforce discovery before query, review before apply, and similar. Audit log The single log that records every tool call with the authenticated user, the resolved persona, the tool and connection, the arguments, and the outcome. Plexara-side, not database-side, so the human identity is preserved. Identity provider IdP The system that authenticates the caller before persona resolution runs. Plexara integrates with enterprise IdPs via OIDC and OAuth 2.1 with PKCE, and supports managed API keys for automation. On this page [Previous 206 - Knowledge: from a memory to something the whole team can use](https://plexara.io/learning/mcp/knowledge-from-memory-to-insights) [Next 208 - The prompt library: versioned, shared, and measurable](https://plexara.io/learning/mcp/mcp-prompts-reusable-prompts) ### Related reading product [Product 102 - Tokens and your budget Every LLM interaction is priced and rate-limited in tokens. What a token is, how much text fits a budget, and how to avoid wasting tokens on useful answers.](https://plexara.io/learning/ai-concepts/tokens-and-your-budget) [Product 105 - What is an AI agent? An AI agent is not a chatbot and not magic. It is a short loop (think, call-tool, observe, think again) on top of a language model. Mental model first.](https://plexara.io/learning/ai-concepts/what-is-an-ai-agent) [Product 202 - Your first day with Plexara A new Plexara user gets connected, sends a first question, and platform_info takes over. Walks through day one and how subsequent turns inherit context.](https://plexara.io/learning/mcp/first-engagement) --- # The prompt library: versioned, shared, and measurable URL: https://plexara.io/learning/mcp/mcp-prompts-reusable-prompts/ > Two buckets, collections and facets, version history with approval provenance, attached materials, and running a prompt by whatever handle you know it by. Product 16 min read ## 208 - The prompt library: versioned, shared, and measurable Two buckets, collections and facets, version history with approval provenance, attached materials, and running a prompt by whatever handle you know it by. On this page ### What you will take away from this lesson A prompt starts as one person's careful instruction and ends as something a team depends on. Between those two states sit the questions that decide whether the library is worth having. Who else can run this? Which version did they get? Who approved that version? Has anyone run it since March? Is the report template it fills the current one? In [207 - Governance: personas, access, and audit](https://plexara.io/learning/mcp/governance-personas-and-access), we covered the runtime checks that decide which tools a caller can reach. This lesson is the mechanism behind the prompt library: how it is organized, how a change to a shared prompt is reviewed before anyone is served it, how usage is measured, and how the agent resolves a prompt from whatever name the user happened to use. Learning Objectives 1. 01 Read the two buckets the library opens on: My Prompts, everything you own plus everything shared with you, and Library, the approved team prompts grouped by collection. 2. 02 Organize a library with collections, and narrow one with the collection, tag, status, owner, and usage facets. 3. 03 Read the run count and last-run age on every row, and say what a never run or unused 60d+ badge is actually claiming. 4. 04 Read a version history: author, timestamp, status, and the approver bound to one specific version, and say what a pending draft changes for the people reading the prompt. 5. 05 State what a Library reader can and cannot see of a prompt whose latest draft is still in review. 6. 06 Explain why material attached to a prompt is used as given rather than paraphrased, and which resources may be attached to which prompts. 7. 07 Run a prompt by whatever handle you happen to know it by, and recognize scope prefixes as a serve-time detail you never type. ### 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 [Open index](https://plexara.io/learning/ai-concepts) - [101 What is a Large Language Model? Brilliant at language, blind about your data. Tokens, hallucination, the grounding problem.](https://plexara.io/learning/ai-concepts/what-is-a-large-language-model) - [102 Tokens and your budget Subscription-plan economics, session limits, and Plexara enrichment dedup.](https://plexara.io/learning/ai-concepts/tokens-and-your-budget) - [103 Context, compression, and memory The keep / compress / clear playbook and how memory carries across sessions.](https://plexara.io/learning/ai-concepts/context-windows-and-tokens) - [104 Frontier models, specialized models, and why enterprise AI uses both Three knowledge sources (training, web search, tools). MCP as the exposure protocol.](https://plexara.io/learning/ai-concepts/frontier-models-explained) - [105 What is an AI agent? The think/call-tool/observe loop. Professor's knowledge, child's literalism.](https://plexara.io/learning/ai-concepts/what-is-an-ai-agent) - [110 Is MCP just an API wrapper? MCP as an application layer. Spectrum from thin wrapper to full application server.](https://plexara.io/learning/ai-concepts/mcp-vs-apis) 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. ### What a prompt is, and what it carries In the Model Context Protocol, a prompt is a named, reusable instruction the server advertises to the client. The server defines it once, along with the arguments it accepts, and any session can invoke it. That is the protocol-level definition and it is worth holding on to, because everything else in this lesson is what Plexara adds around it: an organization model, a review gate, a usage record, and reference material. The useful mental model is not a saved message. It is a written procedure. A prompt composes several tools into a predictable sequence that produces a predictable output shape, so two people running it on two different topics both get correctly shaped answers without either of them re-describing the workflow. What a prompt record carries - Name The stable identifier, like daily-sales-report. Personal names are unique per owner, so two people can each keep a prompt called report without colliding. - Display name The human-readable label, like Daily Sales Report. It is a real handle, not decoration: the agent resolves a prompt from its display name as readily as from its name. - Description A sentence on what the prompt produces. It carries weight in relevance search, so a vague description makes a prompt hard to find later. - Arguments Named inputs written into the content as {placeholder}, each with a description and a required flag. The editor extracts them from the body into a typed table as you write. - Content The instruction itself, in markdown. In a well-written prompt this is a procedure: which datasets to pull, how to shape the output, what to flag. - Category, tags, collection The organizing metadata. Tags are free-form and comma-separated; a collection is a shared named group, and a prompt belongs to at most one. Every mutation of the content, display name, description, arguments, or tags snapshots an immutable version with its author. Nothing on this list can be changed without leaving a record of who changed it. ### The library opens on two buckets An earlier version of this surface asked users to think in scopes: was this prompt personal, persona, or global? That is the right model for the system and the wrong one for the person using it, because a scope is an answer to a question about visibility that most users never asked. The Prompts page now opens on the question people do ask. Is this mine, or is it the team’s? Two buckets, not five scopes - My Prompts Every prompt you own, whatever scope it sits at, plus every prompt another person has shared with you, each attributed to the person who shared it. This is the bucket with lifecycle in it. Your own prompts show status badges (draft, approved, deprecated, superseded), and the status facet is offered here rather than in the Library. - Library The approved team prompts you are allowed to see, grouped under the collection each one belongs to, with anything uncollected under a General group. Everything here is approved by definition, so the useful facet is owner rather than status. This is the shared shelf, and it is the same shelf your agent resolves against. The question a person actually has is whether a prompt is theirs or the team's, so that is the split the page makes. Scope and persona mechanics still exist underneath, and they surface where they are the subject: the promote flow and the admin review queue. ### What the Library looks like [Image: The Library bucket of the portal Prompts page, with prompts grouped under the Data Operations, Executive Briefings, Sales Reporting, and General collections, each row showing a run count and a last-run age, and several rows carrying a never run or unused 60d+ badge] The Library bucket, grouped by collection. Daily Sales Report has been run 128 times and was run yesterday. Data Quality Scan has been run seven times and not for three months, which is why it carries an `unused 60d+` badge. Three prompts under General have never been run at all. None of that is visible from reading the prompts themselves. ### Collections group the shared shelf A flat list of forty approved prompts is a list nobody reads. Collections are the grouping the Library uses instead: named groups by team, domain, or workflow, with a General group holding whatever has not been placed. How collections behave - Anyone can create one Collections are named groups by team, domain, or workflow, and creating one is not an admin action. Renaming and deleting are limited to the collection creator or an admin. - One collection per prompt A prompt belongs to at most one collection, which is what keeps the Library groupable into a single flat set of headings rather than a tree. Owners place their own prompts; admins place shared ones. - Deleting releases, never destroys Deleting a collection moves its prompts to the General group. A collection is an organizing label, so removing the label cannot remove the work it was labelling. ### Managing them [Image: The Manage collections dialog over the Prompts page, listing Sales Reporting, Data Operations, and Executive Briefings with their descriptions and prompt counts, each with rename and delete controls, above a form for naming a new collection] The Collections manager, opened from the button beside the search field. Each collection reports how many prompts it holds, which is the number that matters before deciding to delete one. Behind the dialog, the My Prompts bucket shows the status and sharing detail that the Library bucket does not: an Approved badge, and rows attributed to the colleague who shared them. ### Finding one Search ranks by meaning rather than by substring, and the facets differ between the two buckets on purpose. Each bucket offers the facet that answers a live question in that bucket, and omits the one that does not. Search and facets - Search by meaning Type a phrase and prompts rank by relevance to what you meant, not by literal substring. Results span both buckets: your own prompts at any status, shared prompts once approved, and prompts shared with you matched on name and description. - Collection Narrow to one named group. This is the facet that answers "what does the sales team actually run". - Tag Free-form labels set on create and edit. Useful for the cross-cutting groupings a single collection cannot express. - Status, in My Prompts Draft, approved, deprecated, or superseded. Offered on your own prompts, where lifecycle is a live question. - Owner, in the Library Who owns the shared prompt. In a bucket where everything is already approved, the useful question is whose procedure this is. - Usage Recently used, or never and long unused. The facet that turns the library into something you can prune. ### Usage is a first-class column The failure mode of a prompt library is not that it stays empty. It is that it fills with procedures nobody runs, and nothing on the screen distinguishes the one the sales team depends on every morning from the one somebody wrote in March and abandoned. Both look like a name and a description. Usage is a column, not a report you have to request Every row carries a run count and a last-run age, aggregated from prompt-serve audit events: each time the prompt is fetched over MCP, and each resolved run, counts as a serve. The list sorts by name, by runs, or by last run, and the usage sorts open most-active-first, because the question that sends you to that column is usually which procedures the team is actually leaning on. A dead prompt is flagged with a badge that names the exact condition rather than a vague warning. `never run` means it has been served zero times since it was created. `unused 60d+` means it has been run and then not for at least sixty days. A prompt created within the last week carries no flag at all, because a week-old prompt with no runs is new, not dead, and a library that cannot tell those apart quickly trains people to ignore its badges. The same counts come back on the tool side: `manage_prompt` `get` and `list` report `run_count` and `last_run_at` per prompt, so an agent asked to tidy the library is working from the numbers the portal shows, not a separate estimate. ### Every change is a version, and shared changes are reviewed A prompt other people run is not a document you edit. It is something being served, and changing it changes what a colleague gets tomorrow morning without them being told. The version history is what makes that visible, and the review gate is what stops it happening silently. What a version carries - Author and timestamp Who wrote that version and when. Every mutation of content, display name, description, arguments, or tags snapshots one. - Status Applied, draft, superseded, or rejected. Applied versions are the ones that have been served; the others record what was proposed and what happened to it. - Approval, bound to the version Who approved it and when, attached to that specific version rather than to the prompt. An approval is a statement about a particular text, and it does not carry forward to the next edit. - Diff against current Any version renders as a line diff against the content being served now, so a reviewer reads the change rather than the whole procedure. Editing an approved global or persona prompt does not take effect on save. The edit lands as a pending draft, the prompt page shows a banner naming its author, and every caller keeps being served the approved snapshot until an admin approves the draft. Personal prompts and never-approved drafts version silently, because there is nobody else being served to protect. ### A Library prompt, open [Image: A Library prompt open in the portal: Daily Sales Report with Library and Approved badges, its collection picker, a details panel with name, description, owner and category, an arguments table listing a required date and an optional threshold, the rendered prompt content, and an attached materials panel showing one restricted item] An approved Library prompt. The arguments table is generated from the `{{date}}` and `{{threshold}}` placeholders in the body, and it distinguishes the required one from the optional one. The attached materials panel is reading as a viewer who cannot see the attached resource: it reports that the prompt carries material outside their scope, and stops there. It does not name the file, and it does not show its contents. ### The history, and a pending draft [Image: The version history panel of a prompt: a banner reporting that draft v4 is pending review and readers are served the approved v3, above rows for v4 draft, v3 applied and current with its approver, v2 superseded, and v1 applied with its approver, each offering a diff against the current content] Four versions and one pending draft. The banner states the consequence rather than the state: readers are served the approved v3 until an admin approves v4. Note that v3 and v1 each name their own approver, and that v2 names none, because it was superseded before it was ever approved. Above the history sits the Run from chat panel, whose copyable line is built from the prompt's stable name and its required arguments. ### What a Library reader can and cannot see Version history is visible to anyone who can view the prompt, which raises the question of how much of the editorial record a reader is entitled to. The answer follows one principle: a reader sees what was served, and an admin sees what was written. Who sees which history - The owner, on their own prompt The full history, every version and every status, including drafts nobody else has been served. - A Library reader, on an enabled shared prompt The served history. Applied snapshots in full, and a pending draft as an author and date stub whose content stays private until an admin approves it. - A Library reader, on rejected or superseded drafts Nothing. A draft that was never served to anyone appears only to admins, so the history a reader sees is a record of what they could have received. - Someone a prompt was shared with person-to-person The served content only, with no version history. A direct share hands over a runnable prompt, not the editorial record behind it. The organizing idea is that history is visible to whoever can view the prompt, and that a reader is shown what was served rather than what was written. A rejected draft is an editorial fact about the authoring team, not a fact about the procedure anyone ran. ### Prompts carry their reference material A procedure that says "produce the quarterly summary in the usual format" is not a procedure. The format is the part that matters and it is the part being left out, which is why a prompt can carry the material it depends on: the report template it fills, the checklist it follows, the brand header it embeds, the sample payload it matches. Attachments are links to [managed resources](https://plexara.io/learning/mcp/mcp-resources-templates-and-examples), stored by resource id rather than copied, so editing the uploaded file updates every prompt that attaches it. Because a prompt can travel further than the person who wrote it, the visibility rule is enforced rather than assumed. An attachment must be at least as visible as the prompt carrying it - Global resource Any prompt. - Persona resource, for persona P Personal prompts, and persona prompts scoped to exactly P. - User resource The author's own personal prompts only. The rule is checked when the attachment is made, again when the prompt changes scope, and a third time at serve time against the individual caller. Requesting promotion of a personal prompt that carries a private template is refused with the resource named, rather than promoted into a state where most of its audience gets a broken procedure. ### Attached material is authoritative Attached material is used as given A resolved prompt delivers its materials after the prompt text: text at or below 64 KiB arrives inline as an embedded resource, and anything binary or larger arrives as a link the client reads on demand. What matters is the framing that comes with them. An attached template is to be filled rather than reinvented, and an attached checklist is to be followed. This is the rule that turns a prompt from an instruction into a complete standard operating procedure, because the format is no longer something the agent improvises each time. Attachments are links to managed resources stored by id, so editing the uploaded file updates every prompt that attaches it, and deleting one does not break the prompt: it still serves, and both the result and the portal flag the material as missing. A reader who cannot see an attachment receives the prompt with a note that some materials were not delivered, never their contents and never their names. ### Run it by whatever handle you know Users do not remember prompt names. They remember what the thing does, or roughly what it is called, and they ask for it in those terms: "run the daily sales report". So when a user names a report, a procedure, or a recurring task, the agent does not enumerate the library and guess. It resolves the handle with the `use` command. What manage_prompt use accepts as a handle - The exact name daily-sales-report - The display name, case-insensitively Run the Daily Sales Report - A reference from a search result mcp:prompt: - A description of it, ranked against the library the one that breaks revenue down by region One confident match resolves, and the response carries the rendered content, the argument specs, any required argument still missing, and the provenance the agent needs to say what it is about to do: running Daily Sales Report v4, approved by carol@example.com. An ambiguous handle returns a short ranked candidate list to choose from. It is never an error, and it is never a silent first match. Served over MCP, prompt names are prefixed by scope so they cannot collide across users and personas: `personal-`, `-`, `global-`, and `shared-` for a prompt someone handed you directly. The prefixes are computed at serve time and the stored name stays bare. They are worth recognizing in a tool-call log and are not something anyone types. ### The List Prompts app The portal is one way to look at a library. The other is inside the conversation, in a client that renders [MCP Apps](https://plexara.io/learning/mcp/what-is-an-mcp), where the library can be browsed without leaving the chat. List Prompts, bound to show_prompts In a host that renders MCP Apps, asking to see your prompts calls `show_prompts`, and the built-in List Prompts app renders in the conversation: search-as-you-type over the ranked query, the same My Prompts and Library buckets, the same collection and tag filters and usage sorting, cards carrying version, approval provenance, and run count, and a detail view with a form generated from the prompt's argument specs. Run resolves the prompt through `manage_prompt` `use` with the filled arguments and places the rendered result straight into the chat. The binding is the design decision worth noticing. `show_prompts` performs no data operation at all; its entire job is to render the library for a human who asked to look at their library. `manage_prompt`, the tool that actually resolves, runs, creates, and edits, carries no app and renders nothing. So the agent's routine prompt work never puts a surprise interface in front of you, and a request to browse never has to be inferred from a request to run. The app is presentation only, and it holds no state of its own: it populates itself from the same `manage_prompt` calls whose JSON results are complete on their own in clients that do not render apps. Nothing about the library is only reachable through the picture of it. ### Editing without rewriting A one-line fix is a one-line edit Rewriting a long operating procedure to change one sentence costs output proportional to the document rather than to the change, and every full rewrite is a chance to silently drop an unrelated paragraph. So `manage_prompt` carries the same content verbs as `manage_asset`: `patch` for anchored edits, `locate` and `outline` for finding the part to change, `get_content`, `stats`, and `diff`. Patching does not bypass review. A patch to an approved global or persona prompt produces a pending draft exactly as a full edit would, and the approved snapshot keeps being served until an admin approves it. `diff` with no versions named compares the newest pending draft against the version being served now, which is the comparison a reviewer actually wants to see. ### From personal to shared Everything in the Library started as somebody’s personal prompt. There are three distinct ways out of a personal account, and the difference between them is worth being precise about, because two of them produce a runnable prompt and one produces a document. Three ways a personal prompt leaves your account - Share it with a person Owner-initiated, by email, and no admin approval. The recipient sees it in their My Prompts bucket attributed to you, and their agent can run it with its arguments intact, because a share hands over a real prompt rather than a markdown snapshot. Revoke it any time from the same dialog. - Request promotion to the team Pick one or more personas, or global. The prompt stays personal and carries a Promotion requested badge while an admin reviews it. On approval it moves to the requested scope and becomes a genuinely shared prompt. Requesting is self-service; promoting is admin-only. - Save it as an asset A separate action that exports the content as a markdown asset, for documentation or for sending outside the platform. It produces a document, not a runnable prompt, and it is worth not confusing with sharing. One ownership and publication rule runs across every prompt surface, so the portal, the agent, and the admin review queue agree on who may do what. An admin creating a global or persona prompt is its approver, which is why it lands approved and searchable with the approval already stamped rather than sitting in draft behind its own author. [403 - Sharing prompts, and closing the loop with feedback](https://plexara.io/learning/prompts/sharing-prompts-and-feedback) takes the same ground from the practitioner side. ### The prompts that ship with a deployment Alongside anything a team authors, every deployment advertises a baseline set of workflows: discovery, dashboard building, report generation, lineage tracing, asset management, and [knowledge capture that turns usage into documentation](https://plexara.io/learning/insights/knowledge-application-turns-usage-into-documentation). What ships in the box (from the ACME demo) - `explore-available-data` workflow · arg: topic Search the catalog for datasets related to a topic, present them with descriptions, ownership, and quality scores, and flag deprecation warnings. - `create-interactive-dashboard` workflow · arg: topic Discover the relevant datasets, query them, build an interactive visualization, and save it as a shareable asset. - `create-a-report` workflow · arg: topic Discover the relevant datasets, analyze them, and produce a structured Markdown report with tables, metrics, and conclusions. - `trace-data-lineage` workflow · arg: dataset Trace upstream sources and downstream consumers for a dataset, including column-level lineage where available. - `save-this-as-an-asset` toolkit Identify the key output from the current conversation and save it as a shareable asset with name, description, and tags. - `show-my-saved-assets` toolkit List the assets you have saved, with names, descriptions, tags, and creation dates. - `capture-this-as-knowledge` toolkit Review the conversation for corrections, business context, data quality observations, or newly discovered relationships, and capture each as an insight for the knowledge pipeline. These come from server configuration rather than the database, and they are reported in the prompts array of the `platform_info` response. They resolve through `use` like anything else, and they are read-only to the management commands. They are also worth reading as reference implementations: each one is a numbered procedure rather than a paragraph of intent. ### When to write one Write the prompt the second time you run the workflow The signal is repetition, not complexity. If an analyst runs the same three searches and the same query shape every Monday, that sequence belongs in a prompt taking the date as an argument. If a steward performs the same review on insights for one dataset every month, that belongs in a prompt too. The first run of a hard workflow deserves real thought; the tenth should not need any. Writing it down is also what makes the rest of this lesson apply to it. Once a workflow is a prompt it has a version history, an approver, a run count, and a place in a collection, and the question of whether anyone still uses it stops being a matter of opinion. [401 - Prompts are the new SOPs](https://plexara.io/learning/prompts/prompts-are-the-new-sops) and [402 - Letting the agent write the prompt](https://plexara.io/learning/prompts/letting-the-agent-write-the-prompt) cover the writing itself. ### Where this leads Where this leads This lesson covered the mechanism: buckets, collections, versions, approvals, usage, attachments, and resolution. The 400 series covers the practice, and does not repeat any of it: [401](https://plexara.io/learning/prompts/prompts-are-the-new-sops) on treating a prompt as an operating procedure, [402](https://plexara.io/learning/prompts/letting-the-agent-write-the-prompt) on drafting one with the agent, [403](https://plexara.io/learning/prompts/sharing-prompts-and-feedback) on sharing and feedback, and [404](https://plexara.io/learning/prompts/running-prompts-and-schedules) on running them. Next in this series, the attachments that made a prompt into a complete procedure get a lesson of their own. [209 - Resources: the company files the agent should use, not reinvent](https://plexara.io/learning/mcp/mcp-resources-templates-and-examples). ### Key terms Seven terms cover the vocabulary of the library. Collection, version, and attachment are the ones a user meets on screen; approval provenance, serve event, and scope prefix are the ones that explain what the screen is showing them. Key Terms Collection A named group of prompts, organized by team, domain, or workflow. Any user can create one; renaming and deleting are limited to its creator or an admin. A prompt belongs to at most one, and deleting a collection releases its prompts to the General group. Version An immutable snapshot taken on every change to a prompt content, display name, description, arguments, or tags. Carries its author, timestamp, and status (applied, draft, superseded, rejected). Pending draft An edit to an approved shared prompt that has not yet been approved. It is visible as an author and date stub, and every caller keeps being served the approved version until an admin approves it. Approval provenance Who approved a version and when, bound to that specific version rather than to the prompt. An approval is a statement about one text, so the next edit does not inherit it. Attachment A managed resource linked to a prompt by id: a template, a checklist, a brand file, a sample payload. Delivered with the resolved prompt and framed as authoritative, meaning it is used as given rather than paraphrased. Serve event One fetch or one resolved run of a prompt, recorded in the audit log. The run count and last-run age on every row, and the never run and unused 60d+ badges, are all aggregated from these. Scope prefix The personal-, -, global-, or shared- prefix applied to a prompt name when it is served over MCP, so names cannot collide across users and personas. Computed at serve time; the stored name stays bare and nobody types the prefix. On this page [Previous 207 - Governance: personas, access, and audit](https://plexara.io/learning/mcp/governance-personas-and-access) [Next 209 - Resources: the company files the agent should use, not reinvent](https://plexara.io/learning/mcp/mcp-resources-templates-and-examples) ### Related reading product [Product 102 - Tokens and your budget Every LLM interaction is priced and rate-limited in tokens. What a token is, how much text fits a budget, and how to avoid wasting tokens on useful answers.](https://plexara.io/learning/ai-concepts/tokens-and-your-budget) [Product 105 - What is an AI agent? An AI agent is not a chatbot and not magic. It is a short loop (think, call-tool, observe, think again) on top of a language model. Mental model first.](https://plexara.io/learning/ai-concepts/what-is-an-ai-agent) [Product 202 - Your first day with Plexara A new Plexara user gets connected, sends a first question, and platform_info takes over. Walks through day one and how subsequent turns inherit context.](https://plexara.io/learning/mcp/first-engagement) --- # Resources: the company files the agent should use, not reinvent URL: https://plexara.io/learning/mcp/mcp-resources-templates-and-examples/ > Your templates, brand files, and reference documents, uploaded once and used as-is: which layer a file belongs on, search then fetch, revisions that keep every citation resolving, and making a template mandatory. Product 15 min read ## 209 - Resources: the company files the agent should use, not reinvent Your templates, brand files, and reference documents, uploaded once and used as-is: which layer a file belongs on, search then fetch, revisions that keep every citation resolving, and making a template mandatory. On this page ### 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](https://plexara.io/learning/mcp/mcp-prompts-reusable-prompts), 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 1. 01 Apply 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. 2. 02 Tell 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. 3. 03 Describe 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. 4. 04 State 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. 5. 05 Replace a resource in place and read its version history without breaking a single citation or prompt attachment. 6. 06 Read the usage panel and the Last read column to find the material nothing has touched. 7. 07 Take 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 [Open index](https://plexara.io/learning/ai-concepts) - [101 What is a Large Language Model? Brilliant at language, blind about your data. Tokens, hallucination, the grounding problem.](https://plexara.io/learning/ai-concepts/what-is-a-large-language-model) - [102 Tokens and your budget Subscription-plan economics, session limits, and Plexara enrichment dedup.](https://plexara.io/learning/ai-concepts/tokens-and-your-budget) - [103 Context, compression, and memory The keep / compress / clear playbook and how memory carries across sessions.](https://plexara.io/learning/ai-concepts/context-windows-and-tokens) - [104 Frontier models, specialized models, and why enterprise AI uses both Three knowledge sources (training, web search, tools). MCP as the exposure protocol.](https://plexara.io/learning/ai-concepts/frontier-models-explained) - [105 What is an AI agent? The think/call-tool/observe loop. Professor's knowledge, child's literalism.](https://plexara.io/learning/ai-concepts/what-is-an-ai-agent) - [110 Is MCP just an API wrapper? MCP as an application layer. Spectrum from thin wrapper to full application server.](https://plexara.io/learning/ai-concepts/mcp-vs-apis) 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. [Image: The Upload Resource dialog over the portal Resources page, opening with the positioning statement about resources, assets, knowledge pages and memory, above a category picker set to samples with its one-line explanation, then display name, description, tags, and a file chooser] The upload dialog leads with the same sentence the agent is given, at the one moment it decides anything: while somebody is choosing where to put a file. Under it, the category picker explains itself as you change it. Here `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](https://plexara.io/learning/mcp/what-is-an-mcp), 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. [Image: The portal Resources page on the My Resources tab, listing query templates, dashboard notes, a store list, a weekly report template, lineage notes, backfill helpers, a QBR deck and forecast assumptions, each row showing category, MIME type, tags, file size, uploader and last updated date] The Resources page, on the tab holding one person's own uploads. The tabs beside it are visibility, not folders: material shared with a persona, and material global to the deployment. A file may be any format the library needs, documents through spreadsheets, images, media and archives, with executables refused by both extension and content type. ### 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:. - 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](https://plexara.io/learning/mcp/discovery-search-and-fetch). 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 The protocol methods are still there, as the fallback The Model Context Protocol has its own way to reach this material: `resources/list` enumerates what a caller can see and `resources/read` returns one file by URI. Both are filtered by the same visibility rules as search, and neither is a tool, which is the point: a persona can be denied every tool and still enumerate the material it is allowed to see. So these are not the main path, they are the guaranteed one. An agent that can search finds a template by describing it. An agent that cannot still gets a list. ### 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 Steering, not enforcement Read that section for what it is. It changes what the agent knows to look for. It does not stop an agent from writing a report without checking for a template, any more than a style guide stops a person from ignoring it. That is worth stating plainly because instructions are the easiest thing in this industry to assert and the hardest to prove. Whether steering of this kind changes what an agent produces is a measurement, and we publish ours: the [accuracy study](https://plexara.io/benchmark/accuracy) and the [knowledge-use study](https://plexara.io/benchmark/knowledge-use) both hold the ablations and the raw runs behind them. When steering is not enough, the next section is how you make it a rule. ### 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 1. 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. 2. 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. 3. 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. 4. 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](https://plexara.io/learning/mcp/mcp-prompts-reusable-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. [Image: The SQL Style Guide resource dialog scrolled past its preview to three panels: Usage, showing 46 reads in 30 days and 118 in 90 days split into agent reads, search fetches, and portal downloads; Version history, listing v3 as current and restored from v1, v2, and v1 with download and restore controls and a Replace content button; and an Attached to 1 prompt panel, with Download, Edit, and Delete actions along the bottom] The same resource, scrolled down to the lifecycle panels. **Replace content** adds a version and keeps the link and file name, so every prompt attachment and citation keeps resolving; the restore control beside an older version adds it back as a new one rather than rewriting history. The note under the list says exactly that, in place, where someone about to replace a file will read it. ### One resource, open [Image: A resource open on the admin Resources page: the SQL Style Guide, global and filed under documentation, with its description, MIME type, size, uploader, last updated date, canonical URI, a preview pane offering download, and its sql and standards tags] One resource, open. The URI under the metadata is the stable one a citation resolves through, and it survives every content revision. Below the preview sit the panels this lesson has been describing: the version history, the usage counts, and the list of prompts that attach this file as reference material. ### 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 [Image: The admin Resources page filtered to the data-engineer persona, showing an ETL runbook, a migration checklist, a Trino performance runbook and a data quality query library, with scope, category, type, tags, size, uploader, updated date and a Last read column reading Never on every row] The admin view of the same library, filtered to one persona by the tabs across the top, with the sort set to Recently updated. Every row here reports `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. Attached to a prompt, and used as given The tightest binding between a procedure and its material is an attachment. A prompt's owner, or an admin for a shared one, attaches resources from a searchable picker and orders them, and that order is authored rather than incidental, because it is the order the agent receives them in. Text arrives inline; larger or binary files arrive as links the agent reads on demand. All of it is authoritative: used as given, not paraphrased. [208](https://plexara.io/learning/mcp/mcp-prompts-reusable-prompts) covers the library those prompts live in. Two rules constrain the binding. An attachment must be at least as widely visible as the prompt, so a private file belongs only on your own prompts and a persona file only on that persona's: attaching something narrower is refused by name, and so is promoting a prompt still carrying it. And deleting a resource that prompts depend on does not break them. They keep serving and report the material as missing, with the broken link flagged in the prompt viewer for its author to repair. ### Starting a library from nothing Where to start, if the library is empty Upload the thing that gets pasted into a chat most often. That is usually a report template or a data dictionary, and it is the file somebody is already working around by hand. Give it a description that says what it is for, not what it contains, because the description is what a semantic search matches against and what the agent reads when it is deciding whether this is the file the user meant. Then wait a month and sort the library by last read. What nothing has touched either has the wrong description or was never needed, and the two are easy to tell apart once you ask. ### Where this leads Where this leads Tools, prompts, and the material both of them lean on. The 200 series closes with a worked example that threads a single real question through every piece at once. [210 - Putting it all together: a worked end-to-end example](https://plexara.io/learning/mcp/tool-survey). For the practitioner side of the same material, the [300 series opens with producing a report or dashboard](https://plexara.io/learning/assets/creating-reports-and-dashboards) and saving it, which is the moment an approved template either gets used or does not. ### 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: 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. On this page [Previous 208 - The prompt library: versioned, shared, and measurable](https://plexara.io/learning/mcp/mcp-prompts-reusable-prompts) [Next 210 - Putting it all together: a worked end-to-end example](https://plexara.io/learning/mcp/tool-survey) ### Related reading product [Product 102 - Tokens and your budget Every LLM interaction is priced and rate-limited in tokens. What a token is, how much text fits a budget, and how to avoid wasting tokens on useful answers.](https://plexara.io/learning/ai-concepts/tokens-and-your-budget) [Product 105 - What is an AI agent? An AI agent is not a chatbot and not magic. It is a short loop (think, call-tool, observe, think again) on top of a language model. Mental model first.](https://plexara.io/learning/ai-concepts/what-is-an-ai-agent) [Product 202 - Your first day with Plexara A new Plexara user gets connected, sends a first question, and platform_info takes over. Walks through day one and how subsequent turns inherit context.](https://plexara.io/learning/mcp/first-engagement) --- # Putting it all together: a worked end-to-end example URL: https://plexara.io/learning/mcp/tool-survey/ > A capstone that walks a single real-world question through every Plexara subsystem covered in the 200 series, with a tool-by-tool reference at the end. Product 16 min read ## 210 - Putting it all together: a worked end-to-end example A capstone that walks a single real-world question through every Plexara subsystem covered in the 200 series, with a tool-by-tool reference at the end. On this page ### What you will take away from this lesson In [209 - Resources: the company files the agent should use, not reinvent](https://plexara.io/learning/mcp/mcp-resources-templates-and-examples), we closed out the three MCP primitives. Every subsystem in a Plexara MCP has now had its own lesson. This final 200-series lesson is the capstone: a single realistic question walked end to end, with a callout for every subsystem that fires along the way, plus an appendix of every tool a Plexara MCP exposes for when you need it. Nothing here is new. The point is to see the pieces working together in one session rather than one at a time. If a step surprises you, the lesson that introduced that piece is linked right on the step. Learning Objectives 1. 01 Follow one real Plexara session end to end, turn by turn, naming which subsystem fires at each turn. 2. 02 See discovery as the platform actually enforces it: one search across every source, fetch to read a result in full, and a warehouse query that is refused outright until discovery has happened. 3. 03 Watch a result become a durable object: saved with save_asset, corrected in place with an anchored manage_asset patch rather than a regeneration, and recorded with memory_capture for the Memory to Insight to Knowledge path. 4. 04 Pick from three styles of prompting (high-level, prompt-by-name, tool-by-name) and know when each is appropriate. 5. 05 Use the tool directory at the end as the reference it is: every tool the Plexara MCP exposes, grouped by toolkit, with badges that flag writes, admin-only operations, and the mandatory first call. 6. 06 Find any subsystem again from the series index: the eleven other 200-series lessons, plus the apps surface a tool result can carry. ### 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 [Open index](https://plexara.io/learning/ai-concepts) - [101 What is a Large Language Model? Brilliant at language, blind about your data. Tokens, hallucination, the grounding problem.](https://plexara.io/learning/ai-concepts/what-is-a-large-language-model) - [102 Tokens and your budget Subscription-plan economics, session limits, and Plexara enrichment dedup.](https://plexara.io/learning/ai-concepts/tokens-and-your-budget) - [103 Context, compression, and memory The keep / compress / clear playbook and how memory carries across sessions.](https://plexara.io/learning/ai-concepts/context-windows-and-tokens) - [104 Frontier models, specialized models, and why enterprise AI uses both Three knowledge sources (training, web search, tools). MCP as the exposure protocol.](https://plexara.io/learning/ai-concepts/frontier-models-explained) - [105 What is an AI agent? The think/call-tool/observe loop. Professor's knowledge, child's literalism.](https://plexara.io/learning/ai-concepts/what-is-an-ai-agent) - [110 Is MCP just an API wrapper? MCP as an application layer. Spectrum from thin wrapper to full application server.](https://plexara.io/learning/ai-concepts/mcp-vs-apis) 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. ### A single realistic question Every lesson in the 200 series has described one subsystem. That is a sensible way to teach, but it is not how the subsystems show up in a real session. This capstone picks one ordinary analyst question and watches the subsystems work together turn by turn. The scenario A new analyst at ACME Corp opens Claude Desktop. The workspace already has Plexara connected. Their persona is analyst: read access to the warehouse and opensearch connections, the portal tools for saving their own work, and no administrative tools. Their first question of the session: “For ACME Corp, what were Q3 2025 sales by region, and which region saw the biggest change from Q2? Save the analysis as a dashboard.” ### Turn by turn: what happens inside Plexara The ten steps below walk through what happens between the moment the user hits enter and the moment a dashboard link comes back. Governance, platform_info, one search across every source, fetch, the search-before-query gate, a curated query template, enrichment on a byte budget, an asset and its anchored correction, and the memory that outlives the session are all present in this trace. This is a transcript, not a diagram. Every step below was run against a live Plexara deployment, in the order shown, and the details are what came back: the sources search reached, the knowledge page that changed the answer, the runtimes, the version number the patch produced. Where reality differed from the tidy version, reality is what is written down. What happens, turn by turn, inside Plexara 1. Step 01 User sends the first question Governance scopes the session [Governance: 207](https://plexara.io/learning/mcp/governance-personas-and-access) The question names ACME Corp, the entity cue that tells the agent this particular MCP is the right place to look. Without it, the agent might answer about retail sales at large. The persona attached to this user decides which tools exist for the rest of the session. 2. Step 02 Agent calls platform_info first platform_info session gate [First day: 202](https://plexara.io/learning/mcp/first-engagement) Every other tool is refused until platform_info has been invoked, so the agent calls it first. Back comes the ACME operating manual (the data estate, the query rules, the prompt library) and a session handle the agent then carries on every subsequent call. A call without the handle is refused. 3. Step 03 One search, every source the persona can reach Discovery across every source [Discovery: 203](https://plexara.io/learning/mcp/discovery-search-and-fetch) A single search call comes back with hits from nine sources at once: the catalog, the governance glossary, knowledge pages, this user’s memory, captured insights, saved assets, uploaded resources, prompts, and API endpoints. Results are grouped by source with a coverage summary saying how many each source matched against how many are shown, so nothing gets crowded out by a source that happened to rank well. 4. Step 04 fetch reads one result in full, and it changes the answer fetch, and knowledge paying off [Discovery: 203](https://plexara.io/learning/mcp/discovery-search-and-fetch) Among the hits is a knowledge page called ACME Fiscal Calendar. The agent passes its reference to fetch and reads the whole page: ACME’s fiscal year starts February 1, so fiscal Q3 is August through October, not July through September. The question the user asked has a different answer than it appeared to. Nobody had to tell the agent this; it was recorded once and found by search. 5. Step 05 The query would have been refused without step 03 Search-before-query gate [Governance: 207](https://plexara.io/learning/mcp/governance-personas-and-access) Discovery before query is enforcement, not advice. Had the agent gone straight to trino_query, the tool handler would never have run: the platform short-circuits with a SEARCH_REQUIRED result telling it to search first. That is why the agent searched, and why an ungrounded guess at the data’s shape is not a path the agent can take. 6. Step 06 The curated query template, not a query from scratch Curated query templates [Trino and curated queries: 204](https://plexara.io/learning/mcp/trino-query-analytics-and-insights) datahub_get_queries on the matched dataset returns six benchmarked templates, one of which is a region-by-month revenue cross-tab with its measured runtime recorded on it. The agent adapts that template to the fiscal window rather than authoring an aggregation of its own. 7. Step 07 The query runs; business context rides along Cross-enrichment on a budget [Token economics: 102](https://plexara.io/learning/ai-concepts/tokens-and-your-budget) The aggregation returns both fiscal quarters, by region, in well under a second. Attached to the result is the catalog’s context for the tables it touched: description, domain, and the glossary definition of Sales Region. That context runs on a byte budget with a summary-first layout, so it stays a compact header on the answer instead of pushing the data out of the window. 8. Step 08 The dashboard is saved, not pasted Assets, with provenance [Assets: 205](https://plexara.io/learning/mcp/assets-dashboards-reports-and-data) The user asked for a dashboard. The agent calls save_asset with the HTML directly rather than printing it into the chat and saving it afterwards, which would mean generating it twice. The portal returns a link and records provenance: the exact tool calls that produced this asset, attached to it. 9. Step 09 A small correction, patched in place Anchored edits, versioned [Assets: 205](https://plexara.io/learning/mcp/assets-dashboards-reports-and-data) Reading it back, the analyst wants the biggest percentage mover named alongside the biggest dollar mover. That is a manage_asset patch: one anchored edit on the sentence in question, which lands as version 2 with a one-line diff. The rest of the dashboard is untouched and never re-sent. An anchor that matches nothing, or matches twice, refuses the whole call rather than guessing. 10. Step 10 What the session learned, kept Memory to Insight to Knowledge [Knowledge: 206](https://plexara.io/learning/mcp/knowledge-from-memory-to-insights) Along the way the agent found that a date filter on this index needs a full timestamp, not a bare date, and proved it by running both. memory_capture records that against the dataset. Because it is a fact about a dataset rather than a personal preference, it enters review as an insight instead of going live, and the response names the near-duplicate already on file so the reviewer consolidates rather than stacking a second copy. Memory becomes an Insight, and an Insight that survives review becomes Knowledge every future session can find. The user sees the answer, the dashboard link, and a short conversation. Every step above happened in support of that one exchange, and this trace is the sequence a real session produced rather than an idealized one. ### Three styles of prompting The trace above used a high-level prompt: the user described the goal and the agent worked out the steps. That is the right default for most work. Two other styles are worth knowing about: invoking a named prompt from the library, and naming specific tools directly. Each has a place. Three styles of prompting, and when to use each 1. 01 High-level: describe the goal When: Most of the time. The agent picks the right tools, respects the operating manual, and produces a grounded answer. "For ACME Corp, what were Q3 2025 sales by region, and which region saw the biggest change from Q2? Save the analysis as a dashboard." 2. 02 Mid-level: name a prompt When: When a repeatable workflow already exists in the prompt library. Shorter to type; the output shape is predictable. "Run create-interactive-dashboard for Q3 sales by region." Takes topic and applies the template consistently. 3. 03 Low-level: name specific tools When: When you already know exactly what you want. Forces a specific path that the agent would otherwise have to reason its way to. "Call datahub_get_queries for the os_acme_transactions URN, run the region-by-month cross-tab template for fiscal Q3, and write the rows straight to a CSV asset with trino_export." There is no “best” style. The right level is the one that matches what you already know. A new user benefits from high-level prompting and lets the agent figure it out; a power user reaches for tool-by-name only when they want to short-circuit. ### Closing the loop That is the curriculum. Ten lessons in the 100 series, ten in the 200 series, and one worked example that tied them together. The subsystems are not exotic individually; the compounding value comes from [having all of them running at the same time](https://plexara.io/learning/insights/when-an-agent-can-see-the-whole-stack), under governance, with memory and knowledge closing the loop each session. Where to go from here That is the trace end to end. If any step in it surprised you, follow the lesson link on that step and revisit the subsystem in depth. Two of them are worth reading next on their own account. The trace turned on a catalog that already said what things mean, and [211 - Governing the catalog without leaving the portal](https://plexara.io/learning/mcp/catalog-governance-in-the-portal) covers who keeps it that way and where. It also turned on a knowledge page nobody in the session had written, and [212 - Seeing the shape of what your team knows](https://plexara.io/learning/mcp/the-knowledge-graph) shows that body of knowledge drawn as the network it is, so you can see which parts of it hold the rest together and which citations do not resolve. If you want the broader editorial arguments (why Plexara exists, how it fits into the larger enterprise-AI conversation), the [Insights](https://plexara.io/learning/insights) collection is the companion to this curriculum. And when you come back to a real session with a real question, start with the high-level prompt and work down to more explicit styles only when you need to. [Image: The portal Assets page: Assets and Collections tabs, Mine, Shared, and All filters, a search box, a type filter, a tag filter, and a grid of asset cards each with a rendered preview, a title, a description, a content type badge such as text/html, image/svg+xml, or text/markdown, tags, a size, and a date, one carrying a feedback count.] Where the worked example ends up. The dashboard, the pipeline chart, and the inventory report from sessions like the one above sit here as assets, each previewed, typed, and tagged, findable by anyone they were shared with. The session closes; the work does not disappear with it. [Image: The portal Feedback page: Recent, Worklist, and General tabs, a New feedback button, and a list of feedback threads each naming the asset, collection, or knowledge page it is about, a title, a type badge such as Correction, Question, or Suggestion, a status badge such as Open, Answered, or Resolved, who raised it, and a reply count.] Feedback is how the loop closes on the human side. A correction on a dashboard, a question about where a column comes from, a suggestion for a collection: each one is a thread attached to the thing it is about, with a status, and the corrections are the raw material the next capture turns into memory and, once reviewed, into knowledge. ### The 200 series, in one place This lesson is also the index. Each row below is the subsystem lesson behind one part of the trace, and the two at the end cover ground the trace only leaned on: who curates the catalog the search reads from, and what the accumulated body of knowledge looks like once you can see its shape. One surface the trace did not show is the interactive one. A tool result can carry a reference to a small interface, and a client that knows how renders it beside the answer instead of narrating it: the prompt library as something you browse rather than something read aloud, the deployment summary as a panel rather than a paragraph. Plexara ships two of these, and [201 covers what they are and why they stay presentation-only](https://plexara.io/learning/mcp/what-is-an-mcp). 200 Series: the platform, subsystem by subsystem [Open index](https://plexara.io/learning/mcp) - [201 Anatomy of a Plexara MCP The tool inventory, the four content layers, and the two apps a tool result can carry.](https://plexara.io/learning/mcp/what-is-an-mcp) - [202 Your first day with Plexara Connecting, the first question, and the operating manual platform_info hands over.](https://plexara.io/learning/mcp/first-engagement) - [203 Discovery: one search, then fetch One query across every source, grouped with a coverage summary. fetch reads one in full.](https://plexara.io/learning/mcp/discovery-search-and-fetch) - [204 Trino Query: analytics and insights Curated query templates, the shape of a fast aggregation, and exporting large results.](https://plexara.io/learning/mcp/trino-query-analytics-and-insights) - [205 Assets: dashboards, reports, and data Output that persists outside chat, with provenance, versions, and anchored edits.](https://plexara.io/learning/mcp/assets-dashboards-reports-and-data) - [206 Knowledge: from a memory to something the whole team can use Memory to Insight to Knowledge: the three stages, the review gate, the two homes.](https://plexara.io/learning/mcp/knowledge-from-memory-to-insights) - [207 Governance: personas, access, and audit Enforcement at invocation time rather than policy on paper, and one audit log.](https://plexara.io/learning/mcp/governance-personas-and-access) - [208 The prompt library: versioned, shared, and measurable Two buckets, version history with approval provenance, and running a prompt by any handle.](https://plexara.io/learning/mcp/mcp-prompts-reusable-prompts) - [209 Resources: the company files the agent should use, not reinvent Templates and brand files uploaded once, found by search, read in full by fetch.](https://plexara.io/learning/mcp/mcp-resources-templates-and-examples) - [211 Governing the catalog without leaving the portal Who keeps the catalog worth searching, and where they do that work.](https://plexara.io/learning/mcp/catalog-governance-in-the-portal) - [212 Seeing the shape of what your team knows The knowledge corpus drawn as its reference network, and what its shape tells you.](https://plexara.io/learning/mcp/the-knowledge-graph) 210 is the lesson you are reading. Every other row is a subsystem the trace above touched, covered in depth. ### Appendix: the tool directory The rest of this lesson is reference material. Plexara groups its tools into eight toolkits. Every tool name below is the exact identifier the agent would invoke. Most tools are read-oriented and side-effect-free; writes and administrator-only operations are flagged. You do not need to memorize this directory. The point of the trace above was that the agent chooses tools on your behalf. Scan this section when you want to know what is possible, or when you need to name a specific tool in a prompt. Toolkits 8 Tools 42 Write-capable 17 Mandatory first call 1 ### Platform The session gate, the connection list, and the tools about the toolbox itself. platform_info is mandatory as the first call in every session and is backed by a runtime session gate (202); platform_find_tools ranks the tool list by intent so the agent can locate a capability without reading every description. - `platform_info` Mandatory first call Session-gated Returns the deployment description, tags, toolkits, feature flags, persona, portal URL, prompts library, and the agent_instructions operating manual. Issues the session handle every subsequent call carries. Runtime-enforced by a session gate that refuses every other tool in the deployment until platform_info has been invoked in the current session. - `list_connections` Lists the configured data connections across every toolkit (Trino catalogs, DataHub endpoints, S3 buckets, API gateways) with their name, kind, and type. Each connection arrives with a bounded sample of the canonical knowledge pages documenting it, so the agent learns what a backend is for and not only that it exists. - `platform_find_tools` Ranks the platform’s own tool list against a plain-language description of a task, so the agent can find the right tool by intent instead of reading three dozen tool descriptions. Persona-scoped at read time: it never returns a tool the caller could not call. Ranks on meaning rather than keyword overlap, so "find out where this number came from" reaches the lineage tool without naming it. - `manage_prompt` Writes Resolve and run a prompt by any handle (name, display name, reference, or free text) with the use command, plus create, update, delete, list, and get. Carries the content verbs (patch, locate, get_content, outline, stats, diff), so editing a long prompt is an anchored patch rather than a full rewrite. Editing an approved shared prompt saves a pending draft while the approved version keeps being served. - `show_prompts` Presentation only Asks the client to render the prompt library as an interactive browser for the human. It performs no data operation and returns only a short confirmation. The MCP App bound to it populates itself from its own manage_prompt calls. Separating the two is what keeps the agent’s routine prompt work from opening a window nobody asked for ([201](https://plexara.io/learning/mcp/what-is-an-mcp)). ### DataHub Schema, lineage, glossary, and curated query retrieval. Discovery itself is not here: it belongs to the universal search tool in the Knowledge toolkit, and [searching the capability rather than the manual](https://plexara.io/learning/insights/search-the-capability-not-the-manual) is what these structural reads follow (203). The write tools at the end are used inside the knowledge-apply flow (206) rather than directly by end users. - `datahub_browse` Lists catalog contents by category (tags, domains, data products). Useful for orientation rather than targeted lookups. - `datahub_get_entity` Fetches a DataHub entity by URN. Returns the full metadata record, including custom properties. - `datahub_get_schema` Returns the column schema for a dataset entity. Use when the agent needs column types and descriptions before writing a query. - `datahub_get_lineage` Upstream and downstream lineage for a dataset. Used to understand where data comes from and what depends on it. - `datahub_get_glossary_term` Business glossary lookup. The agent uses this to disambiguate terms like "revenue," "active customer," or "net amount" against the organization's canonical definitions. - `datahub_get_queries` Retrieves curated, pre-benchmarked query templates for a dataset. The fast path the operating manual tells the agent to prefer over free-form queries. - `datahub_get_data_product` Returns data-product metadata (a named grouping of related datasets). - `datahub_create` Write Admin Writes a new catalog entity. Not typically invoked directly by end users; used inside the apply_knowledge flow. - `datahub_update` Write Admin Updates an existing catalog entity (description, tags, glossary terms, etc.). Called by apply_knowledge when applying approved insights. - `datahub_delete` Write Admin Removes a catalog entity. Restricted to administrator sessions. ### Trino SQL execution, structural navigation, plan inspection, and large-result export across every Trino catalog the deployment reaches (204). [Read-only enforcement is applied at the platform layer](https://plexara.io/learning/insights/governance-at-execution-time), not left to the query author (207). A query here is also refused outright until discovery has run in the session, which is the gate step 05 of the trace describes. - `trino_query` Read-only enforced Executes read-only SQL against any configured Trino catalog. Write statements are refused at the platform layer. - `trino_execute` Write Client-prompted Executes any SQL, including inserts, updates, deletes, and DDL. The write path is a separate tool from the read path on purpose. Annotated as destructive so clients prompt before running it, where trino_query is annotated read-only and can be auto-approved. A connection pinned read-only refuses writes here too. - `trino_browse` Lists catalogs, schemas, and tables. Used for structural navigation once search has pointed at a backend. - `trino_describe_table` Returns the column schema for a Trino table, with an option to include sample rows. - `trino_explain` Returns the Trino execution plan for a query. Used when the agent needs to reason about why a query is slow or how it will be executed. - `trino_export` Writes asset Runs a query and writes the result to a persisted asset (CSV, JSON, or Markdown) instead of returning rows in the conversation. Use when the result set is large enough that putting it in the context window would be wasteful. ### S3 Object storage access under prefix ACLs and size caps. Every tool here is restricted to the paths the persona is allowed to reach, and the restriction is applied when the call is made rather than described in a policy (207). - `s3_list_buckets` Enumerates buckets configured on the deployment, within the configured prefix ACLs. - `s3_list_objects` Prefix-restricted Lists objects inside a bucket. The platform layer enforces the prefix restriction; the agent cannot browse outside allowed paths. - `s3_get_object` Size-capped Reads object content. Subject to the configured maximum file-size limit. - `s3_get_object_metadata` Reads object metadata (size, last modified, content type) without downloading the content. - `s3_presign_url` Returns a time-limited signed URL for a specific object. Useful when a dashboard or report needs to link to raw data. - `s3_put_object` Write Uploads an object, taking text directly or base64 for binary content. Blocked when the connection is pinned read-only. - `s3_delete_object` Write Removes an object. Irreversible unless the bucket has versioning enabled, and blocked when the connection is pinned read-only. - `s3_copy_object` Write Copies an object within a bucket or between buckets, optionally rewriting its metadata on the way. Blocked when the connection is pinned read-only. ### Memory Per-user memory organized along five dimensions. Recording is one action, memory_capture; memory_manage covers the lifecycle afterwards. Reading memory back is not a memory tool at all: the universal search tool reaches memory alongside every other source it covers, so prior-session context arrives in the same result set as the catalog and the knowledge pages (206). - `memory_capture` Writes The one way to record knowledge. Checks existing memory for that user before it writes, so a restatement supersedes the record it corrects instead of stacking a near-duplicate beside it. Memories are organized along five dimensions: Knowledge, Events, Entities, Relationships, Preferences. - `memory_manage` Writes The lifecycle of a memory that already exists. Supported commands: update, forget, list, review_stale, review_duplicates, consolidate. Reading memory back is not here. It moved into the universal `search` tool, which reaches memory alongside the catalog, knowledge pages, insights, assets, and prompts in a single query. ### Knowledge Discovery and admin-reviewed catalog write-back. search and fetch are open to every user and are the front door to the whole platform; the apply path is administrator-only (203, 206, 207). - `search` First call for any question The one way to discover. A single query fans across the catalog, the governance vocabulary, context documents, knowledge pages, the caller’s memory, insights, feedback, assets, resources, prompts, API endpoints, and connections. Results arrive grouped by source with a per-source coverage summary rather than as one flat list, so no single source crowds out the others. [203](https://plexara.io/learning/mcp/discovery-search-and-fetch) covers the response shape in full. - `fetch` Reads one search result in full. Takes any reference a hit carries and returns the complete record behind it, under exactly the scope search applied. Registered alongside search. A persona granted one without the other can find records it cannot open. - `apply_knowledge` Writes catalog Admin The review-and-apply gate. Enumerates pending captures, supports bulk or per-entity review, synthesizes related ones into cohesive changes, and writes approved changes back as a tracked, reversible changeset. Knowledge lands in one of two homes: a DataHub entity when the fact is tied to a dataset or column, or a canonical knowledge page when it is broader business context. Recording is not here; that is memory_capture, described in [206](https://plexara.io/learning/mcp/knowledge-from-memory-to-insights). ### Portal (assets and feedback) Asset persistence, collection management, and the feedback threads people leave on both (205). Dashboards, reports, charts, and exports live here as first-class, shareable objects rather than as transient chat output. - `save_asset` Writes asset Persists generated content (HTML, JSX, SVG, Markdown, JSON, CSV) as a named, shareable asset in the portal. Use this path whenever the agent would otherwise return a large block of content into the conversation. - `manage_asset` Writes List, get, update, delete, or revert existing assets. Edits go through update rather than regenerating from scratch, which preserves provenance. Collection management lives here too: the agent can group assets (dashboards, reports, markdown, CSVs) into sections within a named collection, and collections are shareable as a single unit. - `manage_feedback` Writes Reviews and answers the comments people leave on the agent’s work. Threads hang off an asset, a collection, or a prompt, or off a shared general channel. A list with no target is the "what is waiting on me" query: unresolved threads on everything the caller owns or can edit, plus anything awaiting their validation. Feedback is its own tool rather than an action on manage_asset so an agent finds the loop by name. ### API Registered HTTP APIs, reached the same governed way as the warehouses. The deployment holds the credentials and applies them, so the agent addresses an operation by name and never handles a secret. - `api_list_specs` Lists the sections of a registered API connection’s catalog, each with its title, description, operation count, and base path. The first call against an API that bundles more than one specification. - `api_list_endpoints` Lists the operations an API connection exposes, ranked against an optional plain-language query rather than dumped alphabetically. Persona policy still applies at invoke time, so a listed operation can still be refused when it is called. - `api_get_endpoint_schema` Returns the parameters, request body, and per-status response shapes for one operation, so the agent can form a correct call in one attempt. - `api_invoke_endpoint` Write-capable Makes the authenticated request. The connection’s credentials are applied by the platform, so the agent addresses an operation by name and never sees a secret. Response bodies above the connection’s configured ceiling are truncated and flagged rather than silently cut. - `api_export` Writes asset Runs an operation and writes the response to a persisted asset instead of returning it into the conversation. The same escape hatch trino_export provides for query results. ### Key terms Three terms unique to this lesson. Most of the vocabulary across the curriculum has been covered in earlier key-terms sections; this is the short list of what the capstone adds. Key Terms Capstone An end-to-end walkthrough lesson. This one threads a single realistic question through every Plexara subsystem the 200 series covered, so the pieces are visible working together in context rather than in isolation. Prompting style The level of specificity in a prompt. High-level prompts describe the goal; prompt-by-name prompts invoke a library prompt by identifier; tool-by-name prompts force a specific tool path. Each is right in different situations. Tool directory The appendix at the end of this lesson: every tool a Plexara MCP exposes, grouped by toolkit, with badges that flag writes, admin-only operations, session-gated calls, and the single mandatory first call. Search-before-query gate The rule that a warehouse query is refused until discovery has happened in the session. It is enforced in front of the tool handler, so a query that skips discovery never runs at all; the agent gets a SEARCH_REQUIRED result telling it to search first. On this page [Previous 209 - Resources: the company files the agent should use, not reinvent](https://plexara.io/learning/mcp/mcp-resources-templates-and-examples) [Next 211 - Governing the catalog without leaving the portal](https://plexara.io/learning/mcp/catalog-governance-in-the-portal) ### Related reading product [Product 102 - Tokens and your budget Every LLM interaction is priced and rate-limited in tokens. What a token is, how much text fits a budget, and how to avoid wasting tokens on useful answers.](https://plexara.io/learning/ai-concepts/tokens-and-your-budget) [Product 105 - What is an AI agent? An AI agent is not a chatbot and not magic. It is a short loop (think, call-tool, observe, think again) on top of a language model. Mental model first.](https://plexara.io/learning/ai-concepts/what-is-an-ai-agent) [Product 202 - Your first day with Plexara A new Plexara user gets connected, sends a first question, and platform_info takes over. Walks through day one and how subsequent turns inherit context.](https://plexara.io/learning/mcp/first-engagement) --- # Governing the catalog without leaving the portal URL: https://plexara.io/learning/mcp/catalog-governance-in-the-portal/ > Tags, domains, the business glossary, context documents, and per-table metadata are edited in the portal, under the same persona grants that govern the agent and in the same audit log. Product 13 min read ## 211 - Governing the catalog without leaving the portal Tags, domains, the business glossary, context documents, and per-table metadata are edited in the portal, under the same persona grants that govern the agent and in the same audit log. On this page ### What you will take away from this lesson [206 - Knowledge: from a memory to something the whole team can use](https://plexara.io/learning/mcp/knowledge-from-memory-to-insights) named two places a promoted fact can land, and spent its time on one of them: the canonical knowledge page. This lesson is about the other one. The catalog is not only a sink that writes arrive in; it is a set of vocabularies somebody has to define, keep current, and occasionally retire. All of that now happens inside the portal. The tag vocabulary, the domains the estate is grouped into, the business glossary, the context documents, and per-table metadata are edited on the same page where the agent's work lands, under the same persona rules, in the same audit log. Learning Objectives 1. 01 State the rule that decides what appears under Catalog: everything under it is DataHub, and anything the portal’s own database backs stays outside it. 2. 02 Name the five inner tabs, and say which of them are the described things and which are the vocabularies that describe them. 3. 03 Describe what editing a table covers in the portal, and why DataHub offers no table create or delete. 4. 04 Explain what the Tags, Domains, and Glossary tabs govern: the vocabulary itself, rather than what any one table happens to carry. 5. 05 Say what a delete states before it runs, and why a glossary node that still holds entries is offered no delete at all. 6. 06 Name the two conditions that must both hold before any write is permitted, and where every permitted write is recorded. ### 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 [Open index](https://plexara.io/learning/ai-concepts) - [101 What is a Large Language Model? Brilliant at language, blind about your data. Tokens, hallucination, the grounding problem.](https://plexara.io/learning/ai-concepts/what-is-a-large-language-model) - [102 Tokens and your budget Subscription-plan economics, session limits, and Plexara enrichment dedup.](https://plexara.io/learning/ai-concepts/tokens-and-your-budget) - [103 Context, compression, and memory The keep / compress / clear playbook and how memory carries across sessions.](https://plexara.io/learning/ai-concepts/context-windows-and-tokens) - [104 Frontier models, specialized models, and why enterprise AI uses both Three knowledge sources (training, web search, tools). MCP as the exposure protocol.](https://plexara.io/learning/ai-concepts/frontier-models-explained) - [105 What is an AI agent? The think/call-tool/observe loop. Professor's knowledge, child's literalism.](https://plexara.io/learning/ai-concepts/what-is-an-ai-agent) - [110 Is MCP just an API wrapper? MCP as an application layer. Spectrum from thin wrapper to full application server.](https://plexara.io/learning/ai-concepts/mcp-vs-apis) 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. ### Why this belongs in the portal at all The point is not that the portal has forms Governing a catalog is normally work in a different building. A separate tool, a separate login, a separate permission model, and a separate audit trail from the one that records what your analysts and agents actually did. Two systems that describe the same warehouse drift apart, and the drift is invisible until someone acts on a definition nobody has read in a year. What changed is location. A steward defining Net Revenue, an analyst attaching certified to a table, and an agent promoting an insight are all working in the same place, and the persona that governs one governs the others. There is one record of who changed what, because there is one system doing the changing. ### The rule that decides what lives here A catalog surface in a product that also stores its own knowledge has an obvious way to go wrong: two piles of similar-looking things with no stated boundary between them, and a user who has to guess which pile holds the thing they want. The portal avoids it with a rule you can hold in one sentence. Everything under Catalog is DataHub. Anything the portal keeps in its own database, knowledge pages and the changesets that record promotions, stays outside it. Once you know the rule you can predict where any new surface will appear without being told. One rule decides what appears under Catalog Everything under Catalog is DataHub - Tables: The datasets the connection catalogs, and their metadata - Context Docs: Markdown notes attached to a catalog entity - Tags: The tag vocabulary itself - Domains: The business areas the estate is grouped into - Glossary: The terms your organization defines, and the nodes that hold them Anything the portal's own database backs stays outside it - Knowledge pages: Canonical prose, versioned by the portal - Changesets: The record of what a promotion wrote, and the rollback for it - Insights and memory: The review queue, and what is still personal That rule is why the top row stays at four tabs while the catalog surfaces grow underneath it. A new governance surface is a new inner tab, not a new place to look. ### Five tabs: the things, then the words for them Catalog holds its own inner tabs, and the order they appear in is the order they are best read in. Tables and Context Docs are the described things. Tags, Domains, and Glossary are the vocabularies that do the describing, and each of them governs the vocabulary itself rather than the copy of it that any one table happens to carry. That distinction is the thing most worth taking away from this lesson: the Tags tab is not a list of the tags on the table you were just looking at. Five inner tabs, in the order they are read - Tables Described thing Browse or search what the connection catalogs, and open one for its description, tags, owners, glossary terms, domain, and columns. - Context Docs Described thing Markdown notes attached to a dataset, a glossary term, a glossary node, or a container. Longer than a description and anchored to the thing it explains. - Tags Vocabulary The tag vocabulary itself: what tags exist, what each one means, and which tables carry it. - Domains Vocabulary The business areas the catalog is grouped into, and which tables belong to each. - Glossary Vocabulary The terms your organization defines and the nodes that organize them, walked as a tree one branch at a time. The DataHub connection is picked once, at the top of the section, and applies to every inner tab. Switching it returns each tab to its list, because an open table, document, tag, domain, or term belongs to the catalog it was read from. ### What it looks like [Image: The portal Catalog tab: the Tables, Context Docs, Tags, Domains, and Glossary inner tabs with a connection picker on the right, above a searchable list of catalogued tables with their descriptions and tags] The Catalog sub-tab, open on Tables. The connection picker sits at the top right and governs every inner tab beneath it. The section is addressable at `/knowledge/catalog`, the inner tab rides in the hash, and a single entity stays addressable on its own, which is what a catalog reference chip links to from anywhere else in the portal. ### Tables: metadata editing, not table lifecycle The Tables tab browses or searches what the connection catalogs and opens one dataset at a time. Everything on that screen is the metadata the next person reads before they trust the data: what it is, who owns it, what it has been labelled with, which business area it belongs to, and what each column means. Editing one table's metadata - What an open table shows Its description, tags, owners, glossary terms, domain, and columns. With datahub_update granted on a write-enabled connection, each of those facets is editable in place; without it, the same view appears with no editing controls. - Names, not identifiers Tags, glossary terms, and domains are chosen through a name-search picker. Type Reven, select Revenue, and the identifier is resolved for you. Attaching a term never means knowing the URN the catalog generated for it. - Descriptions are markdown Table and column descriptions render formatted, and the editor is the same split source and preview editor used for knowledge pages and prompts. A description can carry a list of caveats rather than one run-on sentence. - Owners are checked An owner is a DataHub user or group identifier, and an invalid one is rejected with a visible inline error rather than accepted and silently dropped. - No create, no delete DataHub has neither, because tables originate in the source systems that produce them. This tab is metadata editing, not table lifecycle, and the distinction is worth holding on to: nothing here can drop a dataset. ### Context Docs: the explanation that outgrew a description A description is one field, and some things do not fit in one field. A context document is a markdown note attached to a dataset, a glossary term, a glossary node, or a container: the migration history behind a column that has two meanings depending on the date, the reconciliation procedure a table is part of, the reason a metric was redefined in March. Browse or search them, open one to read it rendered, and with the matching grants create, edit, and delete them through the same markdown editor used everywhere else in the portal. The attachment is the point. A note in a wiki about a table is a note somebody has to find. A note attached to the table arrives with the table. ### Tags and Domains: governing the words themselves These two tabs answer questions a per-table view cannot. What does certified actually mean here, and who decided? Which tables are in Finance, and which one moved out of it last week? Both tabs list the connection vocabulary with descriptions, filter by name, and open one entry to see what it means and what carries it, with every carrier linking straight back into the Tables editor. Governing the vocabulary rather than one table's copy of it Tags The tag vocabulary, not the tags one table carries Opening one shows: What the tag means, which tables in the connection carry it, and the knowledge pages that reference it. Each table links straight into the Tables tab editor. With the write grants: Create a tag, edit its description, retire one. A tag description is plain text rather than markdown, and it is the one deliberate exception among the catalog vocabularies. DataHub renders that field as plain text on its own tag page, so formatting authored here would show up as raw source everywhere else in the catalog. Domains The business areas the catalog is grouped into Opening one shows: What the domain covers, which tables are in it, and the knowledge pages that reference it. Descriptions are markdown, edited in the same split editor. With the write grants: Create a domain, edit its description, retire one, and move tables in and out. Two limits the tab states rather than hides. DataHub returns at most 100 domains, so a full list means there are domains this page cannot reach and it says so. And a table has at most one domain, so adding a table that already has one moves it, which the form tells you before you pick. ### Glossary: the definitions the business argues about The glossary is where the words that cause the most expensive misunderstandings get written down. Active customer, net revenue, fiscal quarter: terms every team uses confidently and no two teams define identically. It is a tree rather than a list, because a real glossary has structure, and the portal walks it one branch at a time rather than flattening thousands of terms into a scroll. Five things an open term shows - Its definition Markdown, edited in the split source and preview editor, so a definition can carry a heading, the cases it includes, the cases it excludes, and a worked example. That is the difference between a glossary somebody consults and one they stop trusting. - Where it sits A breadcrumb built from the catalog’s own parent chain, so it reads the same however you arrived at the term. - Its context documents The markdown notes attached to this term, for the material too long to be a definition. - The knowledge pages that reference it The reverse of the citation a page makes. A steward reading a term sees what has been written about it without going looking. - The tables annotated with it Each links into the Tables tab editor, and the ones where a column rather than the table carries the term are marked separately. Listing only the first would report every carrier as a column carrier, which is a different claim entirely. The glossary is a tree, so it is walked one branch at a time: the root holds the nodes and the terms with no parent, and opening a node shows what is inside it. A node is both a place in the tree and an entity of its own, so browsing into one is its detail view. One glossary backs both surfaces: a term defined here is immediately what the Tables tab picker offers. ### What a delete tells you before it runs Retiring a definition is the operation with the widest reach and the least visible consequence, which is a bad combination. Every delete in these tabs states what it is about to affect, in the units you would ask about, before you confirm. The design principle underneath is worth naming: when the outcome of an action cannot be stated precisely, the action is not offered. That is a stricter rule than warning about it, and it produces one case where a button you might expect is simply absent. Every delete states its blast radius first - Retiring a tag Says how many tables in the connection carry it, so retiring an unused tag and retiring one the warehouse depends on do not look identical. - Retiring a domain Says how many tables are in it, and that they will be left without a domain, because the delete removes the definition and touches no table. - Retiring a glossary term Says how many tables are annotated with it, and that the annotation stays. Removing the definition does not remove the term from the tables carrying it. - A glossary node that still holds entries Is offered no delete at all. The catalog would take the node without taking its contents, so the options are to empty it first or leave it, and the tab says which. A confirmation that cannot state its outcome is worse than no button. ### Two gates on every write None of this introduces a governance model of its own, and that is the most important thing about it. A write to the catalog from the portal passes exactly the checks a write from an agent passes, because they are the same checks. Two conditions, both required, before anything is written - The persona grants the tool Creating needs datahub_create, editing needs datahub_update, retiring needs datahub_delete. Reads need only DataHub access, which is why a persona without the write grants sees exactly the same browsing surfaces with no editing controls rather than a tab full of buttons that fail. - The connection is write-enabled A connection marked read-only refuses writes no matter which tools the persona holds. Granting a capability and pointing it at a catalog you are willing to have changed are two separate decisions, and both have to be made. - Both are checked on the server The checks do not depend on what the interface chose to render. A request that reaches the API without both conditions is refused there, and every permitted write is recorded in the audit log alongside the tool calls. These are the same tool grants an agent is subject to. A steward editing a domain in the portal and an agent writing a description through `apply_knowledge` pass the same check and land in the same log, which is what makes the audit trail one trail. ### One behavior to expect A tag you just created may take a moment to appear DataHub indexes new tags, domains, and glossary entries asynchronously. The write itself has already succeeded and the identifier it returns is authoritative, but the list you are looking at is served from an index that has not caught up yet. This is worth saying plainly, because a created thing that is missing from a list reads as a bug when nobody warned you, and the natural response is to create it a second time. Wait, reload, and it is there. ### Where this leads A catalog is worth governing because of what reads it. Every question an agent answers passes through the descriptions, tags, domains, and definitions on this screen, so the work of keeping them accurate is not administrative overhead sitting beside the useful work; it is the input to it. Where this leads Both canonical stores have now been covered as things you read and maintain one entry at a time. The knowledge corpus is also a network, because every page cites the entities it is about, and at any real size that network has a shape worth looking at. [212 - Seeing the shape of what your team knows](https://plexara.io/learning/mcp/the-knowledge-graph) closes the 200 series by drawing it, and by naming which definitions the rest of the corpus is leaning on. ### Key terms Eleven terms cover the vocabulary of catalog governance. Three of them are tool names (datahub_create, datahub_update, datahub_delete), and they are the ones that decide what any given person sees when they open these tabs. Key Terms Catalog (the portal tab) The whole of your data catalog inside the portal, and the second of the two knowledge sinks. Its contents are DataHub and nothing else; the surfaces the portal backs with its own database live beside it rather than inside it. Connection The configured catalog a tab is reading from, picked once at the top of the section and applied to every inner tab. Switching it returns each tab to its list, because an open entity belongs to the catalog it was read from. Write-enabled connection A connection not marked read-only. It is the second of the two conditions a write must satisfy; the first is the persona grant. A read-only connection refuses writes regardless of what the persona holds. Tag A short label attached to tables and columns, defined once in the tag vocabulary and carried by many entities. Its description is plain text rather than markdown, because that is how the rest of the catalog renders the field. Domain A business area the catalog is grouped into. A table has at most one, so adding a table that already has a domain moves it rather than giving it a second. Glossary term and node A term is a definition your organization stands behind; a node is a branch that holds terms and other nodes. Both carry markdown definitions, and both are reached by walking the tree rather than through a flat list. Context document A markdown note attached to a dataset, a glossary term, a glossary node, or a container. It is where the explanation too long for a description goes, anchored to the entity it explains. URN The identifier the catalog generates for an entity. It is what a reference actually stores, and it is deliberately something you never have to type: every picker in the catalog searches by display name and resolves the identifier for you. datahub_create / datahub_update / datahub_delete The three tool grants that gate catalog writes, one per kind of write. They are ordinary persona grants, checked the same way as every other tool covered in [207](https://plexara.io/learning/mcp/governance-personas-and-access), which is why the portal needs no governance roles of its own. Blast radius What a delete states before it runs: how many tables carry the tag, are in the domain, or are annotated with the term, and what happens to them afterwards. Where the outcome cannot be stated precisely, as with a glossary node that still holds entries, no delete is offered. Backlink The list of knowledge pages that reference a tag, domain, or glossary term, shown on the entity itself. It is the reverse of the citation a knowledge page makes, and both directions omit anything the reader cannot access. On this page [Previous 210 - Putting it all together: a worked end-to-end example](https://plexara.io/learning/mcp/tool-survey) [Next 212 - Seeing the shape of what your team knows](https://plexara.io/learning/mcp/the-knowledge-graph) ### Related reading product [Product 102 - Tokens and your budget Every LLM interaction is priced and rate-limited in tokens. What a token is, how much text fits a budget, and how to avoid wasting tokens on useful answers.](https://plexara.io/learning/ai-concepts/tokens-and-your-budget) [Product 105 - What is an AI agent? An AI agent is not a chatbot and not magic. It is a short loop (think, call-tool, observe, think again) on top of a language model. Mental model first.](https://plexara.io/learning/ai-concepts/what-is-an-ai-agent) [Product 202 - Your first day with Plexara A new Plexara user gets connected, sends a first question, and platform_info takes over. Walks through day one and how subsequent turns inherit context.](https://plexara.io/learning/mcp/first-engagement) --- # Seeing the shape of what your team knows URL: https://plexara.io/learning/mcp/the-knowledge-graph/ > The portal draws your knowledge corpus as its reference network and measures it: node size is how much of the corpus an entity holds together, and a citation the catalog cannot confirm is stated rather than drawn as if it resolved. Product 12 min read ## 212 - Seeing the shape of what your team knows The portal draws your knowledge corpus as its reference network and measures it: node size is how much of the corpus an entity holds together, and a citation the catalog cannot confirm is stated rather than drawn as if it resolved. On this page ### What you will take away from this lesson A team that has been writing knowledge pages for a year has a corpus, and nobody can answer the obvious questions about it. Which definitions is everything else leaning on? Which subjects have quietly split into two disconnected halves? Which pages cite a dataset the warehouse no longer has? Reading the pages one at a time will not tell you, because none of those facts live inside any single page. The graph view answers them from the references the pages already carry. [206](https://plexara.io/learning/mcp/knowledge-from-memory-to-insights) covered how a fact becomes a knowledge page and what a page links to. This lesson is about what those links add up to once there are enough of them. Learning Objectives 1. 01 Say what a node and an edge are in the knowledge graph, and which entities become nodes. 2. 02 Explain why the view opens on one node rather than the whole corpus, and what Hops and Whole corpus each do. 3. 03 Read node size as the measurement it is: how much of the corpus that entity holds together. 4. 04 Use the inspector to walk the corpus without a page load, and trace the shortest chain of references between any two nodes. 5. 05 Recognise an unresolved catalog reference as a documentation gap rather than an ordinary node. 6. 06 State what the graph leaves out, and where it tells you it has done so. ### 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 [Open index](https://plexara.io/learning/ai-concepts) - [101 What is a Large Language Model? Brilliant at language, blind about your data. Tokens, hallucination, the grounding problem.](https://plexara.io/learning/ai-concepts/what-is-a-large-language-model) - [102 Tokens and your budget Subscription-plan economics, session limits, and Plexara enrichment dedup.](https://plexara.io/learning/ai-concepts/tokens-and-your-budget) - [103 Context, compression, and memory The keep / compress / clear playbook and how memory carries across sessions.](https://plexara.io/learning/ai-concepts/context-windows-and-tokens) - [104 Frontier models, specialized models, and why enterprise AI uses both Three knowledge sources (training, web search, tools). MCP as the exposure protocol.](https://plexara.io/learning/ai-concepts/frontier-models-explained) - [105 What is an AI agent? The think/call-tool/observe loop. Professor's knowledge, child's literalism.](https://plexara.io/learning/ai-concepts/what-is-an-ai-agent) - [110 Is MCP just an API wrapper? MCP as an application layer. Spectrum from thin wrapper to full application server.](https://plexara.io/learning/ai-concepts/mcp-vs-apis) 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. ### What is drawn: the pages, the things they cite, and the citations The Knowledge Pages sub-tab offers two layouts of the same corpus, switched with a Cards and Graph toggle. Cards is the browse list you already know. Graph draws the corpus as its reference network, and the first thing to settle is what the marks on that canvas mean, because everything else in this lesson is read off them. Every node is a thing, every edge is a citation An edge is one stored reference, drawn as an arrow running from the page to the thing it cites. Nothing is inferred and nothing is guessed at from the text: if an editor attached the reference, the arrow is there, and if they did not, it is not. A node is either end of one of those arrows. - Knowledge pages The corpus itself. Every page is a node, and pages are always drawn, because the graph is a view of them. - Assets, prompts, collections The portal entities a page cites: a dashboard the definition governs, the prompt that produces the report, the collection it belongs to. - Connections The configured systems a page names. A connection has no page of its own in the portal, which is why it is the one node type with nothing to open. - Catalog entities Datasets, glossary terms, tags, and domains, identified by the URN the catalog generated for them. These are the nodes that reach outside the portal, and the ones that can fail to resolve. - Other knowledge pages A page citing a page. These edges are what turn a pile of documents into a corpus with a shape worth looking at. Shape and colour carry the type, so a dataset and a dashboard stay distinguishable at a glance. Size is left free to carry something else, which is the subject of a later section. ### What it looks like [Image: The portal Knowledge graph opened on the neighbourhood around one page: twenty of forty nodes drawn as labelled circles, squares, and diamonds joined by dashed arrows, with an Explore and Whole corpus toggle, a Hops selector, node-type filter chips, and an inspector panel on the right reporting the selected page's references out, references in, bridge score, and cluster] The graph as it opens, centred on the corpus's strongest bridge. The summary line above the canvas says exactly what is on screen and what is not: 20 of 40 nodes, 8 clusters, with the partition's modularity in brackets. The inspector on the right belongs to the selected node and is covered further down. ### Why it opens on one node A force layout of an entire corpus is the picture everyone has seen and nobody has used. It is dense in the middle, it changes every time it settles, and the one question it answers reliably is whether you have a lot of documents, which you already knew. So the graph starts somewhere specific. It opens on the corpus’s strongest bridge, the node the most shortest paths run through, and draws that node’s neighbourhood. That choice is itself a finding: the entity the view opens on is the one holding the most of your knowledge together, and if it is a page nobody has edited in eighteen months, you have learned something before touching a control. Two views of the same corpus Explore: one node and its neighbourhood Where the view opens The strongest bridge in the corpus, its immediate neighbours, and nothing else. Hops widens the ring one step at a time, so the picture grows only as fast as you can still read it. Whole corpus: every node, clusters tinted What you switch to on purpose Every node at once, with each substantial cluster tinted as a region behind its members and the layout pulling those members together so the regions actually separate. This is the view for the question does our knowledge have topics at all, and it is a deliberate switch rather than the default. ### The whole corpus, when you actually want it Whole corpus is still worth switching to, for a different question. Not what surrounds this page, but whether the corpus has topics at all, and whether they are the topics you believe your team has. [Image: The same knowledge graph switched to Whole corpus: all forty nodes and sixty-four references drawn at once, with each detected cluster tinted as a shaded region behind the nodes belonging to it, and two isolated nodes sitting outside any region] The whole-corpus overview, with the detected clusters drawn as regions. The two nodes sitting alone on the right are as informative as the dense regions: they are pages nothing else in the corpus cites and that cite nothing themselves. ### The layout is computed, not arranged The difference between this and a diagram somebody drew is that every visual property here is the output of a measurement over the reference network. Size is not emphasis chosen by a designer, and the tinted regions are not groupings somebody decided on. Both are computed from the citations, which is why they can tell you something you did not already believe. What each visual property is measuring - Node size How much of the corpus stops connecting if this entity goes away. The biggest marks on screen are the definitions, datasets, and pages holding otherwise separate topics together, which makes them the ones you cannot afford to leave stale. Computed by: Betweenness centrality: the share of shortest paths through the graph that run through this node. - Cluster regions Which parts of your knowledge are actually about each other. A subject that has split into two regions with one thin link between them is a subject two teams are documenting separately. Computed by: Louvain community detection over the reference network. - The summary line Whether the structure you are looking at is real. It states how many clusters were found and the partition’s modularity, so a corpus with no genuine topic separation reports a low number instead of being read into a picture. Computed by: Modularity of the partition, printed rather than implied. ### Clicking inspects rather than navigates Selecting a node opens an inspector beside the canvas instead of taking you to a page. That distinction is what makes the view usable for investigation: following a citation, seeing where it goes, and backing out costs nothing, so you can follow twenty of them in the time one page load would take. Clicking a node inspects it rather than navigating away - References out and referenced by How many citations run each way, counted separately. A page with many outward references and none inward is a leaf; one with the reverse is something the rest of the corpus depends on. - Bridge score and rank The measurement behind the node’s size, with its standing among everything in the corpus that bridges anything. Rank is the part worth reading, because a raw path count means nothing on its own. - Cluster Which of the detected clusters this node landed in, and how many were found. Two nodes you assumed were about the same subject sitting in different clusters is a finding. - Both directions of references, listed Every citation out and every citation in, each one selectable in place. Selecting one moves the inspector to that node without a page load, which is how you walk the corpus. - The URN, for anything that is not a page The identifier the node’s label was derived from, and the only string you can search or act on anywhere else. A label is for reading; a URN is for doing something with. ### Moving through the corpus Four actions, one of which leaves the graph - Focus Re-centres the view on this node and redraws its neighbourhood around it. - Expand Pulls in this node’s neighbours without moving the centre, so you grow the picture in the direction you are curious about. - Path from Then click any other node, and the shortest chain of references between the two is highlighted on the canvas and listed hop by hop. This is the answer to “how are these two things related”, stated as the actual citations rather than a guess. - Open The only action that leaves the graph. It is absent where there is nothing to open: a connection has no per-instance page in the portal, and a reference whose target has been removed has no destination at all. Hovering lights a node's immediate neighbourhood and dims the rest. Dragging pulls a cluster apart and it stays where you drop it, with Reset layout releasing every pin. The search box focuses matching nodes rather than removing the others, and switching back to Cards keeps both the search text and the tag filter. ### Catalog nodes are resolved against the live catalog Most nodes in this graph are portal entities, and the portal knows everything about them. Catalog nodes are different: they name something that lives in DataHub, and whether that thing is still there is a question only the catalog can answer. A citation that does not resolve is the interesting one Selecting a catalog node looks the dataset up in DataHub and shows what is actually there, naming the connection it queried: the description, the domain, the owners, the tags. That is useful on its own. A reader deciding whether to trust a page can see the current state of the data it is written about without leaving the canvas. The more valuable case is the other one. When the catalog does not have the dataset, the inspector says so plainly instead of drawing the node as though it resolved. A knowledge page citing a dataset that is not in your catalog is a documentation gap: the table was renamed, the pipeline was retired, or the page was written about something that never made it into the warehouse. Any of those is worth knowing, and none of them is visible from reading the page. ### What the graph leaves out A visualization has an unusual capacity to mislead, because a picture reads as the whole of something in a way a list does not. Three rules limit how far this one can mislead, and all three are about telling you what is missing. What the graph leaves out, and where it tells you - Entities you cannot access are absent entirely Neither node nor edge. Not greyed out, not shown as a placeholder, because a placeholder is itself a disclosure that something exists. This is the same visibility rule the per-page reference list applies, so the graph and the page agree about what you can see. - A very large corpus is capped And the cap is stated in a notice above the canvas rather than applied quietly. A picture that silently omits half your corpus is worse than no picture, because it reads as complete. - The summary line is always on screen How many nodes are drawn out of how many exist, how many clusters were found, and the modularity of that partition. Every claim the layout makes is stated in numbers next to it. ### Where this leads The two things worth carrying out of this lesson are practical rather than conceptual. The largest node on screen names the definition your corpus is leaning on hardest, which tells you where review effort is worth spending. An unresolved catalog reference names a page written about data your catalog cannot confirm, which tells you where the documentation and the warehouse have come apart. Where this leads That closes the 200 series: what a Plexara MCP is, what it exposes, how the two canonical stores behind it are maintained, and what the corpus looks like once it is large enough to have a shape. The 300 series changes vantage point from the platform to the work. [301 - Creating reports and dashboards](https://plexara.io/learning/assets/creating-reports-and-dashboards) starts there, with the artifacts an ordinary session produces. ### Key terms Eleven terms cover the vocabulary of the graph view. Two of them, bridge score and cluster, are the ones doing the work: they are what turns a drawing of your corpus into a measurement of it. Key Terms Node One entity in the graph: a knowledge page, or anything a page cites. Shape and colour carry its type; size carries its bridge score. Edge One stored reference, drawn as an arrow from the page to the thing it cites. Edges come from what editors attached, not from anything inferred out of the prose. Neighbourhood A node and everything within a chosen number of hops of it. The graph opens on one, because a force layout of an entire corpus is a hairball that answers nothing. Hops The control that widens the neighbourhood one step at a time. Whole corpus is the separate switch that drops back to the overview. Bridge score How much of the graph a node holds together, computed as betweenness centrality and drawn as node size. The largest marks on screen are the entities joining otherwise separate topics. Cluster A group of nodes more connected to each other than to the rest, found by Louvain community detection and tinted as a region in the whole-corpus overview. Modularity The quality of the cluster partition, printed in the summary line. It is what lets you tell a corpus with real topic structure from one a layout has merely spread out. Path from The action that traces the shortest chain of references between two nodes, highlighted on the canvas and listed hop by hop. It answers how two things are related with the actual citations. Unresolved catalog reference A catalog node whose dataset the connection does not have. The inspector states it rather than drawing the node as if it resolved, because it marks a page written about data your catalog cannot confirm. URN The identifier a node's label was derived from, shown for anything that is not a knowledge page. It is the string you can search or act on elsewhere, and the same identifier the catalog surfaces in [211](https://plexara.io/learning/mcp/catalog-governance-in-the-portal) resolve for you behind a name. Cap notice The statement above the canvas when a corpus is too large to draw in full. The cap exists; what matters is that it is announced rather than applied silently. On this page [Previous 211 - Governing the catalog without leaving the portal](https://plexara.io/learning/mcp/catalog-governance-in-the-portal) [Next 301 - Creating reports and dashboards](https://plexara.io/learning/assets/creating-reports-and-dashboards) ### Related reading product [Product 102 - Tokens and your budget Every LLM interaction is priced and rate-limited in tokens. What a token is, how much text fits a budget, and how to avoid wasting tokens on useful answers.](https://plexara.io/learning/ai-concepts/tokens-and-your-budget) [Product 105 - What is an AI agent? An AI agent is not a chatbot and not magic. It is a short loop (think, call-tool, observe, think again) on top of a language model. Mental model first.](https://plexara.io/learning/ai-concepts/what-is-an-ai-agent) [Product 202 - Your first day with Plexara A new Plexara user gets connected, sends a first question, and platform_info takes over. Walks through day one and how subsequent turns inherit context.](https://plexara.io/learning/mcp/first-engagement) --- # Creating reports and dashboards URL: https://plexara.io/learning/assets/creating-reports-and-dashboards/ > AI chat tools produce excellent dashboards and reports in HTML, JSX, and SVG, formats that do not move easily through normal business workflows. Plexara gives them a home in the portal under Assets: your team's catalog of AI-built work, shared like Google Docs, stored in your S3, editable in place, and discoverable by future agent sessions. This article is the working playbook, including the two prompting habits that make the agent produce a saved asset efficiently. Product 10 min read ## 301 - Creating reports and dashboards AI chat tools produce excellent dashboards and reports in HTML, JSX, and SVG, formats that do not move easily through normal business workflows. Plexara gives them a home in the portal under Assets: your team's catalog of AI-built work, shared like Google Docs, stored in your S3, editable in place, and discoverable by future agent sessions. This article is the working playbook, including the two prompting habits that make the agent produce a saved asset efficiently. On this page ### 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](https://plexara.io/learning/mcp/assets-dashboards-reports-and-data) introduced this idea; this article is the working habits that get the most out of it. Learning Objectives 1. 01 Understand 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. 2. 02 Adopt the two prompting habits that make the agent produce a saved asset efficiently: ask for the save in one breath, and name the shape. 3. 03 Pick the shape that fits the audience: interactive dashboard, markdown report, chart, or CSV. 4. 04 Know 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. 5. 05 Name and describe assets so future you, your team, and the next agent session can find them. 6. 06 Know 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 [Open index](https://plexara.io/learning/assets) - [301 Creating reports and dashboards How 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.](https://plexara.io/learning/assets/creating-reports-and-dashboards) - [302 Exporting data When you need a spreadsheet a teammate can sort, or a data file for another system, instead of a view.](https://plexara.io/learning/assets/exporting-data) - [303 Sharing your work Name 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.](https://plexara.io/learning/assets/sharing-your-work) - [304 Creating collections Bundle 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.](https://plexara.io/learning/assets/creating-collections) - [305 Editing what you already have Name 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.](https://plexara.io/learning/assets/editing-what-you-already-have) - [306 How an asset was built The 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.](https://plexara.io/learning/assets/how-an-asset-was-built) - [307 Turning a comment into something the agent remembers A 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.](https://plexara.io/learning/assets/feedback-that-becomes-knowledge) - [308 Reproducible prompts Save 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.](https://plexara.io/learning/assets/reproducible-prompts) The 300 series is practical recipes for working with Plexara day to day. It assumes the mental model from [205](https://plexara.io/learning/mcp/assets-dashboards-reports-and-data). ### 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 1. 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." 2. 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. [Image: The Asset Viewer showing an interactive Q4 revenue dashboard: a header with Preview and Source toggles, a v5 (current) version picker, and Feedback, Delete, Download, and Share buttons above four KPI tiles with sparklines, a revenue-by-region bar list, and a top-products table.] The interactive-view shape, opened in the portal. What the agent saved as HTML renders as a working dashboard, with the version picker and the Feedback, Download, and Share actions in the header. The other three shapes open in this same viewer. ### 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. [Image: The Assets page in grid view with Mine, Shared, and All filters, a search box, type and tag filters, and cards for a Q4 revenue dashboard, a sales pipeline chart, a weekly inventory report, and others, each showing a live preview, a content type, tags, a size, and a date.] Where a save lands. Each card previews the asset in its saved shape (dashboard, SVG chart, markdown report) and carries the content type, the tags, and the date, so a reader can tell what will open before clicking. ### 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](https://plexara.io/learning/insights/intent-driven-tools-and-memory). 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](https://plexara.io/learning/insights/search-the-capability-not-the-manual) 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. When to name the tool, and when to let the agent choose You almost never have to tell the agent which tool to use. Every tool ships with a description, and the agent reads them on every turn and picks. Saying “save this as a markdown report” usually produces a Save Asset (`save_asset`) call with markdown content, no tool name required. Where naming the tool helps is when the first try went the wrong way. If the agent put a chart in the chat instead of saving it, “save it as an asset using `save_asset` ” resolves the ambiguity. The lesson: write the prompt you would write for a sharp junior colleague, and reach for the tool name only when you need to be unambiguous. ### 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](https://plexara.io/learning/insights/knowledge-application-turns-usage-into-documentation). Plexara remembers how each asset was built, so you do not have to Every asset you save carries a record of the data work behind it: which tools the agent called during the session, what it asked each one for, and when. Plexara sits between the agent and your data and records what crossed that line, which means the queries are in the record and your conversation is not. You did not ask for this and you do not have to maintain it. The next time someone asks “where did this number come from?” you can open the asset and read the queries that ran while it was being built. Article 306 is the full story, including where the record stops short of proof; for now, the productivity point is this: you do not have to keep notes about which query fed which chart. The dashboard keeps them for you. ### 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. Where this leads Dashboards and reports cover most of what you build in Plexara, but they are views meant to be opened in the portal. The next lesson, [302 - Exporting data](https://plexara.io/learning/assets/exporting-data), covers the case where you want a spreadsheet a teammate can sort in Excel, or a structured file you hand off to another system. Same habits, different shape of output. ### 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 Asset save_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 Asset manage_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. On this page [Next 302 - Exporting data](https://plexara.io/learning/assets/exporting-data) ### Related reading product [Product 102 - Tokens and your budget Every LLM interaction is priced and rate-limited in tokens. What a token is, how much text fits a budget, and how to avoid wasting tokens on useful answers.](https://plexara.io/learning/ai-concepts/tokens-and-your-budget) [Product 105 - What is an AI agent? An AI agent is not a chatbot and not magic. It is a short loop (think, call-tool, observe, think again) on top of a language model. Mental model first.](https://plexara.io/learning/ai-concepts/what-is-an-ai-agent) [Product 202 - Your first day with Plexara A new Plexara user gets connected, sends a first question, and platform_info takes over. Walks through day one and how subsequent turns inherit context.](https://plexara.io/learning/mcp/first-engagement) --- # Exporting data URL: https://plexara.io/learning/assets/exporting-data/ > When a teammate asks for the data instead of the dashboard: a spreadsheet to pivot, a JSON to feed another system, a markdown table for a wiki. Plexara has a dedicated path for this called Trino Export. It runs the query, writes the file straight to your S3 bucket, and never puts the rows in your chat. This article is the analyst's playbook. Product 10 min read ## 302 - Exporting data When a teammate asks for the data instead of the dashboard: a spreadsheet to pivot, a JSON to feed another system, a markdown table for a wiki. Plexara has a dedicated path for this called Trino Export. It runs the query, writes the file straight to your S3 bucket, and never puts the rows in your chat. This article is the analyst's playbook. On this page ### What you will take away from this lesson Article [301](https://plexara.io/learning/assets/creating-reports-and-dashboards) covered the case where the agent's output is meant to live inside the portal, as a clickable dashboard or a written report that teammates open in a browser. This article is the other case: when what you actually need is the data, in a file, ready to leave the portal. A spreadsheet your finance team will pivot in Excel. A JSON your engineering team will hand to another system. A markdown table you will paste into a Confluence page. The same Plexara asset system from 301 hosts these too, but a different, purpose-built tool produces them. The tool is **Trino Export** (`trino_export`). It runs a query, formats the rows, writes the file straight to your S3 bucket, and returns a portal link with the row count and file size. The rows never enter the chat, which matters when the result is ten thousand transactions instead of ten. Same Assets page from 301, same sharing model from 303, but the deliverable is a file, not a view. Learning Objectives 1. 01 Recognize when the right output is a file to leave the portal, not a view to live inside it. 2. 02 Use the sample-first, export-second pattern so a wrong query never becomes a 100,000-row mistake. 3. 03 Pick the right format for the recipient: CSV, JSON, Markdown, or plain text. 4. 04 Know that the rows never enter the chat: Trino Export streams straight to your S3 bucket and the agent only sees metadata. 5. 05 Recognize the safety guards Plexara applies automatically (read-only, CSV-formula escaping, sensitivity-tag inheritance, row and byte caps). ### Where this lesson sits in the curriculum 301 covered building dashboards and reports, which are views meant to live inside the portal. 302 is the case where the deliverable is a file meant to leave the portal. Both kinds of output land in the same Assets page; the producer tool differs. 300 Series: getting more out of Plexara [Open index](https://plexara.io/learning/assets) - [301 Creating reports and dashboards How 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.](https://plexara.io/learning/assets/creating-reports-and-dashboards) - [302 Exporting data When you need a spreadsheet a teammate can sort, or a data file for another system, instead of a view.](https://plexara.io/learning/assets/exporting-data) - [303 Sharing your work Name 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.](https://plexara.io/learning/assets/sharing-your-work) - [304 Creating collections Bundle 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.](https://plexara.io/learning/assets/creating-collections) - [305 Editing what you already have Name 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.](https://plexara.io/learning/assets/editing-what-you-already-have) - [306 How an asset was built The 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.](https://plexara.io/learning/assets/how-an-asset-was-built) - [307 Turning a comment into something the agent remembers A 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.](https://plexara.io/learning/assets/feedback-that-becomes-knowledge) - [308 Reproducible prompts Save 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.](https://plexara.io/learning/assets/reproducible-prompts) The 300 series is practical recipes for working with Plexara day to day. It assumes the mental model from [205](https://plexara.io/learning/mcp/assets-dashboards-reports-and-data). ### The single habit that prevents wasted exports Exports are different from dashboards in one operational way: the cost of getting them wrong is higher. A wrong dashboard prompt produces a wrong view that scrolls off and you try again. A wrong export prompt can produce a 100,000-row asset, with a sensitivity tag, that someone else now has to clean up. The cure is so simple it is easy to skip: sample the query first, with the agent in chat, and only then export the full set. This is not a Plexara invention. The Trino Export tool description tells the agent to do exactly this, every time. Your job is to lean into the rhythm. Ask for ten rows, look at them, then ask for the full export. The next section is the diagram. The two-step pattern: sample first, export second The most expensive mistake with exports is exporting the wrong query. A 100,000-row export of a query with one wrong join clause is a wasted asset, wasted compute, and a confusing artifact for whoever finds it next month. The fix is built into the way Trino Export (`trino_export`) is meant to be used. The tool's own description tells the agent to run a small Trino Query (`trino_query`) first to validate the query shape, and only then export the full result. As a user you can lean into this: ask the agent for ten sample rows, look at them, then say “looks right, export the full set as a CSV and save it as Q3 Southwest transactions.” The cost of a sample query is negligible. The cost of getting a hundred thousand wrong rows is real. ### The three-step shape of a healthy export Three steps cover almost every export session. Sample, export, receive. Each step has its own purpose and its own cost. The sample is the cheap protection against the expensive mistake. The export is the moment the bytes commit to S3. The metadata response is what you read back to your teammate so they know what they are about to download. What comes back is a real file with a real name, and it stays findable. A CSV export lands as a CSV, opens as a sortable table in the portal, and downloads under a name your finance colleague can recognize in their Downloads folder. Months later, you do not have to remember which folder it went in: ask the agent for it and it comes back from the same search that finds everything else you have saved. The three-step shape of a healthy export 1. 01 Sample with Trino Query Ask the agent for ten rows. Confirm the columns, the joins, and the values look right. This step is cheap and the result is in chat. 2. 02 Run Trino Export Ask for the full export, naming the format and what to save it as. The agent runs the query, formats the result, and writes the file straight to your S3 bucket. None of the rows enter the chat. 3. 03 Receive asset metadata The agent returns the portal link, the row count, and the file size. The export names its own format, so the platform takes it at its word and the file lands with the right extension: the download reads q3-2025-southwest-transactions.csv. The asset shows up on your Assets page next to the dashboards from 301, and comes back in a later session when you or a teammate asks the agent for it. It is sortable, downloadable, shareable, and (if it touches sensitive sources) tagged accordingly. Default deployment caps are 100,000 rows and 100 MB per export, with a 5-minute query timeout (10-minute max). Your administrator may tighten these. Treat them as a hint that if you genuinely need a multi-gigabyte extract, it should go through a scheduled job, not a chat session. ### Four formats: which to ask for Trino Export speaks four formats: CSV, JSON, Markdown, and plain text. It is the file-producing sibling of the [Trino Query tool](https://plexara.io/learning/mcp/trino-query-analytics-and-insights) you use for analysis. The choice is mostly about who is on the receiving end. A finance colleague who will pivot the data wants CSV. An engineering team that will feed a pipeline wants JSON. A wiki page that needs an inline table wants Markdown. A debugging session that wants to eyeball log-shaped output wants text. The agent picks the format from the word you use. "Spreadsheet" tends to route to CSV; "machine-readable" tends to route to JSON. Naming the format directly removes ambiguity. The table below shows side-by-side example prompts for each. Four export formats and when to pick each - CSV (csv) A table that opens cleanly in Excel, Google Sheets, or any BI tool. The default choice when a teammate says "send me the data." For: Finance, business users, anyone who will pivot the data themselves. "Export the full Q3 Southwest transactions table as a CSV and save it as Q3 2025 Southwest transactions." - JSON (json) A structured file another system can read directly. Wraps the rows in a small envelope with column names so downstream code does not have to guess. For: Engineering pipelines, automation, any system that needs the data programmatically. "Export the customer segmentation as JSON and save it as 2025 customer segments v3." - Markdown (markdown) A table you can paste into a Confluence page, a GitHub README, or a Notion doc and have it render correctly without further work. For: Anyone writing up findings in a wiki or markdown-shaped document. "Export the top ten products by Q3 revenue as a Markdown table and save it as Top 10 products Q3 2025." - Text (text) Plain columnar output, useful for terminal-style inspection, log-shaped data, or quick eyeballing without spreadsheet software. For: Engineering debugging, quick sanity checks, edge cases where CSV is overkill. "Export the slow query log entries from last night as text and save it as Slow queries 2025-10-14." The four format names above are the words the agent recognizes. Other phrasings tend to work too (“spreadsheet” routes to CSV, “machine-readable” tends to route to JSON), but using the format name removes ambiguity. [Image: The Asset Viewer showing a CSV export named Regional Sales Summary as a sortable table with Region, Quarter, Revenue, Units Sold, Avg Price, and Growth columns, a search-all-columns box, a Download button, and a footer reading showing 8 of 8 rows.] A CSV export opened in the portal. The file renders as a sortable, searchable table rather than raw text, and Download hands the recipient the file itself. Ask for CSV when the person on the other end wants to pivot. ### What the tool does for you without being asked An export is not just data movement; it is data leaving the boundary your organization controls. Plexara bakes in three guards that you would otherwise have to remember on every export: [read-only enforcement](https://plexara.io/learning/insights/closed-by-default-access), CSV formula-character escaping, and sensitivity-tag inheritance. None of them require you to opt in. All of them apply on every Trino Export call, which is one example of [governance applied at the moment of execution](https://plexara.io/learning/insights/governance-at-execution-time) rather than left to the catalog. The point of naming them here is so you can answer your security team's questions later without going back to read source code. What Trino Export does for you without being asked - Read-only, always Even when a Plexara deployment allows write queries through the separate Trino Execute (trino_execute) tool, Trino Export refuses anything other than a SELECT. The same read-only interceptor that protects trino_query covers exports. An accidental DROP TABLE in an export prompt is rejected with a clear error before it touches your warehouse. - CSV cells that start with =, +, -, or @ are escaped A cell like =SUM(A1:A10) in your data would be interpreted as a formula by Excel and Google Sheets when the CSV is opened. Worse, a cell like =cmd|"/c calc"!A1 is a known Excel command-execution exploit. Trino Export auto-prefixes such cells with a single quote so they render as text, not formulas. Your data stays inert when it leaves your hands. - Sensitivity tags follow the data If a source table is tagged PII, confidential, restricted, PHI, or PCI in DataHub, the exported asset inherits a system tag like _sys-classification:pii automatically. The classification follows the data into the portal, so reviewers and access controls can act on it without re-inspecting the rows. Your governance does not have to chase exports; it tags them in flight. These are not features you opt into. They are baked into Trino Export and run on every call. The point of listing them is so that when a teammate asks “is it safe to send this CSV to the auditor?” you can answer yes with reasons. ### Bundling a shareable link into the same export A very common pattern after an export is "now make it shareable to a person outside the portal." An auditor, a vendor, a partner team without a Plexara account. Trino Export has a built-in shortcut for this: when your prompt indicates external sharing, the agent passes an option called create_public_link, which produces a public share URL alongside the asset in the same response. One prompt, one shareable link Trino Export has an option called `create_public_link` that bundles “and also make this asset shareable to anyone with the URL” into the same call. You do not pass this option yourself; the agent does, when your prompt indicates external sharing. A request like “export the Q3 Southwest transactions as a CSV and give me a public link the auditor can fetch” routes the agent to call Trino Export with that option turned on. The result is one asset and one public URL, produced in a single step. [303 - Sharing your work](https://plexara.io/learning/assets/sharing-your-work) covers the full sharing system, including how to add expiration dates and revoke access. [Image: The Share Asset dialog over a dashboard, with a Share by Link row set to Signed-in users for 24 hours beside a Create Link button, a Share with User section with an email field, a Viewer permission picker, and a Share button, and an Active Shares list showing a link with twelve views and an editor share for a user.] The public link the export produces shows up here, under Active Shares on the asset, next to any share you make by hand. Article 303 covers this dialog in full. ### Retries that do not duplicate work Most of the time, idempotency is something the agent handles for you and you never think about. It matters most when exports run on a schedule or as part of a pipeline. The mechanism is simple: a short string the caller supplies that prevents the same export from being created twice if a retry happens. The callout below explains when it surfaces. Retries that do not duplicate work For one-off exports run by a person at a keyboard, this section is background. For exports run on a schedule or by an automation pipeline, it matters. Trino Export accepts an idempotency key: a short string the caller supplies so that if the same export is retried (because the network blipped, or a job retried itself), the second call returns the existing asset instead of running the query again and creating a duplicate. The agent manages the key for you in interactive sessions; for scripted exports the key is what protects you from a Tuesday-morning Slack thread of “why are there three copies of the weekly report?” ### What this looks like in practice One conversation, in the shape you might actually have one. Sample first, export second, share once, sensitivity tag along for the ride. Sample first, export second, share once You I need the full Q3 2025 Southwest transaction table for finance. Show me ten sample rows first so I can confirm the shape. Agent Here is a 10-row sample of Q3 2025 Southwest transactions, joined to the customer and product tables. Columns: transaction_id, transaction_date, customer_id, customer_name, product_sku, product_name, quantity, gross_amount, discount_amount, net_amount. (table of 10 rows shown inline) That covers 14,873 rows in the full result. Shall I export the full set? You Yes, export it as a CSV and save it as Q3 2025 Southwest transactions. Also make a public link so the auditor can fetch it without a portal account. Agent Exported 14,873 rows as CSV (2.1 MB). The asset has inherited a `_sys-classification:pii` tag from the customer table. Portal asset: portal/assets/Q3-2025-Southwest-transactions Public download link: portal/view/sw-aud-q3-2025 Open the asset to set an expiration on the public link before you share it. Notice the rhythm. The sample query runs cheaply and confirms the shape. The export runs once on data you have already eyeballed. The public link is bundled into the same call, and the sensitivity tag follows automatically so a reviewer can see at a glance that this CSV touches PII. Three turns, one asset, one shareable link, no surprises. ### What 303 covers Article 302 introduced create_public_link as a shortcut because it is so often paired with an export. Article 303 is the full story on sharing: named user shares with viewer or editor permission, public links with expiration dates and notice text, and the controls that let you revoke either kind when you no longer want the asset to be reachable. Where this leads Article 302 introduced `create_public_link` as a convenience because it is so often paired with an export. [303 - Sharing your work](https://plexara.io/learning/assets/sharing-your-work) is the full story on sharing: how to share an asset with named teammates as viewer or editor, how to create a public link with an expiration date and a notice line, and how to revoke either kind of share. The mental model is Google Docs and the controls work the way you expect. ### Key terms Six terms cover the vocabulary of exports. The first three are what you will see in the agent's reply. The last three are the mechanics that protect you from common export mistakes. Key Terms Trino Export trino_export The tool that runs a SELECT query and writes the full result to an asset file in your S3 bucket. The rows never enter the chat; the agent only sees metadata (asset link, row count, file size). format The output shape for the exported file: csv, json, markdown, or text. CSV opens in Excel; JSON feeds downstream systems; Markdown pastes into docs; text is for terminal-style inspection. row_count, size_bytes Two fields in the response that tell you how big the export was. Surface them when you reply to a teammate ("here is the CSV, 14,873 rows, 2 MB") so they know what they are receiving before they download. Idempotency key A short string that prevents retries from creating duplicate assets. Mostly invisible to interactive users; meaningful for scheduled or automated exports. Sensitivity tag A system-applied tag like `_sys-classification:pii` that an export inherits from its source tables when those tables are tagged PII, confidential, restricted, PHI, or PCI in DataHub. The classification follows the data into the portal so governance can act on it. create_public_link An option on Trino Export that bundles "and make this asset shareable to anyone with the URL" into the same call. Article 303 covers the full sharing system. On this page [Previous 301 - Creating reports and dashboards](https://plexara.io/learning/assets/creating-reports-and-dashboards) [Next 303 - Sharing your work](https://plexara.io/learning/assets/sharing-your-work) ### Related reading product [Product 102 - Tokens and your budget Every LLM interaction is priced and rate-limited in tokens. What a token is, how much text fits a budget, and how to avoid wasting tokens on useful answers.](https://plexara.io/learning/ai-concepts/tokens-and-your-budget) [Product 105 - What is an AI agent? An AI agent is not a chatbot and not magic. It is a short loop (think, call-tool, observe, think again) on top of a language model. Mental model first.](https://plexara.io/learning/ai-concepts/what-is-an-ai-agent) [Product 202 - Your first day with Plexara A new Plexara user gets connected, sends a first question, and platform_info takes over. Walks through day one and how subsequent turns inherit context.](https://plexara.io/learning/mcp/first-engagement) --- # Sharing your work URL: https://plexara.io/learning/assets/sharing-your-work/ > Sharing in Plexara sends real mail. Name a colleague and they get an email carrying your note and a link that opens the work; name somebody with no Plexara account and they can still read it, through a single-use link sent to the address you named. This lesson is the playbook for getting a dashboard in front of the right person and knowing what happened to it after you clicked Share. Product 14 min read ## 303 - Sharing your work Sharing in Plexara sends real mail. Name a colleague and they get an email carrying your note and a link that opens the work; name somebody with no Plexara account and they can still read it, through a single-use link sent to the address you named. This lesson is the playbook for getting a dashboard in front of the right person and knowing what happened to it after you clicked Share. On this page ### What you will take away from this lesson Article [302](https://plexara.io/learning/assets/exporting-data) ended with a useful shortcut: when the agent runs an export, you can ask for a public link in the same breath, and the agent passes the `create_public_link` option to Trino Export. That is one narrow case. This article covers the full sharing system, which works the same way for every asset (a dashboard from 301, a report, a chart, an export from 302) and for collections. The thing to unlearn from the Google Docs analogy is that sharing here is not only a permission grant. Naming a person sends them mail, carrying a note you wrote and a link that opens the work. If they have no Plexara account, they can still read it. And what governs whether that mail arrives is their preference, not your intent. Learning Objectives 1. 01 Choose between the two things you can create on an asset: a link, or a share addressed to a person, and state what each one is worth if it gets forwarded. 2. 02 Set the access mode so a link opens for exactly the audience you meant, and know why a share addressed to a person carries no expiration. 3. 03 Use the notify toggle and the note field so the email you send explains itself, and share quietly when an email would be noise. 4. 04 Describe what a recipient with no Plexara account does to open your work, and what their one-time link can and cannot do. 5. 05 State the recipient preference model that governs delivery, and why your notify toggle can suppress an email but never force one. 6. 06 Find the evidence of what happened: the share list and its view count for what you sent, and Recent notifications for what you were told. 7. 07 Predict who hears about a comment on a shared asset, and why an @-mention never doubles a recipient up. ### Where this lesson sits in the curriculum 301 built dashboards and reports. 302 produced data exports. Both produce assets that live on your Assets page. 303 is how those assets get into a teammate's hands, or into the hands of someone without a Plexara account at all. 300 Series: getting more out of Plexara [Open index](https://plexara.io/learning/assets) - [301 Creating reports and dashboards How 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.](https://plexara.io/learning/assets/creating-reports-and-dashboards) - [302 Exporting data When you need a spreadsheet a teammate can sort, or a data file for another system, instead of a view.](https://plexara.io/learning/assets/exporting-data) - [303 Sharing your work Name 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.](https://plexara.io/learning/assets/sharing-your-work) - [304 Creating collections Bundle 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.](https://plexara.io/learning/assets/creating-collections) - [305 Editing what you already have Name 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.](https://plexara.io/learning/assets/editing-what-you-already-have) - [306 How an asset was built The 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.](https://plexara.io/learning/assets/how-an-asset-was-built) - [307 Turning a comment into something the agent remembers A 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.](https://plexara.io/learning/assets/feedback-that-becomes-knowledge) - [308 Reproducible prompts Save 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.](https://plexara.io/learning/assets/reproducible-prompts) The 300 series is practical recipes for working with Plexara day to day. It assumes the mental model from [205](https://plexara.io/learning/mcp/assets-dashboards-reports-and-data). ### A link, or a person The Share dialog offers two things, and the difference between them is not cosmetic. Share by Link mints a URL for an audience. Share with User names one person, restricts the item to them, and sends them mail about it. The question that separates the two is not who you want to reach but what you want the artifact you hand out to be worth in somebody else's hands. The two halves of the Share dialog, side by side - Share by Link Who the audience is A URL you paste somewhere: a Slack thread, a ticket, a wiki page. Whoever holds it is the audience, bounded by the access mode you pick. How long it lasts Takes an expiration. The URL is the credential, so a bounded life limits what a copied link is worth. The share list shows how many times each link has been opened. What it is worth if it gets forwarded Forwarding passes on whatever the access mode admits. A signed-in-users link still requires a Plexara login. An anyone-with-the-link link opens for whoever receives it. Reach for it when The auditor who needs the Q3 export for a week and does not need an account. - Share with User Who the audience is One named email address. Only that person, plus you, can open it. Their permission is Viewer or Editor. How long it lasts No expiration. It grants that person access until you revoke it, which is why the expiration field belongs to links and is refused here rather than quietly resolved. What it is worth if it gets forwarded Nothing. The link resolves only for the recipient, signed in, or through a one-time link mailed to the address the share names. Forwarding the message grants the reader no access. Reach for it when The finance partner who will open this dashboard again in three weeks. The asset does not change between them, and you can use both at once. The same Q3 dashboard can carry a link for the Slack thread and a share addressed to your finance partner, listed together under Active Shares on the asset page. [Image: The Share Asset dialog over a Q4 revenue dashboard, with a Share by Link row set to Signed-in users for 24 hours beside a Create Link button, a Share with User section with an empty email field, a Viewer permission picker, and a Share button, and an Active Shares list holding one link with twelve views and one editor share marked no expiration.] The two halves in one dialog. Share by Link on top with its access mode and expiry; Share with User below with an address, a permission, and a Share button. Active Shares lists both kinds together: a link with its view count and expiry beside a user share marked no expiration. ### Access mode: who a share opens for Every share carries an access mode, and it is the field that decides whether your work is readable by one named person, by your colleagues, or by whoever ends up holding a URL. Naming a recipient sets it for you. Minting a link makes you choose. Granting the narrowest audience that does the job is the [least-privilege starting point](https://plexara.io/learning/insights/closed-by-default-access) that runs through the whole platform. Access mode: who a share actually opens for - Restricted What you get by naming a recipient Opens for: The named recipient, and you. A signed-in user who is not the recipient gets a page naming the account they are signed in as, with a switch-account action, rather than a dead end that reads like a bug. Recipients with no account get in through a one-time link instead. - Signed-in users The default for Share by Link Opens for: Anyone with a Plexara account who holds the URL. The right default for an internal link. A colleague who finds it in a wiki page can open it; the internet cannot. Pair it with an expiration. - Anyone with the link An explicit choice, never implied Opens for: Whoever holds the URL, with no sign-in at all. The dialog warns you when you pick it, because at this setting the URL is the whole credential. It is the right answer for a genuinely external reader who cannot authenticate, and the wrong answer for anything you would not hand to a stranger. Every route behind a share token resolves the access mode before it serves anything: the page, the raw content, the thumbnails, and the collection items underneath. This is the same [decision-at-execution-time](https://plexara.io/learning/insights/governance-at-execution-time) rule the platform applies everywhere else, which is why there is no back door to the content of a share whose page you cannot open. ### The Share dialog, as the recipient field opens it up Both halves of the dialog live on one screen, and typing an address into the lower half reveals the two controls that decide what reaches the recipient. Here is what that looks like on a dashboard that already has one link and one user share on it. [Image: The Share Asset dialog over a Q4 revenue dashboard, with a Share by Link row set to signed-in users for 24 hours above a Share with User section holding a recipient address, a Viewer permission picker, a checked Notify by email box, an optional plain-text message, and an Active Shares list showing a link with twelve views and a user share marked no expiration] Typing an address opens the two controls that decide what lands in the recipient's inbox: **Notify by email**, checked by default, and an optional **Message**. The section explains its own rules in place, including the one people are most likely to guess wrong: access lasts until you revoke it, and a recipient with no account still gets in, view-only, through single-use links emailed to them. ### Every field, and what it decides Once you know what each field does, any share takes well under a minute. The reference below is grouped by which half of the dialog the field belongs to, because a few of them exist on one side and are deliberately refused on the other. Every field in the Share dialog, and what it decides - Share by Link Audience Signed-in users (default) or Anyone with the link The access mode for the link. Anyone with the link is never the default and warns you when you choose it. - Share by Link Expires in a duration such as 24 hours or 7 days The link stops resolving when the duration runs out, and the row in the share list reads as expired rather than failing quietly. - Share by Link Options: notice text and expiration countdown up to 500 characters; empty hides the notice Defaults to "Proprietary & Confidential. Only share with authorized viewers." Replace it with something specific ("Q3 board meeting, do not redistribute"), or empty it out. The same panel hides the expiration countdown when the timing itself is sensitive. - Share with User Recipient address one email address Paste from a mail client and the Example User form is reduced to the bare address as the field loses focus, so what you see is what gets stored and mailed. Anything that names no single routable address is refused outright rather than stored raw. - Share with User Permission Viewer (default) or Editor Viewer opens and downloads. Editor can additionally update the asset content. A guest opening through a one-time link is view-only regardless, even when the share grants Editor. - Share with User Notify by email checked by default Clear it to share quietly. The share is created either way; only the email is suppressed. Leaving it checked does not force an email either, because the recipient’s own preferences still decide. - Share with User Message optional, up to 500 characters, plain text Quoted in the email and attributed to you. It travels with that one notification and is stored nowhere, so a quiet share carries no note anywhere. Markup and links are refused rather than escaped and delivered, because a plausible link inside a trusted platform email is a phishing vector however it is encoded. The dialog is the same whether the asset is a dashboard, a report, a chart, an export, or a collection. Collections run on the same sharing system, so the recipient of a shared collection reaches its items through the same share they were given. ### Expiration belongs to links One rule is worth stating on its own, because it is the thing most likely to trip up a reader who learned the old model. Two lifetimes, one revoke The control that surprises people moving from the old model is that expiration is a link concept, not a universal one. A link takes a duration because the URL is the credential and a bounded life limits what a copy is worth. A share addressed to a person does not take one, and sending an expiration alongside a recipient is refused rather than silently resolved one way or the other. Revocation is the control that spans both, and it is the one you should expect to use. ### What the recipient actually receives Leave Notify by email checked and your recipient gets a real message, not a silent permission grant they will discover next time they happen to open the portal. The parts below are what makes that message worth sending and worth trusting on the other end. What lands in the recipient's inbox - A link to the item, not to a search box The message opens on the exact dashboard, report, or collection you shared, not on a portal home page the recipient then has to navigate. For a stakeholder who opens Plexara twice a quarter, that difference decides whether your work gets read on the spot or gets left for later. - Your note, quoted and attributed to you The Message field is rendered as a quoted block with your name on it, which is what turns a share notification into something the recipient can act on. "Here is the Q3 revenue breakdown you asked about" answers the question a bare link leaves open, which is why you are receiving this at all. - A way out that needs no login The unsubscribe link in the footer works without signing in, and so does the unsubscribe button your recipient's own mail client offers. Following the footer link opens a confirmation page with a single button rather than opting anyone out on the spot, because corporate mail security opens links in messages before a person ever sees them, and an opt-out nobody asked for is worse than an extra click. - Mail that reaches the inbox It renders in the mail clients your recipients actually use, threads properly when they reply, and carries the sending details that stop filters treating it as junk. Nobody asks for any of that until a share they sent to an external reviewer turns out to have been sitting in a spam folder for a week. [Image: The Asset Viewer opened on a shared Monthly Sales Trends line chart, with Preview and Source toggles and Feedback, Delete, Download, and Share buttons in the header; the chart plots twelve monthly points rising from March to February.] The link in the email opens the item itself. The recipient lands on the asset, not on a search box or an inbox, and can read it, leave feedback, or download it right there. ### When your recipient has no Plexara account The old answer to "the auditor does not work here" was a public link, which is a wide grant for a narrow need. There is now a path that keeps the item restricted to one named address and still lets that person read it without an account. A recipient with no Plexara account, step by step 1. 01 They open your link and are asked to sign in A restricted share does not resolve for a signed-out visitor. Instead of a dead end that reads like a broken link, they get a page offering a sign-in that returns them to your item afterwards. For a colleague who does have an account, that is the whole story. 2. 02 With no account, they ask for a one-time link The same page offers "Email me a one-time view link". The link is sent to the address your share names, never to an address the visitor types in, so nobody talks their way into your work by typing their own email on your share page. 3. 03 The link opens a guest session for that one item It expires in fifteen minutes and dies after its first use, so a forwarded or replayed link is worth nothing. The session is scoped to that single share for the current visit: they can view and download, they cannot edit even if you granted Editor, and they never reach the portal around it. 4. 04 They come back by asking again Each viewing session starts with a fresh request, which is what keeps an emailed share strictly safer than a public URL: there is no standing credential sitting in their mailbox. Revoking the share ends any guest session already open, immediately. This is the answer to the question that used to force a public link. An external reviewer with no account can read your dashboard without you widening the audience to everyone holding a URL. ### Delivery is the recipient’s decision You control whether an email is offered. The person receiving it controls whether it arrives, and in what shape. Understanding that split is what stops you from misreading a quiet inbox as a broken platform. What actually decides whether an email is sent - Immediate, daily digest, or off Each person picks a delivery mode in Settings. Immediate is the default and sends one email per event. Daily collapses the day into one digest, so a heavy sharing day reaches them as a single message. Off drops their events at the moment they would have been queued. - Per category, not all or nothing Shares, comments and feedback, and mentions toggle separately. Somebody who has muted thread chatter still hears when a comment addresses them by name, which is the point of keeping mentions in their own category. - Your toggle can suppress, never compel Clearing Notify by email removes the email. Leaving it checked does not add one, because the recipient decides. If a colleague tells you they never got your share, the first question is their delivery mode, not yours. - Preferences follow the address, not the account They are keyed to the bare email address, so somebody with no Plexara account still has preferences and can still opt out from the unsubscribe link in any message. If they later change their mind, the share landing page offers a Resume notification emails action, so getting back in does not mean asking you to fix it. - Opting out stops notifications, not transactional mail A one-time view link is something the recipient asked for by pressing a button, so it is sent directly rather than queued: never deferred into tomorrow’s digest, and never suppressed by an opt-out. Somebody who muted Plexara entirely can still read what you shared with them. - Nobody is notified of their own action You never get mail about your own share or your own comment. The rule is applied where every trigger passes through rather than per feature, and addresses are compared in normalized form, so an owner recorded as "Display Name " is still recognized as the person who did it. One thing the preference model never touches is the share itself. The share is created and the access is granted whatever happens to the email, so a notification that is muted, digested, or delayed never costs your recipient their access. ### How you know what happened Two surfaces answer two different questions, and it is worth knowing which one to open. The share list on the asset is your record of what you gave away. Recent notifications in Settings is your record of what you were told. Both are readable at a glance, and this is the same [audit and access surface](https://plexara.io/learning/mcp/governance-personas-and-access) the platform gives you everywhere else. Where the record lives - Active Shares, on the asset What did I share, with whom, and has the link been opened? Every share you created is listed with its recipient or access mode, the permission, and its expiration or the fact that it has none. Link rows carry a view count, which is the closest thing to a read receipt the platform offers and is usually what you actually wanted to know. Revoke is on the row. - Settings, Recent notifications What has Plexara actually sent me? The subject, category, and delivery status of every notification addressed to you, newest first, sitting directly beneath the preferences that govern them: what should I be told, and what was I told. It is recent activity rather than an archive, and the panel states its own window. Anything that never went out reads "Not delivered". Recent notifications is scoped to you and only you: it answers what you were told, not what a colleague was told. When a share email genuinely appears to have gone missing, the person who can see every recipient's delivery row, with the reason a send failed, is an administrator on the Notifications tab. ### End to end: from chat to inbox to revoke A complete share starts in a chat session and ends in somebody else’s inbox. The six steps below cover the full arc, and the shape is the same for every asset and for collections. End to end: chat, to share, to inbox, to revoke 1. 01 Build the asset Chat with the agent "Build a Q3 2025 regional sales dashboard and save it as Q3 2025 regional review." The agent creates the asset and hands back a portal link. Same as 301. 2. 02 Open the asset and click Share Plexara portal The sharing controls sit next to the content, which is the point: you decide who sees this with the work itself in front of you. 3. 03 Name the person, or mint a link Plexara portal Type the recipient address for a share addressed to a person, pick Viewer or Editor, and click Share. For an audience rather than a person, use Share by Link instead: pick the audience, pick an expiration, create. 4. 04 Write the note, or share quietly Plexara portal Leave Notify by email checked and add a line saying why you are sending it. Clear the checkbox when an email would be noise, for instance when you are about to hand them the link in person or in a thread anyway. 5. 05 Your note lands in their inbox Recipient's inbox If their delivery mode is daily, it arrives in the next digest instead. If they have an account, the link opens the item once they are signed in. If they do not, the landing page offers them a one-time view link at the address you named. 6. 06 Check the share list, revoke when the work is done Plexara portal Active Shares shows every share on the asset with its audience, permission, expiration, and, for links, how many times it has been opened. Revoke any row and access stops on the next attempt, including any guest session open at that moment. Only step 01 happens in chat. The rest is portal work, because recipient, permission, audience, expiration, and the note you are about to send are things you want on one screen before you commit. ### Why sharing happens in the portal, not the chat A natural question once you have used the agent for everything else: can I tell the agent to share an asset? The answer is mostly no, and the reason is deliberate. Why the agent does not handle most sharing The one agent-driven exception is **Trino Export** 's (`trino_export`) `create_public_link` option, covered in [302](https://plexara.io/learning/assets/exporting-data). It exists because export-then-share is a common follow-on and bundling it saves a portal trip. Everything else stays in the portal, and the reason is stronger now than it was when sharing was only a permission grant: a share addressed to a person sends mail to a real inbox, with a note carrying your name on it. Recipient, permission, audience and the text of the message belong on one screen where you can read them back before they leave, not in a chat turn where the agent fills in what it guessed you meant. ### Revocation, the control that spans both Expiration handles the planned end of a link. Revocation is what you reach for when something changes before then, and it is the only ending a share addressed to a person has. The owner clicks Revoke on the share row and the next attempt fails, the same [governance at execution time](https://plexara.io/learning/insights/governance-at-execution-time) the platform applies to every other access decision. Revoke when you stop trusting the share, not when you remember to A link takes an expiration and most of its lifecycle then takes care of itself. A share addressed to a person does not, deliberately: it lasts until you end it, because you rarely know in advance how long a colleague will need something. Revocation covers both, and covers the unplanned cases either way, whether an auditor finished early or a link reached somebody outside the audience you meant. The owner clicks Revoke, the next attempt fails, any guest session opened through that share ends immediately, and the row stays in the list so you can see later who had access and when it was cut. ### The conversation your share starts Sharing an asset does more than grant a read. It puts the recipient inside the feedback thread on that item, which means your sharing decisions are also decisions about who gets mail when somebody comments. The rules below are worth knowing before you share something contentious with fifteen people. Who hears about a comment on something you shared - A comment reaches the people who can already open the item When somebody opens a thread on your dashboard or replies to one, the notification goes to the item’s owner, the thread’s author, and the people it is shared with. Sharing an asset is therefore also a decision about who gets pulled into the conversation on it. - An @-mention moves you to a different category, not an extra email Type @ in a comment and the composer suggests the people who can already open the item. Anyone the comment names is notified as a mention instead of as general thread activity, so one comment never sends the same person two emails, and somebody who muted thread chatter still hears their own name. - On a widely shared item, the people named by hand get through Mentions are queued ahead of the general fan-out, and how much mail one author can generate is bounded. On an asset shared with a large group, that ordering is what keeps a comment addressed to two specific people from being buried behind everyone else’s copy. - You cannot mention somebody into access A mention sends the item’s title and an excerpt of the comment, so it may only go to somebody who could open the item anyway. Type an address by hand for somebody without access and the composer says so while you are writing; the mention posts as ordinary text and delivers nothing. Share the item with them first, then mention them. ### Habits worth building A few habits will keep your share list short and meaningful instead of long and full of links you no longer remember authorizing. The panel below is the short version. Habits worth building around shares - Name the person when you know the person A share addressed to a colleague is worth nothing forwarded, tells you in the share list exactly who has access, and puts your note in front of them. Reach for a link when the audience is a room rather than a person. - Put an expiration on every link you mint The URL is the credential for a link share, so a duration limits what a copy is worth. Pick one even when you do not expect to need it. Shares addressed to people do not take one, and do not need one: you revoke those instead. - Write the note A share email with no message is a link and a name. One sentence saying what this is and what you want from them is the difference between a dashboard that gets read and one that gets archived unopened. - Send an external reader a share, not a public link Naming their address and letting them request a one-time view link keeps the item restricted to them. Anyone with the link is for the case where you genuinely cannot know who is reading. - Check delivery mode before you assume mail is broken A colleague on daily digest gets your share tomorrow morning, and one who set shares to off gets nothing at all, by their own choice. Both look identical to you: an email you sent that produced no reply. None of these depend on remembering to clean up later. Granting the narrowest access that does the job is the same [least-privilege starting point](https://plexara.io/learning/insights/closed-by-default-access) the platform applies to connections, tools, and personas. ### What 304 covers Sharing one asset at a time is the right shape when the work is a single dashboard or a single export. Sharing a coherent set, where the recipient should see the dashboard, the supporting report, and the underlying data export as one briefing, is the case for collections. The next lesson covers them. Same dialog, same access modes, same email, applied to a bundle of assets. Where this leads Sharing one asset is useful. Sharing a related set of assets, all at once, as one navigable briefing, is where collections come in. [304 - Creating collections](https://plexara.io/learning/assets/creating-collections) covers how to bundle a dashboard, a supporting report, and the underlying export into a single shareable unit, with the same dialog, the same access modes, and the same email you just learned applied to the bundle. The recipient opens one link and sees the whole briefing, its items included. ### Key terms Nine terms cover the vocabulary of sharing in Plexara. The first three are what you create and who it opens for. The next three are the email you send with it. The last three are how a recipient without an account gets in, how they control what reaches them, and how a share ends. Key Terms Share addressed to a person A share naming one email address, at Viewer or Editor permission, restricted to that recipient. It carries no expiration: it lasts until the owner revokes it. Share by Link A token URL of the form `{base}/portal/view/{token}`, minted with an expiration and an audience. The share list reports how many times each link has been opened. Access mode What decides who a share opens for: restricted (the named recipient), signed-in users (any Plexara account holding the URL), or anyone with the link (no sign-in at all, and never the default). Notify by email The toggle, checked by default, that decides whether naming a recipient also mails them. Clearing it shares quietly. Leaving it on hands the decision to the recipient, whose own preferences govern delivery. Sharer note The optional plain-text message quoted in the share email and attributed to you. Up to 500 characters, links and markup refused, carried by that one notification and stored nowhere. One-time view link How a recipient with no Plexara account opens a share: a single-use link, emailed only to the address the share names, valid fifteen minutes, opening a view-only guest session scoped to that one item. Delivery mode Each person’s own setting for how notifications reach them: immediate (the default), daily digest, or off, with separate toggles for shares, comments and feedback, and mentions. Recent notifications The panel in your Plexara Settings showing the subject, category, and delivery status of the notifications addressed to you, directly beneath the preferences that govern them. Revocation Owner-only operation that cuts a share on the next attempt and ends any guest session opened through it. The row stays in the share list as the audit record. On this page [Previous 302 - Exporting data](https://plexara.io/learning/assets/exporting-data) [Next 304 - Creating collections](https://plexara.io/learning/assets/creating-collections) ### Related reading product [Product 102 - Tokens and your budget Every LLM interaction is priced and rate-limited in tokens. What a token is, how much text fits a budget, and how to avoid wasting tokens on useful answers.](https://plexara.io/learning/ai-concepts/tokens-and-your-budget) [Product 105 - What is an AI agent? An AI agent is not a chatbot and not magic. It is a short loop (think, call-tool, observe, think again) on top of a language model. Mental model first.](https://plexara.io/learning/ai-concepts/what-is-an-ai-agent) [Product 202 - Your first day with Plexara A new Plexara user gets connected, sends a first question, and platform_info takes over. Walks through day one and how subsequent turns inherit context.](https://plexara.io/learning/mcp/first-engagement) --- # Creating collections URL: https://plexara.io/learning/assets/creating-collections/ > A board briefing is rarely one dashboard. It's a dashboard plus a summary plus the underlying data, opened from a single link in the order you chose. Plexara calls that packaging unit a collection. You can ask the agent to assemble one during the same session that produced the assets, or build one by hand on the Collections page. This lesson covers both. Product 10 min read ## 304 - Creating collections A board briefing is rarely one dashboard. It's a dashboard plus a summary plus the underlying data, opened from a single link in the order you chose. Plexara calls that packaging unit a collection. You can ask the agent to assemble one during the same session that produced the assets, or build one by hand on the Collections page. This lesson covers both. On this page ### What you will take away from this lesson A board briefing is rarely one dashboard. It is a dashboard, plus a written summary that leads with the takeaway, plus the underlying CSV in case someone wants to pivot, plus a methodology note for the auditor. Article [303](https://plexara.io/learning/assets/sharing-your-work) was about sharing one of these. Article 304 is about packaging several of them so the recipient opens one link and sees the whole story in order. The packaging unit is a **collection**. It has a name, a description, an ordered list of sections, and a list of asset references inside each section. You can build one two ways. The agent can assemble a collection during the same session it produced the assets, which is usually the faster path. Or you can build one by hand on the portal Collections page from assets you have already saved. This article covers both. Learning Objectives 1. 01 Describe what a collection is in Plexara: a named, ordered set of sections, each holding a list of asset references, with its own description and share controls. 2. 02 Build a collection two ways: ask the agent to assemble one during the session that produced the assets, or build one by hand on the portal Collections page. 3. 03 Read the six Manage Asset actions for collections (create_collection, list_collections, get_collection, update_collection, delete_collection, set_sections) and predict which one the agent will pick. 4. 04 Recognize that set_sections is a full replacement, not an append, and write prompts that respect that. 5. 05 Share a collection the same way you share a single asset (covered in 303): one link, the recipient sees the whole briefing. ### Where this lesson sits in the curriculum 301 built assets, 302 produced exports, 303 covered sharing one of them. 304 is about bundling several into one navigable thing your stakeholders can open from a single link. 300 Series: getting more out of Plexara [Open index](https://plexara.io/learning/assets) - [301 Creating reports and dashboards How 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.](https://plexara.io/learning/assets/creating-reports-and-dashboards) - [302 Exporting data When you need a spreadsheet a teammate can sort, or a data file for another system, instead of a view.](https://plexara.io/learning/assets/exporting-data) - [303 Sharing your work Name 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.](https://plexara.io/learning/assets/sharing-your-work) - [304 Creating collections Bundle 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.](https://plexara.io/learning/assets/creating-collections) - [305 Editing what you already have Name 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.](https://plexara.io/learning/assets/editing-what-you-already-have) - [306 How an asset was built The 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.](https://plexara.io/learning/assets/how-an-asset-was-built) - [307 Turning a comment into something the agent remembers A 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.](https://plexara.io/learning/assets/feedback-that-becomes-knowledge) - [308 Reproducible prompts Save 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.](https://plexara.io/learning/assets/reproducible-prompts) The 300 series is practical recipes for working with Plexara day to day. It assumes the mental model from [205](https://plexara.io/learning/mcp/assets-dashboards-reports-and-data). ### Why a collection is the right unit for a briefing Most analyses end up in more than one shape. The dashboard answers the click-around questions. The summary answers the executive who only has two minutes. The CSV answers the analyst who wants to pivot the numbers herself. Sending three links separately puts the burden of assembly on the recipient. A collection moves that work to you, once, where you can also decide what order makes sense for whoever you're sending it to. What a collection gives you that a single asset cannot - One link for the whole briefing Stakeholders open one URL. They see the dashboard, the summary, and the data in the order you chose. No "see also" emails with three additional links to chase. - Order is part of the message A briefing for an exec usually leads with the takeaway and tucks the supporting data at the end; an analyst opening the same set of assets would prefer the data up front. Sections let you author that order rather than hope the recipient reads in it. - Findable as a unit A collection shows up on the Collections page as a single named entry with its own description. Search finds it; share controls apply to the whole thing; revocation cuts access to all the contained assets at once. ### What a collection is made of A collection has three nested pieces, with hard caps that exist mostly so a collection that is trying to be a full project does not pretend it is a single briefing. The panel below names each piece and the caps that apply. What a collection is made of - Collection Description up to 50,000 characters. The outer container. Has a name, a description for context, and an owner. Sharing applies to the collection as a whole, not to individual sections inside. - Section Up to 50 sections per collection. Title up to 255 characters, description up to 10,000. An ordered group inside the collection. Has a title and an optional description that the recipient reads as the section heading. Sections render in the order you set; the recipient navigates them like a document table of contents. - Item Up to 100 items per section. A reference to an asset inside a section. The collection does not duplicate the asset; it points to it. Updating the underlying asset updates what the collection's viewers see next time they open the section. The collection is governed and shared like any asset: same owner-only mutations, same Share dialog from 303, same revocation. Article 305 covers editing existing assets (including assets inside a collection). ### Two ways to build one Both paths produce the same kind of collection, which is good: a teammate sharing one with you cannot tell which path you used. The agent path is faster when the assets came from the conversation you are still in. The portal path is the right one when you are bringing together work you already saved, especially when section order is something you want to see on screen. Two ways to build a collection - Ask the agent during a session When to pick this You just produced the assets in the same conversation. The agent has them in working context and can bundle them in one prompt. How it works The agent calls Manage Asset (manage_asset) with action=create_collection, plus an initial sections array containing the asset_ids it just produced. One round trip; one new collection. Example "Bundle the Q3 regional dashboard, the exec summary, and the Southwest transactions CSV into a collection called Q3 2025 Board Briefing. Put the dashboard in section 1 (Overview), the summary in section 2 (Takeaways), and the CSV in section 3 (Source Data)." - Build it by hand in the portal When to pick this The assets you want to combine were produced over time, sit in your Assets page already, and you want fine-grained control over section structure as you assemble them. How it works Open the Collections page, click New Collection, name and describe it, add sections, drag in assets from your Assets list, save. Example Click New Collection; name it "Q3 2025 Board Briefing"; add three sections; pick assets from the asset picker; reorder by dragging. The agent path is usually faster when the assets came from the same session. The portal path is the right one when you are assembling old work, or when section order matters enough that you want to see it on screen while you build. ### The six agent actions for collections When the agent works on a collection, it is calling Manage Asset (manage_asset) with one of six action values. You almost never need to know these by name, but they show up in tool-call logs, in the [audit trail](https://plexara.io/learning/mcp/governance-personas-and-access), and in any conversation with an administrator about who did what. The six Manage Asset actions for collections - action=create_collection Creates a new empty collection (or one with initial sections if you pass them). Returns collection_id and a portal URL. The agent calls this when you ask for a new collection. - action=list_collections Returns your collections, with name, description, owner, timestamps. Supports search and pagination. The agent reaches for this when you ask 'do I already have a collection for X?' - action=get_collection Returns one collection by collection_id, with all sections and the asset references inside each. The agent reads a collection before modifying it, so the next set_sections call respects what is already there. - action=update_collection Changes the name or description of an existing collection. Does not touch sections. You renamed the briefing, or want to add context to the description. - action=set_sections Replaces the entire section structure of a collection with the one you pass. Not additive. You are adjusting which assets are in the collection, or re-ordering sections. Important: the agent must first get_collection if it intends to preserve existing sections. - action=delete_collection Soft-deletes a collection. The collection becomes inaccessible; the underlying assets are untouched. You are done with the briefing and want it out of your Collections list. You almost never name these actions in a prompt; the agent picks the right one from your wording. The names matter when you read the agent's tool-call log and want to recognize what just happened. ### The one mechanic that surprises people Every other Manage Asset action is intuitive. set_sections is different because it is a full replacement rather than an append. Knowing this changes how you phrase a follow-up prompt that adds or re-orders sections. set_sections replaces the whole structure, it does not append This is the one collection mechanic that surprises people. When the agent calls `set_sections`, the input is the complete list of sections the collection should have, in order. Whatever was there before is gone. So if you say “add a fourth section called Risks” without specifying the existing three, a naive agent run can erase the first three. Plexara's default prompts steer the agent to `get_collection` first, then call `set_sections` with the existing sections plus the new one. If you are writing your own prompt for collection edits, ask explicitly: “Read the current collection, then call set_sections with the existing sections plus a new Risks section after Takeaways.” The result is the same; the prompt removes the ambiguity. ### What this looks like in practice A short session that builds a collection from three assets the agent just produced, then comes back later to add a fourth section without losing the first three. The second turn is the one that demonstrates the prompt pattern that respects set_sections. Build a collection, then add a section without losing the first three You I have three assets from today: the Q3 regional sales dashboard, the Q3 exec summary, and the Southwest transactions CSV. Bundle them into a collection called Q3 2025 Board Briefing. Section 1 is Overview (the dashboard), section 2 is Takeaways (the exec summary), section 3 is Source Data (the CSV). Add a one-paragraph description that says this is the package for the May 20 board meeting. Agent Done. I created the collection with all three sections in the order you specified. Collection: portal/collections/{collection_id} Sections: Overview (1 asset), Takeaways (1 asset), Source Data (1 asset). The collection inherits the same Share controls as an individual asset. To share with the board, open the collection in the portal and use the Share dialog from [303](https://plexara.io/learning/assets/sharing-your-work). You Actually, add a fourth section at the end called Risks, with the refund-rate anomaly investigation we did last month. Keep the first three sections as they are. Agent I read the current collection so I would not lose the first three sections, then replaced the structure with all four. The order is now Overview, Takeaways, Source Data, Risks. The refund-rate investigation is the only item in the Risks section. Same collection URL, no change required on any share links that already point to it. The second turn is the one that teaches the most. The user said “keep the first three sections as they are” explicitly; that single phrase is what steered the agent to read the collection first and then call set_sections with the full list. Even a default-trained agent benefits from the reminder. ### Building one by hand on the portal Sometimes the work you want to bundle is old: a dashboard from last quarter, a report from a different analysis, a CSV someone else produced. The agent never had these in a single session and cannot bundle them in a single prompt. The portal Collections editor exists for this case. Building a collection by hand 1. 01 Open Collections, click New Collection From the portal sidebar, open the Collections page. Click New Collection. The editor opens with a name field and an empty section list. 2. 02 Name and describe the collection The name shows up on the Collections page and in search. The description is the briefing context the recipient reads before navigating into sections. Use it to say what this collection is for and who it is for. 3. 03 Add sections; drag assets into each Click Add Section to create a section, name it, optionally describe it. Open the asset picker and drag in assets from your Assets list, which keeps loading as you scroll, so old work is reachable however much you have saved. You can re-order sections and items within a section at any point. 4. 04 Save The collection is now in your Collections page. It has a portal URL like /portal/collections/{id}. From here, share it the same way you share a single asset. The portal collection editor is the right tool when you are assembling old work or fussing over section order. Once it is shaped, share it via the same dialog from 303. [Image: The Collections tab of the Assets page with Mine, Shared, and All filters, a search box, a New Collection button, and a grid of collection cards such as Q4 Performance Review, Inventory Health Monitor, and Data Quality Playbook, each with a thumbnail mosaic, a description, tags, and a date.] Step one happens here: New Collection, top right. Every collection you can reach appears as a card with a thumbnail mosaic of the assets inside it. [Image: The Edit Collection page for Q4 Performance Review with a Name field, a markdown Description editor with side-by-side preview, a Settings card with a Thumbnail Size picker, and a Sections list showing an Overview section holding three assets, with an Add Section button.] The editor itself. Name and description at the top, a thumbnail-size setting, then Sections, each with its own name, description, and drag handle. Add Section is where a briefing gets its structure. [Image: The Asset Viewer showing a Q4 revenue dashboard opened from a collection, with a Back link, Preview and Source toggles, a v5 (current) version picker, Feedback, Delete, Download, and Share buttons, KPI tiles, and region and product breakdowns.] Opening an asset from a collection lands in the same viewer as anywhere else, Back link and all. The asset stays one object; the collection only points at it. ### Prompting tips for the agent path Three small phrasings make the agent path consistently produce what you wanted. None of these require knowing how Manage Asset works internally. Prompting tips for the agent path - Name the sections in the prompt. "Section 1 is X, section 2 is Y" routes the agent straight to set_sections in the right order. "Put them in some sensible order" routes the agent to a guess. - Say "keep the existing sections" when you only want to add. Without that phrase, the agent may interpret a follow-up edit as a full replacement and lose work. - Name the collection memorably. The Collections page lists collections by name. "Q3 2025 Board Briefing" survives next quarter; "Briefing" does not. ### Sharing a collection Collections share the same way assets do. The [Share dialog from 303](https://plexara.io/learning/assets/sharing-your-work) applies to the whole collection; the recipient opens one link and navigates the sections. Sharing a collection works exactly like sharing an asset A collection has the same Share dialog as any asset ([303](https://plexara.io/learning/assets/sharing-your-work)). You can share with named teammates as viewer or editor, or generate a public link anyone with the URL can open, both with optional expiration and notice text. The recipient opens the collection URL and navigates the sections like a document. The permission applies to the collection container; the assets inside open from within it. ### Limits The caps are generous enough that you should rarely think about them. They exist so a collection that is genuinely trying to be a full project of its own gets caught before it becomes one. Hard caps you will not bump into in normal use A collection holds at most 50 sections. Each section holds at most 100 items. Collection descriptions are capped at 50,000 characters; section descriptions at 10,000; section titles at 255. If you are bumping these limits, the collection is probably trying to be two collections. ### What 305 covers A collection wraps assets. Eventually one of those assets needs to change: a number revised, a chart updated, a sentence rewritten. 305 covers [editing existing assets in place](https://plexara.io/learning/assets/editing-what-you-already-have) through Manage Asset action=update, including how the platform preserves earlier versions and how to roll back without breaking the share links you already gave to people. Where this leads Collections wrap assets, but assets themselves drift over time: a number gets revised, a chart gets updated, a sentence gets rewritten. [305 - Editing what you already have](https://plexara.io/learning/assets/editing-what-you-already-have) covers updating an asset in place through Manage Asset action=update, what versions are preserved, and how to roll one back without breaking the share links you already gave to people. ### Key terms Six terms cover the vocabulary of collections. The first three are the structure. The next two are the agent actions that come up most often. The last one is the portal surface where collections live. Key Terms Collection col_* A named, ordered set of sections, each holding asset references. Has its own description, owner, share controls, and portal URL at /portal/collections/{id}. Section sec_* An ordered group inside a collection, with a title and optional description. Up to 50 sections per collection. Title up to 255 characters; description up to 10,000. Item item_* An asset_id reference inside a section. The collection does not copy the asset; it points to it. Up to 100 items per section. create_collection Manage Asset (`manage_asset`) action that creates a new collection. Accepts name, description, and an optional initial sections array. Returns collection_id and a portal URL. set_sections Manage Asset action that replaces the entire section structure of a collection. Not additive: whatever was there before is gone. The agent should get_collection first if it intends to preserve existing sections. Collections page The portal page that lists your collections with name, description, owner, and creation date. New Collection opens the editor for building one by hand. On this page [Previous 303 - Sharing your work](https://plexara.io/learning/assets/sharing-your-work) [Next 305 - Editing what you already have](https://plexara.io/learning/assets/editing-what-you-already-have) ### Related reading product [Product 102 - Tokens and your budget Every LLM interaction is priced and rate-limited in tokens. What a token is, how much text fits a budget, and how to avoid wasting tokens on useful answers.](https://plexara.io/learning/ai-concepts/tokens-and-your-budget) [Product 105 - What is an AI agent? An AI agent is not a chatbot and not magic. It is a short loop (think, call-tool, observe, think again) on top of a language model. Mental model first.](https://plexara.io/learning/ai-concepts/what-is-an-ai-agent) [Product 202 - Your first day with Plexara A new Plexara user gets connected, sends a first question, and platform_info takes over. Walks through day one and how subsequent turns inherit context.](https://plexara.io/learning/mcp/first-engagement) --- # Editing what you already have URL: https://plexara.io/learning/assets/editing-what-you-already-have/ > When the dashboard you saved last week is mostly right but needs a fix, you do not re-create it from scratch. You edit the existing asset in place. The link the recipient already has keeps working, the version history accumulates on one asset instead of fragmenting across copies, and any collection that references it picks up the change. This lesson covers the three kinds of edit (metadata, content, revert), what each one does to the version history, and the portal vs agent path. Product 10 min read ## 305 - Editing what you already have When the dashboard you saved last week is mostly right but needs a fix, you do not re-create it from scratch. You edit the existing asset in place. The link the recipient already has keeps working, the version history accumulates on one asset instead of fragmenting across copies, and any collection that references it picks up the change. This lesson covers the three kinds of edit (metadata, content, revert), what each one does to the version history, and the portal vs agent path. On this page ### What you will take away from this lesson Article [304](https://plexara.io/learning/assets/creating-collections) 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. Most of those changes are small, and small changes have their own move: name the part you want changed and let the agent edit that part. “Make the revenue chart green” or “fix the heading typo” is enough. The agent does not rebuild the document around your correction, which is why the change is fast, cheap, and provably confined to what you asked about. That is the first half of this lesson. The second half is what all of it does to the record. Manage Asset (`manage_asset`) covers targeted edits, whole-body replacement with action=update, list_versions to read history, and revert to roll back. All of them are owner-only on the agent path. Editor-share recipients can update content from the portal, which is covered in passing at the end. Learning Objectives 1. 01 Make a small change by naming the part you want changed, so the agent edits that piece and leaves the rest of the document alone. 2. 02 Ask the agent what is in a report, so a phrase like "the second chart" becomes something it can act on. 3. 03 Compare two versions to see what a change did, without reading both. 4. 04 Edit 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. 5. 05 Tell 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). 6. 06 Read an asset version history and pick the right version number to revert to. 7. 07 Recognize that revert is append-only: it creates a new version with old content, it does not erase newer ones. 8. 08 Know 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 [Open index](https://plexara.io/learning/assets) - [301 Creating reports and dashboards How 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.](https://plexara.io/learning/assets/creating-reports-and-dashboards) - [302 Exporting data When you need a spreadsheet a teammate can sort, or a data file for another system, instead of a view.](https://plexara.io/learning/assets/exporting-data) - [303 Sharing your work Name 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.](https://plexara.io/learning/assets/sharing-your-work) - [304 Creating collections Bundle 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.](https://plexara.io/learning/assets/creating-collections) - [305 Editing what you already have Name 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.](https://plexara.io/learning/assets/editing-what-you-already-have) - [306 How an asset was built The 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.](https://plexara.io/learning/assets/how-an-asset-was-built) - [307 Turning a comment into something the agent remembers A 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.](https://plexara.io/learning/assets/feedback-that-becomes-knowledge) - [308 Reproducible prompts Save 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.](https://plexara.io/learning/assets/reproducible-prompts) The 300 series is practical recipes for working with Plexara day to day. It assumes the mental model from [205](https://plexara.io/learning/mcp/assets-dashboards-reports-and-data). ### 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. ### Name the part you want changed 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. Three moves for changing part of a document - Ask for the one change you want Name the part, not the document. "Make the revenue chart green." "Fix the typo in the Methodology heading." The agent edits that part of the report in place instead of regenerating the document, so everything you did not ask about is provably unchanged, and the change costs what the change is worth rather than what the whole report is worth. "In the Q3 board report, recolor the revenue chart from blue to green. Leave the rest of the report alone." - Ask what is in it when your description is loose The agent can list what a report contains: its headings, and on a dashboard the individual panels and charts with their sizes. That listing is what turns "the second chart" or "the section about refunds" into a specific thing it can act on. Reach for it when your description could match more than one thing, or when you are editing a document someone else built. "List the sections and charts in the Q3 board report, then update the one showing Southwest revenue." - Compare two versions instead of reading both When you want to know what a change actually did, ask for the difference between two versions. You get back the parts that changed, which is a far shorter read than the two documents it came from, and it is how you check a correction landed the way you meant it to. "Show me what changed between version 4 and version 5 of the Q3 board report." Naming a part works on the documents that have parts: HTML reports, interactive dashboards, SVG diagrams, and markdown reports, where the part is a heading. A CSV or a JSON file has no named parts, so on those you quote the text you want replaced instead. Whichever route you take, the result is an ordinary new version, so everything the rest of this lesson says about history and revert still applies. ### Three kinds of change 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](https://plexara.io/learning/mcp/governance-personas-and-access) 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. 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 Both routes count here: recoloring one chart by naming it, and replacing a whole dashboard with a rebuilt one. Either way the new content lands in S3 under a fresh version key, current_version bumps, and older versions are preserved. A targeted edit is not a lesser kind of change to the record; it is the same kind, described more precisely. "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 changed 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 What the version was for. A targeted edit carries the summary you gave it ("correct the YoY figure"), or a generated one naming how many edits it applied. A whole-body replacement reads "Content updated via MCP", and a rollback reads "Reverted from v{N}". This is the field that makes a history worth scanning, so it is worth saying what a change is for when you ask for it. - size_bytes Body size at the time of the version. A sudden drop or spike is worth noticing when you are auditing. - content_type What kind of file this version was: an HTML report, a markdown document, a CSV. 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. [Image: The Asset Viewer on a Q4 revenue dashboard with a v5 (current) version picker beside the Preview and Source toggles, Feedback, Delete, Download, and Share buttons in the header, and the rendered dashboard with KPI tiles and breakdowns below.] The portal side of the same history. The version picker beside Preview and Source reads v5 (current); the list list_versions returns is what stands behind that picker, one entry per version. ### 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. Revert appends, it does not erase When the agent reverts the asset to version 3, it does not remove version 4 from the history. It creates a new version, version 5, whose body is a copy of version 3. The change_summary on the new version reads “Reverted from v3”. The wrong version is still in the history; your audit trail records that you made a mistake and then made a deliberate choice to roll back from it. If your stakeholder asks why a number changed twice this week, you can show them which version the rollback restored and why. ### 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. Editing rights follow the same [least privilege as the starting point](https://plexara.io/learning/insights/closed-by-default-access) that governs the rest of the platform. The agent path is owner-only; editor shares work through the portal When you ask the agent to update an asset, Plexara checks that you are the owner. An editor share (a user share with permission=editor, from [303](https://plexara.io/learning/assets/sharing-your-work)) lets the recipient open the asset and update its content from the portal, but the agent will not honor the same permission on behalf of the recipient's session. This is intentional: shared editing happens in a UI where the editor can see what they are about to change, not through a chat-driven mutation against someone else's asset. ### 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. A note on the portal edit surface From the asset page in the portal, the Actions row gives you Delete, Download, and Share. Renaming and re-tagging is owner-only (same rule as the agent path; the portal does not let an editor-share recipient change the name or tags). Content editing through the portal is the one thing editor-share unlocks: a recipient with permission=editor opens the asset there and replaces its body. Owners can do the same but typically reach for the agent because the agent already has the data in working memory. Either way, the same versioning rules apply: a content change creates a new version, a metadata change does not. [Image: The Asset Viewer showing a KPI Scorecard Component: a live ACME Corp store performance view with a store selector, six KPI tiles with quarter-over-quarter deltas, and a top-selling categories bar list, under a header with Preview and Source toggles and Feedback, Delete, Download, and Share buttons.] The surface the callout describes. Preview shows the rendered component; Source, beside it, shows the body behind it, which is what a content edit through the portal replaces. Saving that change creates a new version exactly as the agent path does. ### What this looks like in practice 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. One targeted change, one full update, one revert You The revenue chart in the regional sales review is blue and the board deck is green. Change just that chart to green. Agent Done. I found the revenue chart in the dashboard and recolored it in place. Nothing else in the document was touched. New current_version: 3. Change summary: recolor the revenue chart to green. One edit, six lines changed. The rest of the report is what it was. 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 - alice@example.com v3 - 2026-05-15 - recolor the revenue chart to green - alice@example.com v2 - 2026-05-14 - Content updated via MCP - alice@example.com v1 - 2026-05-13 - Initial version - alice@example.com 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 any of it. 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, and the recolor at v3 reads as a recolor rather than as another content change of unknown scope. ### Prompting tips for editing Four small phrasings make the agent path produce what you wanted consistently. None of them require knowing how the Manage Asset actions work internally. Prompting tips for editing - Describe the change, not the deliverable. "Change the subtitle on the revenue chart to Q3 FY26" gets you a targeted edit. "Rebuild the dashboard with the new subtitle" invites the agent to regenerate a document that was fine. - Say "update the existing X" or "edit the X in place" so the agent picks update over save_asset. 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](https://plexara.io/learning/assets/how-an-asset-was-built) and names what it can and cannot tell you (prompts and agent responses, for example, are not in it). Where this leads Editing is one half of the answer to “where did this number come from?” The other half is the provenance Plexara captures automatically at the MCP boundary: which catalog searches and queries the agent invoked during the producing session, with what parameters. Plexara does not see your prompts to the agent or the agent's responses, so the record is a strong correlation, not a step-by-step proof. [306 - How an asset was built](https://plexara.io/learning/assets/how-an-asset-was-built) opens that record and shows how to read it. ### Key terms 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. Key Terms Targeted edit action=patch The Manage Asset (`manage_asset`) action behind “change just this part.” The agent sends the change rather than the whole document, everything outside the named part is left untouched, and the result is an ordinary new version. Outline action=outline What is in a document: its headings, and on a dashboard the panels and charts you can address by name. This is what the agent reads when you say "the second chart" and it needs to know which one you mean. Version comparison action=diff The changed parts between two versions, without the parts that stayed the same. Ask for it when you want to confirm what an edit did instead of re-reading the document. action=update The Manage Asset (`manage_asset`) action that replaces an asset's whole body, or changes its name, description, or tags. Owner-only. Metadata changes do not bump current_version; content changes do. current_version The integer position of the most recent version. Starts at 1 on save_asset. Increments on every content change, targeted or wholesale, 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, your own words on a targeted edit, "Content updated via MCP" for a whole-body replacement, "Reverted from v{N}" for reverts. Editor share A user share with `permission=editor` (from [303](https://plexara.io/learning/assets/sharing-your-work)) that lets a recipient update an asset's content from the portal. The agent path remains owner-only. On this page [Previous 304 - Creating collections](https://plexara.io/learning/assets/creating-collections) [Next 306 - How an asset was built](https://plexara.io/learning/assets/how-an-asset-was-built) ### Related reading product [Product 102 - Tokens and your budget Every LLM interaction is priced and rate-limited in tokens. What a token is, how much text fits a budget, and how to avoid wasting tokens on useful answers.](https://plexara.io/learning/ai-concepts/tokens-and-your-budget) [Product 105 - What is an AI agent? An AI agent is not a chatbot and not magic. It is a short loop (think, call-tool, observe, think again) on top of a language model. Mental model first.](https://plexara.io/learning/ai-concepts/what-is-an-ai-agent) [Product 202 - Your first day with Plexara A new Plexara user gets connected, sends a first question, and platform_info takes over. Walks through day one and how subsequent turns inherit context.](https://plexara.io/learning/mcp/first-engagement) --- # How an asset was built URL: https://plexara.io/learning/assets/how-an-asset-was-built/ > Every asset in Plexara carries two kinds of metadata: descriptive fields the agent fills when it saves the asset (name, description, tags) and that you can edit later, and provenance the platform records on its own. Provenance is the audit trail Plexara captures at the MCP boundary: the catalog searches and queries the agent invoked, with what parameters, in the producing session. This lesson opens that record, names what it can and cannot tell you, and shows how to use it to answer the questions stakeholders ask about a number. Product 12 min read ## 306 - How an asset was built Every asset in Plexara carries two kinds of metadata: descriptive fields the agent fills when it saves the asset (name, description, tags) and that you can edit later, and provenance the platform records on its own. Provenance is the audit trail Plexara captures at the MCP boundary: the catalog searches and queries the agent invoked, with what parameters, in the producing session. This lesson opens that record, names what it can and cannot tell you, and shows how to use it to answer the questions stakeholders ask about a number. On this page ### What you will take away from this lesson Article [305](https://plexara.io/learning/assets/editing-what-you-already-have) covered how the body of an asset changes over time. This article is about everything attached to the asset that is not the body: the descriptive fields the agent fills when it saves (name, description, tags), and the provenance Plexara records on its own (a snapshot of the tool calls the agent made during the producing session). Provenance is worth understanding precisely, because what it captures and what it does not both matter. Plexara sits at the MCP boundary: tool invocations cross that boundary and get recorded; chat content does not. That gives you a useful audit trail of what tools the agent ran in your session, but it is a correlation, not a proof. The agent may have used those tool results, ignored them, or transformed them in ways provenance does not capture. This lesson opens the record, names what it can and cannot tell you, and shows how to use it well. Learning Objectives 1. 01 Distinguish the two kinds of metadata an asset carries: descriptive (name, description, tags) and provenance (the tool calls Plexara observed in the session). 2. 02 Read an asset's provenance: the list of tool invocations Plexara recorded at the MCP boundary, with each call's name, timestamp, and parameters. 3. 03 Understand the limits: Plexara does not see your chat with the agent, and the agent may have used, ignored, or transformed the captured calls. Provenance is the strongest available correlation, not a causal proof. 4. 04 Recognize that provenance is captured at save time, attached to the asset, and not refreshed on subsequent content updates. 5. 05 Answer "what if the label was wrong" from the record, which keeps what the file was called next to what it turned out to be. 6. 06 For Trino Export assets, read the extra fields the export captures automatically: the SQL, the source tables, and the row count. ### Where this lesson sits in the curriculum 305 covered editing the content of an asset over time. 306 covers everything else attached to the asset: the metadata the agent fills and you can edit, and the metadata Plexara records on its own. 300 Series: getting more out of Plexara [Open index](https://plexara.io/learning/assets) - [301 Creating reports and dashboards How 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.](https://plexara.io/learning/assets/creating-reports-and-dashboards) - [302 Exporting data When you need a spreadsheet a teammate can sort, or a data file for another system, instead of a view.](https://plexara.io/learning/assets/exporting-data) - [303 Sharing your work Name 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.](https://plexara.io/learning/assets/sharing-your-work) - [304 Creating collections Bundle 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.](https://plexara.io/learning/assets/creating-collections) - [305 Editing what you already have Name 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.](https://plexara.io/learning/assets/editing-what-you-already-have) - [306 How an asset was built The 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.](https://plexara.io/learning/assets/how-an-asset-was-built) - [307 Turning a comment into something the agent remembers A 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.](https://plexara.io/learning/assets/feedback-that-becomes-knowledge) - [308 Reproducible prompts Save 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.](https://plexara.io/learning/assets/reproducible-prompts) The 300 series is practical recipes for working with Plexara day to day. It assumes the mental model from [205](https://plexara.io/learning/mcp/assets-dashboards-reports-and-data). ### Two kinds of metadata An asset's full record has two halves. One half is descriptive: the name, description, and tags. The agent fills these when it saves the asset, taking cues from your prompt and the session context; you can edit them afterward through the agent or the portal. The other half is provenance: the record of MCP tool calls Plexara observed during the producing session. The descriptive half is editable by the asset's owner; the provenance half is not editable by anyone. Most of this lesson is about the second half, because the first half is already familiar from 301 and 305. The two kinds of metadata an asset carries - Descriptive metadata What it is Name, description, tags. The agent fills these on save based on your prompt and the session context. Indexed for search; shown on the Assets page and the asset viewer. Editable later through the agent or the portal without bumping the version. Who sets it The agent on save, taking cues from your prompt. You can edit any of it later (through the agent or the portal) and the platform never overwrites your edits on subsequent updates. Example name: "Q3 2025 regional sales review", tags: ["sales", "q3-2025", "regional"] - Provenance metadata What it is A snapshot of the MCP tool calls Plexara observed during the session before save_asset harvested the buffer. Captured automatically; not editable by anyone. Includes each call's name, timestamp, and parameters, plus the session_id and user_id. Does not include chat content, tool responses, or agent reasoning. Who sets it The platform, on every save_asset and trino_export call. You never write to it; you only read it. The record is an approximation of how the asset was built, not a step-by-step proof. Example tool_calls: [search → trino_query → trino_query]; session_id, user_id. The descriptive side was covered in 301 (naming for findability) and 305 (editing metadata in place). The rest of this lesson is the provenance side. ### The shape of a provenance record Provenance is a small structure with two layers. At the top, it identifies the session and the user, and answers one more question when it applies: what if the label was wrong? If the agent called the file one thing and the file turned out to be another, the record keeps both, so the question of why a report opens as a report when it was saved as plain text is answerable long after the session ended. Inside, it carries an ordered list of MCP tool calls Plexara observed during the session before save_asset (or trino_export) harvested the buffer. Each call has three fields. Note that what gets recorded is the call (its name and parameters), not the response or the agent's use of it. What the platform captures in provenance For each tool call in the chain - tool_name The MCP tool the agent called. Examples: search, fetch, trino_query. - timestamp RFC 3339 UTC timestamp of when the call ran. Lets you sequence events and correlate with audit logs. - parameters The arguments the agent passed to the tool, as a JSON object. For trino_query, this includes the SQL. For search, the query intent and any source filters. At the top level - session_id The Plexara session that produced the asset. Use this to find the conversation log that goes with the audit trail. - user_id The authenticated user whose session ran the calls. The owner field on the asset is the same person; provenance.user_id is a redundant copy at the moment of save. - declared_content_type Present only when the label on the file and the file itself disagreed. It records what the writer called the file, alongside what the asset is actually stored as, which is how "why does this open as a report when the agent called it plain text" has an answer months later. The platform caps the per-session buffer at 100 tool calls (oldest evicted). Normal analytical sessions stay well under that. If your session runs more than 100 tool calls before saving, the earliest ones are dropped from the buffer. ### What provenance is, and what it is not Plexara records tool calls at the MCP boundary, which is where the agent talks to data tools. This is the same boundary where [governance is enforced at execution time](https://plexara.io/learning/insights/governance-at-execution-time): the platform sees the call as it happens. It does not record what crosses any other boundary: not your prompts to the agent, not the agent's responses to you, not the agent's internal reasoning. This is a deliberate privacy boundary. The cost is that provenance is a correlation, not a causal trace. What provenance is, and what it is not - What Plexara records - The name of every MCP tool the agent invoked in your session. - The parameters the agent passed to each tool (the JSON arguments). - A UTC timestamp for each call. - The session_id and the authenticated user_id. - What Plexara does not record - The text of your prompts to the agent. - The agent's responses back to you. - The agent's internal reasoning between turns. - The content of the tool responses (only the parameters going in, not the data coming back). - Which captured tool calls the agent actually used to build the asset, versus called and ignored. - Any transformations the agent applied (rounding, filtering, joining results) that were not themselves separate tool calls. Plexara sits at the MCP boundary. Tool invocations cross that boundary; chat content does not. This is deliberate: by not storing what you said or what the agent said back, the platform avoids becoming the system of record for your private analytical conversation. The cost is that provenance is a correlation between tool activity and the resulting asset, not a step-by-step proof of causation. Treat it as the strongest available record, with the caveats above. ### A real provenance record Abstract field lists are easier to ground when you see one. The block below is the kind of record a Q3 sales dashboard would carry after a typical analysis session. A real provenance record from a Q3 sales dashboard ``` { "session_id": "sess_2026_05_15_abc", "user_id": "550e8400-e29b-41d4-a716-446655440000", "tool_calls": [ { "tool_name": "search", "timestamp": "2026-05-15T14:22:03Z", "parameters": { "intent": "regional sales 2025", "sources": ["catalog"] } }, { "tool_name": "trino_query", "timestamp": "2026-05-15T14:23:11Z", "parameters": { "sql": "SELECT region, transaction_date, net_amount FROM sales.transactions WHERE quarter='Q3' AND year=2025", "limit": 10 } }, { "tool_name": "trino_query", "timestamp": "2026-05-15T14:24:55Z", "parameters": { "sql": "SELECT region, SUM(net_amount) FROM sales.transactions WHERE quarter='Q3' AND year IN (2024, 2025) GROUP BY region, year", "limit": 100 } } ] } ``` Read top to bottom, this is the agent's observed tool activity in the session: a catalog search, a small sanity-check query, a year-over-year aggregate. The most likely path from those calls to the dashboard's content runs through the year-over-year query, but Plexara cannot prove that from the record alone: the agent may have applied rounding, filtering, or other transformations between the query result and the rendered chart, and none of those transformations would appear here. Two field notes: user_id is the authenticated user's UUID (the owner email lives on the asset record itself, not in provenance), and save_asset does not appear in tool_calls because the save is what harvests the buffer, not a recorded call. ### How to actually look at provenance You do not have to manually parse the JSON. Two surfaces present the same record in a readable form. Two ways to read an asset's provenance Through the agent: ask “show me the provenance of the Q3 sales review” and the agent calls Manage Asset (`manage_asset`) with action=get, which returns the asset record including the full Provenance object. From the portal: open the asset page; the metadata panel shows the same provenance in a readable view. Both surfaces show the same data because both come from the same record. [Image: The Asset Viewer for an ACME Corp Sales Dashboard as an admin sees it, with an owner label reading alice@example.com beside Delete, Download, and Share buttons, Preview and Source toggles, and a rendered dashboard with KPI tiles and a monthly revenue chart.] The asset page from the admin side. The owner sits in the header beside the actions, and the Preview and Source toggle is above the rendered dashboard. This record is the one whose provenance the callout describes, the same data the agent returns from Manage Asset with action=get. ### When provenance is captured The single most important fact about provenance is that it is captured once, at save time, and is not refreshed after that. Provenance is captured at save time and is not refreshed by updates This is the one nuance that surprises people. When the agent saves an asset, the provenance reflects the tool calls that ran in that session. Later content updates (`manage_asset` action=update) create new versions but do not refresh the asset's provenance record. If you save a dashboard at v1 from a session with three queries, and then update its content twice in later sessions, the asset's provenance still describes the original v1 session. To understand what changed at v2 or v3, read the version's change_summary and created_by (from [305](https://plexara.io/learning/assets/editing-what-you-already-have)), not the asset's provenance. ### The 100-call cap The provenance middleware caps the per-session buffer so that a runaway session does not produce an asset whose audit record is megabytes of JSON. The cap is generous enough that almost no real analytical session hits it. The 100-call session cap, in practice The provenance buffer holds the most recent 100 tool calls in a session before save_asset (or trino_export) harvests it. Exploratory sessions that browse the catalog and run dozens of small queries before committing to a dashboard can come close. If the count of tool_calls in your saved asset is exactly 100, assume the earliest calls were dropped and the asset captures the tail end of the session, not the full path from the first prompt. ### Trino Export adds extra fields For data exports specifically, the trino_export entry in provenance carries four fields that other tool calls do not. These exist because an export is meant to be reproducible, and reproducibility needs the actual SQL that [the export itself recorded](https://plexara.io/learning/assets/exporting-data). Trino Export adds four fields to provenance that other tools do not - export_query The SQL that produced the export, captured verbatim. You can read it later, copy it into a notebook, or hand it to a colleague to re-run. - source_tables The tables Plexara extracted from the SQL. Used for sensitivity-tag inheritance (302) and useful as a quick "what data sources fed this" reference. - format csv, json, markdown, or text. Records which shape the export was produced in. - row_count How many rows were in the export at save time. Lets a reviewer compare today's row count against the historical one. These fields land in the last entry of the provenance tool_calls array, under the trino_export tool_name. Combined with the session's earlier tool calls, you get the full path from a question in chat to a downloadable CSV with the exact query that produced it. ### The three questions provenance answers Provenance is useful because it answers questions a stakeholder will eventually ask. Each answer comes with a hedge: some parts of the record are exact (who and when), and some are inferences (which observed query produced which number). Three questions come up often enough to memorize both the answer and the hedge. Questions provenance helps you answer (with the right hedge on each) - "Where did this number come from?" Provenance shows which queries the agent ran and what they asked for. That is usually enough to point at the source: a trino_query against a specific table with a specific filter. Provenance gives you a strong correlation, not a step-by-step proof, since the agent may have transformed the query result on its way into the chart. - "Who had access to produce this?" The user_id and session_id at the top of the provenance, plus the asset's owner_email field. These are exact: they identify the authenticated user whose session produced the asset. Compliance can correlate them with the platform audit log to confirm access controls applied at the time. - "Can I reproduce this analysis next quarter?" The captured SQL is your starting point. Copy the export_query (for exports) or the trino_query parameters into a new session, parameterize the date, and the agent will produce a comparable asset. Whether it matches exactly depends on whether the original session applied transformations the provenance does not record. Article 308 covers reproducible prompts in depth. ### What this looks like in practice A real session where a board member asked where a number came from, and the agent answered from the asset record (not by re-running the analysis). Answering a where-did-this-number-come-from question You A board member asked where the Southwest Q3 number on the regional sales dashboard came from. Open the asset and show me its provenance. Agent The Q3 2025 regional sales review (asset_id `asset_01HK7R8Z8M0Y6A5G1R6FQ2VQNK`) was built by alice@example.com on 2026-05-15 in session `sess_2026_05_15_abc`. Three tool calls were recorded; the save itself is implicit (it is the act that harvested the provenance buffer, not a recorded call). 14:22:03Z search intent="regional sales 2025" 14:23:11Z trino_query (sanity check, LIMIT 10) 14:24:55Z trino_query SELECT region, SUM(net_amount) FROM sales.transactions WHERE quarter='Q3' AND year IN (2024, 2025) GROUP BY region, year Based on the recorded tool calls, the most likely source of the Southwest Q3 2025 figure is the year-over-year trino_query (the second one), which aggregated sales.transactions across Q3 of 2024 and 2025, grouped by region and year. The Southwest row of that result, for year=2025, is consistent with what the dashboard shows. I cannot confirm causation from provenance alone: the record captures which queries ran, not how their results flowed into the rendered chart. If the auditor needs a stricter check, the SQL is here for re-execution. Note: this is the v1 provenance. The asset has been updated to v3 since; for what changed at v2 and v3, use the version history. The agent did not regenerate anything. It read the existing provenance record on the asset and translated it into prose, including the hedge about what the record cannot prove. The hedged answer is more useful than a confident wrong one: the SQL is available for re-execution, and the user_id and session_id are exact, even if the step-by-step content path is an inference. ### Working with provenance day to day Three habits make the provenance feature useful instead of theoretical. None of them require knowing the storage format; they are prompt shapes. Working with provenance day to day - Phrase a stakeholder question as a provenance question. "Where did this number come from?" becomes "open the Q3 dashboard and show me its provenance." The agent reads the record and translates it into prose. - Quote the SQL when you reproduce. If you want a new asset built the same way last quarter's was, ask the agent to read the export_query from the prior asset's provenance and re-run it with adjusted dates. Article 308 makes this its own subject. - Treat session_id as the link back to the chat log. When the audit story needs more than what is in provenance, the session_id is the breadcrumb that gets you to the original conversation. ### What 307 covers Provenance is what the platform recorded. The natural follow-up is what people say about the result. 307 covers the human side of an asset record: [a correction opened on the asset itself](https://plexara.io/learning/assets/feedback-that-becomes-knowledge), captured as knowledge rather than left as a comment, and confirmed or disputed by the person who raised it. Where this leads Provenance is the record the platform writes about an asset. The next lesson, [307 - Turning a comment into something the agent remembers](https://plexara.io/learning/assets/feedback-that-becomes-knowledge), is the record people write about it: a reviewer's correction opened on the asset itself, folded into the knowledge loop with `memory_capture thread_ids`, and confirmed or disputed by the person who raised it. ### Key terms Six terms cover the vocabulary of provenance. The first four apply to every asset; the last two are Trino Export specifics. Key Terms Provenance The audit record attached to an asset: the ordered list of MCP tool calls Plexara observed during the producing session, plus session_id and user_id. Captured automatically on save_asset and trino_export. A correlation between observed activity and the saved asset, not a causal proof. tool_calls The array of recorded tool invocations in the asset's provenance. Each entry has tool_name, timestamp (RFC 3339 UTC), and parameters. Capped at 100 entries per session. session_id The Plexara session that produced the asset. Lets you correlate the asset with the conversation log it came from. user_id The authenticated user whose session produced the asset. Mirrors the asset's owner field at save time. export_query trino_export only The SQL captured verbatim in the trino_export entry of a data export's provenance. Read it later to reproduce the export, or hand it to a colleague to verify. source_tables trino_export only The list of warehouse tables Plexara extracted from the export SQL. Used for sensitivity-tag inheritance and as a quick reference for which sources fed an asset. On this page [Previous 305 - Editing what you already have](https://plexara.io/learning/assets/editing-what-you-already-have) [Next 307 - Turning a comment into something the agent remembers](https://plexara.io/learning/assets/feedback-that-becomes-knowledge) ### Related reading product [Product 102 - Tokens and your budget Every LLM interaction is priced and rate-limited in tokens. What a token is, how much text fits a budget, and how to avoid wasting tokens on useful answers.](https://plexara.io/learning/ai-concepts/tokens-and-your-budget) [Product 105 - What is an AI agent? An AI agent is not a chatbot and not magic. It is a short loop (think, call-tool, observe, think again) on top of a language model. Mental model first.](https://plexara.io/learning/ai-concepts/what-is-an-ai-agent) [Product 202 - Your first day with Plexara A new Plexara user gets connected, sends a first question, and platform_info takes over. Walks through day one and how subsequent turns inherit context.](https://plexara.io/learning/mcp/first-engagement) --- # Turning a comment into something the agent remembers URL: https://plexara.io/learning/assets/feedback-that-becomes-knowledge/ > A reviewer writes "we don't use that term" on your dashboard. In most tools that comment stays a comment, and the same correction gets made again next quarter. In Plexara an agent can fold it into the knowledge loop: memory_capture with thread_ids records the lesson as a pending insight, resolves the thread, and routes it to the review queue that produces knowledge pages and catalog changes. The person who raised it then confirms or disputes the resolution. This lesson covers the whole loop, the notification rules, the access rules, and how a reviewer with no account participates through a public link. Product 13 min read ## 307 - Turning a comment into something the agent remembers A reviewer writes "we don't use that term" on your dashboard. In most tools that comment stays a comment, and the same correction gets made again next quarter. In Plexara an agent can fold it into the knowledge loop: memory_capture with thread_ids records the lesson as a pending insight, resolves the thread, and routes it to the review queue that produces knowledge pages and catalog changes. The person who raised it then confirms or disputes the resolution. This lesson covers the whole loop, the notification rules, the access rules, and how a reviewer with no account participates through a public link. On this page ### 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](https://plexara.io/learning/assets/how-an-asset-was-built) covered the record of how an asset was built. This lesson covers what happens after somebody reads it and disagrees. Learning Objectives 1. 01 Open a comment, question, or correction on a saved asset in the place it refers to, instead of relaying it over email. 2. 02 Know 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. 3. 03 Turn 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. 4. 04 Close the loop: the person who raised the feedback confirms or disputes the resolution, and a dispute re-opens the thread. 5. 05 Use worklists and the Feedback hub so open items stay visible, and work a whole backlog through one manage_feedback call. 6. 06 State 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](https://plexara.io/learning/assets) - [301 Creating reports and dashboards How 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.](https://plexara.io/learning/assets/creating-reports-and-dashboards) - [302 Exporting data When you need a spreadsheet a teammate can sort, or a data file for another system, instead of a view.](https://plexara.io/learning/assets/exporting-data) - [303 Sharing your work Name 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.](https://plexara.io/learning/assets/sharing-your-work) - [304 Creating collections Bundle 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.](https://plexara.io/learning/assets/creating-collections) - [305 Editing what you already have Name 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.](https://plexara.io/learning/assets/editing-what-you-already-have) - [306 How an asset was built The 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.](https://plexara.io/learning/assets/how-an-asset-was-built) - [307 Turning a comment into something the agent remembers A 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.](https://plexara.io/learning/assets/feedback-that-becomes-knowledge) - [308 Reproducible prompts Save 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.](https://plexara.io/learning/assets/reproducible-prompts) The 300 series is practical recipes for working with Plexara day to day. It assumes the mental model from [205](https://plexara.io/learning/mcp/assets-dashboards-reports-and-data). ### 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 1. 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. 2. 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. 3. 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. 4. 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. 5. 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. 6. 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 verifies step 3. 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. [Image: 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 Why the anchor is more than a nicety A thread anchored to a selection stores the quoted passage and the version of the target it was raised against. That pairing is what lets a correction survive an edit: when the asset moves to v6 the objection still says which words in v5 provoked it, so nobody has to reconstruct what “this is wrong” meant. It also connects this lesson to [305](https://plexara.io/learning/assets/editing-what-you-already-have): editing in place keeps one asset with one history, which is the only reason feedback on it accumulates instead of scattering across copies. ### 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. [Image: 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 1. 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. 2. 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. 3. 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. 4. 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](https://plexara.io/learning/mcp/knowledge-from-memory-to-insights) 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 1. The practitioner or agent request_validation Routes the resolution back to the person who raised the feedback. The thread is resolved, but not settled. 2. 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. 3. 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. [Image: 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 dana.sme@example.com: “We don't use that term.” Anchored to monthly active users. Two replies, needs resolution. 2. **Q4 Revenue Dashboard**, question from sarah.chen@example.com: 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 The general channel is a different room Every other feedback surface inherits its access from the thing it is attached to. The standalone channel has no thing to inherit from, so its rules are set separately: any authenticated user can read it and reply to it, and only the person who opened a thread (or an admin) can resolve it. Write there when the topic is not about one artifact, and know that [the closed-by-default posture](https://plexara.io/learning/insights/closed-by-default-access) that governs data access does not describe this one surface. ### Feedback from someone with no account The reviewer with no Plexara account The person whose opinion you most need is often the one with no seat: the subject-matter expert in another department, the client, the board member. When you share an asset or collection with a public link ([303](https://plexara.io/learning/assets/sharing-your-work) is the sharing lesson), an anonymous visitor can view the work and sees a **Sign in to leave feedback** prompt. Signing in through that link, when the visitor has no prior share for the item, grants them a viewer share automatically, so the item appears in their portal and they can open threads on it. An existing editor is never downgraded to a viewer by this flow. The effect is that a correction from someone outside your team enters the same pipeline as one from inside it, and can end up as a knowledge page the same way. ### 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 Where this sits between 306 and 206 [306](https://plexara.io/learning/assets/how-an-asset-was-built) is the record of what happened while the asset was built: the tool calls Plexara observed, captured at save time and not editable by anyone. This lesson is the record of what happened after, written by people rather than by the platform, and it is editable by design because it is an argument rather than an audit trail. Where they meet is a stakeholder asking about a number: provenance says which query produced it, and the thread says who objected to it and what the team decided. The forward direction is [206](https://plexara.io/learning/mcp/knowledge-from-memory-to-insights), which covers the memory to insight to knowledge pipeline in full. Feedback is one of its entry points, and the one where the raw material comes from a person who disagreed with you. ### What 308 covers Where this leads A correction that became a knowledge page changes what the agent knows. The last lesson in the series changes what you have to type. [308 - Reproducible prompts](https://plexara.io/learning/assets/reproducible-prompts) covers saving the starting instruction as a template with named arguments, so the work that produced the asset can be run again next quarter without rebuilding the request from memory. ### 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 Feedback manage_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. On this page [Previous 306 - How an asset was built](https://plexara.io/learning/assets/how-an-asset-was-built) [Next 308 - Reproducible prompts](https://plexara.io/learning/assets/reproducible-prompts) ### Related reading product [Product 102 - Tokens and your budget Every LLM interaction is priced and rate-limited in tokens. What a token is, how much text fits a budget, and how to avoid wasting tokens on useful answers.](https://plexara.io/learning/ai-concepts/tokens-and-your-budget) [Product 105 - What is an AI agent? An AI agent is not a chatbot and not magic. It is a short loop (think, call-tool, observe, think again) on top of a language model. Mental model first.](https://plexara.io/learning/ai-concepts/what-is-an-ai-agent) [Product 202 - Your first day with Plexara A new Plexara user gets connected, sends a first question, and platform_info takes over. Walks through day one and how subsequent turns inherit context.](https://plexara.io/learning/mcp/first-engagement) --- # Reproducible prompts URL: https://plexara.io/learning/assets/reproducible-prompts/ > Plexara has a first-class prompt object: a saved instruction template with named arguments that you (or a teammate) can re-run later with different values. Manage Prompts (manage_prompt) is the tool. This article covers what a prompt record actually is, how arguments substitute at run time, which scope to pick (personal, persona, global), the four built-in workflow prompts, and the limits of what re-running a prompt does and does not guarantee. Product 11 min read ## 308 - Reproducible prompts Plexara has a first-class prompt object: a saved instruction template with named arguments that you (or a teammate) can re-run later with different values. Manage Prompts (manage_prompt) is the tool. This article covers what a prompt record actually is, how arguments substitute at run time, which scope to pick (personal, persona, global), the four built-in workflow prompts, and the limits of what re-running a prompt does and does not guarantee. On this page ### What you will take away from this lesson Article [306](https://plexara.io/learning/assets/how-an-asset-was-built) covered the backward-looking question: how was this asset built. This article is the forward-looking version: how do I run that work again next month, next quarter, or for a different region, without re-typing the same instructions every time. Plexara's answer is a first-class prompt object. The agent has a tool, Manage Prompts (`manage_prompt`), that lets you save an instruction as a template with named arguments, then call that template later by name. A saved prompt is a starting instruction, not a script. The agent still decides which tools to invoke when it runs the prompt, and the world has moved on since the last run. So this lesson covers what the prompt object actually is, how to write one that holds up, and where the limits of reproducibility are. Learning Objectives 1. 01 See the Plexara prompt system for what it is: a way to save a reusable instruction template, with named arguments, that you or a teammate can run later with different values. 2. 02 Use Manage Prompts (manage_prompt) to create, list, get, update, and delete personal prompts from inside a chat session, the same way you already use the other tools. 3. 03 Read the shape of a prompt record: name, description, content with {arg} placeholders, arguments list, scope, owner. 4. 04 Pick the right scope for a prompt: personal for drafts, persona for role-based playbooks, global for team-standard workflows. Know which scopes you can set and which require an admin. 5. 05 Set expectations up front: running a saved prompt re-reads your template and hands it to the agent. It does not replay a session, does not pin the data, and does not force the same tool choices. ### Where this lesson sits in the curriculum 306 covered the audit trail attached to an asset after it was built. 308 covers the input side: the saved prompt that started the session, and how to re-run it without re-typing it. 300 Series: getting more out of Plexara [Open index](https://plexara.io/learning/assets) - [301 Creating reports and dashboards How 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.](https://plexara.io/learning/assets/creating-reports-and-dashboards) - [302 Exporting data When you need a spreadsheet a teammate can sort, or a data file for another system, instead of a view.](https://plexara.io/learning/assets/exporting-data) - [303 Sharing your work Name 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.](https://plexara.io/learning/assets/sharing-your-work) - [304 Creating collections Bundle 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.](https://plexara.io/learning/assets/creating-collections) - [305 Editing what you already have Name 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.](https://plexara.io/learning/assets/editing-what-you-already-have) - [306 How an asset was built The 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.](https://plexara.io/learning/assets/how-an-asset-was-built) - [307 Turning a comment into something the agent remembers A 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.](https://plexara.io/learning/assets/feedback-that-becomes-knowledge) - [308 Reproducible prompts Save 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.](https://plexara.io/learning/assets/reproducible-prompts) The 300 series is practical recipes for working with Plexara day to day. It assumes the mental model from [205](https://plexara.io/learning/mcp/assets-dashboards-reports-and-data). ### Why a saved prompt earns its keep Three reasons cover most of the value. They are not abstract: each one tracks a habit that costs time and quality the moment a team's workflow becomes recurring. Why a saved prompt earns its keep - Stop re-typing the same starting instruction If you run a monthly close, a weekly pipeline review, or a quarterly board briefing, you have already typed roughly the same five-paragraph prompt into the agent a dozen times. The drift between this month and last month is real: a phrase you tightened the second time, a constraint you forgot the third time. Saving the prompt once means everyone (including future you) starts from the version that already works. - Change the variables, not the words Most repeated work changes in small, named ways: a different quarter, a different region, a different customer segment. A saved prompt declares those as arguments. The agent reads the template, substitutes the values you pass, and runs the prompt with this quarter's numbers without you having to rewrite the surrounding language. - Make the working version the team version When you have a prompt that produces good board-grade output, the second-most useful thing you can do (after running it) is hand it to your team in a form they can run themselves. A prompt scoped to your persona or shared globally shows up in everyone's prompt list with the same arguments and description you wrote. ### The shape of a prompt record A prompt is a small structured record with seven fields you usually touch and a few more the platform fills in. Knowing the field names makes the rest of the lesson easier, because the agent talks about them by name and the portal surfaces them in the same way. The fields of a prompt record `name` Machine-friendly identifier. Lowercase letters, digits, hyphens, and underscores; up to 128 characters. The agent looks the prompt up by this name. Pick something stable; you'll be typing it. `display_name` Human-readable title for the same prompt. Shown in the portal's prompt list. Free-form; can include spaces and punctuation. `description` One-line summary of what the prompt does. Shows up in listings; the agent uses it to decide whether the prompt is the right one to run for a given request. `content` The template itself. Plain text with named placeholders in {curly_braces} or {{double_curly_braces}}. At run time, Plexara substitutes the argument values you pass. `arguments` The named placeholders, each with a name, a description, and a required flag. The agent uses the descriptions to know what to ask you for if a value is missing. `scope` Who can see and run the prompt: personal (you only), persona (users assigned to a matching role), or global (everyone in your Plexara). Personal is the default; the others require an admin. `owner_email` The authenticated user who created the prompt. Set by Plexara from your session, not from input. This is what gates the 'only edit your own' rule on personal prompts. A prompt also carries timestamps (`created_at`, `updated_at`), an enabled flag (so admins can park prompts without deleting them), and an ID. Those are set by the platform. ### Arguments: the part that changes between runs The single feature that turns a prompt into a reusable template is the named argument. Inside the content field, you mark each value that will change between runs with a placeholder; at run time, the platform substitutes the value you pass for the placeholder. How a template becomes a real instruction Template (content field) ``` Generate a sales review for Q{quarter} {year}. 1. Pull regional revenue for the quarter from the warehouse 2. Compare against Q{quarter} of the prior year 3. Build an interactive dashboard with the year-over-year cut 4. Save it as Q{quarter} {year} sales review - by region ``` What the agent reads at run time (with quarter=3, year=2026) ``` Generate a sales review for Q3 2026. 1. Pull regional revenue for the quarter from the warehouse 2. Compare against Q3 of the prior year 3. Build an interactive dashboard with the year-over-year cut 4. Save it as Q3 2026 sales review - by region ``` Both `{name}` and `{{name}}` work as placeholders. Unfilled placeholders are left as-is in the rendered text, so a missing argument shows up as a literal `{quarter}` the agent can ask you about. Required arguments (flagged in the prompt definition) prompt the agent to ask for a value before running. ### Three scopes: personal, persona, global A prompt has exactly one scope. The scope decides who can see it (and therefore run it), and who can create it in the first place. Personal is the default and the only scope a non-admin can set. Persona and global both require an admin to create or move into, which is the same [persona and access model](https://plexara.io/learning/mcp/governance-personas-and-access) that governs the rest of the platform. The three scopes and what each is for - `personal` Who sees it Only you (the prompt owner). Who can create or move into this scope Anyone. This is the default when you create a prompt without specifying a scope. Good for Drafts, experiments, prompts you are still tightening. The portal's create form forces personal scope; the agent path also defaults to it. - `persona` Who sees it Users assigned to one of the personas listed on the prompt (the platform's role / persona system). Who can create or move into this scope Admins only. Non-admins cannot create or move a prompt into persona scope. Good for Role-based playbooks. A prompt for the finance team, a prompt for the data engineers, a prompt for the marketing analysts. Visible to the role, invisible to everyone else. - `global` Who sees it Every user of this Plexara. Who can create or move into this scope Admins only. Good for Team-standard workflows that any user should be able to run: the company-wide weekly KPI prompt, the onboarding tour, the standard incident-report template. The admin gate on persona and global scope is intentional. A global prompt is something everyone in the org will run, and a persona prompt is something an entire role will run, so authoring those is a shared-content responsibility, not an individual one. ### Two paths to manage prompts: agent or portal You can manage prompts during a chat session by talking to the agent, or on a dedicated Prompts page in the Plexara portal. Both paths read and write the same underlying record. The difference is when each one feels right. Two ways to manage prompts - Agent path (Manage Prompts / manage_prompt) What it does During a session, ask the agent to save the prompt you just wrote, or to list the prompts you already have, or to update one. The tool supports create, update, delete, list, and get. Who can use it Anyone, for their own personal prompts. Admins can also set or change scope to persona or global. Non-admins cannot manage anyone else's prompts. What to watch The agent will follow your instructions about wording verbatim. If you want the template improved before saving, ask for the improvement first, then save. Once saved, the content is what the agent reads next time. - Portal path (the Prompts page) What it does The portal has a Prompts surface that lists personal prompts and available prompts (global, persona-matching, system) and lets you create, update, and delete personal prompts. The portal's create form pins scope to personal. Who can use it Anyone with a portal account, for their own personal prompts. Admins use a separate admin surface to manage persona and global prompts. What to watch The portal is the right place to copy-edit a prompt carefully (long content, multiple arguments). The agent path is faster when you are at the keyboard already. [Image: The Create Prompt form on the Prompts page with Name and Display Name fields, a Description box, a markdown Content editor with side-by-side preview and a placeholder for {{arg}} arguments, an empty Arguments panel, and Category and Tags fields.] The portal path. New Prompt opens this form; the Content editor accepts `{{name}}` placeholders and the Arguments panel fills itself as you type them, so the argument list on the record never drifts from the content. ### The built-in workflow prompts Plexara registers a small set of [built-in MCP prompts](https://plexara.io/learning/mcp/mcp-prompts-reusable-prompts) during startup, based on which toolkits your instance has connected. You do not have to author these; they are there waiting in your prompt list with category workflow. They are also a useful reference for how the built-in prompts are written. What ships in the box Before you write a single prompt of your own, Plexara registers a handful of workflow prompts automatically, conditional on which toolkits your instance has connected. They show up in your available list with category `workflow`. Each takes a single argument named `topic` (or `dataset` for lineage). - `explore-available-data` Discover what data is available about a topic Data catalog access - `create-interactive-dashboard` Discover data, build a visualization, and save it as a shareable asset Data catalog, SQL warehouse, and the Plexara portal - `create-a-report` Analyze data and produce a structured Markdown report Data catalog and SQL warehouse - `trace-data-lineage` Trace where data comes from and what depends on it Data catalog access A workflow prompt that needs toolkits you do not have connected is silently skipped during registration. If your prompt list looks shorter than this, ask the team that runs your Plexara which toolkits are wired up. Your own personal and persona prompts appear alongside these. ### What re-running a prompt does and does not do Without this section, the rest of the article would oversell the feature. A saved prompt is a starting instruction. Running it is exactly equivalent to sending that instruction (with arguments substituted) into a fresh agent session. It is not a recorded macro; it does not pin the data; it does not force the agent's tool choices. What re-running a prompt actually does What re-running a saved prompt does - Reads the latest version of the prompt content from the database. - Substitutes the argument values you pass into the {placeholders}. - Hands the resulting text to the agent as a fresh user message in the current session. - Lets the agent decide, on its own, which tools to call to satisfy the instruction. What re-running a saved prompt does not do - Replay the original session, including its tool calls or responses. - Pin the data: warehouse rows, catalog entries, and shared assets may have changed since the last run. - Force the agent to use the same tools as before, in the same order. - Guarantee the same output, the same numbers, or the same conclusions. - Carry over your prior chat history or context unless you keep it in the same session. A saved prompt is a starting instruction, not a recording. That is a feature for everyday work, because the data changes and you want today's answer, not last quarter's frozen one. It is a constraint when you need bit-for-bit reproducibility: for that, you combine the prompt (which fixes the instruction) with reading the prior asset's provenance (which captures the SQL the agent ran last time). Article [306](https://plexara.io/learning/assets/how-an-asset-was-built) covers the provenance side. ### A real prompt record The abstract field list is easier to ground when you see one. The block below is the kind of record a quarterly-regional-sales-review prompt would carry once it has been saved and used a few times. A real prompt record ``` { "id": "prompt_8f3a91b2", "name": "quarterly-regional-sales-review", "display_name": "Quarterly Regional Sales Review", "description": "Build the standard quarterly sales review dashboard for a given quarter and year, with a year-over-year comparison cut by region.", "content": "Generate a sales review for Q{quarter} {year}.\n\n1. Pull regional revenue for the quarter from the warehouse\n2. Compare against Q{quarter} of the prior year\n3. Build an interactive dashboard with the year-over-year cut\n4. Save it as Q{quarter} {year} sales review - by region", "arguments": [ { "name": "quarter", "description": "Quarter number, 1 through 4", "required": true }, { "name": "year", "description": "Four-digit year (e.g. 2026)", "required": true } ], "category": "analysis", "scope": "persona", "personas": ["sales-analyst"], "owner_email": "admin@example.com", "source": "operator", "enabled": true, "created_at": "2026-04-02T15:18:00Z", "updated_at": "2026-04-12T09:33:00Z" } ``` A sales analyst on this team opens their agent and says “run the quarterly regional sales review for Q3 2026.” The agent finds this prompt by name, asks for `quarter` and `year` if they are missing, substitutes them, and runs the resulting instruction. The output is a new asset on the portal, with its own provenance for the catalog searches and queries that built it. [Image: A prompt page for My Weekly Summary marked Personal and Approved, with Copy, Feedback, and Save as Asset buttons, a Collection picker, a Details card listing name, description, owner, category, and updated time, the prompt content under Preview, an Attached materials list with one missing resource, and a Run from chat box.] The same kind of record as the JSON, rendered. Details maps to the fields above, the content sits under Preview and Source, and Run from chat gives the sentence that invokes it by name. Attached materials shows what the prompt carries beyond its text, including a warning when a resource is gone. ### How a prompt connects to the assets it produced A natural question after seeing the example: when this prompt produces an asset, is the asset back-linked to the prompt? The short answer is no, not directly. The longer answer is that the link you do get is your own naming convention plus the [asset-level provenance from 306](https://plexara.io/learning/assets/how-an-asset-was-built). Prompts and assets are not joined at the hip A saved prompt does not carry a list of assets it has produced, and a saved asset does not carry the name of the prompt that started its session. The link between the two is your naming convention. If the prompt saves its output as Q{quarter} {year} sales review - by region, every run of that prompt drops an asset whose name follows that pattern, and the Assets page search will line them up. The asset's provenance (article 306) still tells the per-asset story; the prompt is the shared starting point. ### What this looks like in practice A real session where the user runs a saved prompt and the agent reports that the data drifted slightly since the prior run rather than papering over it. A saved prompt in use, including the hedge You Run the quarterly regional sales review for Q3 2026. Agent Loading the saved prompt `quarterly-regional-sales-review` with `quarter=3` and `year=2026`. Pulling Q3 2026 regional revenue from the warehouse and comparing against Q3 2025. Building the dashboard now. Agent Done. Saved as portal/assets/Q3-2026-sales-review-by-region. Southwest is up 11% year over year; Northeast is flat. Note: the warehouse picked up two late-arriving September entries since I started, so the Q3 2025 comparison numbers are 0.4% higher than the last run of this prompt. Re-run with the same arguments if you want a clean re-render with the updated numbers. You Open the prior version. I want the numbers I sent to the board last week. Agent Last week's asset is at portal/assets/Q3-2026-sales-review-by-region in its version history; opening version 1, which is what you shared on the 9th. The Q3 2025 comparison numbers there are 0.4% lower than what just rendered. The SQL each version's provenance records is comparable across runs (same tables, same filters), which points at the source data as the cause of the drift rather than a different analysis. Two things happened here that could easily have been papered over. The agent named the saved prompt and the arguments it loaded, so the action was inspectable. And when the re-run produced slightly different comparison numbers, the agent surfaced the drift instead of silently overwriting last week's narrative. Reproducibility lives in the prompt; the record of what changed lives in how the agent answers. ### Habits that make a prompt hold up Three habits do most of the work. None of them are about the prompt format; they are about how you write and where you scope it. Habits that make a prompt hold up - Write the prompt as a template before you save it. A prompt that has the next quarter hard-coded is going to mislead someone in three months. Replace every value that will change (dates, regions, customer IDs, periods) with a {named_argument} before you call save. - Name the prompt for the action plus the variables. "quarterly-regional-sales-review" reads better in a list than "sales-prompt-final-v2." If the prompt takes a date or a region, the name should hint at that without including the values. - Move from personal to persona to global deliberately, not by default. A prompt that only you run belongs in personal scope. A prompt your team runs belongs to a persona an admin sets up. A prompt the whole company runs is global and needs more wording care, because the audience is broader than the writer's head. ### That wraps the 300 series Eight articles cover the asset system end to end. There is no 309 to wait for; the next step is to apply this to one of your real recurring workflows. That wraps the 300 series Plexara turns the agent's output into governed, shareable, editable, traceable, reproducible work product. The artifacts you save are first-class assets; the share decisions you make are recorded; the way an asset was built is readable; the prompt that started it is reusable. The most productive next move from here is not another article. It is sitting with one of your real recurring workflows, writing it out as a saved prompt with named arguments, and running it once to see what the agent produces. ### Key terms Six terms cover the vocabulary of prompts. The first three are the mechanics, the next two are the visibility model, and the last is the audit-trail field that gates who can edit what. Key Terms Manage Prompts manage_prompt The MCP tool the agent uses to create, list, get, update, and delete saved prompts. Non-admins can manage their own personal prompts; admins can also manage persona and global prompts. Prompt template The reusable instruction record itself: a name, a content field with {placeholder} arguments, and metadata. Stored in the platform database; loaded into the MCP server so the agent can run it by name. Argument A named placeholder in a prompt's content, declared with a description and a required flag. At run time, the agent substitutes the argument value into the {placeholder} or {{placeholder}} before reading the resulting text. Scope The visibility level of a prompt: personal (owner only), persona (users with a matching role), or global (everyone). Non-admins can only create personal prompts and can not move them to other scopes. Workflow prompt A built-in prompt the platform registers automatically based on which toolkits your Plexara has connected. Examples include explore-available-data and create-interactive-dashboard. Categorized as 'workflow' in your prompt list. owner_email The authenticated user who created a prompt. Set by the platform from the session, not from input. Used to enforce the "only edit your own personal prompts" rule. On this page [Previous 307 - Turning a comment into something the agent remembers](https://plexara.io/learning/assets/feedback-that-becomes-knowledge) ### Related reading product [Product 102 - Tokens and your budget Every LLM interaction is priced and rate-limited in tokens. What a token is, how much text fits a budget, and how to avoid wasting tokens on useful answers.](https://plexara.io/learning/ai-concepts/tokens-and-your-budget) [Product 105 - What is an AI agent? An AI agent is not a chatbot and not magic. It is a short loop (think, call-tool, observe, think again) on top of a language model. Mental model first.](https://plexara.io/learning/ai-concepts/what-is-an-ai-agent) [Product 202 - Your first day with Plexara A new Plexara user gets connected, sends a first question, and platform_info takes over. Walks through day one and how subsequent turns inherit context.](https://plexara.io/learning/mcp/first-engagement) --- # Prompts are the new SOPs URL: https://plexara.io/learning/prompts/prompts-are-the-new-sops/ > You work with the agent for an hour to get one report exactly right, with a year-over-year cut, holiday annotations, and storm-closure markers. The agent saves durable business knowledge on its own. But that specialized report is not institutional knowledge, it is a procedure. This article draws the line between the two, and makes the case that a saved prompt is the standard operating procedure for an AI-run job. Philosophy 9 min read ## 401 - Prompts are the new SOPs You work with the agent for an hour to get one report exactly right, with a year-over-year cut, holiday annotations, and storm-closure markers. The agent saves durable business knowledge on its own. But that specialized report is not institutional knowledge, it is a procedure. This article draws the line between the two, and makes the case that a saved prompt is the standard operating procedure for an AI-run job. On this page ### What you will take away from this lesson You spend an hour with the agent on a real question. You ask for the 2024 sales numbers with a year-over-year comparison, then you ask it to annotate the chart with US public holidays, then you remember the regional storms that closed stores that spring and you ask it to mark those too. Three times you nudge the wording. On the fourth pass the report is exactly right, and you send it to the board. Three weeks later you need the same report for a different period. None of the rigor you put in the first time is written down anywhere you can run again. This article is about the thing that fixes that, and about why it is a different thing from the knowledge the agent already saves on your behalf. Learning Objectives 1. 01 Separate two things teams often blur: institutional knowledge (what your organization knows, captured as memory and insights) and a specialized procedure (how one particular job gets done, captured as a prompt). 2. 02 Recognize the report that is worth saving as a prompt: one you went back and forth on, that carried real annotations and gotchas, and that you will want again without redoing the rigor. 3. 03 See why a prompt is the operating-procedure layer of an AI workflow, the SOP your team keeps so the next run starts from the version that already works. 4. 04 Know what the prompt captures that a saved insight does not, and what an insight captures that a prompt should not. ### Where this series sits The 300 series taught the mechanics of the prompt object: the fields, the arguments, the scopes, and what re-running one does. This series assumes that and asks a different question. Not how does a prompt work, but when is the right thing to make, and how does a team run on prompts the way it runs on written procedures. 400 Series: Prompts as SOPs [Open index](https://plexara.io/learning/prompts) - [401 Prompts are the new SOPs The difference between what your organization knows (memory and insights) and how one specialized job gets done (a prompt). When a perfect report is a recipe worth keeping, not institutional knowledge.](https://plexara.io/learning/prompts/prompts-are-the-new-sops) - [402 Letting the agent write the prompt The agent that just did the work is the best author of the prompt that repeats it. It still holds the gotchas, the tool order, and the values worth turning into arguments. You review the draft, then save it.](https://plexara.io/learning/prompts/letting-the-agent-write-the-prompt) - [403 Sharing prompts, and closing the loop with feedback Hand a prompt to one teammate by email, or promote it to a whole role through the admin review queue. Then let feedback threads tell you what to fix, and fold the good corrections back into the catalog.](https://plexara.io/learning/prompts/sharing-prompts-and-feedback) - [404 Running prompts, by hand and on a schedule Run a saved prompt at the keyboard three ways, or on a cadence using your agent’s own scheduling: an in-session loop, headless plus cron, a desktop task, or a cloud routine. Scheduling lives in the agent, not Plexara.](https://plexara.io/learning/prompts/running-prompts-and-schedules) The 400 series builds on the prompt mechanics from [308](https://plexara.io/learning/assets/reproducible-prompts). If the words prompt, argument, and scope are new, read that first. ### The agent already saves knowledge. This is not that. During that hour, a good agent was doing more than answering. When you told it that the spring storms closed specific stores, that is the kind of correction a Plexara agent captures as an insight for an administrator to review and, if it holds, promote into the catalog. When you told it your team counts revenue net of next-period returns, that becomes durable knowledge every future session inherits. This is real, and it is covered in the 200 series. It is also not the thing you are missing three weeks later. What you are missing is the procedure: the particular sequence of pulls, comparisons, annotations, and presentation choices that turned a blank prompt into a board-ready report. That is not a fact about your business. It is a way of doing one job. It deserves its own home, and it has one. Two kinds of durable output, two different homes - Institutional knowledge What it is A fact about your business that is true regardless of which report you are building. It belongs to the organization, not to a task. For example "Revenue excludes returns booked in the following period." "The Southwest region includes Texas." "Store 412 was a remodel in Q2 and its numbers are not comparable." Where it lives Saved as memory and as reviewed insights, then promoted into the data catalog so every future session inherits it. - A specialized procedure What it is The exact steps, sources, and presentation choices that produced one particular deliverable. It belongs to the job, not to the whole company. For example "Pull the year-over-year cut, annotate with US public holidays, mark the spring storm closures, save it as a dashboard named for the period." Where it lives Saved as a prompt: a named instruction template with arguments, runnable again by you or a teammate. The knowledge side is covered in [206](https://plexara.io/learning/mcp/knowledge-from-memory-to-insights). This series is about the procedure side. The mistake worth avoiding is filing one as the other: a storm closure that affected one chart is not a permanent business fact, and “revenue excludes returns” is not a step in a single report. ### The rigor was the asset It is tempting to think the report was the output and the conversation was just the means. The opposite is closer to true. The report is a snapshot of one period. The conversation, specifically the corrections you made on each pass, is the reusable part. Look at what the final version actually encoded. What the fourth-pass report actually carried - The year-over-year comparison was a join you had to get right: this period against the same period a year earlier, aligned on the calendar, not on row order. - The US public holiday annotations came from a specific source and a specific list. You picked which holidays mattered and which were noise. - The spring storm closures were not in any dataset the agent could find on its own. You told it which stores and which dates, and that context only existed in your head. - The final shape, an interactive dashboard named for the period rather than a wall of chat, was a choice you made on the third pass after the first two outputs were not shareable. Every one of these was a decision, and most of them were corrections of an earlier attempt. That accumulated judgment is the asset. Write it down as a prompt and the next run starts from the fourth pass instead of the first. [Image: A prompt page for Daily Sales Report tagged Library and Approved, showing a Details card, an Arguments panel with a required {{date}} and an optional {{threshold}}, the prompt content under Preview, one attached material marked restricted, and Copy, Feedback, and Save as Asset buttons.] What the rigor looks like once it is a prompt in the library. The steps are the content, the things that change between runs are declared arguments, and the whole thing is approved and named so the next person starts from the finished procedure. ### Why this is a standard operating procedure Every operations team that survives a key person leaving has learned the same lesson: the way a job is done has to live somewhere other than one person’s head. The standard operating procedure is the artifact that holds it. It is boring on purpose. It is the steps, in order, with the gotchas called out, so the next person produces the same quality without rediscovering the path. A saved prompt is that artifact for work you do with the agent. The report you went back and forth on was a procedure being discovered in real time. Saving it as a prompt is writing the procedure down. The difference between a team that does this and one that does not is the difference between starting next month’s report from the version that already works and starting it from a blank prompt and a fading memory. A prompt is the SOP for an AI-run procedure A standard operating procedure exists so that a job done well once gets done the same way every time, by whoever picks it up, without rediscovering the steps. It is not a record of any single run and it is not a statement of company values. It is the written-down procedure. A saved prompt plays exactly that role for work you do with the agent. It is not the conversation you had and it is not a fact about your business. It is the procedure: the steps, the sources, the annotations, the output shape, written so the agent can follow it again. The teams that get the most out of an AI workflow are the ones that notice when a good session was actually a procedure, and save it as one. ### Not every good session is a procedure The discipline cuts both ways. A one-off question you will never ask again is not a procedure, and saving it as a prompt just clutters the list everyone scans. A genuinely new business fact you discovered is knowledge, and filing it as a step inside one report buries it where the next report cannot find it. The test is simple: will you, or someone on your team, want to run this same shape of job again with different inputs. If yes, it is a procedure, and it is a prompt. If it is a fact that should change how every job runs, it is knowledge, and it belongs in memory or an insight. The report from the opening is a clean yes. You will want the year-over-year, holiday-annotated, closure-marked sales view again, for the next period and probably for a different region. The shape is stable; the inputs change. That is the exact signature of something worth saving as a prompt. ### You do not have to write it yourself There is one more reason teams skip this step: writing a good prompt by hand, after the fact, is its own chore. You would be reconstructing an hour of decisions from memory. The next article removes that chore entirely. Next: let the agent write it You could write the prompt by hand. You would be transcribing, from memory, the same instructions you already gave the agent across an hour of back and forth, including the gotchas you only discovered on the second and third tries. The agent that just did the work is holding all of that right now. [402 covers asking it to author the prompt for you](https://plexara.io/learning/prompts/letting-the-agent-write-the-prompt). ### Key terms Four terms anchor the series. The first two are the distinction this article is built on; the last two are the analogy it runs on. Key Terms Prompt A saved, named instruction template with arguments that you or a teammate can run again. In this series, the unit that captures how a specialized job gets done. Institutional knowledge Facts about your business that hold across tasks, captured as memory and reviewed insights and promoted into the data catalog. Covered in [206](https://plexara.io/learning/mcp/knowledge-from-memory-to-insights). Distinct from a prompt. Specialized procedure The steps and choices that produced one deliverable: the sources, the comparison, the annotations, the output shape. The thing a prompt is for. SOP Standard operating procedure. The everyday-business name for a written-down, repeatable way of doing a job. The analogy this series runs on: a prompt is the SOP for an AI-run procedure. On this page [Next 402 - Letting the agent write the prompt](https://plexara.io/learning/prompts/letting-the-agent-write-the-prompt) ### Related reading philosophy [Philosophy 101 - What is a Large Language Model? LLMs predict the next token from patterns learned across trillions of training examples. What that means, why it produces fluent reasoning, and its limits.](https://plexara.io/learning/ai-concepts/what-is-a-large-language-model) [Philosophy 104 - Frontier models, specialized models, and why enterprise AI uses both Frontier models bring world knowledge; small local embedding models power memory and catalog search. Knowing each role designs AI systems that work.](https://plexara.io/learning/ai-concepts/frontier-models-explained) [Philosophy 501 - The last mile of data is a spreadsheet The join was never the expensive part of using an outside file. Loading it was, and loading was staffed: a ticket for the table, an engineer for the load, an integration platform somebody had to keep. A chat agent does not close that gap on its own, because a large file does not fit its context and the scripts it writes vanish with the session. This lesson sets out the gap, the registration model that closes it (a table over the file where it sits, nothing copied), and the size rule for when a file needs no table at all.](https://plexara.io/learning/spreadsheets/the-last-mile-of-data-is-a-spreadsheet) --- # Letting the agent write the prompt URL: https://plexara.io/learning/prompts/letting-the-agent-write-the-prompt/ > The cheapest way to save a procedure is to not write it yourself. The agent that just spent an hour producing your report still holds the tool order, the corrections, and the values worth turning into arguments. Ask it to author the prompt, review the draft, and save it. This article covers the move, why the agent is the better author, and how to read what it produces. Product 9 min read ## 402 - Letting the agent write the prompt The cheapest way to save a procedure is to not write it yourself. The agent that just spent an hour producing your report still holds the tool order, the corrections, and the values worth turning into arguments. Ask it to author the prompt, review the draft, and save it. This article covers the move, why the agent is the better author, and how to read what it produces. On this page ### What you will take away from this lesson Article [401](https://plexara.io/learning/prompts/prompts-are-the-new-sops) made the case that the report you went back and forth on is a procedure worth saving. This article is about who writes it down. The short answer is that you should not, at least not from scratch. Writing a prompt by hand means reconstructing an hour of decisions from memory: the order you did things, the join you got wrong the first time, the annotation source you settled on, the values that changed between tries. The agent in that session was holding all of it. Asking it to author the prompt turns the chore into a sentence. Learning Objectives 1. 01 Use the move that makes saving a prompt nearly free: ask the agent that just did the work to write the prompt that repeats it. 2. 02 Understand why the agent is the better author here. It still holds the tool order, the corrections, and the values worth turning into arguments, because it just lived through them. 3. 03 Read the prompt record the agent produces: an ordinary personal prompt, the same shape and the same record you would get by typing it yourself. 4. 04 Review the draft before it ships. An agent-authored prompt is a first draft with your name on it, not a finished standard. ### Where this lesson sits 401 argued that a report worth re-running is a procedure, and a procedure belongs in a prompt. This lesson closes the gap between deciding to save one and actually having one, by handing the authoring to the party best equipped to do it. 400 Series: Prompts as SOPs [Open index](https://plexara.io/learning/prompts) - [401 Prompts are the new SOPs The difference between what your organization knows (memory and insights) and how one specialized job gets done (a prompt). When a perfect report is a recipe worth keeping, not institutional knowledge.](https://plexara.io/learning/prompts/prompts-are-the-new-sops) - [402 Letting the agent write the prompt The agent that just did the work is the best author of the prompt that repeats it. It still holds the gotchas, the tool order, and the values worth turning into arguments. You review the draft, then save it.](https://plexara.io/learning/prompts/letting-the-agent-write-the-prompt) - [403 Sharing prompts, and closing the loop with feedback Hand a prompt to one teammate by email, or promote it to a whole role through the admin review queue. Then let feedback threads tell you what to fix, and fold the good corrections back into the catalog.](https://plexara.io/learning/prompts/sharing-prompts-and-feedback) - [404 Running prompts, by hand and on a schedule Run a saved prompt at the keyboard three ways, or on a cadence using your agent’s own scheduling: an in-session loop, headless plus cron, a desktop task, or a cloud routine. Scheduling lives in the agent, not Plexara.](https://plexara.io/learning/prompts/running-prompts-and-schedules) The 400 series builds on the prompt mechanics from [308](https://plexara.io/learning/assets/reproducible-prompts). If the words prompt, argument, and scope are new, read that first. ### The whole move is one sentence When the report is right, you do not open a separate prompt editor and start typing. You stay in the session and ask the agent to write the prompt that reproduces what you just did. The work of distilling an hour of conversation into a clean, parameterized template is exactly the kind of work the agent is good at, and it is sitting on the full context required to do it. From a finished session to a saved procedure 1. 1 The session that just worked An hour of back and forth ending in a report you are happy with. The full record of what was tried, corrected, and kept is in the conversation. 2. 2 You ask for the prompt "Write a reusable prompt that produces this report for any period and region, and save it." One instruction, no transcription. 3. 3 The agent drafts it It distills the conversation into a template: the steps in the order that worked, the gotchas as explicit instructions, the values that changed as named arguments. 4. 4 You review and save You read the draft, fix anything off, and confirm the save. It is stored as your personal prompt, ready to run by name. ### What it looks like in the chat The interaction is short. You describe the goal once, in plain language, and the agent reports back what it is encoding and what it is making variable before it commits anything. That readback is the important part: it is the moment to correct a default or add a step you forgot, while the original session is still in front of you. Asking the agent to author the prompt You This report is exactly what I needed. Write a reusable prompt that produces this same report for any period and region, and save it so I can run it again next quarter. Agent I will turn this session into a prompt. Here is what I am encoding from what we did: pull the period revenue and the same period a year earlier for the year-over-year cut, annotate with US public holidays from the calendar reference, recall any store-closure events for the period from memory and mark them, and save the result as an interactive dashboard named for the period and region. I am making `period` and `region` arguments. Saving it as your personal prompt `annotated-sales-review`. Review it before you rely on it. Notice the agent named what it was encoding and which values it was turning into arguments before saving. That summary is your chance to catch a missing step or a wrong default while the context is still on screen. ### Reading the prompt it produced The output is an ordinary prompt record, the same shape covered in 308: a personal prompt no different from one you would type by hand. The detail worth pointing at is how it handles the one-time facts. Instead of baking the spring storm closures into the text, it instructs the agent to recall closure events from memory at run time. That single choice is what keeps the procedure reusable for a period with entirely different closures. The prompt the agent drafted ``` { "name": "annotated-sales-review", "display_name": "Annotated Sales Review", "description": "Year-over-year sales review for a period and region, annotated with US public holidays and any known store-closure events for the period.", "content": "Produce an annotated sales review for {period} in the {region} region.\n\n1. Pull revenue for {period} and for the same period one year earlier; align them for a year-over-year comparison.\n2. Annotate the timeline with US public holidays from the calendar reference.\n3. Recall any store-closure events affecting {region} during {period} from memory and mark them on the chart with a short label.\n4. Build an interactive dashboard, not a chat reply.\n5. Save it as an asset named '{period} {region} annotated sales review'.", "arguments": [ { "name": "period", "description": "The period to report on, e.g. Q2 2026 or May 2026", "required": true }, { "name": "region", "description": "Sales region name, e.g. Southwest", "required": true } ], "category": "analysis", "scope": "personal", "source": "operator", "enabled": true } ``` The detail worth pointing at is step 3. It does not hard-code the spring storms; it tells the agent to recall closure events from memory at run time, so the procedure keeps working in a period with different closures, or none. The one-time fact stays in knowledge; the repeatable instruction to consult it stays in the prompt. The record itself is nothing exotic: an ordinary personal prompt, the same shape and origin you would get by typing it yourself. [Image: A prompt page for My Weekly Summary marked Personal and Approved, with a Details card of name, description, owner, category, and updated time, the prompt content under Preview, an Attached materials list, a Run from chat box, and Copy, Feedback, and Save as Asset buttons.] Once you save the draft, this is the page it becomes: an ordinary personal prompt. Read it here the way you read the JSON above. The Details card, the content, and the attached materials are the parts to check before anyone else runs it. ### Why hand it to the agent at all The instinct to write the prompt yourself comes from a good place, which is wanting the procedure to be correct. But correctness here depends on details that are freshest in the agent’s context and stalest in yours: the order of operations, the mistakes already corrected, and which values actually varied across your attempts. Why the agent is the better author here - It knows the order that worked. You may remember the report; the agent remembers that it pulled the prior-year figures before the current ones because the join was cleaner that way. Order is half of a good procedure. - It knows the gotchas, because it hit them. The correction you made on the second pass is in the conversation. A hand-written prompt three weeks later is unlikely to include the mistake you have since forgotten you made. - It can tell a constant from a variable. The agent just saw which values you changed across tries (the period, the region) and which stayed fixed (the annotation sources, the output shape). That is exactly the line between an argument and a hard-coded step. ### Then read it like you mean it Letting the agent draft the prompt does not move the responsibility for the procedure off you. It moves the typing. The prompt now carries your name and your team will run it, so the draft earns a real review before it becomes the standard. An agent-authored prompt is a first draft The agent is a strong author and an imperfect one. It can encode a step you meant to drop on the next run, hard-code a value you wanted parameterized, or describe an argument vaguely enough that a teammate fills it in wrong. Read the draft the way you would read a junior colleague’s SOP before putting your name on it: is every step still needed, is every changing value an argument, and would someone who was not in the room run it correctly from the description alone. Fixing it is a conversation, not a rewrite. Tell the agent what to change and have it update the saved prompt. The point of letting it author the draft was never to skip your judgment. It was to skip the transcription. ### A good prompt wants an audience You now have a reviewed, parameterized procedure saved as a personal prompt. The next return on that work comes from getting it into other people’s hands and letting their use of it make it better. Next: get it off your machine The prompt the agent just drafted is scoped to you. It is a personal procedure, useful but private. The moment a teammate needs the same report, the question becomes how to hand it to them, and how to learn from what they tell you about it. [403 covers sharing and feedback](https://plexara.io/learning/prompts/sharing-prompts-and-feedback). ### Key terms Three terms specific to agent-authored prompts: what the agent produces, and the two judgments it applies while drafting. Key Terms Agent-authored prompt A prompt the agent drafts and saves for you by calling manage_prompt. It is an ordinary personal prompt, the same record you would get by typing it yourself; the win is that the agent did the authoring from the session it just ran, not that the prompt carries any special marker. Argument extraction The agent’s judgment, when authoring a prompt, about which values changed between runs (and should become named arguments) and which stayed fixed (and should be written into the steps). Recall from memory A step that tells the agent to consult stored knowledge at run time rather than hard-coding a fact into the prompt. Keeps one-time facts in the knowledge layer and out of the procedure. See [206](https://plexara.io/learning/mcp/knowledge-from-memory-to-insights). On this page [Previous 401 - Prompts are the new SOPs](https://plexara.io/learning/prompts/prompts-are-the-new-sops) [Next 403 - Sharing prompts, and closing the loop with feedback](https://plexara.io/learning/prompts/sharing-prompts-and-feedback) ### Related reading product [Product 102 - Tokens and your budget Every LLM interaction is priced and rate-limited in tokens. What a token is, how much text fits a budget, and how to avoid wasting tokens on useful answers.](https://plexara.io/learning/ai-concepts/tokens-and-your-budget) [Product 105 - What is an AI agent? An AI agent is not a chatbot and not magic. It is a short loop (think, call-tool, observe, think again) on top of a language model. Mental model first.](https://plexara.io/learning/ai-concepts/what-is-an-ai-agent) [Product 202 - Your first day with Plexara A new Plexara user gets connected, sends a first question, and platform_info takes over. Walks through day one and how subsequent turns inherit context.](https://plexara.io/learning/mcp/first-engagement) --- # Sharing prompts, and closing the loop with feedback URL: https://plexara.io/learning/prompts/sharing-prompts-and-feedback/ > A procedure is only worth as much as the people who can run it. Plexara distributes a prompt two ways: a direct share to one teammate, or a promotion to a whole role or company through the admin review queue. A shared prompt is live, not a copy. Feedback threads then carry corrections back, with a validation step and a path into the knowledge catalog, and the deprecate-and-supersede lifecycle retires old versions cleanly. Governance 12 min read ## 403 - Sharing prompts, and closing the loop with feedback A procedure is only worth as much as the people who can run it. Plexara distributes a prompt two ways: a direct share to one teammate, or a promotion to a whole role or company through the admin review queue. A shared prompt is live, not a copy. Feedback threads then carry corrections back, with a validation step and a path into the knowledge catalog, and the deprecate-and-supersede lifecycle retires old versions cleanly. On this page ### What you will take away from this lesson A prompt that only you can run is a private habit. A prompt your team can run is shared infrastructure. This lesson is about crossing that line in both directions: getting a good procedure into other people’s hands, and getting their experience of running it back to you so the procedure improves. Plexara gives you two distinct ways to distribute a prompt and a structured channel for feedback on it. They are easy to confuse and worth keeping straight, because they have different audiences, different controls, and different people who can set them up. Learning Objectives 1. 01 Pick the right way to get a prompt to other people: a direct share to one named teammate, or a promotion to a whole role or the whole company. 2. 02 Understand that a direct share serves the live prompt, not a copy, so your edits reach the recipient and there is no forked version to keep in sync. 3. 03 Follow a promotion through the admin review queue: an owner requests a shared scope, an admin approves or rejects, and only then does the scope change. 4. 04 Use feedback threads to learn what to fix, including the validation step that lets a subject-matter expert confirm or dispute a correction. 5. 05 Close the loop by folding a good correction into the knowledge catalog, and retire an old prompt cleanly with the deprecate-and-supersede lifecycle. ### Where this lesson sits 402 left you with a reviewed, parameterized prompt scoped to you. This lesson is about everything that happens after a procedure stops being yours alone: distributing it, hearing how it performs in other hands, and keeping it correct over time. 400 Series: Prompts as SOPs [Open index](https://plexara.io/learning/prompts) - [401 Prompts are the new SOPs The difference between what your organization knows (memory and insights) and how one specialized job gets done (a prompt). When a perfect report is a recipe worth keeping, not institutional knowledge.](https://plexara.io/learning/prompts/prompts-are-the-new-sops) - [402 Letting the agent write the prompt The agent that just did the work is the best author of the prompt that repeats it. It still holds the gotchas, the tool order, and the values worth turning into arguments. You review the draft, then save it.](https://plexara.io/learning/prompts/letting-the-agent-write-the-prompt) - [403 Sharing prompts, and closing the loop with feedback Hand a prompt to one teammate by email, or promote it to a whole role through the admin review queue. Then let feedback threads tell you what to fix, and fold the good corrections back into the catalog.](https://plexara.io/learning/prompts/sharing-prompts-and-feedback) - [404 Running prompts, by hand and on a schedule Run a saved prompt at the keyboard three ways, or on a cadence using your agent’s own scheduling: an in-session loop, headless plus cron, a desktop task, or a cloud routine. Scheduling lives in the agent, not Plexara.](https://plexara.io/learning/prompts/running-prompts-and-schedules) The 400 series builds on the prompt mechanics from [308](https://plexara.io/learning/assets/reproducible-prompts). If the words prompt, argument, and scope are new, read that first. ### Sharing one person versus sharing a role There are two distinct mechanisms, and choosing between them is mostly about reach. A direct share hands the prompt to a named individual and you can set it up yourself. A promotion makes the prompt available to an entire persona or to everyone, and because that is a decision about shared content, it goes through an admin. Two ways to get a prompt to other people - Direct share Who sees it One named teammate, by email address. Who can set it up You, the owner. No admin required. The prompt stays personal scope; sharing it does not change its scope. Controls Each recipient gets viewer or editor permission, with an optional expiration. You can list who you have shared with and revoke at any time. Good for Handing a procedure to a specific colleague: the analyst covering for you next week, the new hire learning the quarterly review. - Promotion to a shared scope Who sees it Everyone in a persona (a role), or every user of your Plexara (global). Who can set it up You request it; an admin approves it. Only an admin can move a prompt into persona or global scope. Controls The promotion request records the scope and personas you are asking for. The change is applied only when an admin approves; until then the prompt stays personal. Good for Turning a procedure into a team or company standard: the finance team’s close narrative, the company-wide weekly KPI prompt. The dividing question is reach. A direct share is for a person; a promotion is for a role or the whole company. The admin gate on promotion is the same [persona and access model](https://plexara.io/learning/mcp/governance-personas-and-access) that governs the rest of the platform, because a shared prompt is shared content and someone owns that decision. ### What the recipient actually gets The most important property of a direct share is the one people assume wrong. Sharing does not copy the prompt. The recipient runs the same live record you own, so improvements you make show up on their side without a re-send, and there is never a forked version quietly going stale in someone else’s list. A shared prompt is live, not a copy When you share a prompt with a teammate, they do not get a snapshot frozen at the moment you shared it. They get the live prompt, served to their agent the same way your own prompts are served to yours. When you fix a step or tighten an argument description, the next run on their side uses the corrected version. There is no forked copy drifting away from yours, and nothing to re-send when you make an edit. This is why permission matters. A viewer can run the prompt; an editor can change the shared record itself. Hand out editor only to the people you want shaping the procedure, not just running it. ### Promotion goes through review Making a prompt a team or company standard is not something you do unilaterally, and the platform reflects that. You file a request naming the scope you want; an admin reviews it; the scope changes only on approval. The request is a signal, not the act itself, which keeps a half-considered prompt from becoming the company default because one person clicked a button. How a promotion request moves through review 1. owner Request promotion You ask to move your personal prompt to a shared scope, naming the target: persona (with at least one persona) or global. This flags the prompt for review. Its scope does not change yet. 2. admin Review in the queue An admin sees the pending request in the review queue. They read the prompt, check the requested scope and personas, and confirm the shared name is free. 3. admin Approve or reject Approve moves the prompt to the requested scope and personas, marks it approved, and stamps the admin. Reject clears the request and leaves the prompt personal and unchanged. The request only sets a signal; the scope changes on approval. If an admin edits the prompt’s scope by hand while a request is pending, the stale request is discarded rather than silently re-scoping the prompt. [Image: The lower half of a prompt page showing the prompt content, one attached material, a Run from chat box, and a Version history panel with a notice that draft v4 is pending review while readers get approved v3, four version rows with draft, applied, current, and superseded badges and approver names, and Diff vs current buttons with one diff open.] Review, visible on the record. The notice says draft v4 is waiting on an admin while readers keep getting approved v3; each row shows who wrote it and who approved it, and Diff vs current shows exactly what the reviewer is deciding on. ### Feedback is a structured thread, not a comment box Once a procedure is in other hands, the people running it know things you do not: where it is brittle, what it assumes, which annotation it is missing. Plexara captures that as feedback threads, and a thread carries more than text. It has a kind, a status, and a validation state, which together let a real correction be tracked to a decision instead of scrolling away. The fields of a feedback thread `kind` What the thread is: a comment, a question, a correction, a rating. Tells the owner whether someone is asking, suggesting, or just noting. `status` Where the thread stands: open, answered, resolved, acknowledged, or wont_fix. The lifecycle of the conversation, not of the prompt. `validation_state` Whether a correction has been confirmed: none, pending, validated, or disputed. This is the field that turns an opinion into a checked fact. `requires_resolution` A flag that marks a thread as needing a decision before it is dropped, so a real correction is not lost in a scroll of comments. Feedback threads attach to assets, collections, and prompts, and there is a shared general channel for anything else. The agent works them through one tool, Manage Feedback (`manage_feedback`), which lists, reads, replies, resolves, and runs the validation step. Threads on a prompt are reached by targeting that prompt and are admin-scoped, which fits: the prompt is shared content, and feedback on it is a curation responsibility. [Image: The Feedback page with Recent, Worklist, and General tabs and a New feedback button, listing threads on assets, a collection, and a knowledge page, each with a title, a type badge such as Correction, Question, or Suggestion, a status badge such as Open, Answered, or Resolved, an author, and a reply count.] Feedback as a worklist, not a comment box. Every thread carries a type, a status, and an author, and the Worklist tab collects the ones waiting on you. Threads on assets, collections, and knowledge pages sit in one list. ### The loop that makes feedback trustworthy The risk with any feedback channel is that the loudest comment wins. The validation step is the answer. Before a correction changes the procedure, it can be routed to someone qualified to confirm it, who records the result as validated or disputed. A disputed correction re-opens rather than disappearing, and a correction that turns out to be a durable fact about your data can graduate out of prompt feedback and into reviewed knowledge. From a comment to a checked, captured fix 1. 1 Someone files a correction A teammate runs the shared prompt and notices the holiday list is missing a regional observance. They open a thread of kind correction on the prompt. 2. 2 Request validation Rather than acting on it blind, the owner routes a validation request to the right person: request_validation sends it to the thread author or a subject-matter expert to confirm. 3. 3 Validate or dispute The expert responds: respond_validation records validated or disputed, with an optional reason. A dispute re-opens the thread instead of quietly closing it. 4. 4 Fold it into knowledge If the correction is a durable fact, capture_insight with the thread id promotes it into the knowledge loop and resolves the thread, so the fix outlives this one prompt. The validation step is what separates this from a comment box. A correction is not acted on because it was loud; it is acted on because someone qualified confirmed it. And when the fix is really about your data rather than this one procedure, it graduates from prompt feedback into [reviewed knowledge](https://plexara.io/learning/mcp/knowledge-from-memory-to-insights). ### Retiring a procedure without breaking its users Procedures change. The holiday source is replaced, the report grows a section, a better version is written. The wrong way to handle that is to delete the old prompt and let everyone who relied on it hit a wall. The lifecycle exists so you do not have to. You deprecate the old version to signal it is on the way out, and you supersede it with a pointer to its replacement. The prompt lifecycle: draft, approved, deprecated, superseded - `draft` A prompt being shaped. The starting state before it is promoted into a shared scope. - `approved` Promoted and live for its scope. Reached only on admin approval; this is the state a shared, in-use prompt sits in. - `deprecated` Still runnable, but on notice. Marks a prompt as obsolete so people stop reaching for it, without yanking it out from under anyone mid-quarter. - `superseded` Replaced. Records the name of the prompt that takes its place in superseded_by, so a run lands on the current version instead of a dead end. Transitions run one way: draft moves to approved or straight to superseded; approved moves to deprecated or superseded; deprecated moves to superseded. You do not delete a team-standard procedure out from under its users. You deprecate it, point it at its replacement, and let the runs migrate. ### From distributed to running Authored, shared, and improving: the procedure is now real shared infrastructure. The remaining question is the most practical one, which is how it actually gets run, by a person and, where it makes sense, on a schedule. Next: actually running it A prompt that is authored, shared, and improving is still only worth what its runs produce. The last article covers running a saved prompt at the keyboard, and what it takes to run one on a schedule. [404 covers running and schedules](https://plexara.io/learning/prompts/running-prompts-and-schedules). ### Key terms Five terms cover this lesson: two ways to distribute a prompt, the feedback thread and its validation step, and the supersede mechanism for retiring one. Key Terms Direct share Sharing a personal prompt with a named teammate by email, as viewer or editor, with an optional expiration. The recipient runs the live prompt, not a copy. Revocable by the owner. Promotion request requested_scope An owner’s request to move a personal prompt into a shared scope (persona or global). It flags the prompt for the admin review queue; the scope changes only on admin approval. Feedback thread A structured conversation attached to a prompt (or asset, collection, or general channel), with a kind, a status, and a validation state. Worked through the manage_feedback tool. Validation request_validation / respond_validation The step that confirms a correction. The owner routes a validation request to an expert, who records validated or disputed. A dispute re-opens the thread. Supersede superseded_by Retiring a prompt by pointing it at its replacement. Part of the draft, approved, deprecated, superseded lifecycle that lets a shared prompt be replaced without breaking its users. On this page [Previous 402 - Letting the agent write the prompt](https://plexara.io/learning/prompts/letting-the-agent-write-the-prompt) [Next 404 - Running prompts, by hand and on a schedule](https://plexara.io/learning/prompts/running-prompts-and-schedules) ### Related reading governance [Governance 505 - Next month’s file The new sheet arrives. Replacing the file’s content writes a new revision, and the registered table keeps reading the old one until it is registered again under the same name; the Scratch Tables page says so. This lesson covers the two cases that look alike and behave differently, moving the table forward, unregistering, what deleting the file does, saving the monthly procedure as a prompt, and the point at which a monthly file needs more than a join, which is where the 600 series begins.](https://plexara.io/learning/spreadsheets/next-months-file) [Governance 605 - What a run may do, and the record it leaves A run presents the roles its author held at the save, every call is authorized at that moment, and narrowing the persona takes effect on the next run. A save refuses a credential-shaped literal and source that does not parse. The dialect has no network, no filesystem, and no clock, so everything a script does is a platform call audited under the script’s own identity. The lifecycle from active to disabled, deprecated, and superseded; who sees what; ownership and an administrator’s transfer; and the administrator’s view of every script and every run.](https://plexara.io/learning/automations/what-a-run-may-do) [Governance Closed by default: least privilege as the starting point Access control that starts open and gets locked down later never actually finishes. Closing connection access by default means every role sees exactly what it was granted and nothing more.](https://plexara.io/learning/insights/closed-by-default-access) --- # Running prompts, by hand and on a schedule URL: https://plexara.io/learning/prompts/running-prompts-and-schedules/ > A saved prompt runs two ways: at your keyboard when you want the report now, and on a schedule when you want it to arrive on a cadence. Running by hand takes a sentence: name it to the agent under any handle it knows, pick it in the List Prompts app, or paste the portal’s copyable invocation. Scheduling is not a Plexara feature at all; it lives in your agent, from an in-session loop to a cloud routine that runs when your machine is off. This article covers both, where the output goes, and how a share turns an unattended run into email somebody actually reads. Product 9 min read ## 404 - Running prompts, by hand and on a schedule A saved prompt runs two ways: at your keyboard when you want the report now, and on a schedule when you want it to arrive on a cadence. Running by hand takes a sentence: name it to the agent under any handle it knows, pick it in the List Prompts app, or paste the portal’s copyable invocation. Scheduling is not a Plexara feature at all; it lives in your agent, from an in-session loop to a cloud routine that runs when your machine is off. This article covers both, where the output goes, and how a share turns an unattended run into email somebody actually reads. On this page ### What you will take away from this lesson A procedure only pays off when it runs. A saved prompt runs two ways: at your keyboard, when you want the report now, and on a schedule, when you want it to arrive on a cadence without being asked. This last article covers both. Running by hand is the common case and takes a sentence. Running on a schedule is a feature of your agent, not of Plexara: you point your agent’s scheduler at the saved prompt, and when it fires, a fresh session runs that prompt by name. Plexara stores the procedure; the agent keeps the clock. Learning Objectives 1. 01 Run a saved prompt three ways: by naming it to the agent under any handle it knows, by picking it in the List Prompts app, and from the portal’s copyable invocation. 2. 02 Pass arguments at run time, and let the agent ask for any required value you leave out. 3. 03 Understand where scheduling lives: in your agent, not in Plexara. The prompt is a saved instruction; the agent is what runs it on a clock. 4. 04 Pick a scheduling mechanism your agent offers, from an in-session loop to a cloud routine that runs when your machine is off. 5. 05 Know that a scheduled run saves its result to the asset portal like any other run, then finish the job: a predictable name, a share that puts real email in front of the right person, and a look at the run counts that tell you the schedule is still firing. ### Where this lesson sits This is the capstone of the 400 series. The procedure has been authored, shared, and kept correct. All that is left is the part that produces value: running it, at the keyboard and on a cadence. 400 Series: Prompts as SOPs [Open index](https://plexara.io/learning/prompts) - [401 Prompts are the new SOPs The difference between what your organization knows (memory and insights) and how one specialized job gets done (a prompt). When a perfect report is a recipe worth keeping, not institutional knowledge.](https://plexara.io/learning/prompts/prompts-are-the-new-sops) - [402 Letting the agent write the prompt The agent that just did the work is the best author of the prompt that repeats it. It still holds the gotchas, the tool order, and the values worth turning into arguments. You review the draft, then save it.](https://plexara.io/learning/prompts/letting-the-agent-write-the-prompt) - [403 Sharing prompts, and closing the loop with feedback Hand a prompt to one teammate by email, or promote it to a whole role through the admin review queue. Then let feedback threads tell you what to fix, and fold the good corrections back into the catalog.](https://plexara.io/learning/prompts/sharing-prompts-and-feedback) - [404 Running prompts, by hand and on a schedule Run a saved prompt at the keyboard three ways, or on a cadence using your agent’s own scheduling: an in-session loop, headless plus cron, a desktop task, or a cloud routine. Scheduling lives in the agent, not Plexara.](https://plexara.io/learning/prompts/running-prompts-and-schedules) The 400 series builds on the prompt mechanics from [308](https://plexara.io/learning/assets/reproducible-prompts). If the words prompt, argument, and scope are new, read that first. ### Running one by hand The common case is a person who wants this report now. There are three ways to do it, and they differ only in how you pick the prompt and hand over its arguments. The instruction that runs underneath is identical. Three ways to run a saved prompt at the keyboard - Ask the agent by name In any chat session, say "run the annotated sales review for Q2 2026, Southwest." The agent resolves that against your library with manage_prompt use, which accepts any handle you happen to have: the exact name, the display name, or a description of the one you mean. You never type a scope prefix. It substitutes the arguments you gave, asks for any required value you left out, and runs the resulting instruction. This works in every client, whether or not it has special prompt support. - Pick it in the List Prompts app In a host that renders MCP Apps, asking to see your prompts opens the built-in List Prompts browser inside the conversation: search-as-you-type, collection and tag filters, and a detail view with a form generated from the prompt’s argument specs. Fill the form, press Run, and the rendered prompt lands directly in the chat. You type no instruction, and clients that draw no UI lose nothing, because the browser reads the same calls whose plain results those clients already get. - From the portal The portal’s Prompts page is where you read a prompt carefully and check its arguments before committing to a run. Each prompt page carries a copyable invocation in plain language, built from that prompt’s stable name and its required arguments. Paste it into any connected client and you are back on the first path, with the name spelled the way the library stores it. All three resolve the same record and substitute the same arguments. The only difference is how you pick the prompt and how you supply the values. A required argument you omit is not an error; the agent asks for it. Lesson [208](https://plexara.io/learning/mcp/mcp-prompts-reusable-prompts) covers the resolution rules and the app itself in detail. ### Running one on a schedule When you want the report to show up on a cadence rather than because you asked, the scheduling does not happen in Plexara at all. Plexara stores the prompt; your agent runs it. Scheduling is a capability of the agent or client you connect to Plexara with, and capable agents already offer several ways to do it. When the schedule fires, a fresh session starts, connects to Plexara as usual, and runs your saved prompt by name. The options below are Claude Code’s, which is a useful concrete example because it spans the full range from a quick in-session loop to a cloud routine that runs when your laptop is closed. If you use a different client, look for its equivalent; the shape is the same. Where scheduling actually happens: in the agent - An in-session loop Your machine, session open Claude Code’s /loop runs a prompt or slash command on a repeating interval while the session stays open. Best for quick polling during work; it stops when you close the session. - Headless plus cron Your machine, no session Run the agent non-interactively (claude -p "run the annotated sales review for ...") and let your system cron or CI fire it on a clock. The scheduler is the operating system; each run is fresh and independent. - A desktop scheduled task Your machine, app open The Claude Code Desktop Routines page runs a saved instruction on a cadence (hourly, daily, weekly, or a custom interval) as a fresh local session. It persists across app restarts and fires while the app is open and the machine is awake. - A cloud routine Managed cloud A routine runs a saved instruction on a schedule, or on an API call or a GitHub event, on managed infrastructure, so it fires even when your own machine is off. These are agent features, not Plexara features. In every case the scheduler fires a fresh session, that session connects to Plexara the same way your interactive ones do, and it runs your saved prompt by name. Plexara never sees a clock. The four options above are Claude Code’s; see its [scheduling docs](https://code.claude.com/docs/en/scheduled-tasks) for the details, and check your own client for the equivalent. ### The output lands in the portal, the same as any run A scheduled run is not a special case for output. Because the procedure ends by saving its result as an asset, the way the 402 example does, a scheduled run lands a dashboard or report in the portal like every other run, already viewable, shareable, and stored in your own bucket. The asset system from the 300 series is its home; there is no separate destination to wire up. What a run nobody is watching needs is a little extra on top, and most of it is one sentence in the prompt or one action in the portal. An unattended run still saves an asset There is no question of where the output goes. A well-written procedure ends by saving its result as an asset, so a scheduled run lands a dashboard or report in the [portal](https://plexara.io/learning/assets/creating-reports-and-dashboards) the same way an interactive run does: viewable and shareable, in your own storage. The result is never stranded in a session nobody opened. What an unattended run needs on top of that is to be found and noticed without you at the keyboard. That used to be the awkward part of scheduling anything: the report arrived and nobody knew. It is not awkward now, because a [share](https://plexara.io/learning/assets/sharing-your-work) puts real email in front of the person who needs the result. The checklist below is the whole of it. [Image: The Assets page in grid view with Mine, Shared, and All filters, a search box, type and tag filters, and cards for a Q4 revenue dashboard, a sales pipeline chart, a weekly inventory report, and others, each with a live preview, a content type, tags, a size, and a date.] Where a scheduled run lands. The asset a procedure saves shows up on the Assets page like any other, with its type, tags, and date, so the reader finds it the same way whether a person or a schedule produced it. [Image: The Activity page with 1h, 6h, 24h, and 7d range buttons, tiles for Total Calls, Avg Duration, and Tools Used, a My Activity line chart of calls across the last 24 hours, and a Top Tools bar chart led by Trino Query and Datahub Get Entity.] The evidence that the run happened. Activity charts your tool calls over the window and ranks the tools used, so an unattended run at midnight leaves a bump you can see the next morning. ### Five things that turn a schedule into something people read A report that arrives on a cadence and sits unopened is worse than no report, because you now trust a number nobody checked. These five close that gap. The middle three are recent: sharing an asset with a colleague mails them, with your note in the message, and the portal keeps a record of what was sent and how often each prompt has run. What a run nobody is watching needs - A name each run produces the same way Have the procedure name and tag its asset from a fixed pattern so successive runs sort next to each other instead of scattering across the library. The other good shape is one long-lived asset the run updates in place: the version history keeps every run, and a link you sent months ago still opens the current one. - A share, which is a real email now Share the result with the colleague who needs it and Plexara mails them: your note quoted in the message, a link that opens the work, and a way in even if they have no account. This is the half of an unattended run that used to be yours to invent. Share the asset once and update it in place on a cadence, or share each run’s output as it lands, whichever suits how often you look. - A record of what was actually sent Recent notifications, in your Settings, lists the notifications addressed to you with their subject, category, and delivery status, directly beneath the preferences that govern them. Delivery is the recipient’s call, not yours: a colleague on daily digest reads your share tomorrow morning, and one who turned shares off reads it never. Both look identical from your side, so ask about their delivery mode before you conclude the mail is broken. - A check that the schedule is still firing A scheduled prompt that quietly stopped running looks exactly like one nobody needed. The portal’s Prompts page carries the evidence: every row shows a run count and a last-run age, sortable, and a prompt that has never run, or has gone 60 days unused, wears a badge naming that condition. A nightly report whose last run was three weeks ago is the schedule telling you it died. - A result the run refuses to save when it is wrong Tell the prompt to flag an empty or out-of-range result rather than saving a broken report quietly. Nobody is in the session to notice, so the procedure has to do the noticing. One sentence in the prompt buys it. Two of these live in the prompt (the naming and the guard), and three live in the portal (the share, the delivery record, and the usage columns). None of them is a setting to hunt for. Lesson [303](https://plexara.io/learning/assets/sharing-your-work) covers sharing, the note, and delivery preferences end to end. ### The end of the series, and the start of the habit The whole series points at one small, high-return change in how a team works with the agent: when a session turns out to be a procedure, save it as one. Everything else, authoring, sharing, feedback, scheduling, follows from that first act. That wraps the 400 series Four articles, one idea: the procedures your team discovers with the agent are worth keeping, and Plexara keeps them as prompts. You saw why a specialized report is a procedure rather than institutional knowledge, how to let the agent author the prompt that repeats it, how to share it and improve it through feedback, and how to run it by hand or on a schedule. The useful next move is not another article. It is taking one report you have rebuilt from scratch more than once and saving it, this week, as a prompt. ### Key terms Four terms close the series: the act of running a prompt, and the three pieces that turn a by-hand run into a scheduled one. Key Terms Invocation Running a saved prompt: by naming it to the agent under any handle it knows, by picking it in the List Prompts app, or by pasting the portal’s copyable invocation into a session. All three resolve the same record and substitute the same arguments. In-session loop /loop Scheduling inside an open agent session. Claude Code’s /loop reruns a prompt or slash command on a repeating interval while the session stays open. Stops when the session closes. Headless run claude -p Running the agent non-interactively so an external scheduler can fire it. Put claude -p in a system cron job or CI schedule; each run is fresh and independent. Scheduled task / routine A saved instruction the agent runs on a schedule on its own: a Claude Code Desktop task on your machine, or a cloud routine that runs on managed infrastructure even when your machine is off. On this page [Previous 403 - Sharing prompts, and closing the loop with feedback](https://plexara.io/learning/prompts/sharing-prompts-and-feedback) ### Related reading product [Product 102 - Tokens and your budget Every LLM interaction is priced and rate-limited in tokens. What a token is, how much text fits a budget, and how to avoid wasting tokens on useful answers.](https://plexara.io/learning/ai-concepts/tokens-and-your-budget) [Product 105 - What is an AI agent? An AI agent is not a chatbot and not magic. It is a short loop (think, call-tool, observe, think again) on top of a language model. Mental model first.](https://plexara.io/learning/ai-concepts/what-is-an-ai-agent) [Product 202 - Your first day with Plexara A new Plexara user gets connected, sends a first question, and platform_info takes over. Walks through day one and how subsequent turns inherit context.](https://plexara.io/learning/mcp/first-engagement) --- # The last mile of data is a spreadsheet URL: https://plexara.io/learning/spreadsheets/the-last-mile-of-data-is-a-spreadsheet/ > The join was never the expensive part of using an outside file. Loading it was, and loading was staffed: a ticket for the table, an engineer for the load, an integration platform somebody had to keep. A chat agent does not close that gap on its own, because a large file does not fit its context and the scripts it writes vanish with the session. This lesson sets out the gap, the registration model that closes it (a table over the file where it sits, nothing copied), and the size rule for when a file needs no table at all. Philosophy 9 min read ## 501 - The last mile of data is a spreadsheet The join was never the expensive part of using an outside file. Loading it was, and loading was staffed: a ticket for the table, an engineer for the load, an integration platform somebody had to keep. A chat agent does not close that gap on its own, because a large file does not fit its context and the scripts it writes vanish with the session. This lesson sets out the gap, the registration model that closes it (a table over the file where it sits, nothing copied), and the size rule for when a file needs no table at all. On this page ### What you will take away from this lesson Once a month a supplier emails a price sheet. It has four hundred rows: a SKU, a unit cost, a minimum order quantity, an effective date. Every number in it matters only next to something you already have. What did we pay last month, what do we sell it for, how many did we move. The join is the whole point, and the join is easy. What has never been easy is getting the file into a place where the join can happen. This lesson is about that gap. It is the most expensive step in everyday data work, it is staffed by people who are not the person holding the file, and an AI agent in a chat window does not close it on its own. The rest of the series is about what closes it. Learning Objectives 1. 01 Recognize that the cost of an outside file was never the join; it was the loading, and the loading was staffed. 2. 02 Describe the traditional path from a file in an inbox to a table in the warehouse (a ticket, a table, a load job, an integration platform, weeks) and the expertise each step requires. 3. 03 Explain why a chat agent does not close the gap on its own: the file does not fit its context, it needs the file on a local disk, the scripts it writes vanish with the session, and nothing reaches the rest of the team. 4. 04 State the registration model: a table created over the file where it sits, nothing copied, the header row becoming the columns. 5. 05 Apply the size rule: a few hundred keys join inline through a VALUES list; registration is for the file that is too big for that. ### Where this lesson sits This is the opening lesson of the 500 series. It makes the argument; the four lessons after it are the workbook, built end to end on one supplier price sheet. 500 Series: Spreadsheets as Tables [Open index](https://plexara.io/learning/spreadsheets) - [501 The last mile of data is a spreadsheet The join was never the expensive part; loading was, and loading was staffed. Why a chat agent does not close the gap on its own, and what a table over the file where it sits changes.](https://plexara.io/learning/spreadsheets/the-last-mile-of-data-is-a-spreadsheet) - [502 Uploading a file and registering it as a table The resource library, the Excel rule, the Query as a table panel, what a registration answers with, the Scratch Tables page, and the three things a file is refused for.](https://plexara.io/learning/spreadsheets/uploading-and-registering-a-file) - [503 Teaching the agent what the file means Units, grain, effective dating, the join key, and what a missing row means: captured once, promoted to a knowledge page, recalled by every teammate’s agent.](https://plexara.io/learning/spreadsheets/teaching-the-agent-what-the-file-means) - [504 Joining, visualizing, and sharing The join with the cast, a supplier quote against a month of sales, a dashboard asset with provenance, and when a dashboard should reference the file instead of querying it.](https://plexara.io/learning/spreadsheets/joining-visualizing-and-sharing) - [505 Next month’s file A new revision leaves the table behind; register again to move it forward. Unregistering, deleting, the monthly procedure as a prompt, and where a join stops being enough.](https://plexara.io/learning/spreadsheets/next-months-file) The 500 series assumes the asset mechanics from the [300 series](https://plexara.io/learning/assets) and the knowledge loop from [206](https://plexara.io/learning/mcp/knowledge-from-memory-to-insights). It ends where the [600 series](https://plexara.io/learning/automations) begins: the point at which a monthly file needs more than a join. ### What arrives by email Most of the data a business runs on is in its warehouse. A surprising share of the data it decides on is not. It arrives as an attachment: a price sheet from a supplier, a lease schedule from the real-estate team, a list from an agency, a rebate schedule from a vendor. These files are small, they come on a cadence, and they were produced by somebody else’s system, which is why they are not already in yours. They have one thing in common. On their own they say almost nothing. A unit cost means something only next to the cost of record and the shelf price; a lease means something only next to the store’s revenue. The file is valuable exactly when it is joined, and it is stranded exactly because joining it was somebody else’s job. Files that are valuable exactly when joined A supplier price sheet, monthly, by SKU The product catalog’s cost of record and shelf price, and the month’s unit sales. A lease schedule from the real-estate team, by store Store revenue, so occupancy cost can be read as a share of sales. A marketing list from an agency, by customer email The customer file and loyalty tier, so a campaign can be measured against spend. A vendor rebate list, by store and quarter Purchase volume by store, so the rebate can be checked before it is paid. None of these files is interesting on its own. Each one answers a question only when it is next to a warehouse table, and each one usually stays in the inbox because putting it next to that table was a project. ### The staffed path The conventional way to get an outside file next to a warehouse table is to make it a warehouse table. That is a project with a cast: a database administrator to create the table and decide its types, an engineer to write the load and handle the file’s quirks, and, for anything that recurs, an integration platform (Workato, n8n, and Apache NiFi are the category) that automates the flow and needs a platform expert to build and keep it. Each step is reasonable. Each step is also a handoff, and the analyst who received the file waits on all of them. For a feed that arrives every hour and has to be typed, validated, and monitored, that investment is correct. For a monthly sheet with four hundred rows it never pays back, so the sheet does not get loaded. It gets joined by hand in a spreadsheet, the answer lives on one laptop, and next month the same person does it again. Two ways an outside file reaches the warehouse The staffed path Registration Who is involved The staffed path The analyst files a ticket. A database administrator creates the table. An engineer writes the load. A platform expert builds and keeps the flow in the integration platform. Registration The person holding the file, and their agent. Nobody else is needed, and nobody else is waiting on. What is built The staffed path A destination table with declared column types, a staging area, a load job, a schedule, and monitoring for when the file’s shape changes. Registration A table over the file where it already sits. Nothing is copied, nothing is loaded, and the header row supplies the columns. Elapsed time The staffed path Days to weeks, most of it waiting for the next person in the chain. Registration Minutes, in the same session the file was uploaded. When the file changes shape The staffed path The load breaks, and the ticket is reopened. Registration Register the new file. The columns are read from its header again. Who can use the result The staffed path Everyone, once it lands. It rarely lands for a one-off file. Registration Everyone granted the connection, from the moment it is registered, by name in ordinary SQL. The staffed path is the right one for a feed that arrives every hour and has to be typed, validated, and monitored. A one-off file, or a monthly sheet with four hundred rows, never earns that setup, so it gets joined by hand in a spreadsheet instead, and the answer stays on one laptop. ### The agent without help It is tempting to assume an AI agent makes this problem go away. It does not, not on its own. A conversation is a poor place to keep a file, a worse place to load one, and no place at all to run a join against seven million line items. The workarounds people reach for reproduce the old problem in a new form: the file goes on a laptop, the agent writes a script to parse it, the script runs once and is gone. Why a chat agent does not close the gap on its own - The file does not fit A 100 MB CSV is millions of tokens. It cannot be pasted into a conversation, and an agent that reads it in pieces cannot hold enough of it at once to join it against anything. - The work happens on a laptop and vanishes The usual workaround is to give the agent the file on local disk and permission to write scripts that parse it. The scripts are temporary. They run once, under one person’s credentials, and disappear with the session, so next month starts from zero. - Nobody else gets anything A colleague who needs the same join tomorrow cannot find the file, the script, or the answer. What one person taught their agent stays with that person. The agent is not the problem. It is being asked to be the storage, the loader, and the query engine at once, and a conversation is the wrong shape for all three. ### Registration, not ingestion The fix is to stop treating the file as something to be moved. Upload it once, to a library where it has an owner, a description, and a version history, and then register it: ask the platform to create a table over the file where it already sits. The header row becomes the column list. From that moment the file is a table in ordinary SQL, beside the warehouse, for everyone granted the connection. The agent does the registering in one call, and the platform answers with the table’s name, its columns, and a sample statement. There is nothing to design and nothing to schedule. A file that would have waited weeks on the staffed path is joinable in the session it arrived in. A registration is a pointer and a name, not an import When a file in Plexara is registered as a table, the platform reads its header row to learn the columns, creates a table over the directory the file already occupies, and records the registration. Nothing is copied. The table reads whatever the file holds, and it sits beside the warehouse tables in the same SQL, on a connection named `scratch`, under a name that carries the registering person’s persona so everyone can see whose working table it is. That is the whole model. There is no destination table to design, no load to write, and no flow to keep. The join that was the point of the file is one statement, and [504](https://plexara.io/learning/spreadsheets/joining-visualizing-and-sharing) runs it against real numbers. ### The size rule Not every outside list needs a table. A handful of store ids somebody pasted into the chat, or a few hundred SKUs from an email, join inline: the agent writes them into a VALUES list and runs one statement. That is faster than registering anything, and it leaves nothing behind to clean up. Registration is for the file that is too big for that: the one where writing the rows into a statement would be slow, would fill the conversation with data instead of reasoning, and would have to be done again by every person who needed the same join. The size rule: a short list needs no table ``` SELECT s.store_id, s.store_name, r.rebate_pct FROM warehouse.public.stores s JOIN (VALUES ('412', '2.5'), ('418', '3.0'), ('433', '2.5')) AS r (store_id, rebate_pct) ON CAST(s.store_id AS varchar) = r.store_id ``` A handful of ids, or a few hundred, join inline: the agent writes them into a `VALUES` list and runs one query. Registration is for the file that is too big for that, where writing the rows into a statement would be slow and would burn the conversation’s context on data. The four-hundred-row price sheet is at the boundary; a fifty-thousand-row one is well past it. ### What the series covers The next four lessons follow one file through its life: uploaded and registered, explained to the agent, joined and turned into a shared dashboard, and replaced when the next month’s version arrives. Every figure in them comes from a real run on the demo tenant. Next: the upload and the registration The rest of the series is the workbook. In [502](https://plexara.io/learning/spreadsheets/uploading-and-registering-a-file) the supplier’s sheet is uploaded, registered, and refused and repaired when a spreadsheet export is not quite a CSV. In [503](https://plexara.io/learning/spreadsheets/teaching-the-agent-what-the-file-means) the agent learns what the columns mean and passes that on to the team. In [504](https://plexara.io/learning/spreadsheets/joining-visualizing-and-sharing) the join runs and becomes a shared dashboard, and in [505](https://plexara.io/learning/spreadsheets/next-months-file) next month’s sheet arrives. The product page for [Spreadsheets as Tables](https://plexara.io/product/spreadsheets) and the insight [The spreadsheet that joins your warehouse](https://plexara.io/learning/insights/the-spreadsheet-that-joins-your-warehouse) make the same case in fewer words. ### Key terms Five terms carry the series. Two name the kinds of stored file, and three describe what registering one does. Key Terms Managed resource A file a person uploads to the resource library: a price sheet, a template, a reference document. It has a description, a category, tags, a version history, and a scope that decides who sees it. Asset A file the agent saved: a dashboard, a report, an exported CSV. Covered in the [300 series](https://plexara.io/learning/assets). A CSV asset registers as a table the same way a CSV resource does. Registration The act of making a stored CSV queryable: the platform reads the header row, creates a table over the file where it sits, and records who registered what on which connection. A pointer and a name, not a copy. Scratch schema scratch.uploads The shared working schema on the connection named scratch where registered tables live. Everyone granted the connection can read every table in it, and table names carry the registering persona as a prefix. External table A table whose data is not stored by the query engine but read from files at a location the engine is pointed at. A registered table is one; dropping it removes the catalog entry and leaves the file untouched. On this page [Next 502 - Uploading a file and registering it as a table](https://plexara.io/learning/spreadsheets/uploading-and-registering-a-file) ### Related reading philosophy [Philosophy 101 - What is a Large Language Model? LLMs predict the next token from patterns learned across trillions of training examples. What that means, why it produces fluent reasoning, and its limits.](https://plexara.io/learning/ai-concepts/what-is-a-large-language-model) [Philosophy 104 - Frontier models, specialized models, and why enterprise AI uses both Frontier models bring world knowledge; small local embedding models power memory and catalog search. Knowing each role designs AI systems that work.](https://plexara.io/learning/ai-concepts/frontier-models-explained) [Philosophy 401 - Prompts are the new SOPs You work with the agent for an hour to get one report exactly right, with a year-over-year cut, holiday annotations, and storm-closure markers. The agent saves durable business knowledge on its own. But that specialized report is not institutional knowledge, it is a procedure. This article draws the line between the two, and makes the case that a saved prompt is the standard operating procedure for an AI-run job.](https://plexara.io/learning/prompts/prompts-are-the-new-sops) --- # Uploading a file and registering it as a table URL: https://plexara.io/learning/spreadsheets/uploading-and-registering-a-file/ > The mechanics. Upload a file to the resource library with a description search will match, export a spreadsheet as UTF-8 CSV first, register it from the file’s own page or with one sentence to the agent, and read what comes back: the qualified name, the columns, and a sample statement with the cast. Then the Scratch Tables page, where every registration is listed with its state, and the three things a file can be refused for, with the repair that writes a corrected version through the file’s own history. Product 11 min read ## 502 - Uploading a file and registering it as a table The mechanics. Upload a file to the resource library with a description search will match, export a spreadsheet as UTF-8 CSV first, register it from the file’s own page or with one sentence to the agent, and read what comes back: the qualified name, the columns, and a sample statement with the cast. Then the Scratch Tables page, where every registration is listed with its state, and the three things a file can be refused for, with the repair that writes a corrected version through the file’s own history. On this page ### What you will take away from this lesson [501](https://plexara.io/learning/spreadsheets/the-last-mile-of-data-is-a-spreadsheet) made the argument. This lesson is the mechanics, done once on a real file: the November price sheet from Blue Harbor Wholesale, four hundred rows, seven columns, the kind of attachment that used to wait weeks for a table. There are two halves. Getting the file into the library, which a person does in the portal or the agent does in one call, and registering it, which turns the file into a table with a name you can write in a FROM clause. Both take minutes. The part worth learning carefully is what the platform tells you back, and the small set of files it refuses. Learning Objectives 1. 01 Upload a file to the resource library with the fields that make it findable (display name, description, category, tags), on the tab that decides who sees it: My Resources, your persona, or Global. 2. 02 Know the Excel rule: export the sheet as UTF-8 CSV, one sheet per file, header row first, before uploading. 3. 03 Register from the file’s own page or by one sentence to the agent, and read what the registration answers with: the qualified name, the columns, and a sample statement with the cast. 4. 04 Find every registered table on the Scratch Tables page (search by name, facets by connection and by kind of file) and open one. 5. 05 Recognize the three things a file can be refused for and take the repair, which writes a corrected version through the file’s own version history. ### Where this lesson sits The second lesson of the 500 series, and the first hands-on one. It takes the supplier price sheet from an attachment to a table with a name, and covers the files the platform turns away. 500 Series: Spreadsheets as Tables [Open index](https://plexara.io/learning/spreadsheets) - [501 The last mile of data is a spreadsheet The join was never the expensive part; loading was, and loading was staffed. Why a chat agent does not close the gap on its own, and what a table over the file where it sits changes.](https://plexara.io/learning/spreadsheets/the-last-mile-of-data-is-a-spreadsheet) - [502 Uploading a file and registering it as a table The resource library, the Excel rule, the Query as a table panel, what a registration answers with, the Scratch Tables page, and the three things a file is refused for.](https://plexara.io/learning/spreadsheets/uploading-and-registering-a-file) - [503 Teaching the agent what the file means Units, grain, effective dating, the join key, and what a missing row means: captured once, promoted to a knowledge page, recalled by every teammate’s agent.](https://plexara.io/learning/spreadsheets/teaching-the-agent-what-the-file-means) - [504 Joining, visualizing, and sharing The join with the cast, a supplier quote against a month of sales, a dashboard asset with provenance, and when a dashboard should reference the file instead of querying it.](https://plexara.io/learning/spreadsheets/joining-visualizing-and-sharing) - [505 Next month’s file A new revision leaves the table behind; register again to move it forward. Unregistering, deleting, the monthly procedure as a prompt, and where a join stops being enough.](https://plexara.io/learning/spreadsheets/next-months-file) The 500 series assumes the asset mechanics from the [300 series](https://plexara.io/learning/assets) and the knowledge loop from [206](https://plexara.io/learning/mcp/knowledge-from-memory-to-insights). It ends where the [600 series](https://plexara.io/learning/automations) begins: the point at which a monthly file needs more than a join. ### Resource or asset Plexara stores two kinds of file, and both register the same way. A managed resource is something a person put in the library: reference material, uploaded with a description so others can find it. An asset is something the agent produced and saved, with the calls that produced it recorded as provenance. A supplier’s sheet is a resource. A CSV the agent exported from a warehouse query is an asset, and it can be registered too, which is how one query’s result becomes a table another query joins against. Two kinds of stored file, one way to register them - A managed resource What it is A file a person uploaded as reference material, or one the agent filed on their behalf. It has a description, a category, tags, a scope, and a version history. For example The supplier’s price sheet. A report template. A brand file. A data dictionary somebody wrote. Where it lives The Resources page, on the tab that decides who sees it. - An asset What it is A file the agent produced and saved: an exported CSV, a dashboard, a report. It carries provenance, the calls that produced it. For example A CSV the agent exported from a warehouse query. The margin dashboard built in 504. Where it lives The asset portal, covered in the 300 series. A CSV of either kind registers the same way, from the same panel, with the same tool. The difference is who put it there and what the file knows about itself. The rest of this lesson follows a resource, because a supplier’s sheet is something a person uploads. ### Uploading in the portal The Resources page has a tab per library: My Resources, your persona, and Global. Upload from the tab you want the file to land in; the dialog states the destination and who will see it before you pick a file. The dialog asks for four things besides the file, and the description is the one that decides whether anyone finds it later. The Upload dialog The tab you are on My Resources, your persona, or Global. The tab is the library the upload lands in, and the dialog says who will be able to see the file before you choose one. Category One of the six shelves (data, visual, templates, playbooks, samples, references) or a custom one. The price sheet is data. Display name What the library and every search hit print. Name the file for what it is, not the month it arrived, because the same file will hold next month’s sheet. Description What the file is and what reads it. This is the text search matches, so write the question somebody will ask: supplier cost per SKU, monthly, compare to the cost of record. Tags Lowercase labels for filtering the library: supplier, pricing, cost, monthly. The portal takes a file up to 100 MB. Once it is in, the file has its own page with a Version history (every revision, who uploaded it, when, how large; any version can be downloaded or restored) and a Replace content control that uploads new bytes under the same name, which is how next month’s sheet will arrive. [Image: The Upload dialog on the Resources page: a file picker, a category selector, display name, description, and tags fields, with a note stating which library the file will land in and who will see it.] The dialog asks for the file plus category, display name, description, and tags. The scope is not a field; it is the tab you opened the dialog from, and the dialog states it. ### The Excel rule Suppliers send spreadsheets, not CSVs. The library will store a workbook, but registration needs a header row and rows under it, so the sheet you intend to query is exported first. This is a thirty-second step and the one people forget. Export a spreadsheet as UTF-8 CSV before uploading The library stores any file that is not an executable, so a workbook can be kept there as reference material. Registration reads CSV, because it needs a header row to take the columns from and a workbook has sheets, formulas, and merged cells instead. Before uploading a spreadsheet you mean to query: one sheet per file, the header row first, saved as CSV with UTF-8 encoding. Skip the Unicode Text export, which is UTF-16 and is refused outright. A machine with Excel installed sometimes declares a `.csv` as a spreadsheet when it uploads it. The platform reads the file by its name and content, so that file registers normally. ### Registering from the file’s page A CSV resource’s page carries a Query as a table panel. It shows what is already registered over the file and offers the connections that can hold a new table. Registering is a connection, an optional name, and one button. The platform reads the file, takes the columns from its header, creates the table over the directory the file occupies, and shows the qualified name it can now be queried by. Registering from the Query as a table panel 1. 1 Open the file’s page A CSV resource or CSV asset carries a Query as a table panel. It lists what is already registered over the file, with each table’s columns, and offers the connections you can reach that can hold one. 2. 2 Pick the connection and, if you like, a name The connection is scratch. The name is optional and defaults to a slug of the file name. Either way your persona is added as a prefix, because the scratch schema is shared by everyone granted the connection and a reader should be able to tell whose working table they are looking at. 3. 3 Register The platform reads the whole file, takes the header row as the column list, creates the table over the directory the file occupies, and records the registration. The panel then shows the qualified name and the columns. 4. 4 Register again, when you need to The control stays available. The same name on the same connection replaces the registration (that is how a table is moved forward in 505); a different name, or another connection, adds a second table over the same file. [Image: The Query as a table panel on a CSV resource page, with a connection selector, an optional table name field, and a Register button, above a list of the tables already registered over the file and their columns.] The panel on the file’s page. Connection, optional name, Register. What is already registered over the file is listed underneath with each table’s columns. ### The same thing by asking the agent The agent does both halves in one turn. Handed the sheet and a sentence about what it is, it files the resource with a description and tags, then registers it, and reads you back the answer. The trace below is the real one from the demo tenant; the answer is worth reading closely because it is the same answer the panel shows, and it tells you the two things you need to write the join. From then on the file is findable by anyone on the team. A search hit for it carries the table reference and the sample statement, so finding the file and querying it are one turn apart. The same two steps as tool calls, with the real answers What the agent calls. This is the exchange the agent has with Plexara on your behalf, shown for the technical reader. You ask in plain language; you never type any of it. ``` manage_resource action=create filename="supplier-price-sheet-2025-11.csv" category="data" content_type="text/csv" display_name="Blue Harbor Wholesale price sheet (November 2025)" description="Monthly supplier quote from Blue Harbor Wholesale: the unit cost they will charge from the effective date, per SKU, with minimum order quantity and lead time. Keyed by sku, which matches warehouse.public.products.sku. ..." tags=["supplier","pricing","cost","monthly"] → resource_id 71131796b81fbb5641bdcbb3df0ef238 size_bytes 23696 scope user reference mcp:resource:71131796b81fbb5641bdcbb3df0ef238 uri mcp://user/d2927f77-2c52-4d0d-a521-76c84428f22a/data/supplier-price-sheet-2025-11.csv manage_table action=register reference = mcp:resource:71131796b81fbb5641bdcbb3df0ef238 connection="scratch" table_name="supplier_price_sheet" → query_table scratch.uploads.admin_supplier_price_sheet registration_id reg_a9de2c4f449ca8d2f44809b4405dfe57 columns sku, supplier_name, unit_cost, currency, moq, effective_date, lead_time_days registered_by craig.johnston@deasil.works stale false sample_sql SELECT * FROM scratch.uploads.admin_supplier_price_sheet -- every column is VARCHAR, so a join to a typed column casts: -- JOIN scratch.uploads.admin_supplier_price_sheet t ON w.id = CAST(t."sku" AS BIGINT) "Registered as scratch.uploads.admin_supplier_price_sheet on connection scratch. Every column is VARCHAR, so a join to a typed column needs a CAST." ``` Two things to read in the answer. The qualified name carries the persona prefix `admin_`, which the registrant did not type. And the sample statement shows the cast pattern against the first column because every registered column arrives as text; in this file `sku` is text on both sides (`SKU-000001`) and needs no cast, while `unit_cost` does before any arithmetic. The agent writing a file this way is capped at 10 MB; a bigger file goes in through the portal and the agent registers it. ### The Scratch Tables page A file’s page shows what is registered over that file. The scratch schema is shared, though, so the question a reader usually has is wider: what is registered here at all, by whom, and is it still current. The Scratch Tables page in the portal’s section list answers that in one list, and each row opens to a page of its own. What a row on the Scratch Tables page carries Qualified name The name to write in a FROM clause, persona prefix included. Connection Which connection holds the table. A facet narrows the list to one. The file behind it The resource or asset the table reads, and a facet for which kind it is. Columns, who, when How many columns the table has, who registered it, and when. State Behind the file, when the file has a newer version than the table points at. Source deleted, when the file is no longer on the platform. The scratch schema is shared, so the question “what is registered here” has to be asked of the platform rather than of one file at a time. This page answers it: every registration you may see, searchable by name, whichever kind of file each was built over. Unregistering is done here, on the tables you may drop. Registering stays on the file’s own page, because it needs the file. [Image: The Scratch Tables page: a search box, facets for connection and kind of file, and a list of registered tables showing each qualified name, connection, source file, column count, registrant, and state.] One list of every registration. Each row names the table, the connection, the file behind it, its column count, and who registered it, with the state called out when a table has fallen behind its file. [Image: A registered table’s own page: the sample statement with the cast a join needs, the columns with their types, the file the table was built from, and the directory it reads.] Opening a row. The sample statement with the cast, the columns with their types, the file it came from, and the directory it reads, at an address of its own. ### Files that are refused, and the repair Registration reads the whole file before it creates anything, and it refuses three things a spreadsheet export commonly carries. Each would otherwise produce a table that is created without error and answers with wrong rows, which is worse than a refusal. Each refusal says what is wrong, and for all three the platform offers to correct the file itself. Three refusals, one repair - A line break inside a cell Why it is refused The query engine reads a CSV line by line, so a multi-line address or note tears one record into several. The table would be created without error and answer with rows made of fragments. The refusal says how many rows carry one and which columns they are in. What the repair does Each run of line breaks inside a cell becomes a single space and the cell is trimmed. - Lines ending in a bare carriage return Why it is refused The classic Mac line ending some spreadsheet exports still write. To a line-based reader the whole file is one record. A Windows ending is not this and costs nothing. What the repair does Each carriage-return line ending becomes a newline, so every record is on its own line. - Bytes that are not UTF-8 Why it is refused A legacy code page arrives as replacement marks in every affected cell. A NUL byte is refused on the same ground even where the rest of the file is valid. What the repair does The bytes are read as windows-1252, a leading byte-order mark is dropped, and the file is written back as UTF-8 CSV. None of the three is refused silently and none leaves anything behind: no table is created and no registration is recorded. The refusal offers the correction, which is one control in the portal (Save a corrected copy and register that) or `repair=true` on the tool call. The result is a new version of the file itself, written through the version history the file already has; the upload stays as the version before it and can be restored. Two things are refused with no repair offered, because no correction could be made on somebody’s behalf: a file whose rows have a different field count from the header, and a UTF-16 or UTF-32 export. Both have to be fixed where they were written. [Image: The Query as a table panel refusing a CSV that cannot be read as a table, stating what is wrong with the file and offering a Save a corrected copy and register that control.] A refusal names what is wrong and offers the correction. Taking it writes a corrected version of the file and registers that; the version panel records why the file changed. ### What is recorded A registered table is readable by everyone granted the connection, so registering is treated as the consequential act it is. It requires the authority to change the file, and it leaves a record. Every registration is recorded Registering publishes a file’s contents into a schema everyone granted the connection can read, so it takes the authority to change the file, not merely to read it: the person who uploaded a resource, the owner of an asset, or an administrator. Every registration and unregistration writes an audit event with who, which connection, the statement that ran, and the table it named. Refused attempts are recorded too, and a repair is recorded on the same event, because it rewrote somebody’s file on their behalf. ### What the platform still does not know At the end of this lesson the sheet is a table with seven text columns and a name. The platform knows the columns are called unit_cost and effective_date. It does not know what they mean, and neither does the agent, until somebody tells it. Next: what the columns mean The table exists and the platform has told you its columns. It has not told you that `unit_cost` is a landed cost in US dollars, that `effective_date` is the first day the quote applies, or that a SKU missing from the sheet means the supplier does not carry it. A header row cannot. [503 is the five minutes in which you tell the agent, and it tells the team](https://plexara.io/learning/spreadsheets/teaching-the-agent-what-the-file-means). ### Key terms Five terms from this lesson: two portal surfaces, the prefix every table name carries, and the correction the platform offers for a file it cannot read. Key Terms Resource library The portal’s Resources page: files people upload, filed by category on the tab (My Resources, a persona, Global) that decides who sees them. A file has a page of its own with a version history. Query as a table The panel on a CSV resource’s or CSV asset’s page that registers it: choose the connection named scratch, optionally a name, and press Register. It lists what is already registered over the file. Persona prefix The prefix added to every registered table name, from the registering person’s persona (admin_ in this lesson). It keeps one persona’s working table apart from another’s in a shared schema and tells a reader whose it is. Scratch Tables The portal page listing every registration you may see: qualified name, connection, source file, columns, registrant, and state. Search by name, facet by connection and kind of file, unregister from here. Repair repair=true The correction offered when a CSV cannot be read as a table the way it is stored: a new version of the file written through its own version history, with the upload kept as the version before it. On this page [Previous 501 - The last mile of data is a spreadsheet](https://plexara.io/learning/spreadsheets/the-last-mile-of-data-is-a-spreadsheet) [Next 503 - Teaching the agent what the file means](https://plexara.io/learning/spreadsheets/teaching-the-agent-what-the-file-means) ### Related reading product [Product 102 - Tokens and your budget Every LLM interaction is priced and rate-limited in tokens. What a token is, how much text fits a budget, and how to avoid wasting tokens on useful answers.](https://plexara.io/learning/ai-concepts/tokens-and-your-budget) [Product 105 - What is an AI agent? An AI agent is not a chatbot and not magic. It is a short loop (think, call-tool, observe, think again) on top of a language model. Mental model first.](https://plexara.io/learning/ai-concepts/what-is-an-ai-agent) [Product 202 - Your first day with Plexara A new Plexara user gets connected, sends a first question, and platform_info takes over. Walks through day one and how subsequent turns inherit context.](https://plexara.io/learning/mcp/first-engagement) --- # Teaching the agent what the file means URL: https://plexara.io/learning/spreadsheets/teaching-the-agent-what-the-file-means/ > A header row says what the columns are called, not what they mean. This lesson is the five minutes after registration: telling the agent the units, the grain, the effective dating, the join key, and what a missing row means; letting it capture that as memory; promoting the capture to a knowledge page so every teammate’s agent recalls it; and recording the first successful join as a reusable query. Registering publishes the data. This is how you publish the meaning. Product 9 min read ## 503 - Teaching the agent what the file means A header row says what the columns are called, not what they mean. This lesson is the five minutes after registration: telling the agent the units, the grain, the effective dating, the join key, and what a missing row means; letting it capture that as memory; promoting the capture to a knowledge page so every teammate’s agent recalls it; and recording the first successful join as a reusable query. Registering publishes the data. This is how you publish the meaning. On this page ### What you will take away from this lesson After [502](https://plexara.io/learning/spreadsheets/uploading-and-registering-a-file) the supplier’s price sheet is a table. Any agent on the scratch connection can select from it. What none of them knows is what a row means: whether `unit_cost` is landed or ex-works, whether it is per unit or per case, which warehouse column `sku` matches, and whether a SKU that is missing from the sheet means the supplier does not carry it or quoted zero. You know all of that, because you opened the email. This lesson is the five minutes that move it out of your head: one message to the agent, one capture, one promotion, and one cited query. After that the file is not only queryable but understood, by your agent and by everyone else’s. Learning Objectives 1. 01 Write a description that makes the file findable by the question somebody will ask, not by its filename. 2. 02 Capture the facts a header row does not carry: units, grain, effective dating, what the cost includes, which warehouse key the file joins on, and what a missing row means. 3. 03 Know which captures are live for you at once and which enter review before the whole team inherits them. 4. 04 Promote the captured facts to a knowledge page so every teammate’s agent recalls them without being told again. 5. 05 Record the first successful join as a reusable query by citing its call. 6. 06 Separate the two halves: registering publishes the data to everyone on the connection; the description and the knowledge page publish the meaning. ### Where this lesson sits This is the third lesson of the 500 series. The file is uploaded and registered; the table exists. This lesson is about the meaning, which no header row carries, and about who ends up holding it. 500 Series: Spreadsheets as Tables [Open index](https://plexara.io/learning/spreadsheets) - [501 The last mile of data is a spreadsheet The join was never the expensive part; loading was, and loading was staffed. Why a chat agent does not close the gap on its own, and what a table over the file where it sits changes.](https://plexara.io/learning/spreadsheets/the-last-mile-of-data-is-a-spreadsheet) - [502 Uploading a file and registering it as a table The resource library, the Excel rule, the Query as a table panel, what a registration answers with, the Scratch Tables page, and the three things a file is refused for.](https://plexara.io/learning/spreadsheets/uploading-and-registering-a-file) - [503 Teaching the agent what the file means Units, grain, effective dating, the join key, and what a missing row means: captured once, promoted to a knowledge page, recalled by every teammate’s agent.](https://plexara.io/learning/spreadsheets/teaching-the-agent-what-the-file-means) - [504 Joining, visualizing, and sharing The join with the cast, a supplier quote against a month of sales, a dashboard asset with provenance, and when a dashboard should reference the file instead of querying it.](https://plexara.io/learning/spreadsheets/joining-visualizing-and-sharing) - [505 Next month’s file A new revision leaves the table behind; register again to move it forward. Unregistering, deleting, the monthly procedure as a prompt, and where a join stops being enough.](https://plexara.io/learning/spreadsheets/next-months-file) The 500 series assumes the asset mechanics from the [300 series](https://plexara.io/learning/assets) and the knowledge loop from [206](https://plexara.io/learning/mcp/knowledge-from-memory-to-insights). It ends where the [600 series](https://plexara.io/learning/automations) begins: the point at which a monthly file needs more than a join. ### What the header does not say Registration reads the header row and turns each name into a column. That is all it can know. The supplier’s sheet has seven columns, and for every one of them the name is less than half of what an analyst needs before joining it to the warehouse. The ledger below is the running example: the header on the left, the facts the agent has to be told on the right. The description you wrote at upload time in 502 covers the file as a whole. This is the column-level layer beneath it, and it is where confident, wrong joins come from when it is missing. Seven columns: what the header says, and what the agent needs to know | Column | The header says | What the agent needs to know | | --- | --- | --- | | sku | A product code. | Matches warehouse.public.products.sku exactly (SKU-000001), so the join needs no cast. | | supplier_name | A name. | Always Blue Harbor Wholesale on this sheet. One sheet, one supplier. | | unit_cost | A number. | The supplier’s landed cost per unit in USD from effective_date. Every registered column is text, so it is cast to DECIMAL(10,2) before arithmetic. | | currency | A code. | USD so far. If a future sheet quotes in another currency, the cost is not comparable. | | moq | An integer. | Minimum order quantity, in units, not cases. | | effective_date | A date. | The first day the quoted cost applies, written YYYY-MM-DD. | | lead_time_days | An integer. | Days from order to delivery. | Three facts are not in any column at all. A SKU absent from the sheet is one the supplier does not carry, not a zero, so the join has to be a LEFT JOIN with the null read as “not quoted”. The comparison the sheet exists for is `unit_cost` against `products.cost`, the cost of record, and against `products.price` for the projected margin. And a new sheet arrives every month and replaces this file. ### Telling the agent in one message There is no form for this. You tell the agent what the file means the way you would tell a new analyst, in one message, and the agent records it. The capture tool it uses is the same one it reaches for whenever it learns something worth keeping, and the reply says exactly what happened to the fact. One message, one capture You A few things about that price sheet you should keep. Blue Harbor sends it once a month and the new one replaces the file. sku matches products.sku exactly. unit_cost is their landed cost per unit in USD from effective_date; compare it to products.cost for the change and to products.price for margin. moq is units. A SKU that is not on the sheet is one they do not carry, not a zero. Agent Recorded as business knowledge, with the query that just answered the category comparison cited as its source. The platform’s reply: “Captured. It will be reviewed before promotion to a shared catalog.” It is live for me now, and it is in the review queue for the team. The call underneath was `memory_capture` with type `business_knowledge`, confidence high, and the category comparison’s call reference in `sources`. The reply has two halves on purpose: the memory is yours immediately, and the same text is now an insight waiting for review. ### Personal memory and reviewed insight One capture serves two audiences. It is live for you the moment it is recorded, and because it was captured as business knowledge it also enters the review queue, where a reviewer decides whether the whole team should inherit it. The two speeds are deliberate: your own agent should not have to wait for a review to use what you just said, and the organization should not inherit a claim nobody checked. The same capture reaches two audiences at two speeds - Personal memory Who has it You, in every future session. From when The moment it is captured. How Recalled by search alongside the file and the table, with no review step. - Reviewed insight Who has it Everyone, once a reviewer applies it. From when After review, when it is promoted to a knowledge page or a catalog entity. How Durable business facts are captured with a type that enters the review queue, so a wrong claim cannot become team knowledge by accident. The capture types and the review queue are covered in [206](https://plexara.io/learning/mcp/knowledge-from-memory-to-insights). What matters here is the choice of type. Facts about a supplier’s sheet are business knowledge for the team, so they are captured as `business_knowledge` rather than as a personal preference, which would never reach anyone else. ### The capture in the portal The Knowledge section of the portal shows both halves. Memory is the tab with what your agent has recorded for you; the review queue is where the durable captures wait; Knowledge is where the promoted pages live. [Image: The portal’s Knowledge section on the Memory tab, listing captured memories with their type, confidence, and the session that recorded each one.] The capture as it appears in the portal’s Knowledge section, under Memory. It is already yours here. The review queue on the next tab is where it waits for the team. ### Promoting the capture to a knowledge page A reviewer with the role, or the reviewer’s agent, turns the queued insight into a knowledge page. The page is found or created by its slug, so a second promotion on the same topic updates the page rather than adding a duplicate. The promotion is recorded as a changeset and can be rolled back. From a capture to a knowledge page 1. 1 Search first The reviewer’s agent searches the catalog and the knowledge pages for the topic, so the decision is update-or-create rather than blind-create. Nothing about a supplier price sheet existed yet. 2. 2 Apply to a knowledge page apply_knowledge with sink=knowledge_page, the insight id, and a page: slug supplier-price-sheet, title Blue Harbor Wholesale Price Sheet, a body in markdown, and two references, the scratch connection and the November dashboard asset. 3. 3 The platform answers Knowledge page created. References attached: 2. Insights marked applied: 1. The promotion is a changeset with an id, and it is revertible, so a page that turns out to be wrong can be rolled back rather than edited over. 4. 4 Every agent recalls it From the next session on, any teammate’s search for supplier cost, price sheet, or Blue Harbor returns the page beside the file and the table, and fetch reads it in full. ### The page that resulted The page carries more than the message you sent. The reviewer folded in what the first join surfaced, including a catalog data-quality issue that has nothing to do with the supplier, and a note on what to do when next month’s sheet arrives. It cites the scratch connection and the November dashboard as references, so a reader can follow the page to the table and to the work built on it. The page as promoted, abridged ``` # Blue Harbor Wholesale Price Sheet Blue Harbor Wholesale sends ACME a price sheet once a month. The current sheet is the managed resource "Blue Harbor Wholesale price sheet", and it is registered as scratch.uploads.admin_supplier_price_sheet on the scratch connection, so it joins to the warehouse in ordinary SQL. ## Columns | Column | Meaning | | sku | Matches warehouse.public.products.sku exactly. | | unit_cost | Landed cost per unit in USD from effective_date. | | moq | Minimum order quantity, in units. | | effective_date | First day the quoted cost applies, YYYY-MM-DD. | ... ## How to read it - Compare unit_cost against products.cost, the cost of record. - Compare unit_cost against products.price for projected margin. - A SKU absent from the sheet is one the supplier does not carry. - Weight category figures by units sold in the period, not SKU count. - Twelve products in the quoted range carry a cost of record above their shelf price. That is a catalog data-quality issue, not a supplier change; report it separately. ## When a new month's sheet arrives The new file replaces the content of the same resource. The registered table keeps reading the previous revision until it is registered again under the same name; the Scratch Tables page reports it as Behind the file until then. ``` The page says where the file is, what the table is called, what each column means, how to compare it, what a missing row means, and what to do next month. It is the message you sent the agent, made durable and cited. The data-quality note about twelve products is on the page because the first join surfaced it, and the next analyst should not rediscover it. ### Knowledge pages in the portal The page sits in the Knowledge section beside the other canonical pages for the business. Every agent on the deployment recalls it through search, and fetch reads it in full. [Image: The portal’s Knowledge section on the Knowledge tab, listing canonical knowledge pages with their titles, summaries, tags, and the references each page cites.] Knowledge pages in the portal. A promoted page sits here beside the seasonality calendar and the returns policy, findable by search and readable by every agent connected to the deployment. ### Recording the join as a reusable query The capture in this lesson did one more thing: it cited the call that had just compared the quote to the cost of record. Every query and API call returns a call id, and citing one in a capture records that statement as reusable. The next person who asks the same question is offered the statement that already answered it. The capture, with the call it cites What the agent calls. This is the exchange the agent has with Plexara on your behalf, shown for the technical reader. You ask in plain language; you never type any of it. ``` memory_capture type business_knowledge category usage_guidance confidence high sources ["mcp:call:e-16onSTB…"] content "Blue Harbor Wholesale sends a price sheet once a month ..." -> id bea60fc9ddaa8471421fe808b2b4098e sink_class business_knowledge status active message "Captured. It will be reviewed before promotion to a shared catalog." ``` Every query and API call returns a call id. Citing it in `sources` records the statement as reusable, with your description of what it answers, and puts it up for promotion to the catalog. The next person who asks how the quote compares to the cost of record is offered the statement that already answered it, not a blank editor. ### What a teammate’s agent sees the next morning The test of all of this is a colleague who was not in the room. Their agent searches for the question, not the file. The result carries the file with its table and sample statement, the page that says what the columns mean, and the join that already worked. What a teammate’s agent finds the next morning ``` search intent="supplier cost vs cost of record" resources Blue Harbor Wholesale price sheet (November 2025) mcp:resource:71131796b81fbb5641bdcbb3df0ef238 table: connection scratch query_table scratch.uploads.admin_supplier_price_sheet sample_sql SELECT * FROM scratch.uploads.admin_supplier_price_sheet -- every column is VARCHAR, so a join to a typed column casts: -- JOIN scratch.uploads.admin_supplier_price_sheet t ON w.id = CAST(t."sku" AS BIGINT) knowledge_pages Blue Harbor Wholesale Price Sheet mcp:knowledge_page:kp_abbee77d-58f0-4789-b881-227d14f418d5 "The monthly supplier quote: where the file lives, the table it is registered as, what each column means, how it joins ..." calls Cost change and projected margin by category, November 2025 mcp:call:e-16onSTB… ``` Three hits from one question, and none of them needed the teammate to know the file existed. The resource hit carries the table name and a sample statement, so finding the file and querying it are one turn apart. The knowledge page says what the columns mean. The recorded call is the join that already worked. The sample statement guesses the first column is the key and shows the cast pattern; the page corrects that for this file, where `sku` is text on both sides and `unit_cost` is the column that needs the cast. ### Two halves of one integration Registration and meaning are separate acts with separate audiences, and a file is integrated only when both are done. The whole of this lesson took about five minutes on the demo deployment, most of it spent typing the message. Registering publishes the data; this publishes the meaning Registration made the rows readable by everyone granted the connection. That is why it requires the authority to change the file, not merely to read it. But rows without meaning produce confident, wrong joins: a cost read as per case, a missing SKU read as free. The description on the file, the capture, and the knowledge page are the other half. Together they are what “fully integrated” means: findable, queryable, and understood. ### Where this leads With the file registered and understood, the work that was the point can start: the join, the figures, and the dashboard. Next: the join, the figures, and the dashboard The file is a table and the agent knows what it means. The next lesson runs the join against a month of sales, reads the figures, and turns them into a dashboard the merchandising lead can open. [504 covers joining, visualizing, and sharing](https://plexara.io/learning/spreadsheets/joining-visualizing-and-sharing). ### Key terms Five terms from this lesson: the description on the file, the two states a capture passes through, the page it becomes, and the query it cites. Key Terms Description The text on a resource that search matches. A file over 8 MB is found by its description and tags alone, so the description is what makes the file findable by the question somebody will ask. Memory memory_capture A fact the agent records during a session. Live for you at once, and, for the durable types, queued for review before the team inherits it. Insight A captured memory of a durable type (business knowledge, an operational rule, a fact about a dataset) waiting in the review queue. Covered in [206](https://plexara.io/learning/mcp/knowledge-from-memory-to-insights). Knowledge page apply_knowledge sink=knowledge_page A canonical page in the portal’s Knowledge section, found or created by slug, that every agent on the deployment recalls through search. The promotion is a revertible changeset. Reusable query A recorded call cited as the source of a capture. The statement is stored with your description of what it answers and offered to the next person who asks the same question. On this page [Previous 502 - Uploading a file and registering it as a table](https://plexara.io/learning/spreadsheets/uploading-and-registering-a-file) [Next 504 - Joining, visualizing, and sharing](https://plexara.io/learning/spreadsheets/joining-visualizing-and-sharing) ### Related reading product [Product 102 - Tokens and your budget Every LLM interaction is priced and rate-limited in tokens. What a token is, how much text fits a budget, and how to avoid wasting tokens on useful answers.](https://plexara.io/learning/ai-concepts/tokens-and-your-budget) [Product 105 - What is an AI agent? An AI agent is not a chatbot and not magic. It is a short loop (think, call-tool, observe, think again) on top of a language model. Mental model first.](https://plexara.io/learning/ai-concepts/what-is-an-ai-agent) [Product 202 - Your first day with Plexara A new Plexara user gets connected, sends a first question, and platform_info takes over. Walks through day one and how subsequent turns inherit context.](https://plexara.io/learning/mcp/first-engagement) --- # Joining, visualizing, and sharing URL: https://plexara.io/learning/spreadsheets/joining-visualizing-and-sharing/ > The join, with the cast every registered column needs, run against a real supplier quote and a month of sales: cost change by category, the SKUs whose margin falls under a threshold at the current price, and the SKUs the sheet does not cover. The result becomes a dashboard asset with provenance, shared with the people who need it. The lesson closes with the choice between querying a registered table and having a dashboard reference the file directly, which re-reads it on every open. Product 10 min read ## 504 - Joining, visualizing, and sharing The join, with the cast every registered column needs, run against a real supplier quote and a month of sales: cost change by category, the SKUs whose margin falls under a threshold at the current price, and the SKUs the sheet does not cover. The result becomes a dashboard asset with provenance, shared with the people who need it. The lesson closes with the choice between querying a registered table and having a dashboard reference the file directly, which re-reads it on every open. On this page ### What you will take away from this lesson The supplier’s November quote is a table and the agent knows what its columns mean. This lesson does the work the file was uploaded for: join it to the product catalog and a month of sales, read what the join says, and put the result in front of the person who decides prices. Every figure below comes from the demo deployment’s warehouse and the sheet registered in [502](https://plexara.io/learning/spreadsheets/uploading-and-registering-a-file). The join is three statements. The dashboard is one call. Learning Objectives 1. 01 Write the join with the cast every registered column needs, and know which side of the join needs it. 2. 02 Produce figures the business cares about from the join: cost change by category, the SKUs whose margin falls under a threshold at the current price, and the SKUs the sheet does not cover. 3. 03 Turn the result into a dashboard asset with provenance, and edit it in place with anchored patches instead of regenerating it. 4. 04 Share it with the people who need it: a person by email with a note, a link, or a collection. 5. 05 Choose between querying a registered table and having a dashboard reference the file directly, which re-reads it on every open. ### Where this lesson sits This is the fourth lesson of the 500 series and the one where the file earns its place. The table exists and the agent knows what it means; what follows is the join, the reading, and the dashboard. 500 Series: Spreadsheets as Tables [Open index](https://plexara.io/learning/spreadsheets) - [501 The last mile of data is a spreadsheet The join was never the expensive part; loading was, and loading was staffed. Why a chat agent does not close the gap on its own, and what a table over the file where it sits changes.](https://plexara.io/learning/spreadsheets/the-last-mile-of-data-is-a-spreadsheet) - [502 Uploading a file and registering it as a table The resource library, the Excel rule, the Query as a table panel, what a registration answers with, the Scratch Tables page, and the three things a file is refused for.](https://plexara.io/learning/spreadsheets/uploading-and-registering-a-file) - [503 Teaching the agent what the file means Units, grain, effective dating, the join key, and what a missing row means: captured once, promoted to a knowledge page, recalled by every teammate’s agent.](https://plexara.io/learning/spreadsheets/teaching-the-agent-what-the-file-means) - [504 Joining, visualizing, and sharing The join with the cast, a supplier quote against a month of sales, a dashboard asset with provenance, and when a dashboard should reference the file instead of querying it.](https://plexara.io/learning/spreadsheets/joining-visualizing-and-sharing) - [505 Next month’s file A new revision leaves the table behind; register again to move it forward. Unregistering, deleting, the monthly procedure as a prompt, and where a join stops being enough.](https://plexara.io/learning/spreadsheets/next-months-file) The 500 series assumes the asset mechanics from the [300 series](https://plexara.io/learning/assets) and the knowledge loop from [206](https://plexara.io/learning/mcp/knowledge-from-memory-to-insights). It ends where the [600 series](https://plexara.io/learning/automations) begins: the point at which a monthly file needs more than a join. ### The cast rule Every column of a registered table arrives as text. That is the storage format’s rule for a CSV, not a choice, and it means a comparison to a typed warehouse column has to cast one side. Which side depends on the column: a text key joins to a text key with no cast at all, and a number the file carries as text is cast where the arithmetic happens. Every registered column is text; the join decides where the cast goes | Column | The two sides | Rule | | --- | --- | --- | | sku | products.sku is varchar(20); the sheet’s sku is text. | No cast. Both sides are text and the values match exactly (SKU-000001). | | unit_cost | products.cost and products.price are decimal(10,2); the sheet’s unit_cost is text. | CAST(s.unit_cost AS DECIMAL(10,2)) before any arithmetic or comparison. | | moq, lead_time_days | Integers in meaning; text in the table. | CAST(... AS INTEGER) when they are compared or summed. | | effective_date | A date in meaning; text in the table. | CAST(... AS DATE) when it is compared to a date column; as text it still groups and filters. | The registration answer ends with a sample statement showing the pattern: `ON w.id = CAST(t."sku" AS BIGINT)`. It guesses the first column is the key. For this file the key is text on both sides, so the cast moves to the cost column instead. The knowledge page from 503 says so, which is why the next analyst’s agent gets it right on the first statement. ### The worked join The question the sheet exists to answer is what the supplier’s new quote does to margin at the current shelf price. Three statements answer it: a category rollup weighted by November units, a per-SKU list filtered to the products whose projected margin falls below a threshold, and a coverage count that uses a LEFT JOIN to find the products the sheet does not quote. The first statement is shown in full. The scratch table sits in the FROM clause beside three warehouse tables, and the only thing that marks it as an uploaded file is its name. Cost change and projected margin by category, weighted by November units ``` WITH nov AS ( SELECT ti.product_id, SUM(ti.quantity) AS units FROM warehouse.public.transaction_items ti JOIN warehouse.public.transactions t ON t.transaction_id = ti.transaction_id WHERE t.transaction_date >= TIMESTAMP '2025-11-01' AND t.transaction_date < TIMESTAMP '2025-12-01' GROUP BY ti.product_id ) SELECT c.category_name AS category, ROUND(100.0 * (SUM(n.units * CAST(s.unit_cost AS DECIMAL(10,2))) - SUM(n.units * p.cost)) / SUM(n.units * p.cost), 1) AS cost_change_pct, ROUND(100.0 * (SUM(n.units * p.price) - SUM(n.units * CAST(s.unit_cost AS DECIMAL(10,2)))) / SUM(n.units * p.price), 1) AS margin_projected_pct FROM scratch.uploads.admin_supplier_price_sheet s JOIN warehouse.public.products p ON p.sku = s.sku JOIN warehouse.public.categories c ON c.category_id = p.category_id JOIN nov n ON n.product_id = p.product_id GROUP BY c.category_name ORDER BY cost_change_pct DESC ``` The scratch table sits in the same statement as three warehouse tables. Weighting by units sold is what makes a category figure mean something: a 15% increase on a product nobody buys is not the same as 15% on the one that sells every day. The second and third statements of the session used the same skeleton: a per-SKU version with a margin filter, and a coverage count with a LEFT JOIN from products to the sheet. ### What the join said The three results, as returned. The coverage figures frame the rest: 400 of the 450 products in scope are quoted, and the 50 that are not sold about eleven percent of the month’s units, so any category figure has to be read as a figure about the quoted range. Three categories carry a double-digit cost increase, and one of them, Flowers & Plants, would drop from a 29.9% margin to 19.1% if the quote were accepted at the current price. The per-SKU list is where the analyst’s reading starts, because a margin filter surfaces two different problems side by side. Coverage of the quote, November 2025 Quoted 400 of 450 50 SKUs in scope are not carried by this supplier. They sold 3,279 of 29,605 November units. Direction 223 up, 163 down Against the cost of record. 14 quoted SKUs are unchanged. Catalog issue 12 SKUs carry a cost of record above their shelf price before any quote. That is a data-quality issue in the catalog, reported separately. Weighted cost change by category, largest movers of 50 | Category | Cost change | Margin now | Margin projected | | --- | --- | --- | --- | | Flowers & Plants | +15.4% | 29.9% | 19.1% | | Beer | +13.1% | 35.9% | 27.5% | | Baking Supplies | +12.6% | 41.1% | 33.7% | | Organic & Natural | +3.1% | 30.7% | 28.5% | | Batteries & Electronics | +2.9% | 29.3% | 27.3% | | Garden Supplies | -1.6% | 43.9% | 44.8% | | Wine | -3.2% | 27.2% | 29.5% | Quoted SKUs below a 20% projected margin, by monthly cost impact | SKU | Category | Price | Cost of record | Quoted | Projected margin | Monthly impact | | --- | --- | --- | --- | --- | --- | --- | | SKU-000237 | Beer | 39.31 | 31.03 | 34.74 | 11.6% | $222.60 | | SKU-000290 | Beverages | 77.43 | 61.85 | 65.53 | 15.4% | $209.76 | | SKU-000172 | Beer | 28.93 | 22.35 | 25.07 | 13.3% | $138.72 | | SKU-000384 | Clothing Basics | 52.45 | 40.89 | 42.39 | 19.2% | $115.50 | | SKU-000212 | Organic & Natural | 78.89 | 106.55 | 109.58 | -38.9% | $112.11 | | SKU-000256 | Personal Care | 61.92 | 84.77 | 86.30 | -39.4% | $102.51 | | SKU-000368 | School Supplies | 67.49 | 89.91 | 91.17 | -35.1% | $90.72 | | SKU-000012 | Baby Care | 38.59 | 31.65 | 33.34 | 13.6% | $86.19 | | SKU-000059 | Baby Food | 29.68 | 25.19 | 26.37 | 11.2% | $86.14 | | SKU-000175 | Diapers & Wipes | 64.40 | 87.48 | 88.98 | -38.2% | $78.00 | | SKU-000219 | Baking Supplies | 6.76 | 5.50 | 6.57 | 2.8% | $70.62 | | SKU-000244 | Kitchen Supplies | 49.13 | 39.87 | 41.18 | 16.2% | $66.81 | Monthly impact is November units multiplied by the cost delta. Four of the twelve (212, 256, 368, 175) were already priced below their cost of record before the quote arrived; the join surfaces them because a margin filter does not care why the margin is negative. Separating a supplier change from a catalog error is the analyst’s reading, and it is the first thing the dashboard says. ### From rows to a dashboard The agent saves the result as an HTML asset in one call, naming the three queries as its sources. The dashboard is a document in the portal from that moment: versioned, viewable, shareable, and stored in the deployment’s own bucket. When the first version of the chart needed fixing, the fix was three anchored patches, not a regeneration. From rows to a dashboard asset What the agent calls. This is the exchange the agent has with Plexara on your behalf, shown for the technical reader. You ask in plain language; you never type any of it. ``` save_asset name "Blue Harbor quote vs cost of record, November 2025" content_type text/html sources ["e-16onSTB…", "vJ_Qhm05h…", "DU0lBGGLv…"] content ... -> asset_id d76092e83675e6828067dd1c81bb7d4f provenance_captured true calls_recorded 3 manage_asset action=patch asset_id=d76092e8... (versions 2, 3, 4) change_summary "Rename the chart script's top-level constant ..." change_summary "Place the value label of a decreasing category ..." change_summary "Draw each category label after its bar ..." ``` The three source call ids are the three statements of the session, so the asset’s provenance names exactly the queries it was built from. The three patches that followed fixed the chart script; each one is an anchored edit with a change summary, recorded as a new version, so the dashboard was never regenerated from scratch. Building and editing assets is the [300 series](https://plexara.io/learning/assets/creating-reports-and-dashboards); here the point is that a registered table feeds it like any warehouse table. ### The dashboard The saved asset, as the merchandising lead opens it. The bar chart states the category result, the table states the per-SKU result, and the note under the table separates the supplier change from the catalog data-quality issue. [Image: The saved dashboard: four figures (400 of 450 SKUs quoted, 223 up and 163 down, 3 categories above a 12% increase, 12 SKUs below a 20% projected margin), a horizontal bar chart of weighted cost change by category with increases in red and decreases in blue, and a table of the twelve SKUs below a 20% projected margin.] The asset as saved. The bar chart is the category statement; the table is the per-SKU statement; the four figures across the top are the coverage count. Nothing on the page is a number the join did not produce. ### Sharing it A dashboard nobody opens is a query that ran for no reason. Plexara shares an asset three ways, and which one fits depends on who needs it and whether they will need next month’s too. Three ways the dashboard reaches the merchandising lead - A person, by email Name the recipient by email or by a name resolved against the user directory. They get a real email with your note and the link, and the portal keeps a delivery record. An editor share lets them change the asset; a viewer share does not. - A link Omit the recipient and the share is a link any signed-in user can open, lasting until it is revoked. This is what the session did: one call, access_mode authenticated, notified false. A public link, open to anyone holding it, needs an expiry. - A collection Put the dashboard in a collection with the November feed and last month’s review, and share the collection once. The next month’s dashboard joins it without a new share. Email shares, delivery history, and guest access are covered in [303](https://plexara.io/learning/assets/sharing-your-work); collections in [304](https://plexara.io/learning/assets/creating-collections). A shared asset is live, not a copy: the three patches above reached everyone who already held the link. ### Sharing from the portal The same share is available on the asset’s page, with the note, the permission, and the notify toggle in one dialog. [Image: The share dialog on an asset, addressed to a person by email, with a viewer or editor permission, a notify toggle, and a note to include in the email.] Sharing with a person from the portal. The note travels in the email, and the delivery record shows whether it landed. ### Reference or query There is a second way a dashboard can use the file, and it behaves differently enough to choose deliberately. Instead of holding numbers a query produced, a dashboard can name the file by its URI and read it on every open. The file’s page then lists the dashboard under Used by. Which pattern fits depends on whether a version should be a snapshot. Two ways a dashboard can use the file - Query the registered table What moves when the file changes Nothing, on its own. The dashboard holds the numbers the join produced when it was saved. Is a version a snapshot Yes. Every version is an as-of record; an old version still shows the figures it showed. Use it for Analysis, a monthly review, anything somebody will compare against later. - Reference the file from the dashboard What moves when the file changes The numbers. The dashboard names the file by its mcp:// URI and re-reads it on every open; the file’s page lists the dashboard under Used by. Is a version a snapshot No. An old version of a referencing dashboard shows today’s file, because the reference belongs to the asset, not to a version. Use it for A status board that should always show the current sheet, with no run in between. The November dashboard is the first kind on purpose: a price review is something the merchandising lead will hold up against December’s. The second kind is the mechanism the 600 series builds on, where a script refreshes the file and every dashboard naming it shows the new numbers without being re-saved. ### Used by, on the file’s page A referencing dashboard shows up on the file it references, which is how a person deleting or replacing the file can see what depends on it. [Image: A managed resource’s page in the portal: the file’s details and version history, with the Used by section listing the assets whose content references the file.] A file’s page lists every asset that references it under Used by. A referencing dashboard with a public link is flagged, because anyone holding that link can load the file through it. ### Where this leads The November review is saved, shared, and cited. The remaining question is what happens in four weeks. Next: the December sheet The dashboard is shared and the November review is done. In four weeks the supplier sends the next sheet. What happens to the table, the dashboard, and the knowledge page when the file changes is its own lesson. [505 covers next month’s file](https://plexara.io/learning/spreadsheets/next-months-file). ### Key terms Five terms from this lesson: the cast, the provenance an asset carries, the patch that edits it, the share that delivers it, and the reference that keeps a dashboard live. Key Terms Cast CAST(s.unit_cost AS DECIMAL(10,2)) The conversion a registered column needs before it is compared to a typed warehouse column. Every registered column is text; the join decides which side carries the cast. Provenance The record of which calls an asset was built from. save_asset captures it from the call ids you name in sources, or from every data call since your last save when you name none. Anchored patch manage_asset action=patch An edit to part of an asset anchored on text, never on a line number, recorded as a new version with a change summary. The way a dashboard is corrected without being regenerated. Share Access to an asset for a person (a real email with your note), for any signed-in user (a link), or for anyone holding a URL (a public link with an expiry). Covered in [303](https://plexara.io/learning/assets/sharing-your-work). Asset reference mcp:// A file named from an asset’s content by its URI instead of carried in it. Resolves to the file’s current content on every open, so a referencing dashboard is live and its versions are not snapshots. On this page [Previous 503 - Teaching the agent what the file means](https://plexara.io/learning/spreadsheets/teaching-the-agent-what-the-file-means) [Next 505 - Next month’s file](https://plexara.io/learning/spreadsheets/next-months-file) ### Related reading product [Product 102 - Tokens and your budget Every LLM interaction is priced and rate-limited in tokens. What a token is, how much text fits a budget, and how to avoid wasting tokens on useful answers.](https://plexara.io/learning/ai-concepts/tokens-and-your-budget) [Product 105 - What is an AI agent? An AI agent is not a chatbot and not magic. It is a short loop (think, call-tool, observe, think again) on top of a language model. Mental model first.](https://plexara.io/learning/ai-concepts/what-is-an-ai-agent) [Product 202 - Your first day with Plexara A new Plexara user gets connected, sends a first question, and platform_info takes over. Walks through day one and how subsequent turns inherit context.](https://plexara.io/learning/mcp/first-engagement) --- # Next month’s file URL: https://plexara.io/learning/spreadsheets/next-months-file/ > The new sheet arrives. Replacing the file’s content writes a new revision, and the registered table keeps reading the old one until it is registered again under the same name; the Scratch Tables page says so. This lesson covers the two cases that look alike and behave differently, moving the table forward, unregistering, what deleting the file does, saving the monthly procedure as a prompt, and the point at which a monthly file needs more than a join, which is where the 600 series begins. Governance 9 min read ## 505 - Next month’s file The new sheet arrives. Replacing the file’s content writes a new revision, and the registered table keeps reading the old one until it is registered again under the same name; the Scratch Tables page says so. This lesson covers the two cases that look alike and behave differently, moving the table forward, unregistering, what deleting the file does, saving the monthly procedure as a prompt, and the point at which a monthly file needs more than a join, which is where the 600 series begins. On this page ### What you will take away from this lesson The December price sheet arrives from Blue Harbor Wholesale. Same columns, same 400 SKUs, new numbers. Everything the series built in November, the registration, the knowledge page, the margin dashboard, was built against the November file, and the useful question is how much of it has to be done again. The answer is one replacement and one re-registration, and the reason it is not zero is worth understanding, because it is the same reason a table over a file can be trusted at all: the platform never moves a table forward on its own. Learning Objectives 1. 01 Update a file when the new one arrives, with Replace content on the file’s page or the agent’s replace_content, and know that both write a new revision the Version history keeps and can restore. 2. 02 Read the Behind the file state on the Scratch Tables page and move the table forward by registering again under the same name. 3. 03 Tell the two cases apart: a file overwritten in place is followed by the table; a new revision is not, until somebody registers again. 4. 04 Unregister without touching the file, and know that deleting the file drops every table over it. 5. 05 Save the monthly procedure as a prompt, and know the two ways a table stays current with nobody in the loop. 6. 06 Recognize the point at which a monthly file needs more than a join, which is where the 600 series begins. ### Where this lesson sits This is the last lesson of the 500 series. The file has been uploaded, registered, explained to the agent, joined, and turned into a dashboard the right people can open. What remains is the part that decides whether any of that survives past the first month: what happens when the next file arrives. 500 Series: Spreadsheets as Tables [Open index](https://plexara.io/learning/spreadsheets) - [501 The last mile of data is a spreadsheet The join was never the expensive part; loading was, and loading was staffed. Why a chat agent does not close the gap on its own, and what a table over the file where it sits changes.](https://plexara.io/learning/spreadsheets/the-last-mile-of-data-is-a-spreadsheet) - [502 Uploading a file and registering it as a table The resource library, the Excel rule, the Query as a table panel, what a registration answers with, the Scratch Tables page, and the three things a file is refused for.](https://plexara.io/learning/spreadsheets/uploading-and-registering-a-file) - [503 Teaching the agent what the file means Units, grain, effective dating, the join key, and what a missing row means: captured once, promoted to a knowledge page, recalled by every teammate’s agent.](https://plexara.io/learning/spreadsheets/teaching-the-agent-what-the-file-means) - [504 Joining, visualizing, and sharing The join with the cast, a supplier quote against a month of sales, a dashboard asset with provenance, and when a dashboard should reference the file instead of querying it.](https://plexara.io/learning/spreadsheets/joining-visualizing-and-sharing) - [505 Next month’s file A new revision leaves the table behind; register again to move it forward. Unregistering, deleting, the monthly procedure as a prompt, and where a join stops being enough.](https://plexara.io/learning/spreadsheets/next-months-file) The 500 series assumes the asset mechanics from the [300 series](https://plexara.io/learning/assets) and the knowledge loop from [206](https://plexara.io/learning/mcp/knowledge-from-memory-to-insights). It ends where the [600 series](https://plexara.io/learning/automations) begins: the point at which a monthly file needs more than a join. ### Two changes that look the same and behave differently A registration points at the place the file lives, not at a particular set of bytes. That one fact explains everything in this lesson. Change the bytes where the table is already looking and the next query reads them. Put the new bytes somewhere else and the table keeps reading the old place until somebody points it forward. On Plexara, replacing a file in the portal and asking the agent to replace it both write a new revision. The file keeps its id, its address, and its name, so every dashboard that references it shows the new content on its next open. The registered table does not follow, and the platform tells you so rather than moving it on its own. Two ways a file changes, and what the table does about each - The file is overwritten in place What happened The same object is written again at the same address. A vendor drop replacing yesterday’s file, or a script writing over its own output. What the table does The next query reads the new contents. What to do Nothing. - A new revision is written What happened Replace content in the portal, or replace_content from the agent. The file keeps its id, address, and name; the new bytes are a new revision in its Version history. What the table does Keeps serving the revision it was registered against. That is correct SQL over the file as it was, and it will not change on its own. What to do Register again, same connection, same name. The second case is the one a monthly sheet lands in, whichever surface you use to update it. A dashboard that references the file by its address follows the new revision on its next open ([504](https://plexara.io/learning/spreadsheets/joining-visualizing-and-sharing)); a table registered over the file does not, and says so. ### The Scratch Tables page states it Nothing else can report that a table is behind its file, so the Scratch Tables page calls it out. The table is not broken and it is not dropped: a report built on it keeps running, against the revision that was current when it was registered. What the page adds is the fact that a newer revision exists. [Image: A registered table’s page on the Scratch Tables section, showing the qualified table name, its connection, the file behind it, its columns, and a Behind the file notice stating that the file has a newer version than the table points at.] Two states are called out because nothing else can report them. **Behind the file** means the file has a newer revision than the table points at; the table keeps working against the revision it has. **Source deleted** means the file is no longer on the platform, so the table reads a place whose contents are gone. Both are visible on the Scratch Tables list, on the table’s own page, on a search hit for the file, and in the agent’s `manage_table action=list` answer. ### Moving the table forward Registering again under the same name on the same connection replaces the registration and points the table at the current revision. There is no unregister step first. The trace below is the December revision landing on the demo tenant: the replacement, the check that shows the table behind, the second registration, and the query that confirms the table now reads December. The December revision landing on the demo tenant What the agent calls. This is the exchange the agent has with Plexara on your behalf, shown for the technical reader. You ask in plain language; you never type any of it. 1. 1 manage_resource action=replace_content reference=mcp:resource:71131796… change_summary="December 2025 price sheet from Blue Harbor Wholesale: 400 SKUs requoted, effective 2025-12-01." Content replaced and recorded as version 2, restorable from the file’s version history. The id, uri and filename are unchanged, so every asset referencing this file now serves the new bytes without being re-saved. 2. 2 manage_table action=list reference=mcp:resource:71131796… registration_id reg_a9de2c4f… · query_table scratch.uploads.admin_supplier_price_sheet · stale: true 3. 3 manage_table action=register reference=mcp:resource:71131796… connection=scratch table_name=supplier_price_sheet registration_id reg_67fe6630… · query_table scratch.uploads.admin_supplier_price_sheet · stale: false. Registered as scratch.uploads.admin_supplier_price_sheet on connection scratch. 4. 4 trino_query … SELECT s.effective_date, COUNT(*) … FROM scratch.uploads.admin_supplier_price_sheet s JOIN warehouse.public.products p ON p.sku = s.sku … GROUP BY s.effective_date effective_date 2025-12-01 · quoted_products 400 · weighted_cost_change_pct 2.38 · below_20_margin 73 Four calls, and the table reads December: every one of the 400 quoted rows now carries an effective date of 2025-12-01, the weighted cost change against the cost of record is +2.38% on November volume, and 73 quoted SKUs sit below a 20% projected margin. Registering the same name on the same connection replaces the registration, which is why the panel says to register again rather than to unregister first. A name somebody else registered is refused and names who holds it, so nothing is overwritten by accident; an administrator is unrestricted and does replace it. ### The monthly procedure as a prompt Three steps, once a month, in the same order every time: replace the file’s content, register again, rerun the dashboard. That is a procedure, and the 400 series already covered where a procedure goes. Ask the agent that just did it to write the prompt, review the draft, and next month the whole thing is one sentence. The monthly procedure, in the order it runs 1. 1 Replace the file’s content Replace content on the file’s page in the portal, or hand the agent the new sheet. Either way it is a new revision, restorable from Version history, and the file keeps its address. 2. 2 Register again Same connection, same name. The Scratch Tables page stops reporting the table as behind the file, and a search hit for the file stops carrying the stale flag. 3. 3 Rerun the dashboard The margin dashboard from 504 was built from queries against the table, so its numbers are a snapshot of the month it was built. Rerunning the procedure writes a new version of the same asset. Lesson [402](https://plexara.io/learning/prompts/letting-the-agent-write-the-prompt) covers asking the agent that just ran a procedure to write the prompt that repeats it. This one is three steps and one argument, the month, and next time it is a sentence: “the December price sheet is in, run the monthly supplier update.” Name a recurring file for what it is The demo file was uploaded as `supplier-price-sheet-2025-11.csv`. After the December revision landed it still carries that name, because a replacement never renames a file: the name is part of its address, and every reference to it depends on that address not changing. The display name still says November too. A file that will be replaced every month should be named for what it is, a supplier price sheet, and dated in its description or its revision summary, not in its filename. ### Keeping the table current without a person The monthly prompt still needs someone to say it. Two shapes remove the person from the loop, and which one fits depends on how the file arrives. Two shapes that keep a table current with nobody in the loop - A file that is overwritten in place When the supplier, or a system on your side, writes the new sheet over the same object, the table reads the new contents on its next query and nothing has to be registered again. This is the better shape when the table has to stay current by itself. - A script that refreshes the file and registers again When the sheet arrives as a new revision, a managed script can do the two steps a person would: replace the resource’s content, then call manage_table to register the same name again. The dashboard rerun is the same script’s next lines. The second shape is a managed script, which is what the 600 series is about. Lesson [603](https://plexara.io/learning/automations/outputs-feeds-reports-and-dashboards) shows the call: the script refreshes the file with `replace_content`, then registers again with `platform.call("manage_table", …)`, because a new revision leaves the table behind exactly as it did here. ### Unregistering, deleting, and the record Two more actions complete the lifecycle, and they are not the same action. One removes the table and leaves the file. The other removes the file and takes every table over it along. Both, like every registration, are written to the audit log. Removing a table, and removing a file - Unregister What it does Drops the table and forgets the registration. The file is not touched: it stays exactly where it was, byte for byte, with its revisions. Who may The person who registered the table, or an administrator. The table lives in a schema everyone granted the connection shares, so the person who put it there is the one who takes it out. What is recorded An audit event: who, which connection, the statement that ran, the table it named. - Delete the file What it does Removes the resource or asset, and drops every table registered over it, whoever registered them. A registration that survived a deletion would read a place whose contents are gone; that is the Source deleted state, and deleting the file properly leaves none behind. Who may Whoever may change the file: its owner or uploader, or an administrator. The same authority registering it took. What is recorded One audit event per table dropped, alongside the deletion itself. Failed attempts are recorded too. Unregistering is offered on the Scratch Tables page and on the file’s own Query as a table panel, on the tables you may drop. Registering stays on the file’s page, because it needs the file: the platform reads the header row to learn the columns. ### What a join cannot do A registered table turns a file into something SQL can reach. That is the whole of what it does, and for a price sheet joined to a catalog it is enough. Some monthly files need more than a join before they are useful, and that work is not a registration problem. Five things a registration does not do 1. 01 Parse a file that is not a flat table: a workbook with three sheets, a report with a title block above the header, a nested export. 2. 02 Normalize what arrives: a supplier who sends prices in cases this month and units the next, a code that changes spelling, a currency that is not always USD. 3. 03 Call an API on the way through: an exchange rate on the effective date, a geocode for a new address, a forecast for the week. 4. 04 Recompute a KPI every time the file lands, on a cadence, without somebody asking. 5. 05 Deliver a result somewhere else: a feed another system reads, a drop in a bucket, a dashboard whose numbers refresh while its layout stays put. Next: the 600 series, Automations Every item on that list is deterministic work: settled logic that should run the same way every month without a person, and without spending a model on it. Plexara runs that kind of work as a managed script the agent writes in a session and the platform stores, versions, runs, and schedules. [601 opens the 600 series](https://plexara.io/learning/automations/do-not-spend-ai-on-what-a-script-can-do) with the rule that decides what goes in a script and what stays with the agent. ### The end of the series Five lessons, one file. It arrived as a spreadsheet and left as a table the whole team can join, with its meaning written down where every agent finds it, a dashboard built on it, and a monthly procedure that keeps it current. That wraps the 500 series One supplier price sheet went from an attachment to a table the whole team can join, in the time it takes to read these five lessons. You saw why loading was the expensive step and why registration removes it, how to upload and register a file and read what comes back, how to tell the agent what the columns mean so every teammate’s agent knows too, how to join the table to the warehouse and share what it shows, and how to keep it current when the next file arrives. The useful next move is a file in your own inbox: the one you keep joining by hand in a spreadsheet. Upload it, register it, and tell the agent what it means. ### Key terms Five terms cover the lifecycle of a registered file after its first month. Key Terms Revision A new version of a managed resource’s content, written by Replace content in the portal or replace_content from the agent. The file keeps its id, address, and name; the previous revision stays in Version history and can be restored. Stale Behind the file A registration whose file has a newer revision than the table points at. The table keeps serving the revision it was registered against. Reported on the Scratch Tables page, on the file’s panel, on a search hit, and in manage_table action=list. Register again Registering the same name on the same connection, which replaces the registration and points the table at the current revision. A different name, or another connection, adds a second table over the same file instead. Unregister Dropping the table and forgetting the registration while leaving the file untouched. The registrant’s action, or an administrator’s. Deleting the file is the other direction: it drops every table over the file. Overwrite in place Writing new bytes over the same object at the same address, as a vendor drop or a script writing its own output does. A table over that object reads the new contents on its next query with no re-registration. On this page [Previous 504 - Joining, visualizing, and sharing](https://plexara.io/learning/spreadsheets/joining-visualizing-and-sharing) ### Related reading governance [Governance 403 - Sharing prompts, and closing the loop with feedback A procedure is only worth as much as the people who can run it. Plexara distributes a prompt two ways: a direct share to one teammate, or a promotion to a whole role or company through the admin review queue. A shared prompt is live, not a copy. Feedback threads then carry corrections back, with a validation step and a path into the knowledge catalog, and the deprecate-and-supersede lifecycle retires old versions cleanly.](https://plexara.io/learning/prompts/sharing-prompts-and-feedback) [Governance 605 - What a run may do, and the record it leaves A run presents the roles its author held at the save, every call is authorized at that moment, and narrowing the persona takes effect on the next run. A save refuses a credential-shaped literal and source that does not parse. The dialect has no network, no filesystem, and no clock, so everything a script does is a platform call audited under the script’s own identity. The lifecycle from active to disabled, deprecated, and superseded; who sees what; ownership and an administrator’s transfer; and the administrator’s view of every script and every run.](https://plexara.io/learning/automations/what-a-run-may-do) [Governance Closed by default: least privilege as the starting point Access control that starts open and gets locked down later never actually finishes. Closing connection access by default means every role sees exactly what it was granted and nothing more.](https://plexara.io/learning/insights/closed-by-default-access) --- # Do not spend AI on what a script can do URL: https://plexara.io/learning/automations/do-not-spend-ai-on-what-a-script-can-do/ > The report that gets rebuilt every Monday spends tokens on logic that was settled weeks ago and drifts a little each time. Integration platforms automate well but need a platform expert, so a one-off analysis never crosses that bar; an agent on a laptop writes scripts that vanish with the session. This lesson sets out the division of labor the series runs on: a script for the deterministic part, the model for writing it and for judgment about what it produced, and a managed script as the thing Plexara keeps, versions, runs, and schedules. Philosophy 10 min read ## 601 - Do not spend AI on what a script can do The report that gets rebuilt every Monday spends tokens on logic that was settled weeks ago and drifts a little each time. Integration platforms automate well but need a platform expert, so a one-off analysis never crosses that bar; an agent on a laptop writes scripts that vanish with the session. This lesson sets out the division of labor the series runs on: a script for the deterministic part, the model for writing it and for judgment about what it produced, and a managed script as the thing Plexara keeps, versions, runs, and schedules. On this page ### What you will take away from this lesson The [500 series](https://plexara.io/learning/spreadsheets) ended with a supplier price sheet that is a table, a join that works, and a dashboard the merchandising lead reads. Next month the sheet arrives again, and the month after. Each time, somebody opens a session and asks the agent for the same join, the same cast, the same margin figure, and the agent works it out again from the beginning. That is the gap this series is about. The logic was settled the first time; every later run spends tokens re-deriving it and produces a slightly different answer. The fix is not to stop using the agent. It is to let the agent write the script once, and to let Plexara run the script from then on. Learning Objectives 1. 01 Name the automation gap: settled logic re-derived on every run, at a token cost, with a little drift each time. 2. 02 Describe what an integration platform costs in expertise, and why a one-off analysis never crosses that bar. 3. 03 Explain why the scripts an agent writes on a laptop are lost, and what that loss costs a team. 4. 04 State the division of labor: a script for the deterministic part, the model for writing the script and for judgment about its output. 5. 05 Define a managed script: authored in a session, executed unattended, versioned, governed, run by Plexara on demand or on a schedule. 6. 06 Place scheduling correctly: a prompt is scheduled by your agent because it needs a model; a script is scheduled by Plexara because a run needs none. ### Where this lesson sits The first lesson of the 600 series, and the argument the other five rest on. It assumes the 500 series: the supplier price sheet is registered as a table, the agent knows what its columns mean, and the margin join has been worked out once. 600 Series: Automations [Open index](https://plexara.io/learning/automations) - [601 Do not spend AI on what a script can do The automation gap, what integration platforms and laptop scripts each cost, and the division of labor: a script for the deterministic part, the model for writing it and for judgment.](https://plexara.io/learning/automations/do-not-spend-ai-on-what-a-script-can-do) - [602 The agent writes the first script The loop from create to save, what validate and a dry run report, the dialect’s deliberate absences, the traps that fail a draft, and the script’s page in the portal.](https://plexara.io/learning/automations/the-agent-writes-the-first-script) - [603 Outputs: feeds, reports, and dashboards that refresh themselves Output identity across runs, tables and documents, the semi-dynamic dashboard and its data region, the referencing pattern, version caps, and delivery to a bucket drop.](https://plexara.io/learning/automations/outputs-feeds-reports-and-dashboards) - [604 Running it: by hand, from the portal, and on a schedule Three triggers, the cadence builder, the pinned fire date, what a schedule guarantees, and the run history with every trigger, duration, output, and log.](https://plexara.io/learning/automations/running-by-hand-from-the-portal-and-on-a-schedule) - [605 What a run may do, and the record it leaves The authority a run carries, what a save refuses, why the language cannot reach out, the lifecycle, ownership and transfer, and the administrator’s view.](https://plexara.io/learning/automations/what-a-run-may-do) - [606 Scripts as skills: the weekly review the agent runs on your business Three scripts attached to one prompt, the agent running them and reading the outputs against the knowledge graph, and a weekly list of action items with the figures behind them.](https://plexara.io/learning/automations/scripts-as-skills-the-weekly-review) The 600 series picks up the registered table from the [500 series](https://plexara.io/learning/spreadsheets) and the prompt mechanics from the [400 series](https://plexara.io/learning/prompts). It is the last numbered series in the curriculum. ### The report that gets rebuilt every Monday Automation has always been the hard part of putting AI on a data system. The first session is worth its cost, because that is where the judgment happens: which tables, which definitions, which corrections. The problem is every session after it. The same logic is re-derived from a description, at model speed and model cost, and it comes out a little different each time. The report that gets rebuilt every Monday - The first session An hour of real work: finding the right tables, agreeing what margin means, casting the text columns, correcting the first draft. Worth every token, because the judgment happened here. - Every Monday after The same queries, re-derived from a description of them. The join is rediscovered, the cast is rediscovered, the threshold is guessed at again. Ten minutes of model time on logic nobody needs to think about. - The drift Week three rounds differently. Week five picks a different threshold. Nobody can say which Monday’s number is comparable to which, because no two runs executed the same procedure. The insight [The report that runs without the agent](https://plexara.io/learning/insights/the-report-that-runs-without-the-agent) makes the argument at length. This series is the workbook: how the script gets written, what it produces, how it runs, and what it is allowed to do. ### Three ways a recurring job gets done There have been two answers to this for years. An integration platform automates the job properly, but it is built and kept by a platform expert, so the analyst files a request and the one-off analysis never becomes a flow. An agent on a laptop does the job in a session, but everything it built is gone when the session ends. A managed script is the third answer, and the ledger below is what it keeps from each of the other two. Three ways a recurring data job gets done Integration platform Agent on a laptop Managed script Who builds it Integration platform A platform expert who knows the flow builder, its connectors, and its failure modes. The analyst files a request and waits. Agent on a laptop The agent, in a session, on the analyst’s machine, against a file it was given a path to. Managed script The agent, in a session, from the work it just did. The analyst reviews the draft and the dry run. Where it runs Integration platform On the integration platform, with credentials it holds for each system it touches. Agent on a laptop On the laptop, under the person’s own credentials, only while the session is open. Managed script On Plexara, as the script’s own principal, presenting the roles its author held at the save. What survives the session Integration platform The flow, once somebody has built and tested it. Agent on a laptop Nothing. The scripts were temporary files; the next session starts from a description. Managed script The script, every version of it, every run’s record, and every output as a versioned asset. Who can see it Integration platform The platform team. The analyst sees the output, if it was wired to a place they look. Agent on a laptop One person, on one machine. Managed script The owner and administrators see the script; anyone the output is shared with sees the output. What it can reach Integration platform Whatever the connectors were configured for, with the credentials the platform holds. Agent on a laptop Whatever the person’s credentials reach, with no record of what was reached. Managed script Exactly the connections and tools its author may use, checked on every call, recorded in the audit log. Cost per run Integration platform Zero model time; the setup is the cost, and it is paid in weeks. Agent on a laptop A full session of model time, every time, plus the person’s attention. Managed script Zero model time. A run takes seconds and no agent has to be connected. Workato, n8n, and Apache NiFi are the integration-platform category, and they automate well once a flow exists. The problem is the bar: a flow is built by somebody who knows the platform, so a job that only an analyst and their agent understand never gets one. The managed script keeps what the platform offers (it runs unattended, under held credentials, with a record) and drops the bar to the session that already did the work. ### What vanishes on a laptop The laptop answer deserves its own look, because it is what most teams are doing today and it feels productive while it happens. A person hands the agent a 100 MB CSV, the agent writes scripts to parse it, and an hour later there is an answer. Four things were true of that hour that nobody noticed. What vanishes when the agent works a file on a laptop - The file lives on a laptop A 100 MB CSV does not fit an agent’s context, so the agent needs the file on local disk and permission to read it there. The data never reaches anywhere a teammate could reach it. - The scripts are temporary To parse the file the agent writes scripts, runs them, and discards them. Next week’s file starts from a description of what the scripts did, not from the scripts. - It ran as the person, with no record Whatever the scripts reached, they reached with the person’s own credentials, and nothing recorded what was read or written. - The team gets nothing No output anyone else can open, no procedure anyone else can run, no history to compare against. The work was real and it evaporated. Upload the same file to Plexara and let the agent write the script there instead, and every one of these reverses: the file is in the library with a description, the script is saved and versioned, the run is recorded under the script’s own identity, and the output is an asset the team can open. Next week the new file is uploaded and the script is run, by a click or by asking. ### The division of labor The series runs on four rules. They are not about using the model less. They are about pointing it at the part of the job only a model can do, and letting a script do the part a script does better. The division of labor 1. 1 Do not spend AI on what a script can do. Extracting, joining, computing, calling an API, and delivering a file are deterministic. A model doing them is slow, costs tokens, and drifts. A script does them the same way every time. 2. 2 Do not write a script when the agent can write it. The agent that just solved the problem in a session holds the tables, the casts, and the corrections. Writing the script is a sentence to it, and a review from you. 3. 3 Spend the model on judgment about the output. What the numbers mean for the business, given what the organization knows, is the part only a model can do. Point it at the script’s output and the knowledge graph, not at the raw tables. 4. 4 Keep the scripts, the prompts, and the knowledge. A saved script, a saved prompt that runs it, and a knowledge page the review cites mean every session starts further along than the last one. ### What a managed script is A managed script is the unit this series is built around. Six facts about it are enough for now; the lessons that follow fill each one in. What a managed script is A small language Scripts are written in Starlark, a Python-shaped dialect with no imports, no clock, no network, and no filesystem. Everything a script does is a call to a Plexara tool, so what it reaches can be read from its source. Authored in a session The agent drafts it from the work it just did, validates it, dry-runs it against real data with nothing persisted, and saves it. The saved version is the version that runs. Runs as itself, with your reach A run executes as the script’s own principal, presenting the roles you held when you saved it. It can never do unattended what you could not do at the keyboard. Versioned and recorded Every save is a version with an author. Every run records its trigger, duration, queries, outputs, and log, and a year of that history is kept. Run by Plexara On demand from any session, from the Run button on the script’s page, or on a schedule in your timezone. No agent has to be connected for a run to happen. Outputs are assets A CSV feed, a JSON feed, a markdown report, or an HTML dashboard, each a versioned asset in the portal with the same sharing every asset has. The product page [Automations](https://plexara.io/product/automations) describes the same thing in a page. The next five lessons take it apart: authoring, outputs, running, authority, and the review that composes several scripts into one job. ### Where the schedule lives The 400 series drew a line worth restating here, because scripts sit on the other side of it. Where the schedule lives Lesson [404](https://plexara.io/learning/prompts/running-prompts-and-schedules) put a saved prompt on a schedule, and the schedule lived in your agent, not in Plexara. A prompt needs a model to run, so only something that can start a model can fire it. A script needs no model. Plexara executes it, so Plexara schedules it: a cadence, a timezone, and the values every fire binds, set on the script’s page or by the agent. The two are not in tension. The weekly review in lesson 606 is a prompt the agent runs; the scripts it reads have already run on their own clock. ### What the rest of the series covers The agent is the developer during the session and the analyst afterward, and it gets better at both with every session, because the scripts, the prompts, and the knowledge persist. The next lesson starts with the developer half. Next: the agent writes the first script The margin analysis from the 500 series is settled logic. Lesson [602](https://plexara.io/learning/automations/the-agent-writes-the-first-script) asks the agent to turn it into a script, and follows the loop it works through, including the two drafts that failed before one succeeded. ### Key terms Five terms carry through the series: the script itself, a run of it, a version of it, the schedule that fires it, and what a run produces. Key Terms Managed script A small Starlark program the agent writes in a session and Plexara stores, versions, runs, and schedules. It reaches only Plexara tools, and only the ones its author may use. Run One execution of a script’s latest saved version, by a call from a session, by the Run button on its page, or by a schedule. Each run records its trigger, duration, queries, outputs, and log. Version What a save creates. Each version carries its author and the roles a run of it presents. The latest saved version is the one that runs. Schedule A cadence, a timezone, and the parameter values every fire binds, set on the script. A script has at most one, and Plexara fires it. Output What a run writes: a CSV or JSON feed, or a markdown, HTML, or JSX document, each a versioned asset in the portal under a name the script chose. On this page [Next 602 - The agent writes the first script](https://plexara.io/learning/automations/the-agent-writes-the-first-script) ### Related reading philosophy [Philosophy 101 - What is a Large Language Model? LLMs predict the next token from patterns learned across trillions of training examples. What that means, why it produces fluent reasoning, and its limits.](https://plexara.io/learning/ai-concepts/what-is-a-large-language-model) [Philosophy 104 - Frontier models, specialized models, and why enterprise AI uses both Frontier models bring world knowledge; small local embedding models power memory and catalog search. Knowing each role designs AI systems that work.](https://plexara.io/learning/ai-concepts/frontier-models-explained) [Philosophy 401 - Prompts are the new SOPs You work with the agent for an hour to get one report exactly right, with a year-over-year cut, holiday annotations, and storm-closure markers. The agent saves durable business knowledge on its own. But that specialized report is not institutional knowledge, it is a procedure. This article draws the line between the two, and makes the case that a saved prompt is the standard operating procedure for an AI-run job.](https://plexara.io/learning/prompts/prompts-are-the-new-sops) --- # The agent writes the first script URL: https://plexara.io/learning/automations/the-agent-writes-the-first-script/ > From a solved session to a saved script, with the loop the agent works through: create, validate, dry-run, patch, validate, dry-run, save. What a validate report says about the tools, connections, and destinations a script reaches; what a dry run measures without persisting anything; the dialect’s deliberate absences and the three traps that fail a draft; typed parameters; and the script’s own page in the portal with its source, Validate, Dry run, and versions. Grounded in a real script that reads the 500 series’ registered table. Product 12 min read ## 602 - The agent writes the first script From a solved session to a saved script, with the loop the agent works through: create, validate, dry-run, patch, validate, dry-run, save. What a validate report says about the tools, connections, and destinations a script reaches; what a dry run measures without persisting anything; the dialect’s deliberate absences and the three traps that fail a draft; typed parameters; and the script’s own page in the portal with its source, Validate, Dry run, and versions. Grounded in a real script that reads the 500 series’ registered table. On this page ### What you will take away from this lesson Lesson [504](https://plexara.io/learning/spreadsheets/joining-visualizing-and-sharing) worked out the supplier margin analysis in a session: three statements against the registered price sheet, a cast on the cost column, a threshold for the at-risk list, and a coverage count. That logic is settled. This lesson asks the agent to write it down as a script, and follows what happened on the demo tenant, including the two drafts that failed before one ran. The sentence that starts it is short: turn the margin analysis into a script that takes a month and a connection, runs the three queries, and publishes a category table and a JSON feed. Everything after that is the agent’s loop, and your review. Learning Objectives 1. 01 Start from a solved session and describe the job so the agent can write the script. 2. 02 Follow the loop the agent works through: create, validate, dry-run, patch, validate, dry-run, save. 3. 03 Read a validate report: the tools, connections, and destinations a script reaches, and what it reports as unreadable. 4. 04 Read a dry run: executed as you, under draft limits, nothing persisted, each output measured. 5. 05 Know the dialect’s deliberate absences and the traps that fail a draft: a DECIMAL that arrives as text, a result that hits the row cap, SQL built by hand, a format the language does not have. 6. 06 Know how a script reads a file: through the registered table, in SQL, never by parsing the bytes. 7. 07 Declare typed parameters, document the script so search finds it, and read its page in the portal: source, Validate, Dry run, versions. ### Where this lesson sits The second lesson of the 600 series, and the first hands-on one. It produces the script the next four lessons run, refresh, schedule, and compose. 600 Series: Automations [Open index](https://plexara.io/learning/automations) - [601 Do not spend AI on what a script can do The automation gap, what integration platforms and laptop scripts each cost, and the division of labor: a script for the deterministic part, the model for writing it and for judgment.](https://plexara.io/learning/automations/do-not-spend-ai-on-what-a-script-can-do) - [602 The agent writes the first script The loop from create to save, what validate and a dry run report, the dialect’s deliberate absences, the traps that fail a draft, and the script’s page in the portal.](https://plexara.io/learning/automations/the-agent-writes-the-first-script) - [603 Outputs: feeds, reports, and dashboards that refresh themselves Output identity across runs, tables and documents, the semi-dynamic dashboard and its data region, the referencing pattern, version caps, and delivery to a bucket drop.](https://plexara.io/learning/automations/outputs-feeds-reports-and-dashboards) - [604 Running it: by hand, from the portal, and on a schedule Three triggers, the cadence builder, the pinned fire date, what a schedule guarantees, and the run history with every trigger, duration, output, and log.](https://plexara.io/learning/automations/running-by-hand-from-the-portal-and-on-a-schedule) - [605 What a run may do, and the record it leaves The authority a run carries, what a save refuses, why the language cannot reach out, the lifecycle, ownership and transfer, and the administrator’s view.](https://plexara.io/learning/automations/what-a-run-may-do) - [606 Scripts as skills: the weekly review the agent runs on your business Three scripts attached to one prompt, the agent running them and reading the outputs against the knowledge graph, and a weekly list of action items with the figures behind them.](https://plexara.io/learning/automations/scripts-as-skills-the-weekly-review) The 600 series picks up the registered table from the [500 series](https://plexara.io/learning/spreadsheets) and the prompt mechanics from the [400 series](https://plexara.io/learning/prompts). It is the last numbered series in the curriculum. ### The dialect in one screen Scripts are written in Starlark, which looks like Python and is deliberately smaller. The agent reads the dialect contract from the platform before it writes a line, and the contract is short enough to fit on one screen: what is available, what is not, and why each absence is there. The dialect in one screen What is there What is not, and why - platform.query, platform.export, platform.publish_data, platform.call The four capabilities. Read-only SQL with :name parameters, a named output, a data-region refresh, and any other Plexara tool by name. import There is no module system. json and date are already here. - json, date, sum, and the builtins json.encode and decode; date.of, add_days, add_months, start_of_month and the rest, all as YYYY-MM-DD strings; len, range, sorted, min, max, str, int, float, fail, and the string, list, and dict methods. try / except Errors fail the run by design, so the failure is recorded rather than swallowed. Check first, or call fail("why"). - run.run_id, run.fire_time, run.params The frozen run record. The fire time is the only clock a script has, so a re-run months later asks the same question. while, recursion Unbounded loops are off so a script’s cost is readable from its source. Loop over a list, or do it in SQL. - print(...) Goes to the run log, which is kept with the run and capped at 64 KB. f"...", class Use "{}".format(x) or "%s" % x. Use dicts for structured values and functions for behavior. - def, for, if, list comprehensions Ordinary functions and bounded loops. A sort key is a named function, since there is no lambda. datetime, now(), random There is no clock and no randomness. Reading one would make the run unreproducible. - A named connection A script names the connection it queries; Plexara holds the credentials and authorizes each call. open, requests, credentials There is no filesystem and no direct network. The platform is the only outside world a script has. A credential never goes in the source. The absences are the point. Same script version, same parameters, same underlying data produce the same output; the script contributes no variation of its own. The agent reads this contract from the platform before it writes a line, which is why its first draft is already in the dialect. ### How a script reads a file The first question people ask about a script that works a spreadsheet is how it opens the file. It does not. The 500 series already did the hard part. A script reads a file through its registered table The dialect has no CSV parser and no file reads. A script reaches a file the way the 500 series set up: the file is registered as a table, and the script queries it with `platform.query` like any warehouse table, cast and all. The supplier sheet is `scratch.uploads.admin_supplier_price_sheet` to the script, joined to products in the same statement. This is what makes a 100 MB upload workable. The agent never holds the file and the script never parses it. The query engine holds it, the SQL aggregates it, and a result that would exceed the row cap fails rather than truncating, so the script is told to aggregate further instead of quietly computing on half the rows. ### The first script The agent turned the 504 session into the script below. It takes a month and a connection, runs the three statements from the session against the registered sheet, computes the weighted change in Starlark, prints a four-line summary to the run log, and exports a category table as CSV and a feed as JSON under names that will hold across every run. acme-supplier-margin, the saved version that first ran ``` month_start = date.start_of_month(run.params["month"]) month_end = date.add_months(month_start, 1) conn = run.params["conn"] print("supplier margin review for %s to %s" % (month_start, month_end)) NOV = """ WITH sold AS ( SELECT ti.product_id, SUM(ti.quantity) AS units FROM warehouse.public.transaction_items ti JOIN warehouse.public.transactions t ON t.transaction_id = ti.transaction_id WHERE t.transaction_date >= CAST(DATE :start AS TIMESTAMP) AND t.transaction_date < CAST(DATE :end AS TIMESTAMP) GROUP BY ti.product_id ) """ categories = platform.query( connection = conn, sql = NOV + """ SELECT c.category_name AS category, c.department, COUNT(*) AS quoted_products, SUM(s2.units) AS units, ROUND(SUM(s2.units * p.cost), 2) AS cost_of_record, ROUND(SUM(s2.units * CAST(s.unit_cost AS DECIMAL(10,2))), 2) AS quoted_cost, ROUND(100.0 * (SUM(s2.units * CAST(s.unit_cost AS DECIMAL(10,2))) - SUM(s2.units * p.cost)) / SUM(s2.units * p.cost), 1) AS cost_change_pct, ROUND(100.0 * (SUM(s2.units * p.price) - SUM(s2.units * CAST(s.unit_cost AS DECIMAL(10,2)))) / SUM(s2.units * p.price), 1) AS margin_projected_pct FROM scratch.uploads.admin_supplier_price_sheet s JOIN warehouse.public.products p ON p.sku = s.sku JOIN warehouse.public.categories c ON c.category_id = p.category_id JOIN sold s2 ON s2.product_id = p.product_id GROUP BY c.category_name, c.department ORDER BY cost_change_pct DESC """, params = {"start": month_start, "end": month_end}, ) at_risk = platform.query(connection = conn, sql = NOV + AT_RISK_SQL, params = {"start": month_start, "end": month_end}) coverage = platform.query(connection = conn, sql = NOV + COVERAGE_SQL, params = {"start": month_start, "end": month_end}) cat_rows = categories["rows"] if len(cat_rows) == 0: fail("no sales joined to the price sheet for %s; nothing to publish" % month_start) cov = coverage["rows"][0] total_record = sum([float(r["cost_of_record"]) for r in cat_rows]) total_quoted = sum([float(r["quoted_cost"]) for r in cat_rows]) weighted_change = 100.0 * (total_quoted - total_record) / total_record def by_change(r): return -float(r["cost_change_pct"]) movers = sorted(cat_rows, key = by_change) print("categories quoted: %d, weighted cost change %s%%" % (len(cat_rows), int(weighted_change * 100) / 100.0)) print("largest increase: %s %s%%" % (movers[0]["category"], movers[0]["cost_change_pct"])) platform.export(name = "supplier-margin-by-category", rows = cat_rows, format = "csv") platform.export( name = "supplier-margin-feed", rows = [{"as_of": run.fire_time, "month": month_start, "coverage": cov, "categories": cat_rows, "at_risk": at_risk["rows"]}], format = "json", ) ``` Abridged from the real source, which runs to about 114 lines with the two other statements written out. Every choice from the 504 session is here: the shared CTE with the month bound as `DATE :start` and `DATE :end`, the cast on `unit_cost`, the join on `sku` with no cast, the `fail` guard for a month with no sales, the `float()` on every DECIMAL, a named sort key because there is no lambda, and two outputs under stable names. The agent wrote it; the person reviewing it had to know what it should do, not how to write it. ### Typed parameters The two values that change between runs are declared as parameters with types, not read from free text. The types decide what every surface that asks for them shows. The parameter contract month date, default 2025-11-01 Any date inside the calendar month to report on. The script takes the start of that month and the month after it, so a schedule can bind the fire date and get the right month. conn connection, default acme A connection parameter binds as a string, but every surface that asks for it offers the connections this script may reach instead of a blank box, and a name outside them is refused where it was entered. A parameter is typed string, int, float, bool, date, enum, or connection, and every surface that asks for a value renders the control the type deserves. An optional enum, date, or connection declares a default; there is no meaningful empty connection. Values are checked against the contract before anything is queued. ### The loop: create, validate, dry-run, patch, save The agent does not write the script and hand it over. It saves a first version, checks it statically, executes it as a draft against real data, fixes what the draft turns up, and repeats until the draft succeeds. On the demo tenant that took two fixes. The rail below is the real sequence, and the trace under it is what the agent saw at each step. The loop, as it happened on the demo tenant 1. 1 Create The agent saves a first version with its parameters, a display name, a category, tags, and a markdown description. The answer says it already runs, and points at run_draft for iterating before the next save. 2. 2 Validate A static read of the source. It reports the two capabilities used, the destination (portal), no tools called by name, and that the connection is computed from a parameter, so the connection list is incomplete. Nothing runs. 3. 3 Dry run, fails Executed as the author with nothing persisted. Three queries ran, 1,705 steps, 6.1 seconds, then line 92: unknown conversion, because the print used a %.2f format the dialect does not have. 4. 4 Patch One anchored edit replaces the format with "%s" and an integer rounding. Version 2, and the answer says this version is what runs now. 5. 5 Dry run, fails again The CSV export was measured (50 rows, 3,378 bytes) before line 103 refused the JSON export: rows must be a list of dicts, and the feed was a dict. 6. 6 Patch The feed is wrapped in a list. Version 3. 7. 7 Dry run, succeeds Three queries, 1,807 steps, 5.1 seconds, two outputs measured and nothing written: the CSV at 50 rows and 3,378 bytes, the JSON feed at 27,626 bytes. The log shows 50 categories quoted and 400 of 450 products covered. 8. 8 The saved version runs Version 3 is what run_script executes and what a schedule fires. The first real run, for December, wrote both outputs as versioned assets in 8.5 seconds. Two failed drafts is normal, and it cost nothing: a draft persists nothing, and a script failure is deterministic, so the platform says so and asks for a fix rather than retrying. The person’s part was reading the three lines of log at the end and agreeing they matched the 504 session. ### The same loop as the agent sees it Each step is one call to Plexara and one answer. The answers are worth reading because they are written for the agent to act on: which version is live, which line failed, what to do instead. The same loop as calls, with the real answers What the agent calls. This is the exchange the agent has with Plexara on your behalf, shown for the technical reader. You ask in plain language; you never type any of it. ``` manage_script command=create name=acme-supplier-margin params=[month: date (default 2025-11-01), conn: connection (default acme)] display_name="Supplier Quote Margin Review" category=merchandising → status created version 1 "Saved, and it runs: run_script executes it under the access you held when you saved it, and a schedule you set will fire it. Use run_draft to iterate on changes before saving them." manage_script command=validate name=acme-supplier-margin → ok true capabilities [platform.export, platform.query] destinations [portal] connections [] dynamic_connections true tools [] findings null "At least one call computes its connection instead of naming one ... so this connection list is incomplete." manage_script command=run_draft name=acme-supplier-margin args={month: 2025-11-01} → status failed queries 3 steps 1705 duration 6,105 ms run dpx_0107… acme-supplier-margin:92:60: Error: unknown conversion %. "A script failure is deterministic: the same source on the same inputs fails the same way, so retrying it changes nothing." manage_script command=patch edits=[replace "%.2f%%" → "%s%%" with int(x * 100) / 100.0] → version 2 "Saved, and this version is what runs now" manage_script command=run_draft → status failed exports [supplier-margin-by-category csv 50 rows 3,378 bytes preview] acme-supplier-margin:103:16: Error in platform.export: rows must be a list of dicts, or a string body for a document format, got dict manage_script command=patch edits=[wrap the feed: rows = [{...}]] → version 3 manage_script command=run_draft → status succeeded queries 3 steps 1807 duration 5,111 ms run dpx_6e26… exports supplier-margin-by-category csv 50 rows 3,378 bytes preview supplier-margin-feed json 1 row 27,626 bytes preview "Nothing was persisted. platform.export reported the shape of each output rather than writing it." ``` Every answer names its version and says what is now live, which is how the agent knows the patch it just made is the one that will run. A patch is anchored on text, never on a line number: an anchor that matches nothing or matches twice refuses the whole edit and writes nothing. ### What validate reports Validate is a static read of the source. It answers the question a reader has before running anything: what does this script reach? The report for the first script is short, and one field in it is a note rather than a list. What validate reports, for this script capabilities platform.export, platform.query Which of the four helpers the source uses. A script that only queries and exports can never refresh a dashboard or call another tool without a new version. connections [] with dynamic_connections true The connections named literally in the source. This script takes its connection from a parameter, so validate says the list is incomplete instead of guessing. destinations portal Where the outputs go. A destination Plexara does not have is reported here, before any query has run. tools [] Every tool named in a platform.call. A computed tool name is reported as a gap rather than left out. findings null Anything the static read objects to, with a correction for each: a credential-shaped literal, source that does not parse, a destination passed by position. Validate executes nothing and stores nothing. It is how a reader learns what a script reaches without reading the Starlark, and the same report is one button on the script’s page in the portal. ### The dry run and the account it keeps A dry run executes the source for real, under your own identity, and persists nothing. It is the only way to try a change without making it live, because a save is immediately the version that runs. What a dry run is Executed as you A dry run is your own session: your identity, your access, and nothing reachable through it that you could not already reach. A real run executes as the script, presenting the roles you held at the save. Nothing persisted Every export is serialized in its declared format to measure it, then discarded. The answer carries the shape and size a real run would write; no asset is versioned. Tighter limits A draft is capped at 5,000 rows per query and one minute. A platform run allows 20,000 rows per query, ten minutes, 16 outputs, and 100 MB per output. A source is at most 256 KB. The account it keeps Each dry run is recorded: who ran it, when, how it ended, what it printed, and the shape of its outputs. The account is keyed to the exact source that executed, so the version later saved from that source carries it, and a version with no account says so. [Image: A script’s page in the portal after a dry run: the outcome, the log the script printed, and each output’s format, row count, and size, with nothing written.] A dry run on the script’s page executes what is on screen, as you, and reports each output’s shape instead of writing it. The same check the agent runs before every save. ### Documenting the script A script outlives the conversation that produced it, so its description is a document rather than a caption. The agent wrote this one at the save; the owner can rewrite it on the script’s page. The four fields that say what a script is Display name The label every listing, page header, and search result prints. Supplier Quote Margin Review, here. Description A markdown document, not a caption: what the script produces, what each parameter means in the reader’s terms, what it assumes about the data, and what somebody re-reading it in six months needs. This one states the three queries, the two outputs, the cast rule, and that a month with no sales fails the run. Category One lowercase slug the listings filter on. Reuse an existing one rather than coining a near-duplicate; merchandising, here. Tags Free-form labels, up to twenty, for everything one category cannot carry. All four are matched by search, with the parameter contract, so how a script is described decides whether anybody finds it. The owner edits them together from the About section’s Edit control on the script’s page, or the agent writes them at the save. [Image: The About section of a script’s page in the portal, showing the rendered markdown description with its display name, category, and tags, and the Edit control that opens all four fields together.] The description renders as markdown on the script’s page, the way a knowledge page does. It is the document a colleague reads before deciding whether to run the script. ### Editing it later The script will change: a new column, a different threshold, a third output. The loop is the same the second time, on either surface. Editing a script after it is saved A save is immediately the version that runs, so an edit is tried before it is made live. The agent edits with an anchored patch and finds the place to change with locate, which reports line numbers and a copyable context window; it never reads the whole body back to resend it. On the script’s page, the source is editable in place, with Run and Dry run side by side above the editor and one parameter form below serving both. Run executes the saved version; a dry run executes what is on screen. Validate before every save, on either surface. Source that does not parse is refused at the keyboard rather than at the next fire, and every save is a version with an author. [Image: A script’s page in the portal with the Starlark source in an editor, the Run and Dry run buttons above it, and the parameter form below.] The source on the script’s page, with Run and Dry run above the editor and the parameter form below. The owner edits here; the agent edits with an anchored patch. Both cross the same gate. [Image: The version history of a script in the portal: each version with its author, when it was saved, and the roles a run of it presents.] Every save is a version with an author and the roles a run of it presents. The script in this lesson reached version 3 before its first real run and version 6 by the end of lesson 603. ### The traps that fail a draft Every one of these is a refusal with a named line and a stated fix, which is the point of running a draft before saving. The first two failed real drafts of this script; the last failed a real run in the next lesson. The traps that fail a draft, and what the platform says A DECIMAL arrives as text Arithmetic on a cost column refuses, or a sum concatenates strings. Pass every DECIMAL through float() before arithmetic: sum([float(r["total"]) for r in rows]). A result hits the row cap The query fails rather than returning a partial answer. Aggregate in SQL or narrow the query. A partial result would silently change what the script computes. SQL built by hand One apostrophe in an upstream value breaks the statement, or appends one of its own. Use :name placeholders and pass values in params; the platform quotes them by type. Compare a date as DATE :day. A format the dialect does not have Error: unknown conversion %. at the print line. There is no %.2f. Use "%s" with int(x * 100) / 100.0, or "{}".format(x). A JSON export given a dict rows must be a list of dicts, or a string body for a document format, got dict. Wrap the feed in a list. csv and json take rows; html and jsx take a string body. One name written twice in a run output "…" was already written to "portal" by this run. One output name lands once per destination per run. Give the second write its own name, or branch so only one write happens. Two of these failed real drafts in this lesson and one failed a real run in the next. All three refusals named the line and said what to do instead, which is what a dry run is for. ### What the script does not yet do At the end of this lesson there is a saved script that a call from any session can run. What it produces, where that lands, and how a dashboard can refresh itself from it are the next lesson. Next: what a run produces The script writes a CSV and a JSON feed under two names. Lesson [603](https://plexara.io/learning/automations/outputs-feeds-reports-and-dashboards) follows those outputs into the portal, adds a dashboard the script publishes once and refreshes on every later run, and meets the third trap in the ledger above on a real run. ### Key terms Five terms from the authoring loop: the two checks, the edit, the contract, and the language. Key Terms Validate A static read of the source that reports the capabilities, connections, destinations, and tools a script reaches, with a correction for every finding. It executes nothing and stores nothing. Dry run run_draft Executing the source as yourself, under draft limits, with nothing persisted. Each output is measured rather than written, and the run is recorded as an account keyed to the exact source. Patch An edit anchored on text, never on a line number. An anchor that matches nothing or matches more than once refuses the whole edit. Each patch that saves is a new version. Parameter contract The typed parameters a script declares: string, int, float, bool, date, enum, or connection, each with a description and, when optional, a default. Every run and every schedule binds values against it. Starlark The Python-shaped dialect managed scripts are written in, deliberately smaller: no imports, no clock, no network, no filesystem, no try, no while. Everything a script does is a platform call. On this page [Previous 601 - Do not spend AI on what a script can do](https://plexara.io/learning/automations/do-not-spend-ai-on-what-a-script-can-do) [Next 603 - Outputs: feeds, reports, and dashboards that refresh themselves](https://plexara.io/learning/automations/outputs-feeds-reports-and-dashboards) ### Related reading product [Product 102 - Tokens and your budget Every LLM interaction is priced and rate-limited in tokens. What a token is, how much text fits a budget, and how to avoid wasting tokens on useful answers.](https://plexara.io/learning/ai-concepts/tokens-and-your-budget) [Product 105 - What is an AI agent? An AI agent is not a chatbot and not magic. It is a short loop (think, call-tool, observe, think again) on top of a language model. Mental model first.](https://plexara.io/learning/ai-concepts/what-is-an-ai-agent) [Product 202 - Your first day with Plexara A new Plexara user gets connected, sends a first question, and platform_info takes over. Walks through day one and how subsequent turns inherit context.](https://plexara.io/learning/mcp/first-engagement) --- # Outputs: feeds, reports, and dashboards that refresh themselves URL: https://plexara.io/learning/automations/outputs-feeds-reports-and-dashboards/ > What a run produces and where it lands. One script and one output name is one asset, and every run adds a version; a dated name builds an archive instead. Rows become CSV or JSON feeds; a string body becomes a markdown, HTML, or JSX document. A semi-dynamic dashboard is published once and has only its data region refreshed on later runs, so layout edits made in the portal survive. A dashboard can instead reference a file a script rewrites, capped versions keep an asset tidy, and a named bucket drop delivers the same bytes to another system. Product 11 min read ## 603 - Outputs: feeds, reports, and dashboards that refresh themselves What a run produces and where it lands. One script and one output name is one asset, and every run adds a version; a dated name builds an archive instead. Rows become CSV or JSON feeds; a string body becomes a markdown, HTML, or JSX document. A semi-dynamic dashboard is published once and has only its data region refreshed on later runs, so layout edits made in the portal survive. A dashboard can instead reference a file a script rewrites, capped versions keep an asset tidy, and a named bucket drop delivers the same bytes to another system. On this page ### What you will take away from this lesson A script that only prints is a log. What makes a managed script worth running on a schedule is what it leaves behind: a feed another system reads, a report somebody opens, a dashboard whose numbers move while its layout stays put. This lesson is about those outputs, where they land, and what identity they keep from one run to the next. The example is the script from 602, which grew from two feeds to a dashboard across three saved versions on the demo tenant. Two of its runs were refused on the way, and both refusals are worth reading, because each one is a rule about outputs stated in the platform’s own words. Learning Objectives 1. 01 Choose an output shape: rows serialized as a CSV or JSON feed, or a document body written as markdown, text, HTML, or JSX. 2. 02 Understand output identity: one script and one output name is one asset, and every run adds a version; a dated name builds an archive instead. 3. 03 Build a semi-dynamic dashboard: publish the document once, refresh only its data region on later runs, and keep the layout edits made in the portal. 4. 04 Use the referencing pattern when a document should show a file’s current content: the script refreshes the file, and every document naming it shows the new content without being re-saved. 5. 05 Cap the versions an asset a script rewrites keeps, and keep a registered table current from a script. 6. 06 Deliver the same bytes to a bucket drop by naming a destination and a key, and read what the run records about it. ### Where this lesson sits The 602 script exists, has been dry-run, and has been saved. This lesson is about the other end of it: the feeds, documents, and dashboards a run writes, and the identity each one keeps from one run to the next. It uses the same script, followed through three more saved versions. 600 Series: Automations [Open index](https://plexara.io/learning/automations) - [601 Do not spend AI on what a script can do The automation gap, what integration platforms and laptop scripts each cost, and the division of labor: a script for the deterministic part, the model for writing it and for judgment.](https://plexara.io/learning/automations/do-not-spend-ai-on-what-a-script-can-do) - [602 The agent writes the first script The loop from create to save, what validate and a dry run report, the dialect’s deliberate absences, the traps that fail a draft, and the script’s page in the portal.](https://plexara.io/learning/automations/the-agent-writes-the-first-script) - [603 Outputs: feeds, reports, and dashboards that refresh themselves Output identity across runs, tables and documents, the semi-dynamic dashboard and its data region, the referencing pattern, version caps, and delivery to a bucket drop.](https://plexara.io/learning/automations/outputs-feeds-reports-and-dashboards) - [604 Running it: by hand, from the portal, and on a schedule Three triggers, the cadence builder, the pinned fire date, what a schedule guarantees, and the run history with every trigger, duration, output, and log.](https://plexara.io/learning/automations/running-by-hand-from-the-portal-and-on-a-schedule) - [605 What a run may do, and the record it leaves The authority a run carries, what a save refuses, why the language cannot reach out, the lifecycle, ownership and transfer, and the administrator’s view.](https://plexara.io/learning/automations/what-a-run-may-do) - [606 Scripts as skills: the weekly review the agent runs on your business Three scripts attached to one prompt, the agent running them and reading the outputs against the knowledge graph, and a weekly list of action items with the figures behind them.](https://plexara.io/learning/automations/scripts-as-skills-the-weekly-review) The 600 series picks up the registered table from the [500 series](https://plexara.io/learning/spreadsheets) and the prompt mechanics from the [400 series](https://plexara.io/learning/prompts). It is the last numbered series in the curriculum. ### What a run produces, and where it is recorded A run records what it did: its status and timing, the queries it issued, the outputs it wrote, and the log the script printed. The outputs are the part that matters to everyone who is not the script’s author. Each one is named in the script, and each one lands as a portal asset with a version number, linked from the run’s page. The ledger below is the real record of three runs of the 602 script on the demo tenant. The middle run failed partway, for a reason the next sections explain, and its record still names what it had written before it stopped. Three runs of one script, and what each left behind - dpx_88dfb063… v3, trigger tool, 8,542 ms succeeded supplier-margin-by-category → asset 871da875… version 1 (csv, 50 rows, 3,404 bytes); supplier-margin-feed → asset 589855b4… version 1 (json, 1 row, 27,660 bytes) - dpx_ba4f9dd0… v5, mode=publish failed at line 174 supplier-margin-by-category version 2; supplier-margin-feed version 2; supplier-margin-dashboard → asset bab7c8e7… version 1 (html, document, 4,562 bytes). The outputs that landed before the failure stayed. - dpx_3bea162a… v6, mode=refresh, 8,231 ms succeeded supplier-margin-by-category version 3; supplier-margin-feed version 3; supplier-margin-dashboard version 2, refresh: true, 24,020 bytes spliced into the island Every run records its outputs by name, with the asset each one landed in and the version it wrote. The same three names appear on every run because the names are the identity: three runs did not create nine assets, they wrote three versions of three assets. The middle run failed, and its record still names what it wrote before it stopped. ### The run’s page Every run has an address of its own in the portal. The page shows the parameters it ran with, how long it took, each output with a link to the asset version it wrote, and the log. A scheduled run and a run asked for by hand have the same page. [Image: A single run’s page in the portal: the parameters it ran with, its timing, the outputs it wrote with each one linking to the asset version it produced, and the log the script printed.] A run’s own page. Every output it wrote is listed by name and links to the asset version it produced; an output delivered to a drop names where it was written instead. The log underneath is what the script printed. ### Identity across runs The most consequential decision about an output is its name, because the name is what persists. Two shapes cover every case, and the choice between them is made when the script is written, not later. The output name is the identity - A stable name name = "supplier-margin-by-category" What happens across runs One asset. Every run writes a new version of it, so the asset keeps its id, its shares, and its history. On the demo, three runs took it from version 1 to version 3. When to use it A feed a dashboard references, a report people bookmark, a dashboard on a wall. Anything that should have one address. - A dated name name = "daily-sales-" + report_date What happens across runs One asset per date. Each run creates a new one, and the old ones stay exactly as they were written. When to use it An archive series, where each run is its own kept document and nobody wants yesterday’s numbers to move. The pair of script and output name maps to one asset. A different script writing the same name gets its own asset, so two scripts never overwrite each other’s work by accident. The dated example is the one the dialect reference ships with: the date comes from the run’s pinned fire time, never from a clock. ### Tables and documents An output carries its content in one of two shapes: a list of rows, which the platform serializes in the declared format, or a string body, which lands byte for byte. Which shapes a format accepts is a rule, not a preference, so a feed another system parses stays well-formed by construction and a document arrives exactly as the script composed it. Six formats, two shapes csv A list of dicts, one per row A CSV asset another system can parse, well-formed by construction json A list of dicts A JSON asset: a feed a dashboard references or a system reads html A string body, written verbatim An HTML document: a dashboard or a formatted report jsx A string body A JSX document, rendered by the portal like any saved JSX asset markdown Either rows or a body A markdown page: a prose report, or a table from rows text Either rows or a body A plain-text document The declared format decides which shape is valid, and a mismatch fails the run rather than guessing. The 602 script hit this on its second dry run, when the JSON feed was passed as a single dict: “rows must be a list of dicts, or a string body for a document format (html, jsx, markdown, text), got dict.” Wrapping the feed in a list was the whole fix. An empty document body is refused the same way, so a conditionally assembled report that ends up blank fails loudly instead of replacing the current version of a shared dashboard with nothing. ### A dashboard that refreshes itself A document can be produced two ways, and the choice is made before its first line is written. Compose the whole document in the script when each run is its own kept document, when the structure has to vary with the data, or when nobody will ever edit the presentation; the cost is that every fire overwrites the current version wholesale, so a heading fixed in the portal is destroyed by the next run. Publish the document once and refresh only its data region when there is one stable-named dashboard at one address whose layout a person may edit and whose numbers alone move per run. That is the semi-dynamic dashboard, and it is what the 602 script became in versions 4 through 6. The data region, and the two lines that publish and refresh it In the document ``` ``` In the script, version 6 ``` if run.params["mode"] == "publish": platform.export( name = "supplier-margin-dashboard", rows = DASHBOARD, format = "html", ) else: platform.publish_data("supplier-margin-dashboard", feed) ``` The document marks exactly one element with `id="data"`, and its own code reads that element at view time. `platform.publish_data` serializes the payload as JSON and replaces the interior of that one element, leaving every other byte of the document as its author wrote it. The document has to exist first, as an HTML, JSX, or markdown output of the same script under the same name, which is what the `publish` mode does once. A document without the region fails the run rather than being written anywhere else. ### Publishing it, and the rule the first run broke The first run of the dashboard version did two things under one output name in one run, and the platform refused the second. The refusal is a rule about outputs worth knowing before it costs you a run of your own. Publishing the dashboard, as it happened on the demo tenant What the agent calls. This is the exchange the agent has with Plexara on your behalf, shown for the technical reader. You ask in plain language; you never type any of it. 1. 1 run_script name=acme-supplier-margin args={month: 2025-12-01, mode: publish} (version 5: export the document, then publish_data, in one run) failed at line 174. Error in platform.publish_data: output "supplier-margin-dashboard" was already written to "portal" by this run; each output name may be written once per destination, so give the second one its own name. Outputs that landed: supplier-margin-dashboard → asset bab7c8e7… version 1 (html, document, 4,562 bytes). 2. 2 manage_script command=patch name=acme-supplier-margin (publish_data only when mode is refresh) Saved, and this version is what runs now. Version 6. 3. 3 run_script name=acme-supplier-margin args={month: 2025-12-01, mode: refresh} succeeded, 8,231 ms. supplier-margin-dashboard → asset bab7c8e7… version 2, refresh: true, 24,020 bytes. The first run wrote the document and then tried to refresh it in the same run, and the platform refused: one output name may be written once per destination in a run. The document it had already written stayed as version 1. The fix was a branch, and the next run wrote version 2 with only the data region changed. From here on every scheduled fire is a refresh, and every version is an as-of snapshot: an old version still shows exactly the numbers it showed, and a public share works with no live query behind it. A layout edit made in the portal survives, because the script never touches the markup again. If a run finds no rows, that is the script’s decision: publish the empty structure, or `fail("why")`. ### What the dashboard looks like The dashboard the script publishes carries the same layout as the one built by hand in 504: the coverage figures, the cost change by category, and the at-risk table. The difference is that nobody rebuilds it. Its data region is refreshed by the schedule, and its layout is edited in the portal like any document. [Image: The supplier quote margin dashboard: four figures across the top, a bar chart of weighted cost change by category, and a table of the quoted SKUs whose projected margin falls under 20 percent.] The dashboard from [504](https://plexara.io/learning/spreadsheets/joining-visualizing-and-sharing), built once by hand. The script-published one carries the same layout with a data region the schedule refreshes, so the second-week numbers land in the same shape every Monday without anyone rebuilding the page. ### The other pattern: a document that references a file There is a second way to keep a document current, and it is the one 504 introduced: the document does not carry its data at all. It names a managed resource by its address and re-reads it on every open. A script keeps that file current by rewriting it, and every document naming it shows the new content without being re-saved. The two patterns look alike from the reader’s chair and behave differently in the ways that matter: what a version holds, and how many documents follow one refresh. Two ways a dashboard stays current publish_data A referenced file What moves on a run The JSON inside the document’s data region. The markup is untouched. The referenced file, rewritten with replace_content. The document is not touched at all. What a version holds A complete as-of snapshot: an old version of the dashboard shows the numbers it showed then. A pointer. Open a six-month-old version of the document and it reads today’s file. Who edits the layout Anyone with edit rights, in the portal, like any document. The schedule keeps refreshing only the numbers. The same, and the data half is edited by whatever rewrites the file. How many documents follow one refresh One: the named output. Every document that names the file, without any of them being re-saved. Choose it when One dashboard at one address whose history should be exact, whose layout a person may edit. Several documents should read one live file, or a table over the file should stay current (see below). The referencing pattern is the one from [504](https://plexara.io/learning/spreadsheets/joining-visualizing-and-sharing): a document names a managed resource by its `mcp://` address and re-reads it on every open. A script keeps that file current with `platform.call("manage_resource", {"action": "replace_content", …})`, which keeps the file’s id, address, and name, so nothing that names it has to change. ### Keeping a registered table current from a script The same rewrite that keeps a referencing document current leaves a registered table behind, because a new revision of a file is a new place and the table keeps reading the old one. A script that rewrites a registered file registers it again in its next lines, under the same name, which replaces the registration and points the table at the new revision. Refreshing a file and moving its table forward, from a script ``` platform.call("manage_resource", { "action": "replace_content", "reference": "mcp:resource:71131796b81fbb5641bdcbb3df0ef238", "content": sheet_csv, "change_summary": "Price sheet for " + month_start, }) platform.call("manage_table", { "action": "register", "reference": "mcp:resource:71131796b81fbb5641bdcbb3df0ef238", "connection": "scratch", "table_name": "supplier_price_sheet", }) ``` A new revision of a file leaves a registered table behind, exactly as it did in [505](https://plexara.io/learning/spreadsheets/next-months-file), so a script that rewrites the file registers the same name again on the same connection in its next lines. Both are ordinary tool calls the script’s author could make at a prompt, authorized the same way. Neither appears in the run’s output list, because only `platform.export` and `platform.publish_data` are outputs; a write made by tool call is recorded in the audit log instead. ### Versions Every refresh is a version, and a schedule produces versions on a cadence. The asset’s owner decides how many it keeps. Cap the versions an asset a script rewrites keeps An asset keeps a version per run, and a daily refresh writes 365 of them a year. The asset’s owner sets how many it keeps with `max_versions`: the newest N, every version, or the platform’s default. Older versions are deleted with their stored content when a new one pushes them past the cap. Set it on the dashboard a schedule refreshes and on the feeds beside it; leave it alone on a report people cite by version. ### Delivering to another system Some output exists to be consumed somewhere else: the weekly CSV another system picks up from a bucket. A script delivers the same bytes there by naming a destination, a named drop Deasil sets up for your deployment on request, and a key beneath it. Nothing else about the drop is the script’s business. One result, two destinations ``` rows = platform.query(connection = conn, sql = "SELECT ...")["rows"] # The portal asset, refreshed: a new version of one asset. platform.export(name = "weekly-sales", rows = rows, format = "csv") # The same bytes, delivered for another system to read. platform.export( name = "weekly-sales", rows = rows, format = "csv", destination = "acme-drop", key = "2026/08/sales.csv", ) ``` 1. 01 The script names only the destination and the key. The bucket, the prefix, and the credentials belong to the destination, a named drop Deasil sets up for your deployment on request; nothing about them appears in the source. 2. 02 Destination and key are passed by name, never by position, so where a script writes can be read from its source by validate before it ever runs. 3. 03 One output name may be written once per destination in a run, which is what lets one result go to the portal and to the drop; a second write to the same destination fails rather than silently keeping one of the two. 4. 04 A key that could climb out of the drop’s prefix is refused rather than cleaned up, and two outputs may not land on one object. 5. 05 Each delivery is recorded on the run: destination, bucket, key, and bytes. A run that is interrupted and resumed does not deliver the same object twice. ### Where the outputs go from here Every output in this lesson is an ordinary asset once it lands: shareable, versioned, referenceable from other documents, and findable by search. The 300 series covers what happens to an asset after that; nothing about a script-written one is different. Next: running it, three ways The outputs exist because something ran the script. The runs in this lesson were asked for from a session, one at a time. The next lesson covers the other two triggers, the Run button on the script’s page and a schedule, and what a schedule guarantees about the runs it produces. [604 covers running, by hand, from the portal, and on a schedule](https://plexara.io/learning/automations/running-by-hand-from-the-portal-and-on-a-schedule). ### Key terms Five terms cover what a run writes and where it goes. Key Terms Output Something a run declares with platform.export or platform.publish_data. Recorded on the run by name, with the asset and version it produced. A write made by any other tool call is audited but is not an output. Output identity The pair of script and output name, which maps to one asset. A stable name refreshes that asset with a version per run; a dated name creates an asset per run. Data region id="data" The one element of a document whose interior platform.publish_data replaces with the run’s JSON. The document’s own code reads it at view time, so the layout and the numbers change independently. Semi-dynamic dashboard A document published once whose data region a schedule refreshes. Every version is an as-of snapshot, and a layout edit made in the portal survives the next fire. Destination Where an output lands: the portal by default, or a named drop Deasil sets up for your deployment. The script names the destination and a key; the bucket and its credentials are never in the source. On this page [Previous 602 - The agent writes the first script](https://plexara.io/learning/automations/the-agent-writes-the-first-script) [Next 604 - Running it: by hand, from the portal, and on a schedule](https://plexara.io/learning/automations/running-by-hand-from-the-portal-and-on-a-schedule) ### Related reading product [Product 102 - Tokens and your budget Every LLM interaction is priced and rate-limited in tokens. What a token is, how much text fits a budget, and how to avoid wasting tokens on useful answers.](https://plexara.io/learning/ai-concepts/tokens-and-your-budget) [Product 105 - What is an AI agent? An AI agent is not a chatbot and not magic. It is a short loop (think, call-tool, observe, think again) on top of a language model. Mental model first.](https://plexara.io/learning/ai-concepts/what-is-an-ai-agent) [Product 202 - Your first day with Plexara A new Plexara user gets connected, sends a first question, and platform_info takes over. Walks through day one and how subsequent turns inherit context.](https://plexara.io/learning/mcp/first-engagement) --- # Running it: by hand, from the portal, and on a schedule URL: https://plexara.io/learning/automations/running-by-hand-from-the-portal-and-on-a-schedule/ > Three triggers, one run. From any session with a single call, from the Run button on the script’s page where the form comes from its parameter contract, or on a cadence set in the portal’s builder or by the agent, in a timezone, with the fire date pinned onto the run. What a schedule guarantees: one fire is one run, an overlapping fire is recorded as skipped, a gap produces one run for the latest fire, a failed scheduled run emails its owner and is never retried. And the run history that records every trigger, duration, output, and log. Product 10 min read ## 604 - Running it: by hand, from the portal, and on a schedule Three triggers, one run. From any session with a single call, from the Run button on the script’s page where the form comes from its parameter contract, or on a cadence set in the portal’s builder or by the agent, in a timezone, with the fire date pinned onto the run. What a schedule guarantees: one fire is one run, an overlapping fire is recorded as skipped, a gap produces one run for the latest fire, a failed scheduled run emails its owner and is never retried. And the run history that records every trigger, duration, output, and log. On this page ### What you will take away from this lesson A saved script runs. There is no approval step and no state in which a script exists but nothing may execute it: the version you saved is the version that runs, whichever of three triggers asks for it. This lesson covers the three, what each one records, and the guarantees a schedule makes about the runs it produces. The runs in the two previous lessons were all asked for from a session. Here the same script gets a Monday morning cadence on the demo tenant, and the answer the platform gave when it was set is the shape of everything a schedule promises. Learning Objectives 1. 01 Run a script from any session with one call, and read a long run’s result later by its run id. 2. 02 Run it from the script’s page, where Run and Dry run sit above the editor and one form built from the parameter contract serves both. 3. 03 Set a cadence in the portal’s builder or with the agent, in a timezone, and read it back in words. 4. 04 Use ${fire_date} and explain why the script has no clock of its own. 5. 05 State what a schedule guarantees: one schedule per script, one fire is one run, an overlapping fire is recorded as skipped, a gap produces one run for the latest fire, a failed scheduled run emails its owner and is never retried. 6. 06 Read the Scripts page, the Runs tab, and a script’s run history, and know why a script’s schedule lives in Plexara while a prompt’s schedule lives in the agent. ### Where this lesson sits The script from 602 writes the outputs from 603. This lesson is about what makes it run: the three triggers, the cadence that turns a script into an automation, and the record every run leaves. The next lesson covers the authority each of those runs carries. 600 Series: Automations [Open index](https://plexara.io/learning/automations) - [601 Do not spend AI on what a script can do The automation gap, what integration platforms and laptop scripts each cost, and the division of labor: a script for the deterministic part, the model for writing it and for judgment.](https://plexara.io/learning/automations/do-not-spend-ai-on-what-a-script-can-do) - [602 The agent writes the first script The loop from create to save, what validate and a dry run report, the dialect’s deliberate absences, the traps that fail a draft, and the script’s page in the portal.](https://plexara.io/learning/automations/the-agent-writes-the-first-script) - [603 Outputs: feeds, reports, and dashboards that refresh themselves Output identity across runs, tables and documents, the semi-dynamic dashboard and its data region, the referencing pattern, version caps, and delivery to a bucket drop.](https://plexara.io/learning/automations/outputs-feeds-reports-and-dashboards) - [604 Running it: by hand, from the portal, and on a schedule Three triggers, the cadence builder, the pinned fire date, what a schedule guarantees, and the run history with every trigger, duration, output, and log.](https://plexara.io/learning/automations/running-by-hand-from-the-portal-and-on-a-schedule) - [605 What a run may do, and the record it leaves The authority a run carries, what a save refuses, why the language cannot reach out, the lifecycle, ownership and transfer, and the administrator’s view.](https://plexara.io/learning/automations/what-a-run-may-do) - [606 Scripts as skills: the weekly review the agent runs on your business Three scripts attached to one prompt, the agent running them and reading the outputs against the knowledge graph, and a weekly list of action items with the figures behind them.](https://plexara.io/learning/automations/scripts-as-skills-the-weekly-review) The 600 series picks up the registered table from the [500 series](https://plexara.io/learning/spreadsheets) and the prompt mechanics from the [400 series](https://plexara.io/learning/prompts). It is the last numbered series in the curriculum. ### Three triggers, one run A run is asked for in one of three ways, and the run itself does not care which. The platform executes the latest saved version, as the script’s own principal, and records which trigger asked. Three triggers, one run - From any session trigger: tool Anyone the script is visible to, through the agent You ask for it in plain language and the agent calls run_script with the script’s name and its parameters. The values are checked against the contract before anything is queued, and the call waits for the result. - From the script’s page trigger: portal The script’s owner, or an administrator Press Run on the script’s page. The form is built from the parameter contract, so a date gets a date picker, an enum gets a choice, and a connection gets the set the script may reach. - On a schedule trigger: schedule Nobody; the cadence fires it A cadence, a timezone, and the values every fire binds. When it is due, Plexara runs the latest saved version with those values, whether or not anyone is connected. The three execute identically. Every run executes the latest saved version as the script’s own principal, presenting the roles its author held at the save, and the only difference in the record is the label saying which trigger asked. A script taken out of service, disabled, deprecated, or superseded, is refused by all three in the same words. ### Running one from a session The common case is a person who wants the output now. You say so to the agent, the agent calls the script by name with the values it needs, and the answer comes back with the run’s record: the version that ran, how long it took, the outputs it wrote, and the log. The trace below is the first real run of the 602 script. One run from a session, with the real answer What the agent calls. This is the exchange the agent has with Plexara on your behalf, shown for the technical reader. You ask in plain language; you never type any of it. ``` run_script name acme-supplier-margin args {"month": "2025-12-01", "conn": "acme"} wait_seconds 120 -> status succeeded trigger tool version 3 duration_ms 8542 run_id dpx_88dfb063… outputs supplier-margin-by-category asset 871da875… version 1 (csv, 50 rows, 3,404 bytes) supplier-margin-feed asset 589855b4… version 1 (json, 1 row, 27,660 bytes) log supplier margin review for 2025-12-01 to 2026-01-01 categories quoted: 50, weighted cost change 2.57% largest increase: Flowers & Plants 14.800% at-risk SKUs under 20% projected margin: 25 coverage: 400 of 450 quoted ``` The call waits up to two minutes by default and at most five. A run that outlives its window keeps going: the answer carries the run id with a `pending` status, and the agent reads the result when it finishes with `manage_script get_run`. Asking for a run that should not wait at all queues it and returns at once. Either way the run executes on Plexara, so a long report does not hold the agent’s session open and a run in progress survives a platform upgrade. ### Running one from the script’s page The owner of a script runs it from the script’s own page, without an agent in the loop. Everything the run needs is already on that page: the saved code, a form built from the parameter contract, and the history the run will appear in. Running from the script’s page 1. 1 Run and Dry run sit above the editor Run executes the saved version. Dry run executes what is on screen, as you, with tighter limits and nothing persisted. Both are on the page the owner already reads the script on. 2. 2 One form serves both The parameter form below the editor is built from the script’s contract: a date picker for a date, a choice for an enum, the set of reachable connections for a connection parameter. It supplies the values for a run and for a dry run alike. 3. 3 The history re-reads itself The run appears in the history under the code and updates as it progresses, re-reading while anything is pending or running and stopping once nothing is. A run may take ten minutes; the history is where it is followed. A run asked for here and a run asked for by the agent are the same run in every respect except the trigger label. The page cannot widen anything: the run is authorized at every call against the roles captured at the script’s last save. And it cannot run what the platform would refuse, so a disabled or retired script says so instead of offering a button that cannot work. [Image: A script’s page in the portal: its details, its schedule stated in words, the About section, and the source editor with Run and Dry run buttons above it and a parameter form below.] A script’s own page, ordered the way a script is debugged: details and schedule, the About document, the code with Run and Dry run above it and one parameter form below, then the run history. ### The cadence A schedule is what turns a script into an automation: a cadence, a timezone, and the parameter values every fire binds. It is set on the script’s page, in a builder that asks for the cadence the way a person has it in mind, or by the agent in one sentence. Both produce the same row, and the Scripts page states it in words either way. Setting a cadence: the builder, or a sentence to the agent - Hourly, daily, on weekdays, on chosen days of the week, or on a day of the month - A time, and the timezone the time is read in - The values every fire binds, checked against the parameter contract when the schedule is saved - A Custom field for an expression the builder cannot express; an expression the agent wrote opens there as itself What the agent calls. This is the exchange the agent has with Plexara on your behalf, shown for the technical reader. You ask in plain language; you never type any of it. ``` manage_script command=schedule_set name acme-supplier-margin cron 0 7 * * 1 timezone America/Los_Angeles args {"month": "2025-12-01", "conn": "acme", "mode": "refresh"} -> enabled true cron 0 7 * * 1 timezone America/Los_Angeles next_run_at 2026-08-31T14:00:00Z missed_fires 0 message "The platform will run the latest saved version on this cadence, with these parameters, as the script's own principal presenting your captured roles." ``` The portal asks for a cadence in the terms a person has it in and derives the expression, showing it rather than asking for it; the Scripts page then states it in words, as “Every Monday at 7:00 AM, America/Los_Angeles”. The agent sets the same thing with a cron expression or a descriptor such as `@daily`, and the answer above is what came back on the demo tenant. A cadence is read in its timezone, so a report stays on its wall clock across a daylight-saving change. A script has at most one schedule; setting it again replaces the cadence in place. Pausing and resuming are their own actions, and a schedule is never deleted, only disabled, so the runs it produced keep the row that explains them. ### The date of the fire A scheduled report almost always needs to know what day it is. The dialect deliberately gives a script no way to ask, and the schedule supplies the answer instead. ${fire_date}, and why the script has no clock A schedule’s bound values may carry one token, `${fire_date}`, which expands at the moment of the fire to that day’s date in the schedule’s own timezone. The expanded value is what the run records. That is the whole reason the dialect has no clock: a script that computed today’s date itself would answer a different question every time it ran, and a run nobody can reproduce is not a governed run. With the date pinned onto the run, re-running it later with the same parameters asks the same question. The previous day, a month boundary, the start of the quarter: all of it is arithmetic the script does on that value through the date module, where a reader can see it. The demo schedule pins `month` to 2025-12-01 instead, because the demo warehouse ends in December 2025 and a fire date in 2026 would find no sales. A schedule over live data binds the token. ### Pausing and resuming A schedule is paused and resumed from the header of the Schedule section on the script’s page, or by the agent. Pausing is its own action rather than a field of the cadence, so resuming does not re-base the fire it resumes on, and nothing is ever deleted. [Image: The Schedule section of a script’s page with the cadence paused: the cadence stated in words, no next run shown, and a resume control on the header.] A paused schedule. The cadence is kept and stated in words, no next run is shown because nothing will fire, and resuming picks up on the fire it was parked on. Disabling never removes the row, so the runs it produced keep their explanation. ### What a schedule guarantees Seven rules govern the runs a schedule produces. They are what let you trust a number that arrived on a Monday morning nobody was watching. What a schedule guarantees 1. 01 One schedule per script Setting it again replaces the cadence in place and keeps the run history that points at it. A second cadence over the same code is a second script. 2. 02 One fire is one run A fire produces exactly one run, however the platform is scaled underneath. Nothing about a fire is duplicated. 3. 03 An overlapping fire is recorded as skipped A fire arriving while the previous run is still going does not queue behind it. It is recorded as a skipped run, so the skip appears in the history rather than as silence. 4. 04 After a gap, one run for the latest fire When fires could not be materialized for a while, one run is produced for the most recent fire that has come due, and the fires before it are counted as missed on the schedule. A catch-up burst of stale reports would be worse than a visible gap; a backfill somebody wants is a run by hand with the parameters they want. 5. 05 A paused schedule resumes on the fire it was parked on While it is paused it reports no next run. The fire it resumes on collapses to one run under the same rule as a gap. 6. 06 A failed scheduled run emails its owner The mail carries the run id, the failure, and the tail of what the script printed. A run asked for by hand is not mailed, because its failure is already in the answer its caller is reading. 7. 07 A failure is never retried The same version on the same inputs fails the same way, so a retry would multiply the cost and change nothing. The fix is to correct the script, dry-run it, and save the correction. A run that could not start because of a platform fault, rather than a script error, is a different case and is retried on its own. ### The record a run leaves Every run, whichever trigger asked for it, records the same things, and the portal shows them at three levels: the Scripts page for the state of everything, the Runs tab for every run newest first, and a run’s own page for one run in full. What one run records Trigger tool, portal, or schedule: which of the three asked for the run. Version The saved version that executed, which is the version that was latest when the run was queued. Duration and outcome When it started, how long it took, and whether it succeeded, failed, or was skipped as an overlap. A failure carries the error and the line it failed on. Outputs Each output by name, linking to the asset version it produced. An output delivered to a drop names where it was written instead. The log What the script printed, kept to 64 KB with the head preserved. A year of run history is kept. A script’s page shows its most recent runs with a rollup in the header: the share that succeeded, how many failed or were skipped, and the median duration. The Runs tab shows every run across every script you own, newest first, with the reason a run failed in the row rather than behind it. The agent reads the same records with `manage_script command=runs` and `get_run`. [Image: The portal’s Scripts page: three tiles counting Scripts, Scheduled, and Failing, a search box with category chips, and a list of scripts each showing its schedule in words, its next fire, and how its last run ended.] The Scripts page. Three tiles that are also filters: every script, the ones with a schedule (paused or not), and the ones whose last run failed, which is the number most people open this page for. Each row states its cadence in words and how its last run went. [Image: The Runs tab: every run of every script the person owns, newest first, with the trigger, the outcome, the duration, and for a failed run the reason in the row.] The Runs tab: every run across your scripts, newest first, with what triggered it, how it ended, how long it took, and, when it failed, the reason in the row. Opening a row opens the run on its script’s page. [Image: A single run’s page: the parameters it ran with, its timing, each output linking to the asset version it produced, and the log the script printed.] One run, at its own address: parameters, timing, outputs linking to the versions they wrote, and the log. ### Why a prompt’s schedule lives in the agent and a script’s lives in Plexara Lesson 404 said that scheduling a prompt is not a Plexara feature at all. This lesson has just described Plexara scheduling a script. Both statements are true, and the difference between them is the difference between the two kinds of saved work. Scheduling a prompt, scheduling a script A prompt (404) A script (this lesson) Who keeps the clock Your agent: an in-session loop, headless plus cron, a desktop task, a cloud routine. Plexara. The cadence is a row on the script, fired by the platform. What a fire needs A model. A fresh session starts, connects to Plexara, and runs the prompt by name. Nothing. No model, no session, no tokens; the platform executes the saved version. What varies between fires The model’s reading of the instruction, which is the point of a prompt. Only the data. The script contributes no variation of its own. Where the record lives In the asset the prompt saved, and the agent’s own session log. On the run: trigger, version, duration, outputs, log, kept for a year. Lesson [404](https://plexara.io/learning/prompts/running-prompts-and-schedules) explained why a prompt’s schedule lives in the agent: a prompt is an instruction, and running one needs a model to read it. A script needs none, which is why its schedule lives in Plexara and why the 606 capstone puts the two together: a schedule keeps the scripts’ outputs fresh, and a prompt tells the agent what to make of them. ### From a run to its authority Three triggers, one schedule, one record. The script on the demo tenant now fires every Monday at seven, refreshes its dashboard, and writes a run record nobody has to be awake for. Next: what a run may do Every trigger in this lesson ran the script with the same authority, and the schedule’s answer named it: the script’s own principal, presenting your captured roles. Where that authority comes from, what a save refuses, why the language cannot reach out, and the record every call leaves is the next lesson. [605 covers the authority a run carries](https://plexara.io/learning/automations/what-a-run-may-do). ### Key terms Five terms cover how a script comes to run and what it leaves behind. Key Terms Trigger Which of the three producers asked for a run: tool for run_script from a session, portal for the Run button on the script’s page, schedule for a fire. Recorded on the run; the three execute identically. Cadence schedule A cron expression or a descriptor, a timezone, and the values every fire binds. One per script; set in the portal’s builder or by the agent; paused and resumed rather than deleted. Fire The moment a cadence comes due. One fire is one run. A fire arriving while the previous run is still going is recorded as skipped; after a gap, one run is produced for the latest fire. ${fire_date} The one token a schedule’s bound values may carry. It expands to the date of the fire in the schedule’s timezone and is recorded on the run, which is why the script needs no clock. Run record Trigger, version, duration, outcome, outputs linking to the asset versions they wrote, and the log. Read on the script’s page, on the Runs tab, and by the agent; kept for a year. On this page [Previous 603 - Outputs: feeds, reports, and dashboards that refresh themselves](https://plexara.io/learning/automations/outputs-feeds-reports-and-dashboards) [Next 605 - What a run may do, and the record it leaves](https://plexara.io/learning/automations/what-a-run-may-do) ### Related reading product [Product 102 - Tokens and your budget Every LLM interaction is priced and rate-limited in tokens. What a token is, how much text fits a budget, and how to avoid wasting tokens on useful answers.](https://plexara.io/learning/ai-concepts/tokens-and-your-budget) [Product 105 - What is an AI agent? An AI agent is not a chatbot and not magic. It is a short loop (think, call-tool, observe, think again) on top of a language model. Mental model first.](https://plexara.io/learning/ai-concepts/what-is-an-ai-agent) [Product 202 - Your first day with Plexara A new Plexara user gets connected, sends a first question, and platform_info takes over. Walks through day one and how subsequent turns inherit context.](https://plexara.io/learning/mcp/first-engagement) --- # What a run may do, and the record it leaves URL: https://plexara.io/learning/automations/what-a-run-may-do/ > A run presents the roles its author held at the save, every call is authorized at that moment, and narrowing the persona takes effect on the next run. A save refuses a credential-shaped literal and source that does not parse. The dialect has no network, no filesystem, and no clock, so everything a script does is a platform call audited under the script’s own identity. The lifecycle from active to disabled, deprecated, and superseded; who sees what; ownership and an administrator’s transfer; and the administrator’s view of every script and every run. Governance 9 min read ## 605 - What a run may do, and the record it leaves A run presents the roles its author held at the save, every call is authorized at that moment, and narrowing the persona takes effect on the next run. A save refuses a credential-shaped literal and source that does not parse. The dialect has no network, no filesystem, and no clock, so everything a script does is a platform call audited under the script’s own identity. The lifecycle from active to disabled, deprecated, and superseded; who sees what; ownership and an administrator’s transfer; and the administrator’s view of every script and every run. On this page ### What you will take away from this lesson A script runs when nobody is watching. That is the point of it, and it is also the reason the question of what a run may do has to be answered before the first schedule fires. The answer on Plexara is short: a run may do exactly what its author could do at the keyboard on the day the version was saved, and every step it takes is written down. This lesson is the governance half of the series. It covers the authority a run carries, the things a save refuses before anything is stored, why the language itself cannot reach outside the platform, the lifecycle of a script, who sees what, and the view an administrator gets of all of it. Learning Objectives 1. 01 State the authority rule: a run presents the roles its author held at the save, every call is authorized at that moment, and narrowing the persona takes effect on the next run. 2. 02 Know what a save refuses: a credential-shaped literal, source that does not parse, and a destination Plexara does not have. 3. 03 Explain why a script cannot reach out: no network, no filesystem, no clock, and every action a platform call audited under the script’s own identity. 4. 04 Read the lifecycle, active through disabled, deprecated, and superseded, and what each state does to runs and schedules. 5. 05 Know who sees what: a script is its owner’s, its output is the team’s. 6. 06 Understand an administrator’s transfer of ownership and what it changes, and find the administrator’s view of every script and every run. ### Where this lesson sits Lessons 602 through 604 built a script, gave it outputs, and put it on a schedule. This lesson steps back and asks what that schedule is allowed to do while nobody is watching, and what it leaves behind so that somebody can check later. 600 Series: Automations [Open index](https://plexara.io/learning/automations) - [601 Do not spend AI on what a script can do The automation gap, what integration platforms and laptop scripts each cost, and the division of labor: a script for the deterministic part, the model for writing it and for judgment.](https://plexara.io/learning/automations/do-not-spend-ai-on-what-a-script-can-do) - [602 The agent writes the first script The loop from create to save, what validate and a dry run report, the dialect’s deliberate absences, the traps that fail a draft, and the script’s page in the portal.](https://plexara.io/learning/automations/the-agent-writes-the-first-script) - [603 Outputs: feeds, reports, and dashboards that refresh themselves Output identity across runs, tables and documents, the semi-dynamic dashboard and its data region, the referencing pattern, version caps, and delivery to a bucket drop.](https://plexara.io/learning/automations/outputs-feeds-reports-and-dashboards) - [604 Running it: by hand, from the portal, and on a schedule Three triggers, the cadence builder, the pinned fire date, what a schedule guarantees, and the run history with every trigger, duration, output, and log.](https://plexara.io/learning/automations/running-by-hand-from-the-portal-and-on-a-schedule) - [605 What a run may do, and the record it leaves The authority a run carries, what a save refuses, why the language cannot reach out, the lifecycle, ownership and transfer, and the administrator’s view.](https://plexara.io/learning/automations/what-a-run-may-do) - [606 Scripts as skills: the weekly review the agent runs on your business Three scripts attached to one prompt, the agent running them and reading the outputs against the knowledge graph, and a weekly list of action items with the figures behind them.](https://plexara.io/learning/automations/scripts-as-skills-the-weekly-review) The 600 series picks up the registered table from the [500 series](https://plexara.io/learning/spreadsheets) and the prompt mechanics from the [400 series](https://plexara.io/learning/prompts). It is the last numbered series in the curriculum. ### The authority a run carries The rule that makes unattended work safe is that a run never has more reach than its author had at the keyboard. The roles the author held are captured on the version at the moment it is saved, and every run of that version presents exactly those roles, whoever asked for the run and whenever the schedule fired it. Authorization happens per call, not per script. Each query, export, and tool call a run makes is checked against the persona those roles resolve to, at the moment it is made, the same way an agent’s call is checked. That is why narrowing a persona takes effect on the script’s next run without anyone editing the script. The authority a run carries, in five rules 1. 1 A run executes as the script’s own principal Not as you, and not with your session. It authenticates as script:, and that is the name audit records and the name its outputs belong to. 2. 2 It presents the roles its author held at the save The roles are captured on the version when it is saved and cannot be set any other way. A script can never do unattended what the person who wrote it could not do themselves. 3. 3 Every call is authorized at the moment it is made Each query, export, and tool call a run makes crosses the same authorization an agent’s call crosses, against the persona those roles resolve to. There is no script-side allow list to keep in step. 4. 4 Narrowing the persona takes effect on the next run Remove a connection or a tool from the persona and the script’s next run is refused at that call, in the persona filter’s own words. Nothing about the script has to change. 5. 5 A cadence carries no authority of its own Re-timing a script reaches nothing the script could not already reach; the run gate and the persona are re-read at every fire. The platform says the same thing every time a script is saved. The answer to the first save in [602](https://plexara.io/learning/automations/the-agent-writes-the-first-script) read: “Saved, and it runs: run_script executes it under the access you held when you saved it, and a schedule you set will fire it.” ### What a save refuses Some mistakes are caught before a version exists at all. A save is the version that runs, so the checks that protect a run happen at the keyboard, where the author can fix the problem, rather than at the next fire. Three things a save refuses - A credential-shaped literal At validate, before the save. A private key header, a cloud access key id, a well-known token format, or a URL with a password in it blocks the save. A variable merely named like a secret is a warning, so the paste is caught and the false alarm is not fatal. Scripts name connections; Plexara holds the credentials. - Source that does not parse At the keyboard, on the portal editor or the agent’s save. Code that cannot run is refused rather than stored, so the failure surfaces while somebody is looking at it instead of at the next fire. A script that does not parse is not a draft. - A destination Plexara does not have At validate, named in the words the run would use. An output addressed to a bucket drop that has not been set up for your deployment is reported by validate, so it fails while the author is iterating rather than after a real run has already spent its queries. ### Why the language cannot reach out The dialect a script is written in is deliberately small, and the absences are the security model. A script has no way to open a connection, read a disk, tell the time, or pull in code, so the only outside world it has is the platform, and the platform records everything it is asked to do. Why the language cannot reach out - No network A script opens no socket and supplies no endpoint. An external API is reached only through a connection Plexara already holds, with platform.call, so what a script can reach is what its author can reach. - No filesystem A file is read through the registered table or a platform call, and written as an output. Nothing lands anywhere the platform does not record. - No clock, no randomness The fire time is pinned on the run, so the same version with the same parameters asks the same question. A run nobody can reproduce is not a governed run. - No imports json and date are the whole module surface. There is no way to pull code in from outside, so the source on the version is the whole program. Everything a script does is therefore a platform call, over the same governed path an agent’s call takes, and every one of them is audited under `script:`. A run’s reach can be read from its source before it runs, which is what validate reports, and its record is complete after. ### The lifecycle A script is in one of four states, and the state is the only thing that decides whether a run is admitted. There is no approval queue between a save and a run; the trade for that is a lifecycle that can take a script out of service in one action and says so wherever the script is shown. The lifecycle of a script 1. 1 Active The saved version runs: from any session, from the Run button, and on its schedule. 2. 2 Disabled Nothing executes it. The run gate refuses in its own words on every surface, and a cadence set on a disabled script saves and stays inert, which the tool and the page both say plainly. 3. 3 Deprecated Taken out of service and marked as such. The record stays; runs are refused. 4. 4 Superseded Retired in favor of a named replacement. The reference to the old script still resolves, and says which script replaced it. There is no approval step and no state in which a script exists but nothing may run it. A saved script runs; taking it out of service is the only gate, and a schedule is never deleted, only disabled, so the row that explains past runs stays. ### Who sees what A script is personal. Its owner and administrators see everything about it; anyone else who can see it sees what it says about itself. That is not a limitation to work around: the thing a team shares is the output a script produces, and outputs have the sharing model of every other asset. Who sees what - Anyone who can see the script Its details: what it is, what parameters it takes, whether a run would be admitted, and its schedule. The same facts an agent gets when it resolves a reference to it. - Its owner and administrators The source, the run history, the schedule controls, and the version history with each version’s author and the roles a run of it presents. - Whoever asked for one run That run: its parameters, outputs, and log, in addition to the owner and administrators. - The team The output. A script is one person’s; there is no team library of scripts. The dashboard it publishes, the feed it writes, and the shares on them are what everyone else works from. A prompt that references a script resolves it for the script’s owner and tells anyone else that part of its automation was unavailable. The way a whole team benefits from one person’s script is the way [606](https://plexara.io/learning/automations/scripts-as-skills-the-weekly-review) shows: the review it produces is shared; the code stays where it was written. ### Ownership and transfer Because a script is personal, someone leaving the team or changing roles is a real event for the automations they own. An administrator can move a script to another person, and the move changes more than a name on a listing. Ownership, and an administrator’s transfer - Only an administrator moves a script From the script’s page, choosing the new owner from the people who have signed in to your deployment at least once. An owner cannot give a script away. - The whole script moves at once What the owner sees, edits, runs, and schedules, and the history: the new owner reads the run records and dry-run accounts the previous owner produced. - The move is a version, authored by the administrator From then on a run presents that administrator’s roles. Moving a script to an administrator is how it comes to run with an administrator’s reach. - A name clash is refused If the receiving owner already keeps a script of the same name, the transfer does not happen. - It is audited Like every other administrative write, the transfer is recorded in the audit log. ### The transfer control The transfer is done on the script’s own page, the same page the owner reads it on. It is the one thing that page offers an administrator and not an owner. [Image: A script’s page opened by an administrator, with the Owner control for moving the script to another person, chosen from people who have signed in at least once.] The script page an administrator opens is the page its owner opens, plus one control: Owner. There is one script page for both surfaces, so the two views cannot drift apart. ### The record a run leaves Every run writes a row: the version that executed, what triggered it, how long it took, the outputs it wrote and the asset versions they became, and the log the script printed. Every call the run made is also in the audit log under the script’s own principal. The trace below is the last successful run of the margin script from 604, read back. One run, and the record it leaves What the agent calls. This is the exchange the agent has with Plexara on your behalf, shown for the technical reader. You ask in plain language; you never type any of it. ``` run_script name=acme-supplier-margin args={"month":"2025-12-01","conn":"acme","mode":"refresh"} → status succeeded version 6 trigger tool duration 8,231 ms outputs supplier-margin-by-category csv asset 871da875-cd99-44f9-b6d9-55732b4e9086 version 3 supplier-margin-feed json asset 589855b4-cfe1-4355-af26-ae68cbc5770f version 3 supplier-margin-dashboard refresh asset bab7c8e7-67e6-4561-834a-32524f203fc8 version 2 audited as script:acme-supplier-margin, presenting the roles captured at the save of version 6 ``` The run row names the version that executed, what triggered it, how long it took, every output it wrote with the asset version it produced, and the log it printed. The audit log records each call the run made under the script’s own principal. Between the two, a reader six months later can say exactly what happened and under whose authority. ### Versions and the dry-run account The version history is the other half of the record. Each version names who saved it and the roles a run of it presents, and each version carries the account of the dry run that preceded it, if there was one. A version nobody dry-ran is called out as code that first executed unattended. [Image: A script’s Version history in the portal: each version with its author and the roles a run of it presents, and whether a dry run account is attached.] Version history sits under the source. Each version names its author and the roles a run of it presents, which are the roles captured at that save, and carries the account of the dry run that preceded it, when there was one. What a dry-run account holds Who ran it, and when The author’s own identity, under their own persona. How it ended Succeeded, or the failure and the line it failed on. What it printed The bounded log, head kept, tail dropped with a marker when it overflows. The shape of its outputs Each export’s format, row count, and size, measured without being written. Which source it executed The account is keyed to the exact source, so it attaches to whichever version later carries that code. A version with no account is code that first executed unattended, and the version detail says so. ### The administrator’s view An administrator sees every script and every run on the deployment, on the same pages owners use, with an owner column and two panels the owner view does not need: the busiest scripts and the fires that were missed. [Image: The administrator’s All scripts listing: every script on the deployment with its owner, schedule, next fire, and how its last run went.] All scripts, with the Owner column added to the listing owners read on their own Scripts page. A script with no owner reads nobody and is visible to administrators alone; one with no cadence reads On demand. ### Every run, across every script The Runs tab is where a missed fire becomes visible, because a fire that did not produce a run has no row anywhere else. Run history is kept for a year, and older history is still reachable one script at a time. [Image: The administrator’s Runs tab: run counts and durations across every script, panels for the busiest scripts and for missed fires, and the fifty most recent runs.] The Runs tab answers what the run table cannot: a missed fire is a run that does not exist. Busiest scripts and Missed fires each link to the script concerned, and the list shows the fifty most recent runs and says so when it fills. Run history is kept for a year. ### What is settled Unattended never means unaccountable. A run does what its author could do, is refused what its author could not, cannot reach anything the platform does not mediate, and leaves a record that names the version, the trigger, the outputs, and every call. Next: composing scripts, prompts, and knowledge Everything a run may do is now settled: what it presents, what it is refused, what it cannot reach, and what it leaves behind. The last lesson puts three scripts, one prompt, and the knowledge graph together into the weekly review the agent runs on the business. [606 is the capstone](https://plexara.io/learning/automations/scripts-as-skills-the-weekly-review). ### Key terms Five terms cover the authority and the record of an unattended run. Key Terms Script principal script: The identity a run authenticates as. Audit records it, and the run’s outputs belong to it. It carries the author’s address so the run can act on what the author owns. Captured roles The roles the author held when the executing version was saved, stored on that version and presented by every run of it. They cannot be set any other way. Run gate The check that admits or refuses a run. It refuses only a script taken out of service (disabled, deprecated, or superseded), in its own words on every surface. Dry-run account The record a dry run leaves of itself: who, when, how it ended, the bounded log, and the shape of the outputs, keyed to the exact source that executed. Ownership transfer An administrator’s move of a script to another person, recorded as a version the administrator authored, after which runs present that administrator’s roles. On this page [Previous 604 - Running it: by hand, from the portal, and on a schedule](https://plexara.io/learning/automations/running-by-hand-from-the-portal-and-on-a-schedule) [Next 606 - Scripts as skills: the weekly review the agent runs on your business](https://plexara.io/learning/automations/scripts-as-skills-the-weekly-review) ### Related reading governance [Governance 403 - Sharing prompts, and closing the loop with feedback A procedure is only worth as much as the people who can run it. Plexara distributes a prompt two ways: a direct share to one teammate, or a promotion to a whole role or company through the admin review queue. A shared prompt is live, not a copy. Feedback threads then carry corrections back, with a validation step and a path into the knowledge catalog, and the deprecate-and-supersede lifecycle retires old versions cleanly.](https://plexara.io/learning/prompts/sharing-prompts-and-feedback) [Governance 505 - Next month’s file The new sheet arrives. Replacing the file’s content writes a new revision, and the registered table keeps reading the old one until it is registered again under the same name; the Scratch Tables page says so. This lesson covers the two cases that look alike and behave differently, moving the table forward, unregistering, what deleting the file does, saving the monthly procedure as a prompt, and the point at which a monthly file needs more than a join, which is where the 600 series begins.](https://plexara.io/learning/spreadsheets/next-months-file) [Governance Closed by default: least privilege as the starting point Access control that starts open and gets locked down later never actually finishes. Closing connection access by default means every role sees exactly what it was granted and nothing more.](https://plexara.io/learning/insights/closed-by-default-access) --- # Scripts as skills: the weekly review the agent runs on your business URL: https://plexara.io/learning/automations/scripts-as-skills-the-weekly-review/ > The capstone. Three scripts (category velocity, the supplier quote margin review, regional weather context) attached to one prompt, so serving the prompt carries each script’s contract and last successful output and the agent runs them for fresh numbers instead of re-deriving them. The agent then reads the outputs against the seasonality calendar, the returns policy, the store formats, and the stock health bands, and produces the week’s action items: promote, discount, discontinue or renegotiate, watch, each with its figure. The scripts did the data work; the model did the judgment; neither is rebuilt next week. Integration 12 min read ## 606 - Scripts as skills: the weekly review the agent runs on your business The capstone. Three scripts (category velocity, the supplier quote margin review, regional weather context) attached to one prompt, so serving the prompt carries each script’s contract and last successful output and the agent runs them for fresh numbers instead of re-deriving them. The agent then reads the outputs against the seasonality calendar, the returns policy, the store formats, and the stock health bands, and produces the week’s action items: promote, discount, discontinue or renegotiate, watch, each with its figure. The scripts did the data work; the model did the judgment; neither is rebuilt next week. On this page ### What you will take away from this lesson Every Monday somebody at ACME has to decide what to promote, what to discount, and what to stop carrying. The numbers behind that decision are the same every week: how each category sold against the week before, what the supplier’s latest quote does to margin, and whether a regional dip was weather. The judgment on top of the numbers is where the week’s work actually is. This lesson builds that review on the demo tenant with everything the curriculum has covered: three managed scripts for the numbers, one prompt that carries them, five knowledge pages for the rules, and the agent for the judgment. The scripts run in seconds and are never rewritten. The review is a real asset with real figures. Learning Objectives 1. 01 Compose several scripts into one job: a KPI extraction, a file join, and an API call. 2. 02 Attach scripts to a prompt through the agent, so serving the prompt carries each script’s contract and last successful output, never its source, and the agent runs them for fresh numbers instead of re-deriving them. 3. 03 Write the prompt so the agent reads the outputs against the knowledge graph and produces action items: promote, discount, discontinue or renegotiate, watch, each with its figure. 4. 04 Save the review as an asset, share it, and close the loop: feedback on the review becomes knowledge the next run reads. 5. 05 Understand that the scripts stay the owner’s while the review reaches the team; the shared output, not the code, is what everyone gets. 6. 06 Recognize the division of labor realized: the scripts did the data work, the model did the judgment, and neither is rebuilt next week. ### Where this lesson sits This is the last lesson of the 600 series and of the numbered curriculum. It uses the scripts from 602 through 604, the prompt mechanics from the 400 series, the registered table from the 500 series, and the knowledge loop from 206 and 307, and puts them to work on one recurring job. 600 Series: Automations [Open index](https://plexara.io/learning/automations) - [601 Do not spend AI on what a script can do The automation gap, what integration platforms and laptop scripts each cost, and the division of labor: a script for the deterministic part, the model for writing it and for judgment.](https://plexara.io/learning/automations/do-not-spend-ai-on-what-a-script-can-do) - [602 The agent writes the first script The loop from create to save, what validate and a dry run report, the dialect’s deliberate absences, the traps that fail a draft, and the script’s page in the portal.](https://plexara.io/learning/automations/the-agent-writes-the-first-script) - [603 Outputs: feeds, reports, and dashboards that refresh themselves Output identity across runs, tables and documents, the semi-dynamic dashboard and its data region, the referencing pattern, version caps, and delivery to a bucket drop.](https://plexara.io/learning/automations/outputs-feeds-reports-and-dashboards) - [604 Running it: by hand, from the portal, and on a schedule Three triggers, the cadence builder, the pinned fire date, what a schedule guarantees, and the run history with every trigger, duration, output, and log.](https://plexara.io/learning/automations/running-by-hand-from-the-portal-and-on-a-schedule) - [605 What a run may do, and the record it leaves The authority a run carries, what a save refuses, why the language cannot reach out, the lifecycle, ownership and transfer, and the administrator’s view.](https://plexara.io/learning/automations/what-a-run-may-do) - [606 Scripts as skills: the weekly review the agent runs on your business Three scripts attached to one prompt, the agent running them and reading the outputs against the knowledge graph, and a weekly list of action items with the figures behind them.](https://plexara.io/learning/automations/scripts-as-skills-the-weekly-review) The 600 series picks up the registered table from the [500 series](https://plexara.io/learning/spreadsheets) and the prompt mechanics from the [400 series](https://plexara.io/learning/prompts). It is the last numbered series in the curriculum. ### The job A weekly merchandising review for ACME: what to promote, what to discount, what to discontinue or take back to the supplier, and what is moving for reasons nobody should act on. The numbers behind it come from three places, the warehouse, the supplier’s price sheet, and the weather archive, and each place has a script. Three scripts, one each - acme-category-velocity last run 3,605 ms Computes Units and gross revenue per category for the review week against the week before, with each category’s tracked positions in the five stock health bands. Reaches Two warehouse queries. Outputs category-velocity (csv, 50 rows) and category-velocity-feed (json), assets 3fe22a6d-3868-4020-81ca-9a248b61736d and f39cf0f8-0456-4537-8e35-2241b9e6eb16. - acme-supplier-margin last run 8,231 ms Computes The current Blue Harbor quote against the cost of record and the shelf price, weighted by the month’s sales: cost change by category, the at-risk SKUs, and coverage. The 500 series’ registered table, read by a script. Reaches Three warehouse queries joined to the registered table. Outputs supplier-margin-by-category (csv), supplier-margin-feed (json), and the refreshed supplier-margin-dashboard, assets 871da875…, 589855b4…, and bab7c8e7…. - acme-weather-context last run 1,856 ms Computes Each region’s revenue change for the week, paired with its anchor city’s highs, lows, precipitation, snowfall, and wet days from the historical weather archive. Reaches One warehouse query and eight calls through the open-meteo connection. Outputs weather-context (json, one entry per region) and weather-context-daily (csv, 56 rows), assets 2e10a16c-7f61-42dc-85f3-2f103349f99e and 047b038f-68ff-4fb3-919e-78387418c8c2. The first two are the scripts from [602](https://plexara.io/learning/automations/the-agent-writes-the-first-script) and a sibling written the same way; the third is the one that reaches an outside API, eight archive calls through a connection Plexara already holds. All three run on the platform, under the roles their author held at the save ([605](https://plexara.io/learning/automations/what-a-run-may-do)). ### The prompt The prompt is the procedure. It tells the agent which scripts to run and with what, which knowledge pages to read before judging anything, what sections the review has, where to save it, whom to share it with, and to capture what it learned. It says nothing about how to compute a number, because the scripts own that. The prompt, abridged to its structure ``` Produce the weekly merchandising review for the week starting {week_start}. Do the data work with the attached scripts; do not re-derive their numbers yourself: 1. Run acme-category-velocity with week_start={week_start} 2. Run acme-supplier-margin with month set to the first day of the month and mode=refresh 3. Run acme-weather-context with week_start={week_start} Read the outputs and apply the organization's knowledge before judging anything: - ACME Retail Seasonality Calendar - ACME Returns Policy - ACME Store Formats - Inventory Stock Health - Weather and Store Operations Playbook Write the review as a markdown document: - Headline - Promote - Discount - Discontinue or renegotiate - Watch - Every item carries the figure that justifies it and names the script output it came from. Save it with save_asset as "Weekly merchandising review, week of {week_start}", citing the three run outputs. Share it with {recipient}, or create a link any signed-in user can open. Finish by capturing, with memory_capture, any business fact the knowledge pages did not state. ``` Saved as the personal prompt `weekly-merchandising-review`, with `week_start` required and `recipient` optional. The prompt names the scripts and the knowledge pages and says what to do with each; it does not say how to compute anything, because the scripts already do. The 400 series covers how a prompt like this is authored, shared, and run ([401 to 404](https://plexara.io/learning/prompts)). ### Attaching the scripts A prompt can reference the managed scripts its procedure depends on. Once attached, serving the prompt delivers each script’s contract and last successful output alongside the text, with the instruction to run the script for fresh numbers rather than re-derive them. Attaching the three scripts What the agent calls. This is the exchange the agent has with Plexara on your behalf, shown for the technical reader. You ask in plain language; you never type any of it. ``` manage_prompt command=attach_script name=weekly-merchandising-review script=mcp:script:cd8a42cc-c236-4607-9ff5-667029a9aa2c → status attached manage_prompt command=attach_script name=weekly-merchandising-review script=mcp:script:f3dc47f5-81e6-4fcd-a344-40dd494f86e2 → status attached manage_prompt command=attach_script name=weekly-merchandising-review script=mcp:script:3ea98cce-00eb-4e55-9fcb-eb0fed9fc64a → status attached ``` Attaching is done through the agent; the portal’s prompt editor attaches reference material, not scripts. A script is its owner’s, so the reference resolves for the owner, and anyone else the prompt serves is told that part of its automation was unavailable rather than shown the script’s name or parameters. Deleting a referenced script does not break the prompt; it still serves and reports the reference as gone. ### What the served prompt carries When the agent resolves the prompt for a week, it receives the rendered instruction and, for each attached script, everything it needs to run it correctly: the parameter contract with types and defaults, the version that will execute, the schedule where one exists, and the outputs of the last successful run with their asset ids. What the served prompt carries What the agent calls. This is the exchange the agent has with Plexara on your behalf, shown for the technical reader. You ask in plain language; you never type any of it. ``` manage_prompt command=use name=weekly-merchandising-review args={"week_start":"2025-12-08"} → status resolved content (rendered, with 2025-12-08 substituted) scripts [3] ``` availability embedded, for each of the three scripts, because the caller owns them. contract name, display name, the full description, owner, category, tags, status, enabled, and params with types and defaults: week_start (date, 2025-12-08), conn (connection, acme), and for the margin script mode (enum refresh or publish). version 1, 6, and 1: the latest saved version of each, which is what run_script executes. schedule On the margin script only: cron_spec 0 7 * * 1, timezone America/Los_Angeles, next_run_at 2026-08-31T14:00:00Z. last_successful_run The run id, version, finished_at, and every output with its asset id and version, so the agent can read a recent result without running anything. the instruction “Call run_script with a script’s name and parameters to produce fresh output, and use what it returns rather than re-deriving the same result yourself.” The contract never carries the source. Finding a script says it exists and what it takes; running it is still run_script under the run gate, and reading the code is still the owner’s to do. ### The run Say “run the weekly merchandising review for the week of December 8” and the agent does what the prompt says. The trace is short, and every number in the review comes from one of the first three calls. The run, call by call What the agent calls. This is the exchange the agent has with Plexara on your behalf, shown for the technical reader. You ask in plain language; you never type any of it. 1. 1 run_script name=acme-category-velocity args={"week_start":"2025-12-08"} succeeded in 3,605 ms · run dpx_953e18…· category-velocity v1, category-velocity-feed v1 2. 2 run_script name=acme-supplier-margin args={"month":"2025-12-01","mode":"refresh"} succeeded in 8,231 ms · run dpx_3bea16…· by-category v3, feed v3, dashboard v2 (refresh) 3. 3 run_script name=acme-weather-context args={"week_start":"2025-12-08"} succeeded in 1,856 ms · run dpx_837747…· weather-context v1, weather-context-daily v1 4. 4 fetch × 5: the seasonality calendar, the returns policy, the store formats, the stock health bands, the weather playbook five knowledge pages, read in full 5. 5 save_asset name="Weekly merchandising review, week of 2025-12-08" content_type=text/markdown references=[the three feed assets] asset 354ef652c40880981dbfa51787f12e60 · provenance captured, 3 calls recorded · references declared 3 6. 6 manage_asset action=share asset_id=354ef652… access_mode=authenticated a link any signed-in user can open · lasts until revoked · notified false 7. 7 memory_capture type=business_knowledge id 7bde39f329918d094e5d716a07b02eee · “Captured. It will be reviewed before promotion to a shared catalog.” Three runs, five reads, one save, one share, one capture. The review declares the three feed assets as references, so its links to them resolve for everyone it is shared with. Nothing in the trace is a query the agent wrote; every number came from a script. ### The review The finished asset for the week of December 8 to 14, 2025, section by section. Each item carries the figure that justifies it, and the review names the feed each figure came from. The review, week of 2025-12-08 - Headline $4,688,138 against $4,500,609 the week before, up 4.1 percent. The normal second-week-of-December build toward the peak, not a demand event. Every region grew, from Southwest at +0.9 percent to Midwest at +6.4 percent. - Promote First Aid, Outdoor & Sports, Storage & Organization, Garden Supplies, Meat & Seafood. First Aid +12.6% to $96,232 with 3,981 of 5,757 positions Healthy and a projected margin of 31.7% under a quote up 3.9%; Outdoor & Sports +12.5% at 38.7%; Storage & Organization +11.4% at 38.9%; Garden Supplies +10.6% at 42.8%; Meat & Seafood +10.1% at 27.7%. - Discount Stationery, Pasta & Grains, Snacks & Chips, Paper Products, Pet Supplies. Stationery -5.2% to $109,474 at a 28.9% margin; Pasta & Grains -5.1% at 36.7%; Snacks & Chips -4.1% at 41.6%; Paper Products -4.0% at 34.4%; Pet Supplies -3.8% at 26.8%. All five hold about 70% of positions Healthy. - Discontinue or renegotiate SKU-000256, SKU-000175, SKU-000212, SKU-000313, SKU-000219. SKU-000256 Personal Care: price $61.92, cost of record $84.77, December quote $94.80, projected margin -53.1%, $792.37 a month. SKU-000175 -41.6%, $342.24. SKU-000212 -36.2%, $86.48. SKU-000313 -28.9%, $70.38. SKU-000219 +0.6% on a quote up 22.2%, $100.04. Twelve products carry a cost of record above their price, a catalog data-quality issue raised separately. - Watch Toys & Games, Gift Cards, Personal Care, Batteries & Electronics, Northwest, Southwest, Central, Midwest, the week of December 22. Toys & Games +10.6% and Gift Cards +3.0% are the December peak. Personal Care is up 7.0% in revenue but its quote is up 11.9% (margin 24.1 to 15.1). Batteries & Electronics +8.6% with a quote up 13.9%. Northwest +1.5% with five wet days in Seattle. Southwest +0.9% and Central +1.3% with dry weather deserve a store-level look. Midwest +6.4% through a cold snap. Every figure traces to one of the three feeds, and the review names which. The asset is markdown, saved as `354ef652c40880981dbfa51787f12e60`, with a link any signed-in user can open. ### What the agent added that a script cannot The scripts return fifty categories, twenty-five at-risk SKUs, and eight regions. The review is shorter than that because the agent held the outputs against the rules the knowledge pages state and left things out for stated reasons. Three of those reasons, quoted from the asset. What the agent added, in its own words - > Organic & Natural is the fastest category (+12.6 percent to $105,623) but is not on this list: its projected margin under the quote is 21.5 percent (down from 23.8) and 982 of its 5,757 positions are Critical Low or Out of Stock (17 percent). That is a replenishment problem first; promoting it would sell into empty shelves. - > Baking Supplies is also down (-2.3 percent) but is excluded: the December quote raises its cost 14.5 percent and its projected margin falls to 31.3 percent from 40.0, so a markdown would stack on a cost increase. Hold price and see the Watch list. - > Northwest grew only 1.5 percent; Seattle had five days with more than a tenth of an inch of rain that week. Per the weather playbook, that is weather, not performance. Southwest (+0.9 percent, Dallas dry, highs in the mid-60s) and Central (+1.3 percent, Denver dry) have no weather excuse and are worth a store-level look next week. None of these sentences is in a script, and none could be. Each one holds two script outputs against a rule from a knowledge page: velocity against stock health, velocity against the supplier quote, a regional change against the weather playbook. That is the part of the week that needs a model, and it is the only part that gets one. ### Getting smarter The prompt’s last instruction is to capture any business fact the knowledge pages did not already state. The agent found one: a convention about what counts as gaining in the second week of December, and a rule about categories whose supplier quote moved by more than ten percent. What the agent captured after the review > Weekly merchandising review convention: in December, week-over-week chain revenue growth of roughly 4 percent in the second week (the week of 2025-12-08 ran +4.1 percent, $4,688,138 against $4,500,609) is the normal build toward the peak, so a category has to beat that build to count as gaining. Categories whose December supplier quote (Blue Harbor) raised cost by more than 10 percent (Personal Care +11.9, Batteries & Electronics +13.9, Beer +13.4, Baking Supplies +14.5, Flowers & Plants +14.8) should not be promoted or discounted until the quote is renegotiated, whatever their velocity says. Stock health bands are nearly uniform across categories on the current snapshot (about 3.5 percent Out of Stock and 13 to 15 percent Critical Low everywhere), so a category’s band counts only mean something relative to that baseline. Captured as business knowledge and placed in the review queue. Once it is promoted to a knowledge page, next Monday’s run reads it alongside the seasonality calendar, and the convention does not have to be rediscovered. Feedback on the review itself follows the same path: a thread on the asset ([307](https://plexara.io/learning/assets/feedback-that-becomes-knowledge)) or on the prompt ([403](https://plexara.io/learning/prompts/sharing-prompts-and-feedback)) becomes a correction the next run applies. ### In the portal The prompt has a page of its own, where it is read and its arguments checked before a run; the scripts have theirs, with the schedule, the run history, and the Failing tile that says whether Monday went well. [Image: A prompt’s page in the portal, with its details, arguments, and content.] A prompt page in the portal, where the review prompt is read and its arguments checked. Script references are attached by the agent and served with the prompt; the page’s own attachment control is for reference material. ### The scripts, on a Monday The review’s three scripts sit on the Scripts page beside every other automation the owner keeps, each with its cadence and the outcome of its last run. [Image: The Scripts page in the portal: each script with its schedule, next fire, and how its last run went, with Scripts, Scheduled, and Failing tiles above the list.] The three review scripts on the owner’s Scripts page, beside the rest. The Failing tile is the number most people open this page for; on a good Monday it reads zero. ### The division of labor, realized Lesson 601 opened the series with a rule: do not spend AI on what a script can do, do not write a script when the agent can write it, and spend the model on judgment about the data. This is what the rule looks like on a Monday morning. The division of labor, realized 13.7 s of platform time across the three runs: 3,605 + 8,231 + 1,856 ms 0 queries the agent wrote to produce the review 5 knowledge pages read before any judgment was made Mondays 7:00 when the margin dashboard refreshes itself, Los Angeles time The scripts did the data work; the model did the judgment; neither is rebuilt next week. The prompt runs again with a new week_start, the scripts run again with fresh data, and the review starts from the version that already works. That is the rule [601](https://plexara.io/learning/automations/do-not-spend-ai-on-what-a-script-can-do) opened the series with, carried through to a Monday morning. ### The end of the series Six lessons, three scripts, one prompt, one review. The agent wrote the code once, and from now on it reads the outputs and forms a view. The team gets the review; the owner keeps the scripts; the knowledge graph keeps what each week teaches. The end of the numbered curriculum Six series, from what a token is to a weekly review the agent runs on the business. The agent was the developer during the sessions that produced the scripts and the analyst on the Monday that read their outputs, and it gets better at both with every session, because the scripts, the prompts, and the knowledge persist. Start anywhere from the [learning index](https://plexara.io/learning); the insights archive continues from here. ### Key terms Five terms close the series and the numbered curriculum. Key Terms Referenced script attach_script A managed script a prompt names, so serving the prompt carries the script’s contract and last successful output. Attached by the agent; resolves for the script’s owner. Contract What a served or fetched script reveals: name, description, typed parameters, whether a run would be admitted, its schedule, and its last successful run. Never the source. Feed A script output written as rows, under a stable name, that another document or an agent reads: here the JSON the review was built from. Action item A recommendation in the review (promote, discount, discontinue or renegotiate, watch) carrying the figure that justifies it and the script output it came from. Division of labor The rule the series runs on: a script for the deterministic part, the model for writing it and for judgment about its output, the knowledge graph for the rules the judgment applies. On this page [Previous 605 - What a run may do, and the record it leaves](https://plexara.io/learning/automations/what-a-run-may-do) ### Related reading integration [Integration 110 - Is MCP just an API wrapper? MCP is not a replacement for your APIs and not a thin proxy. It is an application layer on top, like a website is an application layer on top of its APIs.](https://plexara.io/learning/ai-concepts/mcp-vs-apis) [Integration Two front doors, one governed surface Plexara exposes the same governed surface through an MCP server and a REST API. SDKs connect to both, custom tools extend it, and every path shares one identity, one audit log, and one persona model.](https://plexara.io/learning/insights/the-developer-surface) [Integration Meeting enterprise systems where they are Real enterprise APIs authenticate in messy ways: client certificates, basic auth, second credential headers. Supporting them, while keeping each user activity isolated, is what makes an agent usable at work.](https://plexara.io/learning/insights/enterprise-authentication-and-isolation) --- # Privacy Policy URL: https://plexara.io/privacy/ > Plexara privacy policy. How Deasil Works, Inc. collects, uses, and protects your information. We do not sell or share your data. Legal ## Privacy Policy Effective: February 18, 2026 ### Introduction Deasil Works, Inc. ("Deasil Works," "we," "us," or "our") operates the Plexara platform and the plexara.io website (collectively, the "Service"). This Privacy Policy describes how we collect, use, and protect information when you use our Service. We are committed to protecting your privacy. We do not sell, rent, or trade your personal information to third parties. We do not use your data for advertising purposes. ### Information We Collect We collect information you provide directly when you contact us, request a demo, or engage our services. This may include your name, email address, company name, and job title. When you use the Plexara platform, we process data on your behalf as a data processor. This customer data is stored exclusively for your use and remains under your control at all times. We collect standard server logs and may use analytics tools (such as Google Analytics) to understand website traffic patterns. These tools use cookies to collect anonymous, aggregate information about how visitors interact with our website. ### How We Use Your Information We use contact information to respond to your inquiries, provide requested services, and send relevant communications about the Plexara platform. Customer data processed through the Plexara platform is used solely to provide the services you have contracted for. We do not access, analyze, or use your data for any purpose other than delivering the Service to you. We may access customer data when you explicitly request diagnostic assistance or technical support. Such access is limited to the scope of the support request and is logged for audit purposes. ### Data Storage and Security Customer data is stored in our U.S.-based data centers located in Dallas/Fort Worth, Las Vegas, Los Angeles, Pasadena, Phoenix, and Washington, D.C. All data is encrypted in transit using TLS 1.2 or higher and at rest using AES-256 encryption. We implement industry-standard security measures including access controls, audit logging, intrusion detection, and regular security assessments. Access to customer data is restricted to authorized personnel on a need-to-know basis. We retain customer data for the duration of your service agreement. Upon termination, customer data is deleted within 30 days unless a longer retention period is required by law or requested in writing. ### Cookies and Tracking Technologies Our website uses strictly necessary cookies required for the website to function, such as remembering your display preferences. These cookies do not collect personal information. With your consent, we may use analytics cookies (Google Analytics) to collect anonymous usage data such as pages visited, time on site, and referral sources. This data is aggregated and cannot be used to identify individual users. You can manage your cookie preferences at any time through your browser settings or the cookie preferences panel on our website. Declining optional cookies does not affect your ability to use the Service. ### Third-Party Services We do not sell or share your personal information with third parties for their marketing purposes. We may share information with service providers who assist in operating our business (e.g., hosting, email delivery), subject to confidentiality agreements. The Plexara platform may connect to third-party data sources at your direction. We do not control and are not responsible for the privacy practices of these third-party services. ### Your Rights You have the right to access, correct, or delete your personal information. You may request a copy of the personal data we hold about you by contacting us at support@plexara.io. If you are located in the European Economic Area (EEA), United Kingdom, or California, you may have additional rights under GDPR, UK GDPR, or CCPA respectively, including the right to data portability, the right to restrict processing, and the right to object to processing. To exercise any of these rights, contact us at support@plexara.io. We will respond to your request within 30 days. ### Children's Privacy The Service is not directed to individuals under the age of 16. We do not knowingly collect personal information from children. If we become aware that we have collected personal information from a child, we will take steps to delete that information. ### Changes to This Policy We may update this Privacy Policy from time to time. We will notify you of material changes by posting the updated policy on this page and updating the effective date. Your continued use of the Service after such changes constitutes acceptance of the updated policy. ### Contact Us If you have questions about this Privacy Policy or our data practices, contact us at: support@plexara.io or by mail at Deasil Works, Inc., 121 W. Lexington Drive, Glendale, CA 91203. See also: [Terms of Service](https://plexara.io/terms) --- # Terms of Service URL: https://plexara.io/terms/ > Plexara terms of service. Terms and conditions for using the Plexara platform and services operated by Deasil Works, Inc. Legal ## Terms of Service Effective: February 18, 2026 ### Acceptance of Terms By accessing or using the Plexara platform and the plexara.io website (collectively, the "Service"), you agree to be bound by these Terms of Service ("Terms"). The Service is operated by Deasil Works, Inc. ("Deasil Works," "we," "us," or "our"). If you do not agree to these Terms, you must not use the Service. These Terms apply to all visitors, users, and customers of the Service. Additional terms may apply to specific features or services, which will be presented to you at the time of use. ### Description of Service Plexara is a standards-based data integration platform that provides governed, semantically rich data access for AI agents and enterprise applications. The Service includes data federation, metadata management, contextual enrichment, audit logging, and related capabilities. We reserve the right to modify, suspend, or discontinue any part of the Service at any time with reasonable notice. We will not be liable for any modification, suspension, or discontinuation of the Service. ### Customer Data You retain all rights, title, and interest in your data ("Customer Data"). We do not claim ownership of Customer Data and will not use it for any purpose other than providing the Service to you. We process Customer Data solely on your behalf as a data processor. We do not sell, rent, share, or otherwise disclose Customer Data to third parties except as necessary to provide the Service or as required by law. We store Customer Data in our U.S.-based data centers for your exclusive use. We may access Customer Data only when you explicitly request diagnostic or technical support assistance, and such access is limited to the scope of the request. Upon termination of your account, we will delete your Customer Data within 30 days unless retention is required by applicable law or requested by you in writing. ### Account Responsibilities You are responsible for maintaining the security of your account credentials and for all activities that occur under your account. You must notify us immediately of any unauthorized use of your account. You agree to provide accurate, current, and complete information when creating an account and to update such information as necessary to keep it accurate. ### Acceptable Use You agree not to use the Service to: (a) violate any applicable law or regulation; (b) infringe the intellectual property rights of others; (c) transmit malware, viruses, or other harmful code; (d) attempt to gain unauthorized access to the Service or related systems; (e) interfere with or disrupt the integrity or performance of the Service; or (f) engage in any activity that is harmful, fraudulent, or deceptive. We reserve the right to suspend or terminate your access to the Service if we reasonably believe you have violated these Terms. ### Intellectual Property The Service, including all software, documentation, trademarks, and content (excluding Customer Data), is the property of Deasil Works, Inc. and is protected by copyright, trademark, and other intellectual property laws. Subject to these Terms, we grant you a limited, non-exclusive, non-transferable license to access and use the Service for your internal business purposes during the term of your agreement. ### Service Level and Support Service levels, support terms, and maintenance schedules are defined in your service agreement. We will use commercially reasonable efforts to maintain the availability and performance of the Service. We may perform scheduled maintenance that temporarily affects Service availability. We will provide reasonable advance notice of planned maintenance when possible. ### Limitation of Liability TO THE MAXIMUM EXTENT PERMITTED BY LAW, DEASIL WORKS SHALL NOT BE LIABLE FOR ANY INDIRECT, INCIDENTAL, SPECIAL, CONSEQUENTIAL, OR PUNITIVE DAMAGES, INCLUDING BUT NOT LIMITED TO LOSS OF PROFITS, DATA, OR BUSINESS OPPORTUNITIES, ARISING OUT OF OR RELATED TO YOUR USE OF THE SERVICE. OUR TOTAL LIABILITY FOR ALL CLAIMS ARISING OUT OF OR RELATED TO THESE TERMS SHALL NOT EXCEED THE AMOUNTS PAID BY YOU TO DEASIL WORKS DURING THE TWELVE (12) MONTHS PRECEDING THE CLAIM. ### Indemnification You agree to indemnify, defend, and hold harmless Deasil Works, its officers, directors, employees, and agents from and against any claims, liabilities, damages, losses, and expenses arising out of or related to: (a) your use of the Service; (b) your violation of these Terms; or (c) your violation of any third-party rights. ### Governing Law These Terms are governed by and construed in accordance with the laws of the State of California, without regard to its conflict of law provisions. Any disputes arising from these Terms shall be resolved in the state or federal courts located in Los Angeles County, California. ### Changes to These Terms We may revise these Terms from time to time. We will notify you of material changes by posting the updated Terms on this page and updating the effective date. Your continued use of the Service after such changes constitutes acceptance of the revised Terms. ### Contact Us If you have questions about these Terms, contact us at: support@plexara.io or by mail at Deasil Works, Inc., 121 W. Lexington Drive, Glendale, CA 91203. See also: [Privacy Policy](https://plexara.io/privacy)