202 - Your first day with Plexara

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.

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.

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 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 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 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, 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.

Every Plexara deployment also ships an interactive MCP 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.

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.

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.

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 promotes validated observations into organization-wide catalog documentation. Both are covered in depth in 206. The summary below is what to expect.

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.

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.

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.