Sisense Agentic Platform: Vision & Prototype

Prototype Home: the assistant offers starting intents - embed intelligence, connect data, visualize, set up an AI analyst, alerts, metrics
Open the prototype (opens in a new tab)

Opens in a new tab. Desktop browser, 1280 px or wider. Access password on request.

Overview

In early 2026 I wrote a working paper on where analytics platforms go once AI agents become the main interface to data. Its argument: the platform turns into an intelligence layer that agents query - governed metrics, analytical reasoning, and decision signals that product companies build into their own software.

SAINI (an internal codename) turns that paper into the platform itself: the Sisense brand shell, a sample company’s data, and a scripted assistant.

What this prototype is

A working prototype, not a polished demo. The data is fictional, the assistant follows prepared scenarios, and a simulation engine keeps signals and agents moving so the system behaves like a live one. Depth follows the questions the team needed to settle.

Its role in the product organization:

  • One place for the plans. AI-native and agentic ideas from separate documents and conversations, brought together and made visible.
  • Hands-on validation. Ideas tried and challenged while they are still cheap to change.
  • A shared reference. Product, design, and engineering plan the roadmap from the same tangible material.

My role

I wrote the concept paper, defining the product vision, information architecture, and interaction model. Then, based on the ideas elaborated there, I built the prototype myself with Claude Code, so it could serve as a grounded asset for future product and strategy discussions.

The concept

Three ideas from my concept shaped the product structure.

The platform as an agent

In a multi-agent product, analytics becomes one specialized agent alongside the customer’s finance, CRM, and support agents.

  • Capabilities as agent tools. Querying a metric, detecting an anomaly, root cause analysis, forecasting - exposed through MCP-style interfaces and discoverable through A2A orchestration.
  • Two layers underneath. A decision engine does the deterministic analysis that language models are unreliable at; the semantic layer defines what each metric means, so every agent works with the same business truth.
  • The customer orchestrates. The orchestration layer usually belongs to the product company, and business actions stay in its own agents.
User / Product AI Assistant Agent Orchestrator Finance Agent CRM Agent Analytics Agent (Sisense) Support Agent Decision Engine Semantic Metrics Layer Data Infrastructure
Fig. 1 - Reference architecture: the platform as a specialized analytics agent inside the customer's multi-agent system.

From signal to action

AI systems will increasingly act on analytics results automatically. I split that loop between two owners.

Detect Metric anomaly identified. Analyze Root cause investigation. Recommend Action trigger produced. Execute Domain agent acts. Measure Feedback loop closure.
Fig. 2 - The decision loop, from a detected anomaly to a measured outcome.
  • The analytics agent monitors metrics, finds anomalies and their root causes, and emits a structured decision signal: the insight, a confidence score, and the reasoning needed to choose an action. It does not execute the action.
  • The customer’s agents decide under their own policy layer, act, and measure the outcome.
  • The feedback loop returns outcomes to analytics, so it learns which recommendations work and future signals get better.

The split keeps accountability clear: the platform owns analytical truth and reasoning quality, the customer owns business actions and risk governance.

Sisense Analytics Agent 📈 Metric Monitoring 🔍 Root Cause 📡 Generates Structured Decision Signal Insight + Confidence + Reasoning Customer Infrastructure ⚙️ Agent Orchestrator + Policy Layer Customer Domain Agent 🎯 Business Action 📋 Outcome measurement Feedback Loop
Fig. 3 - Who owns what: the analytics agent produces the signal, the customer's infrastructure acts on it and reports the outcome back.

Onboarding built on proof

I framed onboarding as a sequence of proofs, each for a different persona: architecture fit for the builder, trust in governed metrics for the semantic owner, business value for the outcome owner.

Architecture Fit (Builder) Ship one embedded agent capability fast. Trust & Governance (Semantic Owner) Prove one governed metric and inspect the reasoning trace. Business Leverage (Outcome Owner) Produce one high-value, reusable decision signal. Wow Moment Trust Moment
Fig. 4 - Onboarding as a sequence of proofs, one per persona.

In the prototype, this shaped the entry point: the first screen asks for your role, and Home adapts its headline, starting flows, and the assistant’s tone to it.

From concept to interface

  • Agents in two modes. Monitors watch continuously and produce signals; assistants work in conversation. The platform’s own assistant is one of them.
  • Signals as the main output. Each carries its reasoning, evidence, and a suggested response.
  • The semantic layer as the control point. Agents, dashboards, and assistants use the same governed models and metrics.
  • Code next to the visual view. Models, metrics, dashboards, widgets, and governance rules open as code, so AI-generated configuration stays readable and reviewable.
  • Governance on the assets themselves. Models, metrics, data sets, agents, and signals each carry their governance status.
Signal stream - signals produced by monitor agents, each with its lifecycle stage and status

AI as the main path

Early feedback was uncomfortable and useful: on paper the platform was AI-native, in use it felt UI-first. The assistant sat at the side, and AI had become the fallback. The second half of the work turned that around:

  • Assistant first. The panel got visual priority and the first word on every screen.
  • Guided flows. Every starting action on Home is led by the assistant. Upload a CSV, and it builds the data set, infers the model and its joins, suggests metrics, and offers dashboards, signals, and a monitor.
  • Memory. Sessions keep their history, remember paused flows, and leave a card for everything created.
  • Full manual control. Power users need it, and people who delegate still want to check what the AI did.
Data model schema with the assistant proposing joins - apply all or review each one - next to the manual diagram editor

Outcome

The prototype was tested both inside the company and with external users, and the response was strong. Participants understood the product’s value better than with the existing platform, although the UI and experience were still a rough draft. Feedback also described the approach as innovative and promising.

Within the company:

  • Engineering directors said that the product vision, and where the company should be heading, had “finally” become clear to them.
  • The leadership team noted the coherence of the vision and its strategic importance, adopted it as the strategic direction for the platform, and approved the prototype as the product team’s working tool for developing that direction further.
Open the prototype (opens in a new tab)

Opens in a new tab. Desktop browser, 1280 px or wider. Access password on request.