Highlights

 

Time to try some demos of MPAI standards

 

  • Thalia: A Demonstration of AIF Composability

MAS-App lets anyone talk to a speaking avatar, ask it a question about a picture, have it translate what they say, or hold a conversation in which it reads their voice and face and answers with matching emotion. It runs in a browser or on the desktop, served by a machine anyone can install, with open AI models running locally: no cloud AI service is involved.

Thalia is not a product. It is a demonstration, in running code, that AI applications can be assembled from standardised, interchangeable components under the MPAI AI Framework (MPAI-AIF) standard – the same approach that underpins 19 MPAI standards developed so far. MAS-App is built on the reference software of MPAI-AIF V3.0, and everything below follows from that one design choice.

  • Reusing components, not rewriting code

Under MPAI-AIF, an application is not one block of software: it is a set of AI Modules (AIMs) connected to each other and described by Metadata rather than by program code. Each AIM’s function and interface – the Data Types crossing its boundary – is precisely specified, so one implementation of an AIM can be replaced by another that conforms to the same specification, without touching the rest of the application.

MAS-App offers four Applications each built from the MPAI-MMC (Multimodal Conversation) standard. Between them, the four Applications use only seven distinct AIMs – several of them shared by more than one Application:

Speech Recognition and Response and Scene Rendering – itself a Composite AIM combining speech synthesis, face animation, and the AIM that splits the avatar’s intended emotion between voice and face – are written once and reused by all four Applications. Adding a fifth Application is mostly a matter of writing new Metadata that connects existing AIMs in a new way, not writing a new application from scratch.

 

AIM Kind MAD AMQ MAT MPD
Speech Recognition Basic ✓ ✓ ✓ ✓
Entity Dialogue Processing Basic ✓ ✓
Natural Language Understanding Basic ✓
Text and Image Query Basic ✓
Text-to-Text Translation Basic ✓
Personal Status Extraction Composite ✓
Response and Scene Rendering Composite ✓ ✓ ✓ ✓

 

  • Served as MPAI as a Service

Thalia’s client – the browser page or the desktop program a person actually uses – contains no Application at all. It captures speech, typed text, pictures and the camera image, renders the avatar, and otherwise just carries out a workflow it is handed at the start of a session.

That workflow, and everything AI, lives on the server side, reached over the network exactly as the MPAI as a Service (MPAI-MAS) standard specifies. For each session, a Controller – the core of MPAI-AIF – reads an Application’s Metadata, builds its Module from the AIMs it needs, and runs it. This split is what makes the four Applications interchangeable behind one client: a new Application added to the service appears in every client at once, with no new client software, because the client was never told what a Multimodal Conversation or a Multimodal Translation actually is.

 

  • How it can be used

You can use Thalia as a demo by accessing https://thalia.mpai.community. Please be advised that this is a demo implementation running on a limited capability computer. The purpose of the demo is to demonstrate the possibility to build many different applications exploiting the composability offered by MPAI standards. It does not demonstrate the quality attainable with MPAI standards. Higher quality for an MPAI standard implementation depends on the typically proprietary technologies that MPAI standards wrap to enable interoperability.

You can run your own version of Thalia: the service runs on Windows or on Linux, with all its AI models on that same machine, and an installation guide exists for a Linux server. Because the client and the service can be on different machines, a service reached over a network requires a token from its clients and encrypts all traffic – so a person can try someone else’s installation of Thalia from an ordinary browser, without installing anything.

 

MPAI’s AI Tools project: building AI applications out of interchangeable parts

 

Most AI applications today are built as one large, closed piece of software. If you want to change how it recognizes speech, or update its translation engine, you often have to touch the whole system — and you’re usually locked into whatever the original developer chose.

MPAI (Moving Picture, Audio and Data Coding by Artificial Intelligence) has spent its early years building a different model. Instead of one monolithic application, an AI system is assembled from smaller, standardized building blocks — think of them like electrical components that all follow the same wiring standard, so any compliant part can be swapped in for another. MPAI calls these building blocks AI Modules, or AIMs. Because each AIM’s job and its inputs and outputs are precisely defined by a public standard, a conversation module built by one company can be replaced by a better one from a different company, without redesigning the rest of the application.

This idea — the AI Framework, or AIF — has already become the foundation for MPAI’s other work. It now underpins 15 published standards and around 25 real-world use cases: applications like carrying on a spoken conversation with an avatar, monitoring health signals, understanding audio scenes, and — increasingly — the AI systems inside self-driving vehicles.

 

Why this matters

If you build, buy, or simply rely on AI applications, this approach offers something valuable:

  • No vendor lock-in. Because each component follows an open specification, you’re not stuck with one supplier’s technology forever. A component can be replaced by a better or cheaper one that follows the same MPAI standard.
  • Faster, cheaper development. Developers don’t have to build every AI capability from scratch. They can assemble applications from existing, proven components — the way software today is built from libraries rather than written line by line.
  • A real marketplace. Because compliance is precisely defined, multiple companies can compete to offer better versions of the same component, the way multiple manufacturers can make a USB cable that works with any device.

 

The next step: making it easier to actually use

One honest complication: a real application usually needs components and data definitions from several different MPAI standards at once — not just one. For someone new to this ecosystem, figuring out which pieces you need and how they fit together can be confusing.

To fix that, MPAI has launched a new initiative called AI Tools. Its goal is to make everything a developer — or a curious newcomer — needs available in one place, for free:

  1. Ready-made software components (the AIMs themselves), organized clearly by the standard they belong to.
  2. Plain-language and technical specifications explaining what each component does and what data it expects.
  3. The underlying infrastructure needed to actually assemble these components into a working application.
  4. Ready-to-download applications, already built from these components, that anyone can try or run.

These will be available from an online demo server where people can simply try these applications in a browser, without installing anything.

 

Open and free to use

Everything released through AI Tools will be free to access and released under the BSD 3-Clause licence — a standard, permissive open-source licence that allows essentially unrestricted use, including commercial use, as long as the original authors are credited. Other developers and companies are welcome to contribute their own compatible components, as long as they’re released under the same free licence.

Components that a developer wants to sell commercially, rather than give away, can instead go through the MPAI Store, an independent mechanism for distributing verified components to paying customers.

 

In short: MPAI is trying to do for AI applications what standardised shipping containers did for global trade, or what USB did for device connectors — make the pieces interchangeable, so that innovation happens faster and no one is locked into a single supplier.

 

MPAI-AIF V3.0 – an extended AI Framework in the making

 

MPAI-AIF, the AI Framework, is the MPAI standard for the environment in which AI applications built from standard components run. Its Version 3.0 is being written now, in a way unusual for a standard: hand in hand with software that implements it, so that every provision is tried in running code before it is fixed in text. This document explains what the AI Framework is, what Version 3.0 brings, how it is being made, and where it stands.

1          Why an AI Framework

Many AI applications are built as one block: models, the code around them and the data they keep are tied together, and the only way to improve a part is to rebuild the whole. MPAI takes another road. An application is a set of AIMs – speech recognition, a language model, an emotion detector, a speech synthesiser, a scene describer – each specified by an MPAI standard, each implementable by anyone, connected so that the data produced by one is consumed by others.

Such an application needs an environment that builds it from its parts, whoever implemented each part and whatever technology it uses; connects them; runs and controls them; and does so in a way that can be trusted. That environment is the AI Framework.

2          The AI Framework in one picture

Figure 1 – The Reference Model of MPAI-AIF V3.0

Figure 1 shows its parts.

  • The User Agent is the application as a person, or a vehicle, meets it: it decides what to do, obtains data from the real world – a microphone, a camera, a sensor – and delivers data to it – a loudspeaker, a screen, an avatar, an actuator.
  • The Module is the AI part of the application: AIMs connected to each other. A Module is itself an AIM – a composite one – so Modules nest: an AIM of a Module may be made of AIMs in turn.
  • The Controller builds the Module from its description, runs it and controls it. The User Agent and the AIMs deal with it through one interface, the Controller API.
  • Beneath the Controller are the services it uses: the MPAI Store, from which it obtains approved descriptions of AIMs and the software that implements them; Communication, which moves data between AIMs and across time; Storage; and Access to knowledge a Module needs.

A Module is described not by program code but by Metadata: which AIMs it contains, what data enters and leaves it, how the data flows between its AIMs, where each AIM runs, and what to do if one fails. The Controller builds the Module from this description alone.

3          What Version 3.0 brings

Version 3.0 rewrites the architecture of the AI Framework around what two demanding applications need: conversational services with avatars, and the Connected Autonomous Vehicle.

  • Applications are Modules. Earlier versions distinguished AI Workflows from AI Modules. Version 3.0 has only AIMs: an application’s AI is a composite AIM, and AIMs compose at any depth.
  • One interface, with answers an application can act on. The User Agent and the AIMs use one Controller API. A call says not only “done” or “failed”, but also “nothing was produced here”, “timed out”, “no such input”, “not allowed”, “not trusted” – so that an application can tell what did not happen from what went wrong.
  • Data identified by type, never by name. Every input and output is identified by the type of data it carries and a number. Names are for people. This removed a whole class of silent errors in which two connections with the same name collapsed into one.
  • Two ways to run, one framework. In an exchange, the application gives data and receives a response, as in a conversation. In continuous execution, data flows through the Module as fast as it arrives, as from the cameras and radars of a vehicle. The same Module description, and the same Controller, serve both.
  • Data that moves fast. Data need not pass through the Controller: it decides who may reach what, and the data travels on the fastest path it sets up – within a process, between processes, between machines. Large data, such as images and point clouds, travels apart from the small message that describes it. Every message carries a timestamp from one clock. Each input declares what happens when it cannot keep up: wait, or keep only the newest data.
  • Memory with rules. Storage is treated as communication across time. Each stored item carries who wrote it, when, who may read it and how long it may be kept – rules set by its writer or by a designated AIM, and enforced by the framework. Everything that enters and leaves a Module can be recorded, and a record can be played back into the Module: the same record serves testing, debugging and audit.
  • AIMs anywhere. An AIM can run on another machine – a language model on a computer with a graphics card, a sensor processor in a vehicle’s electronic control unit – under the Controller of its Module, as if it were local.
  • Failures handled by policy. When an AIM fails, the Module’s description says what happens: stop, carry on without it, or retry. The application is told, and can act according to its context: a conversation can go on; a vehicle may need to stop.
  • Applications as text. The User Agent is programmed in a Workflow Description Language: a short, readable text saying what the application does, step by step. A client that interprets it can run any application without new software.
  • The Store as guarantor. The MPAI Store approves the description of each AIM implementation against what the standard specifies and records the fingerprint of its software.
  • Zero Trust that can be met. Nothing is trusted because of where it runs. Before any AIM runs, the Controller verifies its identity, its credentials, and that its software and models are exactly those approved. A machine that runs AIMs for a Controller proves, through a root of trust in its hardware, what software it runs. Every decision goes into a tamper-evident log. The identities, credentials and protocols come from another MPAI standard, the Portable Trust Framework (MPAI-PTF).

4          How it is being made

Version 3.0 is developed together with its reference software. The work proceeds in phases. Each phase is first specified – what it will build, and how success will be judged – then built, tested and reported. Automated tests check the whole framework at every step, so that nothing that worked stops working unnoticed. What running code shows – a provision that is right, one that is wrong, one that is missing – goes back into the text.

The phases so far have built the foundations – the test system, the Metadata, the Controller API, fast communication, AIMs on other machines, storage with rules, and records – and then Zero Trust with MPAI-PTF.

Running code has already corrected the text more than once. Two examples:

  • The published text identified inputs by name. When an implementation did so, a Module in which two different inputs had the same name silently fed both from one source, and the result looked plausible. Version 3.0 identifies inputs by data type and number.
  • The published text declared components “trusted” because of where they are, and in another chapter required that nothing be trusted because of where it is. Version 3.0 states where verification is made, and how an implementation meets the requirement – which the reference software now does.

The work has also tested MPAI-PTF, whose first implementation this is, and has given its authors a list of findings.

The Working Draft of Version 3.0 now contains every chapter of the standard. Where a choice is not yet settled, the Draft does not hide it: it states the question, the alternatives, which one the reference software takes and why, and what will settle it. Among the questions open today:

  • whether a Controller should manage other Controllers, as the subsystems of a vehicle – each with its own timing, failures and safety certification – may need;
  • which of the ways of moving data between machines the standard should specify, and which to leave to implementations;
  • how the clocks of Controllers on different machines are kept comparable;
  • how each client of a service is identified, and how finely each message between machines must be protected.

When a choice is settled, its text replaces the options. The standard is published when every provision is substantiated by running code.

5          What runs today

The reference software already runs:

  • the four Applications of MAS-App – conversation, questions about pictures, translation and affective dialogue with a speaking avatar – on Windows and on Linux, reached from a web browser;
  • AIMs on other machines, under the Controller of their Module, in exchanges and continuously;
  • a synthetic drive – camera frames, the vehicle’s position and orientation, satellite positioning – recorded at the input of the first stage of a vehicle’s Environment Sensing Subsystem and played back into it, every message received as recorded;
  • Zero Trust from end to end: every AIM verified before it runs, AIMs inside a package verified through it, a Controller and a remote machine trusting each other only after each has proved what it runs – so far through a simulated hardware root of trust – and every decision in a tamper-evident log.

6          Taking part

The AI Framework is open to anyone who implements it or builds on it. MPAI welcomes those who want to review the Working Draft, try the reference software, implement AIMs – including AIMs of the Connected Autonomous Vehicle – or take part in the development of MPAI standards.

You can find an implementation of the AIF at https://github.com/mpai-community/mpai-sw

 

Meetings in the October 2026 cycle.