1 Introduction
Moving Picture, Audio, and Data Coding by Artificial Intelligence (MPAI) is an international unaffiliated not-for-profit organisation having the mission to develop standards for Artificial Intelligence-enabled data coding and to facilitate integration of data coding components into Information and Communication Technology (ICT) systems [The MPAI Statutes]. Reference [The MPAI Standards] provides a list of, and links to, the Standards published so far and [The MPAI Workplan] includes the MPAI Work plan.
In 2024, MPAI started investigating a standard project related to “Agentic AI” and gradually focused the project scope to “AI Agents operating in a metaverse” and specifically in metaverse instances (M-Instances) specified by Technical Specification: MPAI Metaverse Model (MPAI-MMM) – Technologies (MMM-TEC) [10].
The MMM-TEC standard is highly synergistic with the “AI Agents operating in a metaverse” scope because an M-Instance, i.e., a metaverse instance implemented in conformity with MMM-TEC, is populated with Processes acting on Items representing “things” in the M-Instance and other Processes, and Users, i.e., Processes operating under the responsibility of humans, either
- Directly – Human User (H-User), or
- Indirectly – Autonomous User (A-User).
With the belief that
- A-Users able to interact with Users – both A- and H-Users – are attractive components for M-Instances,
- A component-based A-User standard can accelerate the development and deployment at scale of A-Users,
- Necessary capabilities and key technologies are available,
MPAI has renamed its “AI Agents operating in a metaverse” activity as “Pursuing Goals in metaverse (MPAI-PGM)” and has initiated its first standard project called “Autonomous User Architecture (PGM-AUA)”.
As the PGM-AUA standard project requires more technologies to achieve the PGM-AUA goal than currently available from its standards, MPAI is now publishing this Call for Technologies to request interested parties – irrespective of their membership in MPAI – to submit Responses that may enable MPAI to reach the goal stated in Section 2 of this document for potential use in applications similar to the example Use Cases and satisfying the Functional Requirements of [4] under conditions conforming to [5].
The MPAI Secretariat (secretariat@mpai.community) shall receive Responses by 2026/01/18 T23:59 UTC. The Secretariat will acknowledge receipt of Responses via email. The 64th MPAI General Assembly (MPAI-64) is expected to define the Response review schedule at its online meeting on 2025/01/21. The Secretariat will communicate the schedule to all Respondents.
Appropriate MPAI working groups will thoroughly review the Responses and retain those appropriate for the future PGM-AUA standard. MPAI will select suitable technologies from those submitted in Responses, but is not obligated to select a particular proposal, or any proposal. Respondents will be encouraged to join MPAI and those whose Responses will be accepted in full or in part, shall join MPAI or MPAI will discontinue consideration of those selected technologies.
2 Purpose of MPAI-PGM
The PGM-AUA standard project is motivated by the impressive performance achieved by Language Models (LM) in a variety of domains and the recent publication of Technical Specification: MPAI Metaverse Model (MPAI-MMM) – Technologies (MMM-TEC) V2.1 [10]. MMM-TEC targets metaverse instances – called M-Instances – populated by Processes. Some Processes – called Users – represent humans possibly rendered as avatars – called Personae.
MMM-TEC specifies technologies enabling Users to perform a variety of Actions on Items such as sensing data from the real world or moving Items in the M-Instance, possibly in combination with other Processes. However, MMM-TEC is silent on how an A-User reached the decision to perform an Action.
The goal of the PGM-AUA standard project is the definition of the Architecture of an A-User capable of interacting with a User – both Human and Autonomous – rendered as a Persona in an Audio-Visual Scene of an M-Location and optionally moving around if rendered as a Persona.
MPAI believes that A-Users should be based on an architecture that is:
- Modular, i.e., able to swap or update modules independently from other modules.
- Transparent, i.e., able to perform clear roles and expose well-defined interfaces.
- Extensible, i.e., able to add or replace specific competences as needed.
As MPAI has developed a standard [Technical Specification: AI Framework (MPAI-AIF) ] enabling initialisation, dynamic configuration, and control of AI applications called AI Workflows composed of AI Modules executed in the AI Framework, MPAI expects that PGM-AUA will be based on the AI Framework standard, thus making the architecture:
- Effective for the goals pursuable in an M-Instance and
- Efficient, i.e., requiring limited resources to pursue specific goals.
This Call for Technologies is designed to obtain the necessary technologies from the Responses received. It references four related documents:
- Use Cases and Functional Requirements: Pursuing Goals in metaverse (MPAI-PGM) – Autonomous User Architecture (PGM-AUA) V1.0 includes
- An initial set of Use Cases that would benefit from the availability of A-Users
- A set of A-User Functional Requirements.
- Framework Licence: Pursuing Goals in metaverse (MPAI-PGM) – Autonomous User Architecture (PGM-AUA) V1.0 [6] includes the IPR Guidelines that MPAI issues jointly to Functional Requirements for all its Calls for Technologies.
- Template for Responses: Pursuing Goals in metaverse (MPAI-PGM) – A-User Architecture (PGM-AUA) V1.0 [7] designed to facilitate the drafting of a Response.
- Tentative Technical Specification: Pursuing Goals in metaverse (MPAI-PGM) – A-User Architecture (PGM-AUA) V1.0 [8] provided as an example of the ultimate goal MPAI intends to reach with this Call.
This document includes four important Annexes:
- Annex 1 – Information Form. Those intending to respond to the Call are encouraged to fill out and send to the MPAI secretariat by the 29th of December 2025.
- Annex 2 – Evaluation Sheet. Reviewers will use this form to report their findings in the review process.
- Annex 3 – Check list. Respondent are encouraged to use this form to review all the points requested by the Call in their Responses and optionally the Response may cover only some of them.
- Annex 4 – Mandatory text in responses. This text shall appear in any Response and shall include the data of the Respondent.
3 Expected content of Responses
Responses to this Call should preferably use the Template for Responses [7] and may/shall include:
Table 1 – Mandatory and Optional elements of a response
| # | Item | Status |
| 1 | The final version of Annex 1 – Information Form. | mandatory |
| 2 | A filled-out Table of Annex 3. | mandatory |
| 3 | Comments on Use Cases [4]. | optional |
| 4 | Detailed documentation describing the proposed AI Workflows, AI Modules, and Data Types. | mandatory |
| 5 | Descriptions of Use Case where the proposed technologies can be used. | optional |
| 6 | A preliminary demonstration of proposed technologies, with a detailed description. | optional |
| 7 | Any other relevant information that may help evaluate the submission. | optional |
| 8 | The text of Annex 4 – Mandatory text in responses. | mandatory |
Respondents should note that:
- Tentative Technical Specification [8] is a first attempt at mapping the Functional Requirements into a specification.
- Respondents are NOT bound to base their Responses on [8], but they are invited to comment on it.
- The components – AI Workflows and AI Modules – of the AI Framework used in an application are only defined by their functionalities and input and output Data Types.
- This Call is NOT calling for technologies that implement components. However, the component functionalities and input/out data may be strongly influenced by such technologies.
- Respondents may wish to provide software (source code or executable) that allows Evaluators to assess the impact of their technology(ies) on the standard.
- MPAI is interested in being made aware of technologies that can be used to implement PMG-AUA components.
- Annex 3 – Check list provides a list of Functional Requirements against which proposals will be assessed.
- MPAI does not expect – but welcomes – that Respondents provide solutions for all Functional Requirements.
4 How to submit a response
Those planning to respond to this Call are:
- Informed that the MPAI-PGM Call will be presented at two online events held on 2025/11/18 at 09 UTC and 17 UTC. The recorded events and related material will be published at [9].
- Requested to communicate their intention to respond to the MPAI secretariat by 2025/12/29 by sending an initial filled out version of the form in Annex 1. Submissions of Annex 1 help MPAI to properly plan for response review. However, an Annex 1 submission is not a commitment to submit a Response and a Response without a previous submission of Annex 1 will still be accepted.
- Advised to visit regularly the MPAI-PGM web page where relevant updates will be posted.
- Strongly encouraged to use the Template for Responses [7] when submitting a response to this Call.
Respondents are requested to present their Responses at online meetings properly announced by the MPAI Secretariat to submitters. If no presenter of a submission attends that meeting, the submission will be discarded.
Respondents are advised that, upon acceptance by MPAI of their submission in whole or in part for further evaluation, MPAI will require that a non-MPAI member immediately join MPAI. If that Respondent elects not to join, their submission will be discarded. Direction on how to join MPAI are available.
Further information on MPAI can be obtained from the MPAI website.
5 Evaluation Criteria and Procedure
The following process will be used to assess the Responses:
- Evaluation panel is created from:
- MPAI members in attendance.
- Non-MPAI members who are Respondents.
- Non-Respondents/non MPAI member experts invited in a consulting capacity.
- No one from 1.1.-1.2. will be denied membership in the Evaluation panel.
- Respondents present their proposals.
- Evaluation Panel members ask questions to Respondents.
- Respondents respond to evaluation team.
- Evaluation Panel members fill out the Annex 2 form for each proposal.
- Final Evaluation report is produced.
The Evaluation Form will contain the following elements.
Proposal title:
Response summary: (a few lines)
Comments on possible PGM-AUA profiles1
Assessment of Response features:
| Note 1 | The semantics of Response features is given by Table 3. |
| Note 2 | Evaluation Elements indicate the elements used by Evaluators to assess a Response. |
Table 2 – Features to be considered in a Response
| Submission features | Evaluation Elements |
| Completeness of description | A detailed description is recommended |
| Understandability of description | A detailed description is recommended |
| Complexity of proposal | The implementation complexity and technologies that are potentially usable to implement the proposal. |
| Software implementability | A detailed description is recommended |
| Demonstration | Demonstrations are recommended. |
Evaluation summary:
- Main strong points, qualitatively:
- Main weak points, qualitatively:
Additional remarks: (points of importance not covered above.)
Table 3 adds explanatory details to the Response features in Table 2.
Table 3 – Explanation of submission features
| Response features | Criteria |
| Completeness of description | Evaluators should: check if Respondent has described in sufficient detail how the Functional Requirements are supported by the proposal. Note: Responses will be assessed for the merit of what is proposed. A Response on a single technology that is excellent may be considered against a complete but less performing submission. |
| Understandability | Evaluators should identify unclear items (inconsistencies, sentences with dubious meaning etc.) |
| Complexity | Evaluators should identify issues that would make it difficult to implement the proposal based on the state of the art. |
| Software implementability | Possibility to implement a solution with software running in real time. |
6 Expected development timeline
Timeline of the Call, deadlines and response evaluation:
Table 4 – Dates and deadlines
| Step | Deadline | Time |
| Call issued | 2025/10/29 | |
| Notification of intention to submit a Response | 2025/12/29 | 23.59 UTC |
| Imperative deadline for submission of Responses | 2026/01/19 | 23.59 UTC |
| Evaluation of Responses starts | 2026/01/21 | (MPAI-64) |
7 References
- MPAI; The MPAI Statutes
- MPAI; The MPAI Standards
- MPAI; The MPAI Workplan
- MPAI; The MPAI Patent Policy
- MPAI; Use Cases and Functional Requirements: Pursuing Goals in metaverse (MPAI-PGM) – Autonomous User Architecture (PGM-AUA) V1.0.
- MPAI; Framework Licence; Pursuing Goals in metaverse (MPAI-PGM) – Autonomous User Architecture (PGM-AUA) V1.0
- MPAI; Template for Responses; Pursuing Goals in metaverse (MPAI-PGM) – A-User Architecture (PGM-AUA) V1.0
- MPAI; Tentative Technical Specification: Pursuing Goals in metaverse (MPAI-PGM) – A-User Architecture (PGM-AUA) V1.0.
- MPAI; MPAI Presentations; https://mpai.community/community/presentations/
- MPAI; Technical Specification: MPAI Metaverse Model (MPAI-MMM) – Technologies (MMM-TEC) V2.1
- MPAI; Technical Specification: AI Framework (MPAI-AIF) V2.2.
Annex 1 – Information Form
This information form is to be filled in by a Respondent to the MPAI-PGM Call
- Title of the proposal
- Organisation: company name, position, e-mail of contact person
- What are the main functionalities of your proposal?
- Will you provide a demonstration to show how your proposal meets the evaluation criteria?
Annex 2 – Evaluation Sheet
NB: This evaluation sheet will be filled out by Response Evaluators.
Proposal title:
Main Functionalities:
Response summary: (a few lines)
Comments on Relevance to the Call:
Evaluation table:
Table 5 – Assessment of Response features
| Note 1 | Evaluation elements indicate the elements used by the evaluator in assessing the submission |
| Note 2 | Final Assessment indicates the ultimate assessment based on the Evaluation Elements |
| Submission Elements/Features | Evaluation Elements | Final Assessment |
| Comments to Use Cases in [4] | ||
| New Use Cases | ||
| AI Workflow (A-User) | ||
| AI Modules | ||
| Data Types | ||
| Training procedures overlapping with other | ||
| Understandability | ||
| Implementation cost |
Additional remarks: (relevant points not covered above.)
Annex 3 – Check list
Note: A-User refers to an implementation of PGM-AUA.
Table 6 – List of potential response elements (entries from Functional Requirements of [4])
| 1. The A-User shall be implementable with limited computing resources |
| 2. The A-User shall be able to |
| 1. Understand its surroundings including |
| 1. Audio features |
| 2. Visual Features |
| 3. Speech features |
| 2. Converse with one User (either A-User and H-User) in contexts relevant to an MMM-TEC M-Instance. |
| 3. Move in space in a human fashion understanding its constraints. |
| 4. Assume (as mandated or autonomously decided). |
| 1. Personality |
| 2. Ethics |
| 3. Communication style |
| 4. Appearance |
| 5. Display a Personal Status coherent with its conversation partner. |
| 3. The A-User shall be implementable |
| 1. For operation in an MMM-TEC M-Instance. |
| 2. With relatively small Language Models. |
| 3. Assuming access the features available in MPAI standards. |
| 4. Assuming access to specialised knowledge. |
| 4. The A-User should |
| 1. Rely on existing MPAI standards or extensions thereof. |
| 2. Also be able to deal with more than one User at a time in contexts likely to be relevant to an MMM-TEC M-Instance. |
| 5. Optional functionalities |
| 1. The A-User could interact with more than one User at the same time. |
| 2. The A-Use has haptic capabilities |
Annex 4 – Mandatory text in responses
MPAI welcomes Responses whose implementation requires exploitation of third-party Intellectual Property. Therefore, even for responses not containing references to proprietary technologies, Respondents are requested to add the following statements where Company/Member term is replaced by the name of the Responding non-MPAI member or MPAI member.
A Response to this MPAI-PGM Call shall mandatorily include the following text
<Company/Member> submits this technical document as a Response to MPAI Call for Technologies: Pursuing Goals in metaverse (MPAI-PGM) – Autonomous Unser Architecture (PGM-AUA) V1.0 (N2646).
<Company/Member> explicitly agrees to the steps of the MPAI standards development process defined in Annex 1 to the MPAI Statutes (N2115), in particular <Company/Member> declares that <Company/Member> or its successors will make available the terms of the Licence related to its Essential Patents according to Framework Licence: Pursuing Goals in metaverse (MPAI-PGM) – Autonomous Unser Architecture (PGM-AUA) V1.0 (N2648), alone or jointly with other IPR holders after the approval of Technical Specification: Pursuing Goals in metaverse (MPAI-PGM) – Autonomous Unser Architecture (PGM-AUA) V1.0 (“Standard”) by the General Assembly and in no event after commercial implementations of the Technical Specification become available on the market.
In case the Respondent is a non-MPAI member, the submission shall mandatorily include the following text
If (a part of) this submission is identified for inclusion in a specification, <Company> understands that <Company> will be requested to immediately join MPAI and that, if <Company> elects not to join MPAI, this submission will be discarded.
Subsequent technical contribution shall mandatorily include this text
<Member> submits this document to MPAI-PGM Development Committee (PGM-DC) as a contribution to the development of Technical Specification: Pursuing Goals in metaverse (MPAI-PGM) – Autonomous Unser Architecture (PGM-AUA) V1.0.
<Member> explicitly agrees to the steps of the MPAI standards development process defined in Annex 1 to the MPAI Statutes (N2115), in particular <Company> declares that <Company> or its successors will make available the terms of the Licence related to its Essential Patents according to Framework Licence: Pursuing Goals in metaverse (MPAI-PGM) – Autonomous Unser Architecture (PGM-AUA) V1.0 (N2648), alone or jointly with other IPR holders after the approval of the Technical Specification by the General Assembly and in no event after commercial implementations of the Technical Specification become available on the market.
