Skip to main content
Plexara

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 from the production deployment.

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 APIs in that estate, including card settlement, Google Analytics 4, Hootsuite, and Salesforce, are listed on the API connections page.

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

    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.

Automations

A Governed Report Library the Business Extends

A legacy reporting service was rebuilt as a library of parameterized reports the business runs on demand and extends with automations of its own. Four of them run on a schedule, the rest when someone asks, and Plexara can alert a team channel when a run fails. Plexara has been modeled running thousands of automations with little scaling work. In production, automations replace legacy pipeline flows and reporting services, and their owners approve what each one does in plain language.

A reporting service, rebuilt as a library

Sales, inventory, loyalty, discount, and card-reconciliation reports that used to run in a separate reporting service are now parameterized automations anyone with access runs on demand. Each was tied out against the old job before it replaced it, and every difference is written into the report itself.

A weekly ERP dashboard, emailed

Every week an automation reads the sales orders in the ERP and emails a dashboard of them to the people who plan around it. It belongs to client staff.

A dashboard rebuilt every morning

A seasonal business dashboard is rebuilt from point-of-sale data before the day starts, and the link goes to the team that runs that business.

An hourly location import

Each hour an automation reads the location file the business maintains and imports what changed into the point-of-sale platform. It replaced a legacy pipeline process that had been stopped.

A card-settlement mirror

Card-settlement records stay current in the ERP warehouse through an automation that reads the processor's reporting API. It replaced a legacy pipeline flow that had been paused, and the reconciliation reports read from it.

The business extends it

Client staff own automations of their own on the same governed platform: inventory transfer reports that break every repack into its contents, the weekly ERP dashboard, and the morning dashboard among them.

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 what it knows with everyone.

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.