Multilingual, Multimodal, and Artifact Interoperability in Autonomous Machine-to-Machine Systems

Report body

Multilingual, Multimodal, and Artifact Interoperability in Autonomous Machine-to-Machine Systems

The evolution of machine-to-machine (MATM) architectures from human-orchestrated procedural workflows into autonomous, multi-agent intelligent systems introduces profound complexities in data exchange. In conventional computing, interoperability is often bridged by human intuition—developers write custom integration logic, and users visually interpret misaligned encodings or slightly degraded data. In autonomous agent ecosystems, software agents must discover capabilities, coordinate useful work, retain acquired knowledge, and recover from operational faults entirely without routine human intervention. This mandates a foundational shift in how information is serialized, authenticated, and transported. Independent agents must possess the capacity to exchange useful information across languages, complex scripts, structured data formats, and diverse modalities—such as high-resolution images, audio, and compiled binaries—without the loss of semantic meaning or cryptographic provenance.
When an autonomous extraction agent parses an Arabic financial report and forwards its findings to a downstream analytical agent, any failure to preserve Unicode normalization, bidirectional text logical ordering, or precise provenance metadata fundamentally severs the chain of custody. Consequently, the downstream agent cannot definitively trust the data, leading to cascading failures across the system. This research report investigates the mechanisms required for independent agents to seamlessly exchange artifacts. The analysis synthesizes established specifications, experimental proposals, and architectural paradigms to construct a comprehensive framework for deterministic, mathematically verifiable, and universally standardized MATM interoperability.

1. Primary Findings in Artifact and Protocol Standardization

To facilitate independent agents operating on disparate runtimes and models, the underlying communication fabrics must adhere to strictly defined international specifications. The investigation reveals several critical pillars required for seamless artifact exchange.

1.1 Multilingual Text, Unicode Preservation, and Bidirectional Algorithms

A foundational requirement for autonomous agent interoperability is the exact preservation and deterministic comparison of text across multiple languages and scripts. The evidence indicates that agents must categorically decouple exact data preservation from semantic interpretation. To achieve exact structural consistency, agents must enforce Unicode Standard Annex #15 (UAX #15), which defines Unicode Normalization Forms1. For instance, a character such as "é" can be represented programmatically as a single precomposed character (U+00E9) or as the letter "e" followed by a combining acute accent (U+0065 U+0301)1. Without enforcing a canonical normalization form (such as Normalization Form C, or NFC) at both the transport and storage layers, two autonomous agents attempting to match identical semantic strings will register false negatives, severely disrupting capability discovery, semantic routing, and state synchronization1.
Furthermore, when handling complex scripts such as Arabic, Urdu, Persian, Hebrew, and Yiddish, agents must strictly adhere to Unicode Standard Annex #9 (UAX #9), which defines the Unicode Bidirectional Algorithm2. Bidirectional text consists of predominantly right-to-left text with nested left-to-right segments (or vice versa), and the predominant direction is termed the global orientation8. Evidence stresses that text must always be stored and transmitted in logical order—the sequence in which characters are typed or semantically processed—rather than visual order, which is how the text appears on a rendered display8. If an extraction agent attempts to read text in visual order, logically contiguous strings will be fragmented in memory. This renders natural language processing (NLP) models incapable of comprehending the text, as words from distant parts of a paragraph become erroneously fused8. The process of "inverse reordering" (from visual back to logical order) is a many-to-one function without a standard algorithm, often resulting in roundtrip data losses; thus, bidirectional data should be converted and reordered to logical order only once upon ingestion8.
The Unicode Consortium also maintains strict stability policies that guarantee forward compatibility. The Encoding Stability and Name Stability policies dictate that once a character is encoded, it will not be moved, removed, or have its name changed5. This allows independent MATM agents to rely on long-term character identities without fear that future standard updates will invalidate historical data or cryptographic hashes.

1.2 Language Negotiation and Capability Matching

When autonomous systems must route tasks or request artifacts, they require a deterministic method to articulate linguistic capabilities. BCP 47 (comprising RFC 5646 and RFC 4647) provides the authoritative syntax and matching algorithms for language tags9. BCP 47 language tags are assembled from a sequence of subtags separated by hyphens (e.g., en-US or zh-Hant), identifying specific elements of meaning10.
For MATM systems, selecting content or behavior based on language requires specific filtering and lookup mechanisms defined in RFC 46479. The lookup mechanism produces a single matching language tag, which is critical when an agent requests a specific artifact translation, whereas filtering produces a potentially empty set of tags, useful when an agent queries a directory for all models supporting a particular language cluster9. By mandating well-formed and valid language tags according to the IANA Language Subtag Registry, agents avoid ambiguous routing11. Furthermore, private use subtags (starting with x-) should be avoided in general MATM architecture, as they hold no meaning except as negotiated between specific parties, fundamentally interfering with open interoperability10.

1.3 Deterministic Serialization and the JSON Canonicalization Scheme

Autonomous agents frequently rely on cryptographic hashes to verify the integrity and provenance of structured data. However, the standard JSON format is highly non-deterministic; identical semantic objects can be serialized with vastly different key orderings, whitespace variations, and floating-point representations (e.g., 1e21 versus 1e+21), resulting in completely different hashes13. If two independent agents process the exact same knowledge graph but serialize it differently, their integrity hashes will fail to align, destroying consensus16.
The JSON Canonicalization Scheme (JCS), formalized in RFC 8785, addresses this by defining a strict, byte-for-byte predictable serialization format13. JCS enforces the lexicographical sorting of object keys based on UTF-16 code units, relies on ECMAScript-compatible number formatting (IEEE 754), and eliminates all extraneous whitespace14. Critically, RFC 8785 constrains JSON data to the Internet JSON (I-JSON) subset (RFC 7493), which guarantees predictable parsing across different platforms14.
Implementation documentation highlights that robust JCS tooling must operate strictly: canonicalizers must reject invalid inputs—such as duplicate object keys, unpaired surrogate escapes, or numbers that overflow to infinity—rather than attempting to silently normalize them, as silent normalization destroys the determinism required for cryptographic signing pipelines14. Furthermore, schema-level normalizations must precede canonicalization. For example, timestamp fields representing an instant in time should be encoded as JSON integers representing milliseconds since the Unix epoch rather than RFC 3339 strings (e.g., 2026-05-28T12:00:00Z), because RFC 3339 admits multiple lexically distinct strings for the same instant, which would defeat canonical hashing13. By adopting RFC 8785 alongside strict schema normalizations, independent agents operating on distinct runtimes (e.g., Java, Go, Rust) can generate identical hashes for logically equivalent data, enabling verifiable multi-agent consensus13.

1.4 Ephemeral Messaging, Content Delivery, and Partial Retrieval

Agents frequently generate artifacts that are too large to safely embed within synchronous communication payloads, such as high-resolution images, multi-gigabyte video files, or expansive vector databases. Rather than embedding base64-encoded data—which breaches memory limits and bloats network traffic—agents must rely on authorized references utilizing HTTP semantics for partial content retrieval, as defined in RFC 911020.
By supporting the Accept-Ranges: bytes response header and processing requests with the Range header, storage nodes allow downstream agents to request specific byte ranges of a large artifact20. The server returns a 206 Partial Content status code alongside a Content-Range header detailing the exact byte positions delivered and the total size of the resource20. This architectural pattern is highly advantageous in MATM systems. For example, an autonomous video-processing agent can fetch only specific byte-ranges corresponding to distinct frames of a movie without downloading the entire file, preserving constrained memory limits and optimizing bandwidth20. Furthermore, this mechanism naturally enables resumable retrieval; if an agent's network connection drops during a large artifact transfer, it can autonomously request the remaining bytes starting from the point of failure, entirely bypassing the need for human intervention or complete retransmission20.

1.5 Ontological Provenance and Knowledge Retention

To operate safely without human oversight, intelligent systems require a standardized ledger of how artifacts were generated, updated, or derived. The W3C PROV-O specification, an OWL2 ontology, provides the established mathematical vocabulary for this purpose26. PROV-O allows agents to express data provenance as machine-readable RDF triples that software can parse, query, and reason over26.
The ontology defines three foundational classes:

• prov:Entity: A physical, digital, or conceptual thing with fixed aspects (e.g., a raw dataset, a translated document, an extracted artifact)26.
• prov:Activity: The dynamic process that occurs over a period of time and consumes or generates entities (e.g., a translation model executing, a data extraction pipeline)26.
• prov:Agent: The system, software, or human that bears responsibility for the activity26.

By employing relations such as prov:wasDerivedFrom, prov:wasGeneratedBy, and prov:wasAttributedTo, encoded within JSON-LD formats, agents can build interoperable graphs of lineage26. For example, a JSON-LD PROV-O graph can explicitly state that a specific quality-filtered dataset (Entity) was generated by an anomaly-detection algorithm (Activity) executing on behalf of a specific processing node (Agent), and that it was derived from an original raw data stream (Entity)26. This prevents hallucinated data from silently corrupting a MATM ecosystem, as downstream agents can computationally traverse the provenance graph back to a verified origin before executing a critical task28. Recent experimental extensions in AI-readiness also suggest extending PROV-O with specific AI contribution roles to explicitly map how language models interact with source data, further increasing auditability35.

1.6 Decentralized Authorization and Capabilities

When exchanging references to artifacts rather than embedding them directly, authentication boundaries must be strictly preserved without relying on single points of failure. The User-Controlled Authorization Networks (UCAN) specification provides a capability-based authorization model using JSON Web Tokens (JWT)37. Unlike traditional OAuth systems that rely on a centralized authorization server, UCANs enable local-first, decentralized delegation of capabilities37.
UCANs allow one agent to cryptographically prove it possesses the rights to read or mutate a specific artifact on a remote system. An agent can issue a UCAN to a peer agent, delegating specific capabilities (e.g., file/read or msg/send) tied to decentralized identifiers (DIDs)38. Because the capability is cryptographically signed and self-contained, the receiving storage node can independently verify the token without querying a central backend37. This trustless, peer-to-peer design is crucial for autonomous swarms operating in environments with intermittent connectivity or distributed topologies.

2. Comparison of Credible Approaches

The architectural decisions underpinning MATM data exchange require careful balancing of data immutability, physical network constraints, and synchronization models. The analysis contrasts the prevailing methodologies used in distributed systems to highlight where specific approaches fit.

2.1 Content Embedding vs. Authorized References

The fundamental transport mechanism for agent communication is either embedding the artifact directly within the message payload or transmitting an authorized reference pointing to external storage.

Content embedding should be strictly reserved for small, metadata-rich payloads, capability declarations, semantic intents, and the provenance graphs themselves. For all structured extractions, large text corpora, audio arrays, and multimodal artifacts, the ecosystem must utilize Authorized References. To mitigate the risk of expiring links and link rot, references should utilize self-describing IPFS multihashes (CID), meaning the identifier is derived cryptographically from the artifact content itself43. If the storage node moves, any agent holding the artifact can re-host it without breaking the reference. In this model, temporary access constraints and expiring links are managed not by shifting the URL, but by issuing a UCAN token with a strict expiration timestamp (exp) authorizing access to the CID37.

2.2 State Mutation: JSON Patch (RFC 6902) vs. Merge Patch (RFC 7396)

When autonomous agents collaborate to correct previously shared material, transform derivatives, or iteratively build a complex knowledge graph, they must communicate state changes. Transmitting the entire document repeatedly introduces severe race conditions and bandwidth waste. Two primary standards address partial JSON updates: JSON Patch (RFC 6902) and JSON Merge Patch (RFC 7396).
JSON Merge Patch (RFC 7396) acts as a structural overlay where the target document is merged with the incoming patch44. Keys set to null are deleted, and absent keys are left untouched44. While RFC 7396 is highly readable, it contains a fatal flaw for independent multi-agent systems: it cannot perform precise array mutations44. If an agent attempts to append a single item to an array of 1,000 items, RFC 7396 requires the agent to transmit the entire array, completely overwriting the previous sequence44. If two agents update the array simultaneously, one agent's data is irreversibly lost. Furthermore, because setting a key to null is the mechanism for deletion, an agent cannot explicitly assign a literal null value to a field44.
Conversely, JSON Patch (RFC 6902) is robust for autonomous operation. It defines an ordered sequence of explicit operations—add, remove, replace, move, copy, and test—pointing to specific JSON paths using JSON Pointers44. It allows for precise atomic operations (e.g., appending to an array via /tags/- or targeting an index via /tags/0)44. Crucially for MATM systems, it features the test operation for optimistic concurrency, ensuring that an agent's patch is only applied if the target document exactly matches the expected state, thereby preventing destructive race conditions without requiring complex distributed locking44. Therefore, MATM systems must standardize on RFC 6902 for coordinating state mutations of shared artifacts.

2.3 Exact Data Preservation vs. Semantic Equivalence vs. Model Interpretation

When exchanging data, agents must strictly separate the concepts of exact preservation, semantic equivalence, and model interpretation to avoid corruption.

• Exact Data Preservation is required for cryptographic integrity, hashing, and signature validation. If Agent A signs a document, Agent B must evaluate the exact same bytes to verify the signature. This necessitates the use of RFC 8785 (JCS) for structured JSON data13 and strict byte-for-byte binary preservation for multimodal files.
• Semantic Equivalence recognizes that two distinct byte sequences may represent the exact same real-world information. In text, this is governed by UAX #15 (Unicode Normalization)1. To a human reader, a decomposed "é" and a precomposed "é" are semantically identical. To an NLP model or an exact-match algorithm, they are entirely different entities1.
• Model Interpretation involves the subjective transformation of raw data by an LLM or reasoning engine, such as extracting sentiment from text or identifying objects in an image.

A MATM system must separate these layers architecturally. At the network and storage layers, artifacts must be treated as exact immutable data blocks governed by hashes. At the processing layer (immediately before the data is ingested by an LLM or reasoning engine), agents must normalize strings to a predefined canonical format (e.g., NFC) and enforce logical order for Bidirectional text (UAX #9) to guarantee accurate semantic equivalence1. The model interpretation layer must then document its outputs as entirely new prov:Entity objects linked back to the source via prov:wasDerivedFrom, making the uncertain interpretation explicit and auditable26.

3. Recommended Design: The Message-Plus-Artifact Model

To satisfy the rigorous requirements of multilingual support, multimodal handling, verifiable provenance, and exact data preservation across independent runtimes, the MATM ecosystem must adopt a Message-Plus-Artifact Model.

3.1 Architectural Overview

In this model, the Message acts as a lightweight, ephemeral envelope. It contains the semantic intent of the communication, capability negotiations, explicit access requirements, and a W3C PROV-O JSON-LD metadata graph32. The Message never contains large payloads or raw multimodal files.
The Artifact is the actual multimodal file, raw dataset, or large structured extraction. It is stored in a decentralized, content-addressed storage system (such as an IPFS node or an HTTP server strictly compliant with RFC 9110), making it immutable and referenceable via a cryptographic multihash (CID)43.

3.2 Interfaces and State Transitions

1. Registration and Capability Declaration: Agents declare their supported languages via BCP 47 and their functional tools via the Model Context Protocol (MCP) upon joining the network9.
2. Artifact Generation and Publication: An agent generates a multimodal file, hashes it to create a CID, and commits it to a local or remote storage node.
3. Message Construction: The agent builds a JSON-LD message incorporating PROV-O ontology terms to describe the artifact's lineage, MIME type, language tags, and fallback derivatives26.
4. Canonicalization & Signature: The agent applies RFC 8785 (JCS) to canonicalize the JSON-LD message bytes, stripping non-deterministic whitespace and sorting keys13. The agent signs this canonical byte sequence.
5. Authorization Binding: The agent constructs a UCAN capability token delegating read or mutate access for the artifact CID to the target agent's DID37.
6. Transmission: The lightweight message and UCAN token are routed to the target agent via the messaging bus.
7. Retrieval with Safe Fallbacks: The target agent verifies the signature using JCS rules. If the primary artifact's MIME type or BCP 47 language tag is unsupported, the agent inspects the message for fallback representations. The agent utilizes the UCAN token for authorization37. If it requires only a subset of the artifact, it issues an RFC 9110 Range request for efficient partial retrieval20.

3.3 Concrete Example: Agents Exchanging a Multilingual Document

**Scenario:**Agent Alpha (a specialized localization and parsing agent) intercepts an unformatted Arabic PDF document. It translates the text to English, extracts key financial entities into a structured JSON schema, and transmits the structured extraction to Agent Beta (a risk assessment and auditing agent). Agent Beta requires cryptographic proof of where the data originated before it authorizes a downstream financial transaction, but Beta lacks native Arabic parsing capabilities.
Step 1: Artifact Preparation (Agent Alpha) Agent Alpha normalizes the Arabic text using UAX #15 (NFC) and preserves its logical order using UAX #91. It uploads the original PDF and the English JSON extraction to a storage node, receiving two IPFS multihashes:

• Original Arabic PDF CID: bafybeig...arabic
• English JSON Extraction CID: bafybeih...english

Step 2: Message Construction with PROV-O JSON-LD Agent Alpha constructs a message payload defining the entities, the activity, and the agent responsible, using the standard W3C PROV-O vocabulary26. The message explicitly defines the language boundaries and provides a plaintext fallback for limited clients:

JSON
{
"@context": [
"https://www.w3.org/ns/prov",
"https://schema.org/"
],
"@type": "Activity",
"startedAtTime": 1788782400000,
"endedAtTime": 1788782700000,
"wasAssociatedWith": {
"@id": "did:example:agent-alpha",
"@type": "Agent"
},
"generated": {
"@id": "ipfs://bafybeih...english",
"@type": "Entity",
"format": "application/json",
"language": "en",
"wasDerivedFrom": {
"@id": "ipfs://bafybeig...arabic",
"@type": "Entity",
"format": "application/pdf",
"language": "ar",
"accessRequirement": "ucan:read"
},
"fallback": {
"@id": "ipfs://bafybeij...plaintext",
"format": "text/plain",
"language": "en"
}
}
}

(Note: Millisecond integer timestamps are utilized here per strict JCS schema normalization profiles to prevent RFC 3339 string lexical ambiguities).
Step 3: Cryptographic Binding (RFC 8785 & UCAN) Agent Alpha canonicalizes the JSON-LD using RFC 878513. After canonicalization, Alpha generates a cryptographic signature over the exact byte sequence. To grant Agent Beta access to the original source file, Alpha generates a UCAN token, delegating file/read access to Agent Beta's DID37.
Step 4: Verification and Partial Retrieval (Agent Beta) Agent Beta receives the message. It extracts the JSON-LD, processes it through a local JCS canonicalizer, and verifies the signature14. Because the message contains the provenance (wasDerivedFrom), Beta possesses machine-readable proof of the extraction's lineage26.
Beta parses the English extraction. Upon finding a statistical anomaly in the data, it triggers an audit routine to inspect the original Arabic PDF. Using the UCAN token for authorization37, Beta connects to the storage node. Instead of downloading the massive 500MB PDF, Beta utilizes RFC 9110 semantics to request only the specific byte range containing the PDF's header metadata and the first embedded table:
GET /ipfs/bafybeig...arabicRange: bytes=0-4096Authorization: Bearer <UCAN_TOKEN>
The storage node replies with a 206 Partial Content status and the Content-Range: bytes 0-4096/524288000, supplying Beta with the exact proof it requires instantly without overwhelming its runtime memory20.

4. Prioritized Feature Proposals

To implement the Message-Plus-Artifact Model across independent MATM architectures, the following three prioritized features must be developed.

4.1 Feature 1: Content-Addressed Message-Plus-Artifact Brokerage

The Problem: Autonomous agents currently attempt to broadcast massive payload data directly into message buses or API endpoints. This causes severe latency spikes, memory overflows on constrained edge nodes, and a loss of original file integrity when binary formats undergo repetitive base64 serialization and deserialization.
Agent-Visible Behavior: When an agent attempts to transmit an artifact exceeding a configurable threshold (e.g., 1MB), the brokerage middleware automatically intercepts the payload, writes it to a decentralized content-addressed storage (CAS) fabric, generates a cryptographically derived multihash, and swaps the large payload for a lightweight PROV-O JSON-LD reference pointing to the CID.
Expected Benefit: This feature fundamentally decouples message bus throughput from artifact size. It allows downstream agents to utilize asynchronous, resumable retrieval via HTTP 206 Partial Content20, saving vast amounts of bandwidth and memory. It preserves the exact byte-for-byte binary structure of multimodal files, enabling flawless cryptographic hashing.
Dependencies: Integration of the IPFS/Multihash standard43, robust HTTP RFC 9110 Range handling on the storage nodes21, and standardization of the W3C PROV-O graph schema for message envelopes26.
Implementation Effort: Medium to High. Requires deploying distributed CAS nodes adjacent to the message brokers and integrating JSON-LD @context templates into the core agent SDKs.
Principal Failure Modes: Link rot and aggressive garbage collection; if an artifact is purged from the CAS node before the receiving agent processes the deferred message, the autonomous workflow will halt. Furthermore, the system may experience latency spikes during the initial CAS upload phase prior to message dispatch.

4.2 Feature 2: Deterministic Multi-Agent State Synchronization

The Problem: When multiple autonomous agents iteratively update a shared artifact (e.g., a collaborative world-state map or an extracted knowledge graph), simultaneous updates overwrite each other. Furthermore, standard JSON formats fail cryptographic hash validation across different runtimes due to non-deterministic key ordering and whitespace formatting16.
Agent-Visible Behavior: Agents must broadcast state mutations exclusively using JSON Patch (RFC 6902) rather than JSON Merge Patch (RFC 7396)44. Each patch payload must first be canonicalized using RFC 8785 (JCS) before it is cryptographically signed13. Agents utilize the RFC 6902 test operation to assert the expected state of the document before applying mutations44.
Expected Benefit: Enables mathematically perfect resolution of state across completely independent systems. It completely bypasses the array-overwrite failures inherent to RFC 739644. It eliminates non-determinism in JSON, ensuring that a cryptographic signature generated by a Python-based reasoning agent is perfectly verifiable by a Go or Rust-based storage agent13.
Dependencies: Strict RFC 8785 parsing and serialization libraries (e.g., titanium-jcs, json-canon)17 and RFC 6902 application libraries44.
Implementation Effort: Medium. Requires stripping standard JSON.stringify() or json.Marshal() calls from the agent architecture and replacing them with strictly compliant JCS libraries14.
Principal Failure Modes: Agents attempting to use non-compliant or lenient canonicalization tools will generate invalid signatures, resulting in immediate ecosystem rejection13. Strict JCS implementations reject non-finite numbers (NaN, Infinity), which could cause unexpected crashes in data pipelines attempting to transfer scientific floating-point anomalies without mapping them to strings first14.

4.3 Feature 3: Cross-Modal Semantic Fallback Negotiation

The Problem: Specialized agents often receive artifacts they cannot natively parse (e.g., a text-only logical reasoning agent receiving a high-resolution .tiff image, or an English-only NLP agent receiving Mandarin text). This halts autonomous progress and triggers unnecessary fault states.
Agent-Visible Behavior: Agents generating artifacts embed a fallback array within the artifact's JSON-LD metadata graph. Upon receiving a message, an agent utilizes BCP 47 matching algorithms and MIME-type checks to compare the primary artifact against its own capabilities9. If the primary artifact is incompatible, the agent automatically traverses the graph and retrieves the fallback reference (e.g., an OCR text derivative of an image, or a machine-translated string) without requesting human intervention.
Expected Benefit: Prevents autonomous workflows from stalling when encountering unsupported modalities or languages. It preserves all participant languages and original modalities by securely storing the original artifact as immutable evidence while exposing highly functional derivatives for limited clients. It makes uncertain model interpretations explicit by defining the derivative as a distinctly new prov:Entity linked to the original26.
Dependencies: The IANA MIME types registry, BCP 47 matching algorithms (specifically Basic Filtering and Lookup)9, and PROV-O wasDerivedFrom attributes to securely trace the fallback back to the source26.
Implementation Effort: Low to Medium. This feature can be implemented as a lightweight middleware layer in the agent's reception handler, acting before the payload is passed to the reasoning engine.
Principal Failure Modes: "Lossy" fallbacks. An agent may rely on an OCR fallback that has hallucinated text, and because the agent cannot parse the original image, it trusts the flawed derivative entirely, leading to confident but factually incorrect downstream reasoning.

5. Practical Adoption Sequence, Unresolved Questions, and Success Criteria

5.1 Practical Adoption Sequence

To migrate existing agent infrastructures to this robust framework without disrupting current operations, implementers should follow a tiered, phased sequence:

• Phase 1: Canonicalization & Basic Provenance. Replace all native JSON serializers in message signing pipelines with strict RFC 8785 (JCS) compliant libraries14. Mandate the inclusion of minimal W3C PROV-O headers (wasGeneratedBy, wasDerivedFrom, wasAttributedTo) on all inter-agent messages26.
• Phase 2: Decoupling Payload from Messaging. Implement the transition from embedded payloads to CAS IPFS multihashes. Enforce that HTTP servers hosting the artifacts support Accept-Ranges: bytes (RFC 9110) to prepare for streaming operations20.
• Phase 3: Immutable State Mutation. Transition artifact update endpoints to accept only RFC 6902 JSON Patch arrays44. Systematically deprecate full-document PUT and RFC 7396 PATCH operations for iterative datasets.
• Phase 4: Decentralized Authorization. Transition from centralized API tokens and ACLs to UCAN capabilities, enabling agents to self-issue permissions and manage authorization entirely peer-to-peer without central bottlenecks37.
• Phase 5: Native Fallbacks and Language Negotiation. Implement robust BCP 47 language negotiation and multimodal fallback routing natively within the agent discovery protocol, utilizing frameworks like the Model Context Protocol (MCP)9.

5.2 Unresolved Questions

While the recommended specifications solve the immediate interoperability constraints, several areas require further theoretical and practical research prior to widespread adoption:

1. UCAN Expiry in Fully Disconnected Swarms: If a swarm of agents is physically disconnected from a centralized time server (e.g., in aerospace or deep-sea MATM deployments), verifying the expiration timestamps (exp) on UCAN capabilities becomes highly problematic. Time drift between independent nodes could lead to the unauthorized acceptance of expired tokens or the erroneous rejection of valid credentials37.
2. Continuous Multimodal Embeddings vs. Discrete PROV-O Graphs: The PROV-O standard expects discrete, identifiable entities26. However, streaming modalities—such as a continuous lidar sensor data stream mapped dynamically into a vector embedding space—lack clear boundaries. Defining at what discrete interval a continuous embedding stream becomes a new, hashable prov:Entity remains a significant challenge for provenance tracking.
3. Quantifying Semantic Drift in Translations: Even with robust BCP 47 negotiation, bridging two languages via an intermediate autonomous model introduces inevitable semantic drift. Tracking the degree of certainty of a translation within a PROV-O JSON-LD document currently requires non-standardized vocabulary extensions. Developing a standardized ontology for algorithmic confidence boundaries is required35.

5.3 Measurable Success Criteria

Future implementers should evaluate the success of this architecture against the following empirical criteria:

1. Hash Consistency Rate: 100% of JSON payloads logically equivalent across distinct language runtimes (e.g., Java, Python, Go) must yield identical SHA-256 hashes when processed via the JSON Canonicalization Scheme13.
2. Bandwidth Optimization: A measurable reduction (e.g., >80%) in overall network bandwidth utilization during large multimodal dataset processing, achieved through the successful use of RFC 9110 206 Partial Content range requests20.
3. Provenance Traversability: The ability for an auditor (machine or human) to autonomously query a terminal output and successfully traverse the JSON-LD PROV-O graph back through every intermediate model transformation to the original source artifact without breaking the cryptographic chain26.
4. Concurrency Conflict Resolution: Zero instances of accidental data overwriting in array mutations under high concurrency, validated by the successful interception and resolution of conflicts using RFC 6902 test operations44.

By synthesizing strict Unicode compliance, deterministic serialization, HTTP range semantics, cryptographic capabilities, and formal provenance ontologies, MATM systems can guarantee that independent agents seamlessly exchange knowledge. Meaning is preserved, provenance is mathematically verifiable, and the inherent limits of decentralized coordination are elegantly bypassed.

Works cited

1. java.text.Normalizer - Documentation - Android, http://opensource.hcltechsw.com/volt-mx-native-function-docs/Android/java.text-Android-10.0/#!/api/java.text.Normalizer
2. Common References for Unicode Standard Annexes, https://www.unicode.org/reports/tr41/
3. DUTS #55: Unicode Source Code Handling, https://www.unicode.org/reports/tr55/tr55-2.html
4. UnicodeNormalization — Rust text processing library // Lib.rs, https://lib.rs/crates/unicode-normalization
5. Unicode® Character Encoding Stability Policies, https://www.unicode.org/policies/stability_policy.html
6. HK Legacy Banking Upgrades: Mastering Bidi Text Rendering for, https://world.taobao.com/lang/en-us/shopping-guide/2004507391185387520.htm
7. z/OS V2R1.0 Unicode Services User's Guide and Reference - IBM, https://publibfp.boulder.ibm.com/epubs/pdf/iea3un00.pdf
8. BiDi Algorithm | ICU Documentation, https://unicode-org.github.io/icu/userguide/transforms/bidi.html
9. RFC 4647 - Matching of Language Tags - IETF Datatracker, https://datatracker.ietf.org/doc/html/rfc4647
10. TEI data teidata.language - Text Encoding Initiative, https://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-teidata.language.html
11. Language Tags and Locale Identifiers for the World Wide Web - W3C, https://www.w3.org/TR/ltli/
12. BCP 47 subseries contains 2 RFCs | RFC Editor, https://www.rfc-editor.org/info/bcp47/
13. JCS Canonicalisation Discipline for Agentic-Payment Receipts - IETF, https://www.ietf.org/archive/id/draft-hopley-x402-canonicalisation-jcs-v1-02.html
14. jcs package - github.com/DonaldMurillo/gofastr/core/jcs - Go Packages, https://pkg.go.dev/github.com/DonaldMurillo/gofastr/core/jcs
15. RFC 8785: JSON Canonicalization Scheme (JCS), https://www.rfc-editor.org/info/rfc8785/
16. The JSON Canonicalisation Scheme (RFC 8785) in action and how, https://connect2id.com/blog/how-to-secure-json-objects-with-hmac
17. A Strict RFC 8785 Implementation in Go for Deterministic JSON, https://dev.to/lenny321/json-canon-a-strict-rfc-8785-implementation-in-go-for-deterministic-json-3mfg
18. filip26/titanium-jcs: Deterministic JSON serialization and ... - GitHub, https://github.com/filip26/titanium-jcs
19. json-canonicalize - NPM, https://www.npmjs.com/package/json-canonicalize
20. 206 Partial Content - The Status Code, https://www.thestatuscode.com/2xx/206
21. RFC 9110: HTTP Semantics, https://www.rfc-editor.org/rfc/rfc9110.html
22. RFC 9110 - HTTP Semantics - IETF Datatracker, https://datatracker.ietf.org/doc/html/rfc9110
23. 206 Partial Content - HTTP status code explained, https://http.dev/206
24. Accept-Ranges - Expert Guide to HTTP headers, https://http.dev/accept-ranges
25. What is Byte Serving? - ITU Online IT Training, https://www.ituonline.com/tech-definitions/what-is-byte-serving/
26. PROV-O: The W3C Provenance Ontology - CASRAI, https://casrai.org/dictionary/term/prov-o
27. Data Provenance: Definition & Standards - CASRAI, https://casrai.org/guides/data-provenance
28. PROV-O: The PROV Ontology | Request PDF - ResearchGate, https://www.researchgate.net/publication/320333535_PROV-O_The_PROV_Ontology
29. Provenance documentation to enable explainable and trustworthy AI, https://www.researchgate.net/publication/358626473_Provenance_documentation_to_enable_explainable_and_trustworthy_AI_A_literature_review
30. dataprov - data provenance tracking library. A python ... - GitHub, https://github.com/RI-SE/dataprov
31. 5. Provenance information - FAIR Cookbook, https://faircookbook.elixir-europe.org/content/recipes/reusability/provenance.html
32. GitHub - usnistgov/CASE-Implementation-PROV-O, https://github.com/usnistgov/CASE-Implementation-PROV-O
33. RDF & Ontologies Overview - OpenMetadata Standards, https://openmetadatastandards.org/rdf/overview/
34. Managing Provenance Data in Knowledge Graph ... - ResearchGate, https://www.researchgate.net/publication/377996005_Managing_Provenance_Data_in_Knowledge_Graph_Management_Platforms
35. CreditMap: Provenance Ledgers for Attribution in Human–AI, https://openreview.net/pdf?id=Jb5lHZwDNp
36. AI-readiness for Biomedical Data: Bridge2AI Recommendations, https://www.biorxiv.org/content/10.1101/2024.10.23.619844v4.full.pdf
37. UCAN Working Group - GitHub, https://github.com/ucan-wg
38. UCAN - Boris Mann, https://bmannconsulting.com/notes/ucan/
39. Cryptographic Chain-of-Custody for Agentic AI Systems - IETF, https://www.ietf.org/archive/id/draft-helixar-hdp-agentic-delegation-00.html
40. Authorization (UCAN/DID) — macula v0.47.1 - macula v5.2.2, https://macula.hexdocs.pm/0.47.1/authorization_guide.html
41. ucan package - github.com/qri-io/ucan - Go Packages, https://pkg.go.dev/github.com/qri-io/ucan
42. Agent Identity Protocol for Verifiable Delegation Across MCP and A2A, https://arxiv.org/html/2603.24775v1
43. IPFS data types — ipfs-search documentation, https://ipfs-search.readthedocs.io/en/latest/ipfs_datatypes.html
44. JSON Patch vs JSON Merge Patch: RFC 6902 vs RFC 7396, https://jsonviewertool.com/blog/json-patch-vs-merge-patch
45. JSON Patch and JSON Merge Patch - @erosb about software, https://erosb.github.io/json-patch-vs-merge-patch/
46. RFC 6902 JSON Patch implementation for X2 Framework. · GitHub, https://github.com/boylesoftware/x2node-patches
47. Stitching Giant JSONs Together with JSON Patch - DEV Community, https://dev.to/shrsv/stitching-giant-jsons-together-with-json-patch-5gmc
48. Specification - What is the Model Context Protocol (MCP)?, https://modelcontextprotocol.io/specification/2026-07-28
49. Accept‑Language 2.2 Released: Ruby Library Now Fully RFC 7231, https://ubos.tech/news/accept%E2%80%91language-2-2-released-ruby-library-now-fully-rfc-7231-4647-compliant/
50. Data on the Web Best Practices: Data Quality Vocabulary - W3C, https://www.w3.org/TR/vocab-dqv/