Four lines, described by function.
Every entry below states what it is for, how it is built, how it is secured, and whether you can have it. Three of those four answers are more than most technology companies publish. The fourth is the one that matters.
Before you read the list.
Nothing here is generally available. This division builds for the MIDIOS group first; external availability is announced when the internal version has earned it, and not before.
Internal product names are not published. That is a deliberate decision, not an oversight — naming systems before trademark clearance and before they are offered commercially creates exposure with no benefit. Each line is therefore described by what it does.
| Internal | Running inside MIDIOS today, operated by this division. Not offered externally. |
|---|---|
| Development | Being built. Has a working core; not complete, not deployed outside the group. |
| Research | Under investigation. May never ship. Permanently labelled until it does. |
The platform.
Open any line to inspect it. Without JavaScript every panel is simply open — nothing here is hidden behind an interaction.
-
The problem. Automation either asks permission for everything, which makes it useless, or asks for nothing, which makes it dangerous. Most organisations pick one and live with the cost.
Purpose. Run routine work unattended while holding material work — money, contracts, external communication, irreversible change — behind a named human approval, and keep a record that settles the question of who decided what.
Who it is for. Operators and owners who need the work done without signing a blank cheque to a machine.
Capabilities.
- Risk tiering by policy the operator writes, not by model judgement
- Approval gates that cannot be satisfied by the system itself
- Scoped, short-lived credentials issued per action
- Append-only decision log covering proposal, approver, payload and result
- Defined reversal path required before any unattended execution
- Interface
- An operator console — what ran, what is waiting, what failed, what it cost — readable without an engineer present.
- Architecture
- Event-driven. Proposals are records before they are acts. Classification, approval and execution are separate services with separate credentials, so no single component can both decide and do.
- Integrations
- Connects to systems already in place through their APIs. Designed as a layer over an existing stack, not a replacement for it.
- Security model
- Least privilege per action, secrets in a managed store, approval identity bound to a real account, immutable audit. Detail provided under NDA, not published.
- Documentation
- Internal. Published documentation follows first external deployment.
- Deployment
- Currently internal to the MIDIOS ecosystem only.
- Demo
- Request a demo of this line
-
The problem. An agent demo is easy. An agent that runs every day, fails safely, and can explain itself three weeks later is a different engineering problem, and it is the one that matters.
Purpose. Run multi-step agent work reliably: durable state, retries that do not duplicate side effects, tool calls that are scoped and logged, and a trace an operator can read.
Who it is for. Technical leaders and operators putting agent work into production rather than into a pilot.
Capabilities.
- Durable runs that survive restart and resume where they stopped
- Idempotent tool calls keyed so a retry updates rather than duplicates
- Structured capture of inputs, tool selection, arguments and results
- Deterministic replay of any past run from recorded inputs
- Cost and escalation-rate metrics per run
- Interface
- A run view: trace, timeline, gate status, retries, cost. Plus a plain operator summary for people who do not want the trace.
- Architecture
- Queue-backed workers with persisted run state. Model calls are one tool among several, not the control flow — the orchestration is deterministic and inspectable.
- Integrations
- Model-provider agnostic. Tools are declared with explicit scopes; adding one is configuration plus a permission decision.
- Security model
- Sensitive payloads referenced by hash in telemetry rather than copied. Tool permissions are per-run, not ambient.
- Documentation
- In progress alongside the build.
- Deployment
- Internal pilot. Not offered commercially.
- Demo
- Request a demo of this line
-
The problem. Four systems, four versions of the same number, and a monthly meeting spent reconciling instead of deciding.
Purpose. One modelled layer that people and machines both read from, rebuilt on a schedule, with every published figure traceable to its source.
Who it is for. Owners and operators who need numbers they can act on, and agents that need numbers they can reason over.
Capabilities.
- Read-only extraction from existing systems through their APIs
- Raw landing preserved; the model built on top and rebuildable from raw
- Version-controlled definitions named in the output
- Quality tests that block publication rather than warn after it
- Column-level lineage from report back to source field
- Interface
- Dashboards and scheduled reports over the modelled layer. Nothing downstream re-derives its own version of a figure.
- Architecture
- Extraction → raw landing → conformed entities → reporting model → publication, with tests gating the last step.
- Integrations
- Accounting, CRM and operational systems through their published APIs. Spreadsheets where a spreadsheet is genuinely the source of truth.
- Security model
- Least-privilege read scopes, credentials in a managed secret store, no write access to source systems by design.
- Documentation
- In progress.
- Deployment
- Internal. External availability not announced.
- Demo
- Request a demo of this line
-
The problem. The tools an organisation already pays for do not talk to each other, so a person becomes the integration — copying, pasting, re-keying and forgetting.
Purpose. Make the existing stack behave as one system, without a migration and without asking anyone to abandon a tool that works.
Who it is for. Businesses with a stack that grew by accident and now costs more to operate than it should.
Capabilities.
- Connector per system, versioned and independently deployable
- Normalised event shape so downstream logic is source-agnostic
- Schema-drift detection that errors instead of writing nulls
- Replay and backfill without touching the source system
- Queue depth and failure surfaced to an operator, not buried in logs
- Interface
- Connector health, queue depth, last successful sync, and what is stuck — on one page.
- Architecture
- Connectors are independent; a failure in one does not take the others down. State is held between them, not inside them.
- Integrations
- Whatever is in place. The assessment establishes what can be integrated through supported APIs and what cannot.
- Security model
- Credentials scoped per connector, rotated, never shared across systems.
- Documentation
- Per-engagement. A published connector catalogue follows first external deployment.
- Deployment
- Available as engagement work. Not a self-serve product.
- Demo
- Request a demo of this line
The honest next step.
If one of these lines describes a problem you have, the useful move is not a demo request — it is a technical assessment, where we look at your systems and write down what is actually wrong. A demo of something you cannot buy yet is entertainment.