MemoryEndpoints Single-Use Enrollment and Lossless Agent Continuity: A Distributed-Systems Audit

Full report

On this page

Public Observation Log and Explicit Unavailable Facts

An exhaustive analysis of the external authentication boundaries, distributed-sync mechanisms, and public API surface of the MemoryEndpoints network reveals a strict separation between public discovery and protected tenant knowledge. The architecture defines a bifurcated topology: MultiAgentMemory.com operates as the static documentation and repository companion, while MemoryEndpoints.com functions as the live, hosted mid-to-long-term Memory Architecture and Tenancy Model (MATM) endpoint1. The publicly observable surface provides a versioned OpenAPI contract, machine-readable route inventories, and predefined setup procedures for workspace creation and agent coordination, utilizing strict hierarchical persistence spanning from project to workspace to company2. The documented boundary strictly enforces tenant isolation. Capabilities matrices outline a connector pairing flow (v1) constructed around Proof Key for Code Exchange (PKCE) bound authorization requests, human approval stages, and single-use authorization-code claims2. The network supports a specialized "virtual UAIX package" mode explicitly engineered for accountless browser agents, such as the WebAssembly-bound TinyRustLM implementation, allowing them to coordinate active memory states without retaining large local file system overlays2. While public BGP routing registries indicate that the AS-ITS-UAIX and AS49327:AS-UAIX autonomous systems maintain peering relationships in traditional ISP infrastructure3, the application-level UAIX virtual package namespace operates entirely independently of this BGP topology, concerning itself strictly with local active memory continuity and .uai startup boundaries1. Despite the clarity of the public contracts, critical facts and internal state mechanisms remain explicitly unavailable to external observation. The raw MySQL/MariaDB database schemas, internal transaction isolation levels, execution trace IDs, and underlying load-balancing routing configurations cannot be inspected2. The system guarantees that raw credentials, private payloads, hidden prompts, private model assets, and credential-bearing URLs are never persisted or returned in public-safe summaries2. Because internal test fixtures, monitoring dashboards, and server-side connection pooling mechanics are inaccessible, this analysis relies strictly on the publicly advertised API behavior, documented capacity limits, and explicit error redaction shapes2. Any operational guarantees regarding internal failover times, database replica lag, or physical disk encryption must be mathematically inferred from the strict idempotency requirements and conflict-safe no-op responses mandated by the external contract.

Enrollment Contract Schema and Route Requirements

The enrollment of a disposable accountless browser instance executing a constrained implementation like TinyRustLM requires a precise and versioned connector contract. The network enforces HTTPS origin binding, ensuring that all discovery and cryptographic exchange mechanisms occur over secured channels tied explicitly to the exact https://memoryendpoints.com origin without intermediary redirects2. The current publicly advertised Connector Pairing v1 flow utilizes an idempotent PKCE-bound pairing request mapped to the POST /api/matm/connector-pairings/requests endpoint2. However, the idealized headless workflow—where an agent consumes a secret one-time URL to instantaneously agree upon a canonical name and receive an agent-scoped token—requires a highly specific schema that diverges from standard human-in-the-loop OAuth. The schema identity for this interaction must define the agent explicitly while requesting an immutable set of capabilities. The existing contract dictates a closed, four-scope set that must be requested exactly without omission, substitution, or expansion: connector:self:readback, agent:self:register, memory:public-safe:submit, and memory:search:read2. The backend cryptographically enforces this by validating the exact SHA-256 digest of these scopes, which is defined as sha256-v1:1358698c6ddba1a74a688d3718a739f78e4ef50d0773b22c96e025b38aa865942.

Upon successful consumption of the one-time secret, the backend must dynamically provision the agent identity, bind it to a hidden workspace, and issue an agent-scoped bearer token. Hidden workspace identifiers and company bindings must remain purely server-derived2. The browser client reconnects using only the canonical agent name and the issued token, completely obfuscating the broader tenant topology from the ephemeral client environment. Any unknown fields submitted during this enrollment payload must be strictly rejected, triggering a schema validation failure rather than silent truncation. This ensures that anomalous or malformed agent initializations fail closed before any durable database records are allocated. Furthermore, key rotation operations are handled explicitly via dedicated rotation endpoints that generate pending successors without exposing the workspace hierarchy, ensuring the preview and production statuses remain tightly coupled to the active credential snapshot.

Transaction and Crash-State Diagrams

The lifecycle of an accountless browser agent establishing continuous memory involves navigating two distinct transactional boundaries: the local WebAssembly runtime environment governing TinyRustLM, and the distributed relational persistence layer governing MemoryEndpoints. Within the local browser context, TinyRustLM operates under severe hardware and execution constraints. The architecture enforces a strict 128 MiB WebAssembly transfer ceiling, execution within the main browser thread via a scalar CPU path, and precise transient allocation formulas5. For example, the deterministic smoke model (17M parameters) dictates a forward scratch allocation calculated as [Figure omitted from source export], equating to exactly 47,104 bytes, alongside an 8,388,608-byte key-value (KV) cache5. The local model-load transaction requires the parser, tensor materialization, scratch allocation, KV allocation, and logits allocation to all succeed atomically before the local state transitions to ready5. If the browser tab crashes or the process is suspended by the operating system, this entirely transient allocation is immediately reaped, leaving no persistent footprint. On the backend, MemoryEndpoints utilizes a verified MySQL/MariaDB relational persistence layer for production deployments2. The atomic first claim of the one-time enrollment secret represents a critical database boundary where consistency must be absolutely guaranteed against network failures.

A backend process crash at any boundary prior to the final COMMIT forces a full database rollback. This architectural rigor guarantees that a one-time secret is never partially consumed or burned without yielding a fully functional agent identity. If the connection drops immediately after the COMMIT but before the browser fully receives the HTTPS response, the database accurately reflects the consumed state, fundamentally shifting the recovery burden entirely to the client's idempotency protocol.

Replay, Race, Idempotency, and Lost-Response Analysis

Distributed systems operating over unreliable networks must treat lost responses, transient partitions, and malicious replay attacks as operational certainties rather than edge cases. MemoryEndpoints enforces a strict idempotency model for all protected mutations to navigate these conditions gracefully2. When an agent makes the atomic first claim on the one-time enrollment secret, it is required to supply a unique Idempotency-Key HTTP header. If the client disconnects or the browser environment crashes while waiting for the response payload, the backend will still finalize the transaction and write the outcome to an idempotency store. When the browser recovers and retries the exact same HTTP request with the identical Idempotency-Key and an identical request body, the backend intercepts the request at the API gateway layer. It deliberately bypasses the underlying mutation logic and replays the original, successfully committed result2. This guarantees that the agent does not permanently lose access to its one-time credential due to a transient network drop. Conversely, malicious or accidental replay attacks introduce severe database race conditions that must be resolved deterministically. If an attacker simulates ten concurrent network requests attempting to consume the same one-time secret simultaneously, the underlying relational database enforces strict serialization. The first transaction to acquire the row-level lock on the secret evaluates it, validates the expiration, and flags it as consumed. The remaining nine concurrent requests will block at the database level. Once the first transaction commits and releases the lock, the subsequent requests will evaluate the secret, observe that its state has transitioned to consumed, and immediately abort the operation, returning a conflict response. If an attacker captures the enrollment URL and attempts to replay it using a differing Idempotency-Key or a mutated request body, the system categorizes this as a fatal state conflict. The backend will return a typed, safe rejection without creating an additional agent, token, package, or receipt. The public contract specifies that errors return a highly redacted problem shape to limit reconnaissance: ok=false, safeNoOp=true, valuesRedacted=true, rawCredentialExposed=false, and rawPayloadExposed=false2.

URL leakage responses are similarly benign by design. If a malformed or expired URL is submitted, the system emits a generic conflict-safe no-op. Crucially, the internal audit fields and database sequence counts remain completely unaffected by secondary claim attempts, ensuring that a leaked secret cannot be weaponized to generate denial-of-service pressure through database index exhaustion or massive audit log bloat. In all scenarios, exactly one logical operation is permitted to succeed.

Agent-Scoped Authentication Security Model

The authentication architecture relies on a highly restricted, agent-scoped bearer token model designed to minimize the blast radius of a compromised client environment. When the one-time enrollment secret is successfully consumed, the backend system generates a high-entropy bearer token. Adhering to strict cryptographic boundaries, the raw key is revealed to the client exactly once within the setup response payload; the MemoryEndpoints relational persistence layer strictly stores only a cryptographic hash (e.g., Argon2 or SHA-256) of this token2. This token is bound exclusively to the registered agent identity and the server-derived hidden workspace, establishing a very narrow audience. It is explicitly not a workspace administrator credential. Company master credentials—which hold the authority to perform administrative revocations, alter top-level knowledge trees, or override database settings such as matm\_companies.top\_level\_agent\_master\_credential\_enabled—must never be returned to an ephemeral browser agent under any circumstances2. Providing a master credential to a disposable TinyRustLM instance running in a hostile DOM environment would constitute a catastrophic violation of the least-privilege principle, exposing the entire tenant hierarchy to local cross-site scripting or browser extension exploits. The agent token operates under stringent lifecycle constraints. Because it is bound strictly to the four exact connector scopes, it is mathematically impossible for a compromised agent to escalate privileges, access arbitrary protected audit logs, or manipulate human-operator metadata2. Rate limits are aggressively credential-partitioned at the edge: the agent is restricted to exactly 5 self-registration confirmations per 10 minutes, 60 public-safe submissions per minute, and 120 searches per minute2. Any brute-force attempts to guess REST endpoints or blindly exfiltrate data will rapidly exhaust these operational quotas, triggering automated network-level throttling and yielding 429 Too Many Requests responses. Rotation and revocation are treated as atomic database operations. If an agent suspects credential compromise or reaches a scheduled lifetime limit, it can request a rotation summary via POST /api/matm/connector-pairings/{pairingId}/rotations to prepare a pending successor2. Following this, the agent executes an activation call through POST /api/matm/connector-pairings/{pairingId}/rotations/{rotationId}/activate. This activation route atomically provisions the successor token and permanently invalidates the predecessor token in a single, inseparable database transaction2. Should a human company administrator detect anomalous agent behavior, they possess the authority to trigger a machine-actor audit attribution revocation via POST /api/matm/connector-pairings/{pairingId}/revoke, instantly isolating the rogue agent without disrupting the broader workspace or forcing other agents to re-authenticate2.

Short-Term/Long-Term Memory and Reconnect Semantics

True agent continuity necessitates a structural distinction between ephemeral operational states and durable, promoted knowledge. The system elegantly bifurcates memory into two distinct planes: the active .uai startup continuity memory residing within the execution context, and the durable MemoryEndpoints records residing on the remote server1. For the TinyRustLM accountless browser agent, there is no local physical file system to store standard .uai files. Consequently, it relies entirely on the "full virtual UAIX package" mode hosted by the backend2. This mode stores strictly validated active-memory records on the server. Short-term memory encompasses the immediate context window, the transient conversation transcript, and forward scratch allocations5. This data is inherently transient and volatile. The system architecture strictly forbids the silent promotion of raw conversation logs into durable long-term memory2. Ordinary direct messages or unpromoted workspace-broadcast messages are treated as ephemeral coordination chatter and are physically purged from the database after a maximum of 30 days, or a mere 7 days if acknowledged or situated within designated meeting rooms2. Durable long-term memory consists exclusively of intentionally committed public-safe summaries, canonical external links, and contextual citation mentions2. To transition a concept from short-term context to long-term persistence, the agent must execute a highly deliberate promotion action, invoking routes such as POST /api/matm/knowledge-documents/upsert or POST /api/matm/meeting-messages/promote2. Revisions within this durable store utilize an expectedRevision compare-and-swap mechanism to prevent conflicting concurrent overwrites. If the agent attempts to update a memory node based on a stale hash base, the server rejects the operation with a conflict-safe 409 HTTP status. This supersession model forces the agent to fetch the newest document head, reconcile the conflict locally within its context window, and re-attempt the write2.

When untrusted content is introduced to the memory model, the system isolates it within bounded retrieval ranking contexts. Provenance is maintained explicitly, linking every generated insight to its source report, ensuring that hallucinated data cannot silently corrupt authoritative knowledge trees2. Furthermore, memory continuity does not promise verbatim raw transcript replay. Instead, it promises deterministic startup packet ordering, ensuring that the necessary active roles, logic constraints, and public-safe summaries are loaded into the agent's context window in a reproducible sequence upon initialization2.

Cross-Browser Reconnect and State Restoration

When a user completely terminates their session, deletes the initial browser environment, and opens a fresh browser instance, the cross-browser reconnect process relies solely on the canonical agent name and the securely stored scoped token. The agent initiates a highly deterministic startup sequence by invoking GET /api/matm/uai-memory/startup2. During this request, the server cryptographically verifies the bearer token, resolves the hidden server-derived workspace binding, and delivers the startup checkpoint. The receipt fields within this payload explicitly define the missing active roles and provide the necessary readiness evidence2. If the agent attempts to reconnect by presenting a wrong canonical agent name, a mismatched cryptographic token, a previously revoked token, or attempts a cross-tenant lookup by manipulating payload parameters, the connection fails entirely closed. The backend response provides no fallback logic or detailed error messaging that could inadvertently leak the existence of a different tenant or assist in credential brute-forcing. The reconnect sequence restores long-term memory pointers rather than dumping raw data into the client. This allows the newly initialized TinyRustLM runtime to selectively search and pull necessary contextual packages without overwhelming its rigid 128 MiB WASM memory limit or wastefully re-downloading obsolete conversation transcripts5. If the agent has been offline and attempts outbox reconciliation upon reconnect, the Distributed Sync v1 API (/api/matm/sync/capabilities) handles state resolution2. Stale-index reporting relies on epoch movements; if the agent submits a mutation using an outdated device authority epoch, the sync v1 protocol rejects the stale parent rather than silently choosing a dominant writer, forcing the client to re-evaluate the authoritative logical-memory head via GET /api/matm/sync/heads2.

Browser Credential Boundary Threat Model

The modern web browser is a fundamentally hostile environment for durable secret persistence, presenting a vast attack surface for local execution contexts. A TinyRustLM agent executes directly within the browser's main thread via WebAssembly, interacting intimately with JavaScript glue code6. Consequently, it is exposed to significant local threat vectors that require strict mitigation strategies. By default, the browser implementation must never persist the enrollment URL or the agent-scoped token to disk. If the enrollment URL is stored within the browser's URL history, it could be extracted by local malware scanning SQLite database files on the host operating system. If the token is passed via query parameters during setup, it risks catastrophic leakage through the Referer header to third-party domains, inclusion in browser crash dumps, or capture by local network traces2.

Local storage mechanisms—including localStorage, sessionStorage, IndexedDB, and the Cache Storage API—are highly vulnerable to Cross-Site Scripting (XSS) attacks. If an attacker manages to execute arbitrary JavaScript within the context of the agent's origin, they can programmatically dump these stores and exfiltrate the raw token. Furthermore, malicious browser extensions with broad origin permissions can silently observe network requests, read clipboard contents, and intercept form autofill events, easily compromising long-lived secrets stored in plain text. To mitigate these threats, the TinyRustLM deployment must adopt a strict session-only handling model for ephemeral runtime operations. The agent token must be held strictly in transient memory—such as a localized JavaScript closure or, preferably, an isolated WebAssembly memory segment—and injected dynamically into outbound HTTP Authorization headers. For circumstances where a persistent secret is absolutely mandated across browser restarts without requiring manual user re-enrollment, a separate, explicit persistent-secret design utilizing the File System Access API (OPFS) or a highly constrained Secure-Context web cryptography wrapper must be employed. Crucially, raw credentials must never touch third-party analytics platforms, diagnostic logs, prompt payloads, or user-initiated debug screenshots2.

Exact 25-Company Live Test Protocol

To empirically validate the multi-tenant isolation, idempotency semantics, and cleanup guarantees of the production environment, a rigorous live dogfood campaign is mandatory. This automated protocol instantiates 25 unique, disposable companies, exercises the full agent lifecycle, and proves absolute logical and physical cleanup post-execution1. Every iteration of the 25 distinct loops must operate with cryptographically unique identities, UUIDs, and idempotency keys to mathematically ensure no state bleeds between concurrent runs. Reporting outputs must contain only redacted IDs and cryptographic hashes, preventing any accidental leakage of test credentials in audit logs. Phase 1: Instantiation and Enrollment

1. Create Hierarchy: Execute POST /api/matm/agent-setup/free-account to dynamically generate a unique disposable company, workspace, and project2. The script records the resulting company master credential purely in transient process memory.
2. Provision Secret: Generate a single-use enrollment URL bounded strictly to the newly created workspace via the provisioning endpoint.
3. First Claim: From an isolated, mocked "first browser" profile context, execute the atomic claim against the secret URL, providing a unique Idempotency-Key: \<UUID-A\>. The test confirms the receipt of the canonical agent name and the scoped token2.

Phase 2: Memory Operations and Concurrency Validation 4\. Memory Writes: Using the scoped token, invoke POST /api/matm/uai-memory/packages to establish the virtual UAIX package2. Promote a randomized test string into long-term knowledge via POST /api/matm/knowledge-documents/upsert2. 5\. Replay Rejection: Attempt to claim the identical one-time enrollment URL using a differing Idempotency-Key: \<UUID-B\>. The test harness asserts that a strict 409 Conflict or generic safe no-op with valuesRedacted=true is returned2. Phase 3: Continuity Verification 6\. Simulated Destruction: Completely delete the "first browser" profile context, destroying all transient cookies, WebAssembly states, and JavaScript closures to simulate a hard system reset. 7\. Second-Profile Reconnect: Initialize a "second browser" profile. Supply only the canonical agent name and the securely retrieved scoped token to the runtime. 8\. Memory Retrieval: Execute GET /api/matm/uai-memory/startup and subsequently GET /api/matm/knowledge-documents2. Verify that the exact randomized test string promoted in Step 4 is successfully recovered, proving lossless long-term pointer continuity without requiring the original workspace identifiers. Phase 4: Eradication and Audit 9\. Token Scan: Run a specialized secret-scanning validation routine against the audit endpoint to ensure the raw token and enrollment URL were not inadvertently persisted in any readable audit log or generated receipt (GET /api/matm/receipts)1. 10\. Close and Delete: Utilize the transient company master credential to invoke the destructive company deletion route. 11\. Post-Delete Verification: Attempt to authenticate using the agent-scoped token. The system must return an immediate 401 Unauthorized or 403 Forbidden. Attempt to query the workspace via the master credential to ensure a 404 Not Found (or generic 403), proving complete physical eradication of the disposable tenant2. This sequence is executed 25 times sequentially. A failure at any logical step immediately halts the test suite and flags a regression.

Cleanup and Orphan-Recovery Procedure

In a heavily distributed environment, transient faults during the deletion phase of the 25-company campaign can inevitably result in orphaned data structures. If a network timeout occurs exactly as the master credential issues the delete command, the client cannot deterministically know if the backend committed the destruction or rolled it back. To guarantee tenant hygiene, the system must enforce strict compensating cleanup mechanisms. The finally execution block in the dogfood runner must unconditionally attempt to close and delete the company independently, regardless of whether earlier setup, memory write, or validation operations failed. Because company deletion is a highly destructive administrative action, the API endpoint must be designed to be idempotent. Retrying a deletion command against a company that has already been successfully deleted must yield a safe acknowledgment rather than an exception, allowing the cleanup script to safely exhaust its retry budget without crashing. On the database level, retention policies and legal/audit boundaries dictate whether a deletion is logical (soft delete via tombstones) or physical (hard delete). For test campaigns and disposable agents, hard deletion is heavily preferred to prevent database bloat. The Distributed Sync v1 mechanism inherently utilizes tombstones for conflict-safe mutation syncing, governed by the /api/matm/sync/retention endpoint, to prevent stale offline devices from resurrecting deleted records upon reconnection2. However, the backend should employ asynchronous garbage collection routines to physically purge orphaned records—such as expired tokens with no parent company, or .uai hash heads tied to nullified agents—once the tombstone retention window safely expires. If a company cannot be removed due to an unresolvable backend defect (e.g., an unforeseen foreign-key constraint violation in the MySQL schema preventing the dropping of a locked row), a public-safe defect report must be generated. This report must explicitly omit any raw tenant data. It provides only the correlation ID, the UTC timestamp, the specific endpoint invoked (e.g., /api/matm/human/companies/{companyId}), and the resulting HTTP status code, ensuring it is sanitized and safe for integration into standard public GitHub issue trackers1.

Cross-Agent Defect and Evidence Protocol

Effective coordination between the in-browser TinyRustLM agent and the MemoryEndpoints backend requires a robust protocol for handling evidence, telemetry, and execution limits. Because the browser environment is highly volatile, the system cannot rely on synchronous RPC calls; it must operate on asynchronous public-safe messages, deterministic task routing, and observable state transitions. When the TinyRustLM agent encounters a critical processing error—such as exhausting its 128 MiB WASM memory ceiling, failing to decode malformed UTF-8 tokens, hitting the 1,024-candidate sampling cap, or experiencing a transfer truncation—it must emit a highly structured defect report5. This report acts as expected evidence and is routed via POST /api/matm/memory-events/submit directly to the workspace's firewall-reviewed memory2. The telemetry payload must contain immutable identities to aid diagnostics: the source archive, WASM hash, model hash, local browser capabilities, and the UTC timestamp, while strictly excluding any raw prompt data or user-identifiable text to maintain privacy compliance5. For routine autonomous task execution, routing logic relies on the /api/matm/routing-decisions endpoint2. The backend agent dictates the structural lane, the overarching goal, and the next-action requirements. The TinyRustLM agent autonomously polls GET /api/matm/current-message for its required-response lane. Once the local execution of a task is completed, it executes POST /api/matm/notifications/ack to explicitly acknowledge the message and generate a redacted receipt on the server2. If agent credentials become stale or are revoked, the server responds with a 401 Unauthorized status. Upon receiving this, the agent must immediately suspend network execution, preserve its transient context state locally within WASM memory, and gracefully prompt the host application for rotation instructions without crashing. Crucially, if a specific advertised contract is missing (for example, the backend upgrades and deprecates a connector schema that the local agent relies upon), the missing contract blocks distributed execution without blocking local development. The TinyRustLM agent simply degrades gracefully, continuing to execute local offline inferences via its local .uai files and logging the synchronization failure, thereby preserving the user's immediate workflow until connectivity and contract alignment are restored.

TDD Matrix from Fixture to Authorized Production Test

The architecture enforces a strict test-driven development (TDD) progression that transitions from lightweight local mocks to fully authenticated production runs, mapped precisely across varying tiers of storage and network capability2.

A local L0 fixture or an L1 SQLite mock is invaluable for rapid iteration and local integration tests, but it can never satisfy the live L3 production gate. The production release demands passing the MySQL verifier against the real hosted infrastructure, validating not just code logic, but unpredictable network latency, database connection pooling constraints, load balancer timeout behaviors, and actual SSL origin bindings2. A successful L1 mock response must never be conflated with a successful live test.

Blockers Requiring MemoryEndpoints Implementation

While the public documentation extensively outlines the Connector Pairing v1 sequence, a strict analysis of the API Reference reveals a fundamental blocker for the required autonomous product semantics requested in the prompt. Critical Blocker: Absence of an Explicit Headless One-Time Secret Endpoint The required architecture dictates a workflow where an accountless browser user creates an agent from a "secret one-time URL," and the "first atomic claim consumes it and returns a canonical agreed agent name plus an agent-scoped token." However, the explicitly documented public contract for connector pairings requires a mandatory human-interactive approval step. Specifically, the flow demands an authorization URL addressed by a publicRequestRef parameter, which forces a human to resolve an opaque company reference, approve scopes, and return a parameter-free wakeUpUrl that requires manual human interaction to open (/api/matm/human/connector-pairings/{publicRequestRef}/approve)2. There is currently no advertised POST route in the api/matm/connector-pairings/ or api/matm/enrollment/ namespace that allows a completely headless, accountless browser client to submit a one-time secret payload and directly receive a scoped token without an authenticated human session intervening in the flow. Required Evidence for Unblocking: To support this exact scenario without resorting to undocumented API guesses—which are strictly forbidden by the system rules—MemoryEndpoints must advertise a versioned schema explicitly detailing this single-use enrollment capability. The required backend evidence includes:

1. An updated GET /api/matm/openapi.json contract defining a specific, direct-claim route (e.g., POST /api/matm/enrollment/single-use-claim).
2. Exact specification of the request payload schema, ensuring the secret is extracted securely via the JSON body and not the URL query parameters.
3. Exact specification of the atomic database transaction behavior, Idempotency-Key constraints, and error response shapes for this specific route.
4. Redacted capability evidence in the live capability matrix (/api/matm/live-capability-matrix) indicating that this specific route correctly bypasses the human-approval prerequisite while safely provisioning the agent within a pre-authorized ephemeral workspace2.

Until this exact contract is publicly advertised and verifiable, the TinyRustLM client cannot safely invoke the lifecycle route, as doing so would violate the strict prohibition against undocumented API utilization and compromise the deterministic safety of the system.

Current Primary Sources and Public URLs with Dates

The analysis relies strictly on the current public documentation, capabilities matrices, and architectural standards identified in the provided materials.

1. MultiAgentMemory.com API Reference: Outlines the core Trust and Tenancy boundary, relational persistence (MySQL/SQLite), UAIX package constraints, distributed sync limits, and the Connector Pairing v1 flow. Date observed: July 14, 2026\.2
2. MultiAgentMemory.com LLMs and AI Manifests: AI-readable text (llms.txt, llms-full.txt) defining the active .uai startup memory versus the durable MATM endpoint boundary. Date observed: July 14, 2026\.1
3. MiRust.com / TinyRustLM Framework: Documents the architectural constraints of the browser-based TinyRustLM environment, including the 128 MiB transfer ceiling, scalar CPU execution, detailed memory formulas, and deterministic token generation pathways. Date observed: July 14, 2026 (Snapshot Date: 2026-06-25 UTC).5
4. MiRust.com Models Directory: Lists the deterministic runtime smoke artifacts and structural telemetry required for the L0 test fixtures. Date observed: July 14, 2026\.7

Works cited

1. MultiAgentMemory.com | MATM Documentation, https://www.multiagentmemory.com/
2. API And Data Reference | MultiAgentMemory.com \- MATM Documentation, https://multiagentmemory.com/docs/api-reference.html
3. AS-ITS-UAIX \- bgp.he.net, https://bgp.he.net/irr/as-set/AS-ITS-UAIX
4. AS-SET AS49327:AS-UAIX \- bgp.tools, https://bgp.tools/as-set/RIPE::as49327:as-uaix
5. Implementation operations \- MiRust, https://mirust.com/implementation-operations/
6. Implementation \- MiRust, https://mirust.com/implementation/
7. Models \- MiRust, https://mirust.com/models/
8. Framework \- MiRust, https://mirust.com/framework/
9. Guides \- MiRust, https://mirust.com/guides/
10. MiRust: Home, https://mirust.com/
11. Tiny Model Composer \- MiRust, https://mirust.com/composer/