Capability map
The mAIstro platform, end to end.
Every layer, component and service, and what each one does. The orchestrator, agent library, connector fabric and governance kernel ship pre-built; you configure the use cases, the data and the models.
Layer 01
Open →
Application
Dashboards
Composed at query time from a natural-language question. Every figure cites its source and drills to the underlying rows.
Workflows
Repeatable agent sequences with approval gates on the steps that carry risk. Each run is replayable and comparable.
Agent orchestration
Decomposes a request, selects the agents and tools, executes in dependency order and validates the result.
Layer 02
Open →
Platform
Telemetry
Token spend, latency, tool calls and failure modes captured per agent and per run, from the first call.
Reusable results
Every output persists as a queryable object, so downstream agents and analysts reuse it rather than recompute it.
Multi-tenancy
Isolation at the data, permission and model-routing layers. One deployment serves many business units.
Layer 03
Open →
Runtime
Model & tool access
A model router across hosted and local providers, and MCP tool sets against any database. Swap either without re-architecting.
Control plane
PostgreSQL holds tenant state, permissions, the agent registry and full run history.
Storage
Open Iceberg tables you own, readable by any engine — Spark, Trino, DuckDB or your existing warehouse.
Governance
TrustEvery answer carries its inputs, the agents used, the tools called and the approvals given. Review is a click, not a project.
ConsistencyThe same question returns the same answer under the same policy — on every tier and every deployment target.
IntegrityAppend-only audit ledger, role-based access and human-in-the-loop gates. EU AI Act-aligned by construction.
Open→
Differentiators
OptimisationModel routing per agent against cost and latency budgets, rather than one frontier model answering everything.
AgnosticNo lock-in at the model, database, cloud or BI layer, and an open table format underneath all of it.
AccelerationOrchestrator, agent library and connector fabric ship pre-built. First workflow live in two to three weeks.
Open→
Data assessment
Where the data sits, what it can carry, and what has to change first.
Estate discovery
Quality baseline
Evidence trail
Open →
Planning & modernisation
The target design, the order of the moves, and the build itself.
Target architecture
Sequenced roadmap
Delivery at pace
Open →
Deployment & interfaces
Deployment
EU-hosted managed cloud, your VPC, or fully on-prem
Models
Hosted or local providers, selected per agent
Storage
Open Iceberg tables, engine-neutral, client-owned
Integration
MCP tool sets against any database or API
Tenancy
Isolated at data, permission and routing layers
Time to value
First workflow live in two to three weeks
01 · Layer one
The application layer.
Where the platform surfaces to people. Three capabilities that turn a natural-language question into a live dashboard, a running workflow, or a coordinated multi-agent action.
01.1 · Capability
Dashboards
Ask in natural language and the dashboard builds itself, with recommendations on what to look at next. No dashboard templates to maintain, no BI backlog to work through — the question is the dashboard.
In practice
- A CFO can ask “show me DSO drift by customer this quarter” and get the answer, live, with the drill-down already in place.
- Dashboards are composed at the moment of the question, not built ahead of time.
- Every element cites its source; every figure is queryable.
01.2 · Capability
Workflows
Automates processes end to end — the same work done at a fraction of the cost. A workflow is a repeatable, auditable sequence that agents run and humans approve at the points that carry risk.
In practice
- Reconciliation, renewals, exceptions, triage — the shapes of work that never quite fit an RPA tool.
- Each run is a first-class object: reviewable, replayable, comparable.
- New workflows compose from the same agents; you don't hire per workflow.
01.3 · Capability
Agent orchestration
Breaks a request into steps, picks the right agents and tools, runs them in order and checks the result. The orchestrator coordinates specialists so a request of any shape runs as one system.
In practice
- You don't wire agents together by hand — the orchestrator selects and chains them.
- Every run produces a trace: what was called, in what order, with what inputs.
- Add an agent to the roster and every workflow can use it. Retire one, nothing else breaks.
02 · Layer two
The platform layer.
What the capabilities above depend on. Instrumentation from the first call. Every output kept as a reusable asset. Multi-tenant by design, not by retrofit.
02.1 · Capability
Telemetry
Full telemetry out of the box — no separate build required. Every agent call, every tool invocation, every human decision streams into a single pane, so cost, latency and quality are readable from day one.
In practice
- Cost per agent, per action, per workflow — visible as it happens, not month-end.
- Latency and quality tracked per model, so model choice is a data-led decision.
- No separate observability project needed to know what the platform is doing.
02.2 · Capability
Reusable results
Every workflow's output becomes a queryable, auditable asset. Answers don't vanish into a chat window — they land as first-class rows in tables the next agent can read, the next dashboard can chart, and any auditor can inspect.
In practice
- The answer to Monday's question is available for Tuesday's follow-up, without re-running the workflow.
- Downstream workflows compose on upstream outputs — the network effect grows with use.
- Every result is signed, timestamped and traceable to its inputs.
02.3 · Capability
Multi-tenant
Multi-tenant from the ground up — one platform, many clients, with a single-tenant deployment available where isolation is contractual. Tenancy is enforced at the control-plane level, not sprinkled through the code — so scale, isolation and audit are the same story, not three different ones.
In practice
- Regional deployments share the same product, so upgrades and improvements land everywhere at once.
- Tenants can be organisations, business units, or environments — the model is the same.
- Isolation is enforced at the database and orchestrator, not by convention.
03 · Layer three
The runtime layer.
The choices made once, so no project has to make them again. Any model. Any database. Open, client-owned tables. A single control plane holding state and permissions.
03.1 · Capability
Model & tool access
A model router with pluggable providers, and MCP tool sets against any database — swap either without a rebuild. Hosted providers on managed deployments, locally-hosted models where there is no egress. Model choice is a decision per agent, not per tenant; connector choice is a decision per source, not per platform.
In practice
- A frontier model today, a locally-hosted model tomorrow — the agent above stays the same.
- New data sources reach the platform through typed MCP connectors, added in days.
- You are never locked to one vendor's model or one vendor's data stack.
03.2 · Capability
Control plane
PostgreSQL as the control plane, so state and permissions live in one place. A boring, battle-tested database at the centre of the platform is what makes the rest of the choices work.
In practice
- One authoritative place for tenants, agents, workflows, permissions and telemetry.
- No exotic runtime to operate — Postgres skills you already have.
- Backup, replication and disaster recovery are solved problems here, not bespoke ones.
03.3 · Capability
Iceberg
Client-owned tables in an open format, underneath every result. Apache Iceberg means your data stays your data, in a shape any modern engine can read, with time-travel and schema evolution built in.
In practice
- Every table an agent writes is a table you can query from Snowflake, Databricks, Spark, DuckDB, Trino — anything.
- An open format, not a proprietary one — the tables are readable by anything that speaks Iceberg.
- Schema and time-travel are first-class, so “what did we know on the 12th?” is a query, not a project.
04 · Governance
Trust, consistency, integrity.
Three properties the platform holds — always, on every tier, on every deployment. Governance is a first-class layer, engineered into every action the platform takes.
04.1 · Property
Trust
Answers you can take to the board or a regulator without hedging. Every answer carries its evidence with it — inputs, agents used, tools called, decisions made — so review is a click, not a project.
In practice
- Every answer is defensible in front of an auditor without extra preparation.
- Confidence is visible: the platform says when it doesn't know, and shows what would raise the confidence.
- Sensitive actions require the right human at the right approval level.
04.2 · Property
Consistency
The same question returns the same answer — across teams, sites and time. Determinism is a design goal, not a happy accident. When two teams ask the same thing, they get the same answer or a documented reason they don't.
In practice
- Regional teams and central teams operate on the same numbers.
- Version, prompt and model changes are recorded — an answer today is comparable to an answer last week.
- No two dashboards show two different truths for the same question.
04.3 · Property
Integrity
Every figure traces to its source; nothing silently adjusted. When a number changes, the platform says which upstream value moved and when. No orphaned adjustments, no silent overrides.
In practice
- Lineage is a live property of the platform, not a document that gets stale.
- Every change is signed, timestamped and attributable.
- Right-to-erasure and other data-rights obligations propagate through the ledger.
05 · Differentiators
Optimisation, agnostic, acceleration.
Three things mAIstro does that most agent platforms don't — the levers that turn a platform into a return, and the reasons finance and operations teams stay once the numbers land.
05.1 · Differentiator
Optimisation
Moves past reporting the position to improving it. A report tells you where you are; an agent tells you what to do next. mAIstro is built to propose the next action and, where you allow it, take that action.
In practice
- Every workflow ends with a recommendation and, where policy permits, an executed action.
- Human-in-the-loop thresholds are configurable — set them by action, role and amount.
- The measurable delta between the position with mAIstro and without is the KPI.
05.2 · Differentiator
Agnostic
Sits across existing sources, clouds and tools. No rip-and-replace. mAIstro is the layer that spans what you already have — data warehouses, ERPs, CRMs, ITSMs, identity — and turns them into a coordinated system.
In practice
- Existing investments continue to earn — mAIstro coordinates them, doesn't replace them.
- Cloud choice, region choice, model choice — all are yours, all can change over time.
- Adding a new source is a connector, not a project.
05.3 · Differentiator
Acceleration
Collapses the distance from question to decision. Time-to-market is the KPI. The measurable difference is not that answers are better — it is that they arrive in minutes instead of weeks, and that the next action follows.
In practice
- Median time from kick-off to a running workflow: 2-3 weeks.
- Cycles that ran monthly can run daily; cycles that ran daily can run continuously.
- ROI is designed in at scoping, not discovered at year-end.
06 · Service · Data assessment
Know what you have before you build.
Before the first agent runs, mAIstro maps the estate, scores the data and leaves an evidence trail — so what you build next stands on ground you can defend in front of an auditor.
06.1 · Service
Estate discovery
Maps every source, pipeline and owner — a live picture of your data estate rather than a snapshot in a slide deck. Agents crawl what's connectable and interview owners of what isn't.
In practice
- You see the shape of the estate — sources, flows, gaps, orphans — in a week, not a quarter.
- The map stays live: as systems change, the picture updates.
- Owners and stewards are captured alongside systems, so accountability is visible.
06.2 · Service
Quality baseline
Scores accuracy, completeness and lineage across the estate. Not a single “data quality score” — three separate readings, per source, that tell you what to trust and what to fix before you build on top of it.
In practice
- Every source gets three scores, not one, so priorities are legible.
- The baseline informs which use cases go live first — you don't ship a workflow on data that can't carry it.
- Improvement is measurable against the baseline, not against a memory of last quarter.
06.3 · Service
Evidence trail
Every check logged, dated and repeatable. The assessment is not a report; it is a set of running checks. Re-run it any time — the trail shows what changed, when and why.
In practice
- Auditors can inspect the checks themselves, not just a document about them.
- Assessment becomes an operating rhythm, not a one-off exercise.
- The evidence trail becomes the foundation for the audit trail once agents go live.
07 · Service · Planning & modernisation
From assessed to running.
Once the estate is mapped, mAIstro designs the target architecture, sequences the migration and does the heavy lifting — so the move is measured in weeks, not years.
07.1 · Service
Target architecture
Open tables, one control plane. The target is not a diagram — it's a working reference build of your estate on mAIstro, with the same three levels, the same governance, and the same differentiators as any other client.
In practice
- The target is opinionated — Iceberg tables, Postgres control plane, MCP connectors — so decisions are made once.
- Your data stays yours; the shape it lands in is open and portable.
- New use cases plug into the same target — nothing bespoke per project.
07.2 · Service
Sequenced roadmap
Phased migration, no big bang. The roadmap is ordered by ROI and dependency, not by convenience. Each phase delivers a running use case, not a milestone slide.
In practice
- Every phase ends with something in production — the platform earns as it lands.
- Dependencies are made visible so no phase is blocked by a hidden upstream.
- The plan is measured against realised ROI, not planned effort.
07.3 · Service
Delivery at pace
Agents do the migration heavy lifting. Schema translations, data movement, pipeline rewrites, connector authoring — the parts that used to take teams take agents. Humans supervise, decide, approve.
In practice
- Time-to-first-workflow measured in weeks, not quarters.
- Your team's time is spent on decisions, not on hand-coded migrations.
- The knowledge transfer is embedded — your team runs the platform after handover.