Plexara
Portal Tour
See the Platform, Concept by Concept
Find Anything With One Search
An agent should not need to know the platform’s shape before it can ask. One search spans every source a role can reach and returns a balanced set that keeps each source visible, so answers are grounded in what actually exists instead of a guess at the data.
One Query Across Every Source
Why it matters
Knowledge scattered across a catalog, memory, saved work, prompts, and connected APIs is knowledge nobody can find. Discovery has to be a single surface, or agents guess at the data instead of grounding in what exists.
How it works
One query fans across the DataHub catalog, canonical knowledge pages, memory, captured insights, saved assets, prompts, API endpoints, and connections, grouped by source with a coverage summary and balanced so the largest source never drowns the rest. Ranking blends vector similarity with exact keyword match, and degrades cleanly to keyword-only when no embedding provider is available. It is the same federation your agents call, over one endpoint.
Business Context Attached to Every Answer
Cross-enrichment is the platform differentiator. Instead of the assistant making five round-trips to understand one table, the platform attaches the surrounding context to the result automatically, so every answer arrives already grounded.
Five Round-Trips Collapse Into One
Why it matters
Understanding a single table, its owners, tags, quality, deprecation, and glossary, normally takes a describe call plus several catalog lookups, each adding latency and depending on the agent remembering to ask.
How it works
The enrichment middleware intercepts a Trino, DataHub, or S3 result and attaches the matching context: owners, tags, quality score, deprecation with its replacement, glossary terms, column meanings, and the knowledge pages that document the entity. A deprecated table surfaces its warning front and center. It runs on a measured byte budget, and repeat references within a session collapse to a pointer so context never crowds out the data.
Enrich Third-Party Tools Without Code
Why it matters
The same idea, one source’s response carrying another’s context, should apply to proxied third-party tools, but hard-coding it per tool does not scale.
How it works
A declarative rule engine attaches warehouse and catalog context to any proxied tool response: a predicate (always, or when the response contains a value), a source operation against DataHub or Trino, JSONPath bindings over the arguments, response, and caller, and a merge strategy for where the context lands. A dry-run previews the merged response without side effects, and a rule failure attaches a warning rather than failing the call.
Watch Your Semantic Search Stay Healthy
Relevance search across every corpus only works if the embeddings behind it are current. Embedding runs off the request path, so a provider outage or a model change can quietly degrade ranking to keyword-only with nothing but a log line. This dashboard is where that becomes visible.
Coverage and Failures Across Every Corpus
Why it matters
When indexing silently falls behind, semantic search degrades and no one notices until results get worse. Operators need one place to answer whether indexing is healthy, what is covered, and what failed.
How it works
A single admin dashboard reports the embedding provider, model, and dimension, then a health verdict per corpus (API endpoint vectors, tool descriptors, memory, and more) with real indexed-of-expected coverage. It charts throughput and embed latency, lists in-flight and retrying jobs, and groups open failures by error signature with self-resolving triage and one-click re-index. It polls every few seconds and shows real index state, never mocked numbers.
Memory, Insight, Knowledge: One Promotion Pipeline
Everything the platform learns is a memory. The memories that assert something others need become insights, proposals that wait for review. Whoever holds the apply_knowledge capability promotes the good ones into knowledge: business facts become wiki-linked knowledge pages, technical facts go to the DataHub catalog. This is where that pipeline runs.
The Raw Substrate, Captured Automatically
Why it matters
Stateless assistants start every session from zero. Without a place to accumulate what was learned, the same context gets re-explained on loop and the same mistakes get repeated.
How it works
Memory records what sessions surface, classified by type (preference, event, business knowledge, operational rule, schema or entity fact) and scoped to you. Recall blends vector 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 even captured as a correction automatically.
A Proposal Awaiting Review
Why it matters
Letting an assistant write to the shared catalog unattended is how trust evaporates. The facts worth sharing have to route through a human before they become 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 with a status: pending, approved, applied, or rejected. Insights are the only memory that crosses between users, and categories span correction, business context, data quality, usage guidance, relationship, and enhancement. A pending count is badged so nothing sits unreviewed.
Reviewed Insights Become Canonical Knowledge
Why it matters
Approved knowledge is only useful if everyone, and every agent, can find it and trust it. It has to land somewhere durable, not in a reviewer’s head.
How it works
A reviewer with the apply_knowledge capability approves an insight and promotes it: business and domain facts become wiki-linked knowledge pages that cite the exact data they describe, technical and entity facts are written to the DataHub catalog. Every promotion is recorded as a changeset with one-click rollback, and unified search surfaces the result everywhere.
Turn Any REST API Into Governed Tools
The assistant 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 securely and calling it under per-role rules. Ten APIs do not add a thousand tools, and everything rides the same audit pipeline as native data access. Explore the full API.
Whole APIs Behind Four Tools
Why it matters
Generating one MCP tool per endpoint explodes the tool catalog: ten APIs would add a thousand tools an agent has to sort through, wrecking tool selection.
How it works
A connection points at an API and its OpenAPI spec lives in a versioned catalog that many connections can share. The entire surface is served through four tools: browse the spec sections, list a section’s operations, read one operation’s exact schema, and invoke it. Adding APIs never inflates the catalog, and large or binary responses stream straight to an asset instead of into the answer.
Find the Right Endpoint, Watch the Traffic
Why it matters
An agent should find an operation by what it means, not by guessing exact names, and an operator should be able to see where outbound calls are going.
How it works
Every endpoint is semantically indexed so operations rank by intent, not keyword. Outbound calls flow through the same auth, persona, and audit pipeline as native tools, and the gateway view charts the connection-to-operation traffic as a flow with an inbound-versus-outbound health split and breakdowns by status, method, and caller. A plain REST route exposes the same connector to non-agent clients like NiFi, Airflow, and scripts.
Federate Any Other MCP Server
The platform reaches outward as well as inward. Connect an upstream MCP server and its tools become native, governed tools inside the platform, with your warehouse and catalog context woven into their responses.
Upstream Tools, Under One Access Model
Why it matters
Every MCP server your team adopts is another endpoint, another auth model, another silo. Agents end up juggling connections instead of getting one coherent surface.
How it works
A gateway connection proxies an upstream MCP server and re-exposes its tools under a local prefix, so they appear alongside native tools and obey the same persona rules, audit, and cross-enrichment. Test a connection before saving, refresh its tool catalog when the upstream changes, and the assistant’s tool list updates live for everyone connected.
Sign In the Way Each Upstream Demands
Why it matters
Real upstreams authenticate in incompatible ways, and some, like hosted vendor MCP servers, require a human browser sign-in rather than a static token.
How it works
Connections support bearer tokens, API keys, HTTP basic, OAuth 2.1 with either machine-to-machine or browser sign-in and PKCE, and client-certificate mTLS. Tokens and secrets are encrypted at rest, an OAuth connection refreshes itself silently so scheduled work keeps running, and a certificate’s expiry surfaces as a badge before it bites.
Governed, Typed, Testable Tool Access
Every tool is a typed endpoint governed by role. Personas map identity to exactly the tools and connections a role may reach, default-deny, and each tool is fully inspectable and executable, so you can see and test precisely what an agent can do.
Fail-Closed Access by Role
Why it matters
Access defined by low-level permissions drifts from business reality, and anything not explicitly denied tends to leak. Roles should get exactly what they need and nothing else.
How it works
A persona maps upstream identity-provider roles to tool allow and deny patterns and a connection allowlist, plus context overrides (a description prefix and an agent-instruction suffix) that tune behavior per role. It is fail-closed: unauthorized tools and connections are not even visible to the agent, which cuts token waste and blocks access before it reaches the data layer.
Every Tool, Typed and Documented
Why it matters
A tool you cannot introspect is a tool you cannot govern. Schema and access visibility are prerequisites for safe operation.
How it works
The tools view lists every registered tool grouped by connection (Trino, DataHub, S3, platform, and gateway-proxied MCP), each with its description, JSON input schema, and the exact per-persona access rule that decided who can call it. An editable override lets an admin tune a tool’s description in place.
Execute Any Tool From a Form
Why it matters
Debugging tool behavior by asking an agent to call it is indirect and slow. You want to run the tool directly and see the exact response.
How it works
The Try It tab generates a dynamic form from the tool’s schema, runs it against the live source, and renders the result, keeping a timestamped history of test calls with replay. The Visibility tab lets you toggle a tool in the platform-wide deny list and preview whether a given persona can reach it before committing.
An Audit Log You Can Actually Query
Grep over log files is not an audit system. Every tool call, query, and error flows through structured audit middleware with indexed fields, so platform health, per-node status, and any single interaction are all a search away.
Per-Node Health, Scraped Live
Why it matters
Incident response starts with knowing whether the stack is degraded and which node is the problem, without SSHing into boxes.
How it works
The health view reports per-node uptime, CPU, resident memory, heap, and goroutine counts across the platform fleet, scraped from Prometheus, with a clear status per node. Alongside it, MCP and API-gateway activity views chart call volume, success rate, duration percentiles, and error trends over configurable windows.
Every Call, With Full Parameter Detail
Why it matters
When something goes wrong you need the exact call, arguments, response, persona, and session, not a sanitized summary.
How it works
Event search indexes every tool invocation, filterable by user, tool, status, and time, exportable as CSV or JSON. Any row opens a detail drawer with identity, execution, transport sizes, and the full request parameters, and distributed tracing lets you follow one request through sign-in, context-gathering, and the underlying data call.
AI Output as Durable, Rendered Artifacts
Every chart, dashboard, and report an agent produces is saved with provenance, which tool calls produced it and which datasets it drew from, and rendered natively in the portal. Assets are not ephemeral chat output; they are versioned resources that persist, render, and carry lineage.
Dashboards That Render, Not Screenshots
Why it matters
Static images go stale and PDFs do not drill down. Stakeholders want to click into a number and see current data.
How it works
Agents emit HTML and JSX that render as interactive components with live state, SVG as crisp vector graphics, Markdown formatted with diagrams, and CSV as sortable tables, all inline in the portal. Every asset keeps preview thumbnails and full version history with revert.
Full Lineage on Every Artifact
Why it matters
An asset without lineage is a claim you cannot verify. When a number is wrong, the fix starts with where it came from.
How it works
Asset detail shows the originating session, the tool calls executed, the datasets queried, and the full version history. Admins get a platform-wide asset view across every user, filterable by type, owner, and connection, to audit what was produced and what it drew from.
Curate and Share, With Provenance Intact
Collections turn a loose set of artifacts into titled, sectioned deliverables, and the sharing system carries them to teammates or the outside world without losing governance.
Named Briefings, Not Buckets
Why it matters
Assets scattered across sessions are not a deliverable. A collection turns them into a titled, described, ordered package: a board packet, a weekly review, onboarding material.
How it works
Create a collection, add assets from any session, arrange them into sections with markdown descriptions, and it renders as a structured document with configurable thumbnail sizes. Each asset stays clickable to its full provenance and back.
Teammates or a Branded Public Link
Why it matters
Good work buried in a personal workspace might as well not exist, but sharing cannot mean losing control of who sees what.
How it works
Share with specific teammates at viewer or editor access, where the picker suggests known people by name, or mint a time-limited public link with a branded, dark-mode-aware viewer, an expiration notice, and a confidentiality banner. Assets and collections both filter by Mine, Shared, or All.
A Human Feedback Loop That Becomes Knowledge
People and the assistant work on the same artifacts. Reviewers, including subject-matter experts who never touch an agent, leave structured feedback in place, an agent resolves it into lasting knowledge, and the author signs off, all tracked end to end.
Structured Feedback, Anchored in Place
Why it matters
Corrections relayed over email lose the context they refer to. Feedback should live on the artifact, pinned to the exact passage and version it is about.
How it works
A thread targets an asset, collection, prompt, or knowledge page, or a standalone channel, with a kind (comment, question, correction, rating, approval, rejection, suggestion) and a status lifecycle, and it can anchor to a selected passage and the version it was raised against. A hub gathers everything waiting on you with a badge, and one tool lets the assistant review and reply to pending feedback in a single pass.
From Comment to Documented Change
Why it matters
A correction is only useful if it can change something, and the loop closes visibly for both the reviewer and the author.
How it works
A reviewer with apply_knowledge captures a correction thread as a pending insight, which enters the same review pipeline and, once promoted, shows the resulting knowledge or catalog change back on the thread. Validation routes to the author to confirm or dispute, disputing reopens the thread, and sign-off aggregates as signed off by N of M stakeholders.
Prompts as a Governed, Shareable Library
Prompts are typed, parameterized workflows with a real lifecycle and scope, not single-owner snippets. A personal prompt can grow into a team or organization standard through review.
Lifecycle, Scope, and Promotion
Why it matters
Ungoverned prompts mean every analyst reinvents their own, quality drifts, and nobody knows which prompt produced which report.
How it works
Prompts carry typed arguments, tags, and a lifecycle (draft, approved, deprecated, superseded) at personal, persona, global, or system scope. An owner requests promotion of a personal prompt to a persona or global, and an admin approves it through a review queue. All prompts, including built-in ones, are semantically searchable.
Share a Prompt That Actually Runs
Why it matters
Pasting a prompt as text loses its arguments and turns a tool into a snippet.
How it works
Sharing a prompt by email gives the recipient a real, runnable prompt with its arguments intact, invocable by their agent as a shared prompt rather than a flattened copy. The user prompts surface exposes personal, available, and shared prompts with a run button and argument forms.
Enterprise Operations, Grouped and Out of the Way
The plumbing that makes a system operable in production, kept together rather than dressed up: service credentials, a people directory for sharing, uploaded reference material, and a record of every configuration change.
Service Credentials and an Audit of Changes
Why it matters
Programmatic access and configuration edits need the same accountability as everything else, without becoming the story.
How it works
API keys are minted per service with persona scope, an expiration preset, and one-time display, and revocation is instant. Every configuration change made through the admin UI is recorded with its key, action, and timestamp, and admins can even make those changes by asking the assistant, with each change attributed and logged.
People and Reference Material
Why it matters
Sharing is easier when the picker knows your colleagues, and agents work better with reference material a human curated.
How it works
A known-users directory gives the share picker names to suggest, and it grants no access on its own. Resources let people upload SQL templates, runbooks, checklists, and brand assets that agents read during sessions through the standard resource protocol, scoped by persona or shared globally.
