---
title: 'Macaron-V1: Open Agents for Continual Learning'
url: https://www.emergentmind.com/topics/macaron-v1
type: topic
---

# Macaron-V1: Open Agents for Continual Learning

Macaron-V1 is an open agent-model family designed for experiential intelligence, open continual learning, and multi-specialist collaboration. Introduced as a model–harness system rather than as an isolated checkpoint, it combines a frozen foundation model, specialist LoRA adapters, Mixture-of-LoRA (MoL) routing, stateful agent and GenUI harnesses, versioned runtime contracts, and infrastructure for reinforcement learning and adapter lifecycle management. The flagship Macaron-V1-Venti uses a frozen 744B GLM-5.2 base with four approximately 1B LoRA specialists, while Macaron-V1-Tall uses a Qwen3.6-based 50B configuration for local deployment. The system’s principal long-term objectives—compounding improvement across generations and collective intelligence from independently trained specialists—remain open empirical questions [2608.09819].

## 1. Conceptual scope and system objectives

Macaron-V1 defines experiential intelligence as the ability to learn from experience accumulated in real environments and to continue improving after deployment. Conventional post-training produces a checkpoint aligned to a fixed corpus of tasks, tools, users, and workflows. Macaron-V1 instead treats the deployed artifact as a repeatedly revised **model–harness pair** whose behavior depends on both model parameters and runtime configuration.

Its continual-learning formulation includes three possible adaptation channels:

1. **Parameter updates**: changes to model or adapter weights.
2. **Memory and state**: retained trajectories, retrieved experiences, and online state.
3. **Harness and context changes**: modifications to tools, prompts, skills, orchestration, memory procedures, UI components, and execution structures.

Macaron-V1 combines parameter-efficient updates with independently evolving harness configurations. The large foundation model remains frozen, while specialist LoRA adapters can be updated or added. The surrounding harness can evolve without changing the base model, and each deployed revision is versioned and evaluated.

The system has two complementary goals:

- **Adaptation**: successive model–harness versions improve through evaluated experience.
- **Collaboration**: multiple specialist adapters contribute through request-level routing.

The deployable object is represented conceptually as:

$$
(\text{problem bank},\ \text{model},\ \text{HCP})
\longrightarrow
\text{evaluated trajectories}
\longrightarrow
(\text{dataset},\ \text{next model},\ \text{next HCP}).
$$

A checkpoint without its task-bank version, selected data, Harness Context Protocol configuration, and evaluation results is considered an incomplete experiment record. The target application domain includes **Personal Intelligence**, defined as an agent’s ability to work over time for a particular person while using tools reliably, remembering cross-session constraints, asking for clarification appropriately, handling evolving preferences, communicating honestly, and maintaining suitable social and relational behavior.

Macaron-V1 differs from other systems that use “Macaron” terminology. The convolutional Macaron Net is an audio-event-detection architecture [2009.09632], while neuro-constrained V1 models use the name Macaron only informally in relation to biologically motivated vision architectures [2305.11275]. A separate benchmark called Macaron evaluates multilingual and multicultural reasoning [2602.10732]. These works are not components of Macaron-V1.

## 2. Model–harness architecture and versioned execution

Macaron-V1 is organized as a co-designed stack comprising:

1. A frozen foundation model.
2. Specialist LoRA adapters.
3. A MoL serving proxy and adapter router.
4. Agent and GenUI harnesses.
5. A stateful action substrate.
6. The Harness Context Protocol.
7. MindForge for agentic reinforcement learning and lifecycle control.
8. MinT for adapter training and model-state management.
9. LongStraw for long-context response-only reinforcement learning.
10. Sparse-MoE and DSA mismatch controls.
11. External contracts and benchmarks for evaluating successive revisions.

The runtime policy is formalized as:

$$
\pi_{\phi}(a_t \mid o_{\leq t}; \theta,c),
$$

where $\theta$ denotes frozen sparse base-model parameters, $\phi$ denotes trainable LoRA parameters, $c$ is a versioned harness configuration, $o_{\leq t}$ is the exposed conversation and observation history, and $a_t$ is a model-visible action. Actions include natural-language responses, clarifications, discrete tool calls, and REPL expressions evaluated in persistent state. Adapter selection is a separate MoL Proxy routing operation rather than part of the action space.

An episode is recorded as:

$$
\tau=(o_0,a_0,\ldots,o_T,a_T,y),
$$

where $y$ includes task outcomes and process-level judgments. Evaluation examines task outcome, tool-use correctness, process behavior, efficiency, honesty, calibration, boundary compliance, and whether failures originate in the model, task, or harness.

A successful trajectory is not automatically considered a suitable training example. Useful experience must be valid under the evaluator, attributable to the intended task and configuration, non-duplicative, informative for the next model, and sufficiently reliable to justify parameter transfer. This distinction is intended to prevent accidental configurations, evaluator artifacts, or duplicated strategies from being distilled into future adapters.

The Harness Context Protocol, or HCP, is a versioned TOML contract that reconstructs the runtime environment. It records runtime and model selection, working directory and backend, provider and model identifier, context window and generation limits, provider options, tool allowlists, MCP servers, extensions, hooks, system prompts, skills, prompt templates, AGENTS.md-like resources, session snapshots, workspace inputs and outputs, visibility and snapshot policies, environment-variable requirements, path-resolution rules, and secret references without embedding credentials.

HCP is not a learned parameter and contains no gradients. It describes resources that the model may propose changing, including prompts, skills, hooks, tool exposure, and workspace resources. Candidate configurations are rerun and retained only when they pass evaluation. Consequently, HCP establishes a reproducibility and audit boundary but does not guarantee behavioral identity across executions, because backend realization, resources, randomness, and engine behavior may differ.

A successor consists of two linked but separately mutable objects:

1. A new LoRA adapter revision produced from selected trajectories.
2. A new HCP configuration produced from accepted harness changes.

The frozen base remains unchanged while LoRA parameters and harness resources evolve. MindForge links the parent model, parent HCP, problem-bank version, selected trajectories, rewards, evaluation results, training job, new adapter revision, new HCP, and successor benchmark results. This makes it possible in principle to distinguish weight changes, harness changes, and their interaction, although the paper does not provide a controlled attribution study.

## 3. Recursive self-improvement and continual-learning lifecycle

Macaron-V1 implements recursive self-improvement through three stages: discovery, expansion, and update.

### 3.1 Discovery

During discovery, the current model proposes harder task variants by lifting constraints, adding hidden preferences, chaining subgoals, introducing contradictions, and creating new environment configurations. Every proposal must contain a verifiable answer or evaluation rubric. It is retained only if it satisfies both:

- **Quality**: the task and evaluation are well-defined.
- **Learning value**: the current model does not already solve the task reliably.

### 3.2 Expansion

During expansion, accepted tasks are executed under a fixed model–HCP pair. The system runs the task, collects complete trajectories, scores outcome and process behavior, audits failures, proposes changes to prompts, tools, skills, hooks, and other HCP resources, reruns affected tasks, and accepts changes according to actual evaluation performance.

This stage can improve behavior without changing model parameters. A new capability may first appear as a tool, UI4A component, REPL helper, prompt, skill, hook, or HCP configuration.

### 3.3 Update

During update, the system filters invalid trajectories, removes duplicates, selects informative examples, trains specialist LoRAs with GRPO, exports a serving-compatible adapter revision through MinT, registers the accepted HCP, and creates a linked successor model–configuration version. The successor then generates a new task distribution, restarting the loop.

Macaron-V1 therefore uses three release clocks:

1. The base-model clock.
2. The specialist-adapter clock.
3. The harness clock.

Harness changes can ship without weight updates, and adapter revisions can evolve while the foundation model remains immutable.

### 3.4 Configuration-search evidence

The strongest direct self-improvement experiment is an Expansion-stage configuration-search study on 122 TerminalBench 2.1 simulation tasks. The tasks came from 29 source families and were selected because frozen GLM-5.2-FP8 failed all of them under the official reward. Across 69 chronological jobs and 450 attempts, no optimizer steps were performed; only HCP-carried resources, skills, tools, and hooks changed.

| Phase | Attempts | Passes | Pass rate | Cumulative coverage |
|---|---:|---:|---:|---:|
| Retry control | 50 | 6 | 12.0% | 2/122 |
| Portfolio sweep | 244 | 15 | 6.1% | 14/122 |
| Skill/HCP search | 76 | 49 | 64.5% | 60/122 |
| Stop-gate hooks | 80 | 65 | 81.2% | 122/122 |
| Total | 450 | 135 | 30.0% | 122/122 |

Adaptive configuration search eventually found a passing configuration for every selected task. However, this result does not demonstrate full recursive self-improvement: the model was frozen, no adapter training occurred, the task set was adaptively targeted, and each task passed under some configuration rather than necessarily under one shared configuration. The result demonstrates harness search and latent capability elicitation rather than parameter learning.

## 4. Mixture-of-LoRA architecture and specialist routing

The MoL architecture freezes a large base model and attaches multiple specialist LoRA adapters. Rather than merging specializations into one parameter set, Macaron-V1 performs request-level composition:

$$
\text{request}
\rightarrow
\text{L0 route decision}
\rightarrow
\text{one selected LoRA}
\rightarrow
\text{answer}
\rightarrow
\text{summary}.
$$

For a target weight matrix $W$, the LoRA update convention is:

$$
W' = W + \frac{\alpha}{r}BA,
$$

where $W$ is frozen, $A$ and $B$ are trainable low-rank matrices, $r$ is the LoRA rank, and $\alpha$ is the scaling factor.

The design provides base-weight immutability, adapter registration, and adapter portability. These are architectural affordances rather than evidence that independently trained specialists already generate collective intelligence. The paper does not include the budget-matched single-LoRA experiment needed to establish that MoL reduces cross-task interference.

### 4.1 Macaron-V1-Venti

Macaron-V1-Venti uses a frozen 744B GLM-5.2 base and four approximately 1B LoRA specialists:

| Adapter | Role |
|---|---|
| L0 | Chat, instruction following, conversational identity, and routing |
| L1 | Agent behavior, long-horizon tool use, personal workflows, and service integration |
| L2 | Coding, SWE-style tasks, and terminal use |
| L3 | GenUI component generation and interaction |

The Preview release had five adapters; the OpenClaw specialization was folded into L1. Venti uses rank $r=16$, LoRA alpha $\alpha=32$, zero dropout, and targets attention and MLP projections. The target modules are:

$$
\{
\texttt{down\_proj},
\texttt{gate\_proj},
\texttt{kv\_a\_proj\_with\_mqa},
\texttt{kv\_b\_proj},
\texttt{o\_proj},
\texttt{q\_a\_proj},
\texttt{q\_b\_proj},
\texttt{up\_proj}
\}.
$$

Each adapter stores 7,688,042,496 values in BF16, with no additional saved modules. The release is conventionally labeled 748B, whereas the paper distinguishes this release label from stored-tensor count. Four adapters contribute approximately 30.8B stored values, yielding a logical nominal total of approximately 774.8B parameters when added to the 744B base.

### 4.2 Macaron-V1-Tall

Macaron-V1-Tall is intended for lower-latency local deployment and uses a Qwen3.6-35B-A3B base. Its adapters use rank $r=64$, alpha $\alpha=128$, and zero dropout. The target scope includes attention/recurrent and MLP projections, including Qwen3.6-specific input, query, key, value, and output projections, `experts.gate_up_proj`, and `experts.down_proj`. Effective exclusions are `gate`, `lm_head`, and `shared_expert_gate`.

Each adapter stores 3,775,651,840 values. L2 is stored partly in F32, and the nominal aggregate is approximately 50.1B. Tall and Venti adapter sizes cannot be compared directly because their bases expose different expert structures and target modules.

### 4.3 Routing protocol

Each user turn has three stages.

1. **Route**: L0 reads the request and emits exactly one canonical label from $\{\text{L0},\text{L1},\text{L2},\text{L3}\}$ using constrained decoding and a 24-token decode budget.
2. **Answer**: the proxy switches to the selected adapter unless L0 selects itself; the specialist then generates the response using its own conversation view.
3. **Summary**: the specialist produces a server-side summary capped at 192 output tokens. The summary is not shown to the client and becomes shared context for other adapters on later turns.

The router checks wrapper families in priority order: generative UI, code or terminal, and personal-agent or living tasks. Incoming requests are treated as quoted, untrusted text.

If an answer ends with a tool call, the following tool-result turn remains locked to the same adapter and skips routing and summarization. The proxy also supports transactional rollback so that engine failures or client disconnects do not commit undelivered turns to conversation history.

For each adapter hop, the proxy reconstructs a deterministic own-view conversation from an append-only timeline. The target adapter’s own previous turns remain verbatim, including assistant traces, tool calls, and tool results. Other adapters’ turns are compressed into one assistant message containing their 192-token summary, and the current user message is appended verbatim. This provides each specialist with its own detailed history, compact records of other specialists’ actions, and no other specialist’s full private trace.

Because own-view reconstruction is deterministic, returning to an adapter produces a byte-identical prefix. The native engine prefix cache can therefore reuse that prefix without engine modification. The default deployment does not splice arbitrary non-contiguous KV states across adapters; only continuous shared prefixes are reused.

### 4.4 Routing and serving measurements

On 48 mixed-domain requests, measured latency was:

| Hop | Venti | Tall |
|---|---:|---:|
| Route | 0.54 s, 12% | 0.20 s, 11% |
| Answer | 3.17 s, 68% | 1.24 s, 70% |
| Summary | 0.97 s, 20% | 0.32 s, 19% |
| Total | 4.68 s | 1.76 s |

Routing plus summarization accounts for approximately 32% of Venti’s three-hop latency and 30% of Tall’s. On 6,448 training-trace samples, routing accuracy was 99.12% for Venti and 99.04% for Tall. Canonical-label compliance was 100%, with zero request and parse errors. The Venti router achieved 24/24 correctness on an L1/L2 alternating smoke test, including 21/21 within-conversation switches and 18/18 specialist re-entry turns. Because the trace was not held out, it measures implementation behavior rather than routing generalization.

For Venti, MoL stores one shared 744B base plus approximately 30.8B adapter values. A replicated merged deployment with four separate base copies would contain 2.976T parameters. The MoL logical residency is approximately 26.0% of the replicated layout, corresponding to a 74.0% reduction in stored parameter values. The paper does not claim that MoL necessarily reduces latency or increases throughput relative to four independently deployed merged models.

## 5. Stateful agent and GenUI harnesses

### 5.1 UI4A

UI4A is the GenUI harness associated with L3. It occupies an intermediate position between HTML-native generation, which is expressive but difficult to compile, validate, and recover, and schema-native generation, which is auditable but constrained by a fixed component catalog.

Its conceptual programming model is:

$$
\text{Import}+\text{Component}+\text{State}+\text{Action}.
$$

Imports come from a curated Macaron registry or ecosystems including Radix, shadcn, Recharts, KaTeX, and lucide-react. Raw HTML and CSS remain available where required. React, Vue, Svelte, and SolidJS can be supported through framework-specific renderers.

Each user gesture is represented by an origin, state, execution, and visibility contract. Visibility includes `NoAI` fields that must remain hidden from the model. The runtime decides whether an action executes locally, requires user confirmation, or becomes an agent event. L3 specializes in deciding when to render and how to select and bind components, while the substrate handles rendering and execution.

On a 48-case internal gallery, raw HTML required approximately 1,224 output tokens and UI4A approximately 672 tokens, a reduction of approximately 45%. The authors observed up to approximately $6\times$ faster time-to-first-render on interactive cases when UI4A was combined with a non-reasoning LoRA, streaming, and partial rendering. The token comparison did not control output quality or independently establish a latency gain.

UI4A-Bench contains 161 cases with React generation, a pinned compiler and toolchain, headless Chromium, and mobile and desktop viewports. The primary score uses mobile $390\times844$ rendering. Its composite score is:

$$
\text{Composite}=0.08E+0.18T+0.38V+0.20I+0.16C,
$$

where $E$ is Engineering Viability, $T$ Task Quality, $V$ Visual Quality, $I$ Interaction, and $C$ Constraint Adherence.

Venti achieved a UI4A-Bench Final Score of 87.8, compared with 75.9 for Opus 4.8, 72.1 for GPT-5.5, 67.1 for GLM-5.2, 63.0 for MiniMax M3, 62.5 for Qwen 3.7, and 60.3 for Gemini 3.1. Venti’s reported layer scores include 94.2 for Constraint Adherence, 90.0 for Visual Quality, and 95.0 for Interaction.

### 5.2 REPL agent harness

The L1 Agent specialist uses a stateful Python REPL with a persistent namespace. Variables survive across operations, dependent operations can execute within one turn, and intermediate values need not be repeatedly serialized through the model.

In a diagnostic business-operation task producing the exact answer 8208, a one-tool-per-turn substrate required 48 turns, whereas REPL composition required 6 turns. The REPL supports validated helper reuse through `save_tool`, which stages a model-derived helper, and `promote_tool`, which makes it callable only after a private held-out validation run. A bad promoted helper is logged and demoted.

External services enter through `ToolProxy`, which provides Python-shaped wrappers, retry semantics, `NoAI` visibility boundaries, and model-facing signatures aligned with runtime behavior. REPL execution is not universally superior: it performs worse for stateful observe-before-commit APIs and offers little benefit for independent shell tasks. The harness can therefore fall back to discrete calls or shell actions.

A companion BFCL v4 study with 200 tasks reported 49.5% for REPL and 54.0% for function calling. This result is not specific to Macaron-V1-Venti but illustrates a limitation of the substrate.

### 5.3 Personal Intelligence evaluation

Macaron-V1 evaluates Personal Intelligence with ChatBench, LivingBench, VitaBench, VitaBench2, $\tau^3$-Bench, PinchBench, and ClawGym.

ChatBench uses six constitutional axioms: Felt Understanding, Honest Counsel, Authentic Voice, Forward Motion, Calibrated Closeness, and Growing Autonomy. These axioms condition case-specific judgments based on user persona, relationship depth, communication contract, explicit boundaries, core needs, and scenario type. The benchmark score is a judge-mediated 1–5 judgment averaged over three samples per case.

LivingBench contains 40 daily-life scenarios, half Chinese and half English, with at most 10 turns. It simulates partial disclosure, evolving world state, contradictory or noisy observations, tool-result corruption, changing user preferences, resource changes, and social or emotional pressure. Its score is:

$$
S_{\mathrm{case}}=0.7S_{\mathrm{need}}+0.3S_{\mathrm{process}}.
$$

Need fulfillment is a weighted fraction of satisfied checklist items. Process quality averages information integration, tool-use effectiveness, interaction quality, and proactive inquiry on a five-level scale.

## 6. Training, infrastructure, and empirical results

MindForge is the RSI control plane that manages problem banks, evaluation runs, trajectory conversion, training jobs, model versions, parent–successor lineage, HCP artifacts, rewards, and evaluation results. It does not redefine GRPO, REPL, or HCP; it links their artifacts.

MinT manages LoRA reinforcement learning over resident dense and MoE deployments. It distinguishes an immutable serving-compatible adapter revision from a mutable policy record containing base compatibility, adapter shape, trainer checkpoint, optimizer state, rollout records, and exported revisions. Trainer checkpoints and optimizer state do not cross directly into serving.

Reported MinT measurements include an adapter-only handoff that is $18.3\times$ faster than a full merge path for Qwen3-4B with rank 32 and $2.85\times$ faster for Qwen3-30B with rank 16. A packed catalog of $10^6$ Qwen3-30B rank-1 adapters was built with zero errors, with a 256-entry audit sample covering all 100 storage shards. This does not mean that one million adapters reside simultaneously in GPU memory or represent one million independently trained policies.

LongStraw is a response-only long-context reinforcement-learning execution method. It evaluates prompts without autograd, retains only conditioning state, computes old-policy and reference scores without a graph, replays responses serially under autograd, releases each response graph after backward, and finalizes gradients after all group responses. Its memory strategy bounds the graph by the longest response rather than by all prompt-and-response graphs simultaneously. It does not backpropagate through prompt-token computation.

For sparse MoE and DSA systems, Macaron-V1 includes R3 router replay, DSA alignment, and IcePop-style residual filtering. R3 reuses rollout-selected expert IDs in the learner when they are mappable and excludes tokens whose IDs cannot be mapped. DSA alignment addresses indexer rotary-position layout, query/key normalization, deterministic top-$k$ behavior, frozen-indexer defaults, sequence- and context-parallel layout, and LoRA target-module loading. IcePop-style filtering sets importance weights to zero when rollout–learner probability ratios fall outside a trusted interval.

### 6.1 Venti results

Venti’s reported benchmark results are:

| Benchmark | Venti | GLM-5.2 | GPT-5.5 | Opus 4.8 | Gemini 3.1 | Qwen 3.7 | MiniMax M3 |
|---|---:|---:|---:|---:|---:|---:|---:|
| ChatBench | 58.3 | 54.5 | 55.5 | 52.8 | 52.0 | 52.5 | 49.1 |
| LivingBench | 64.0 | 60.5 | 61.9 | 63.8 | 52.1 | 56.1 | 57.1 |
| VitaBench | 60.0 | 55.8 | 55.8 | 56.5 | 55.2 | 61.2 | 56.8 |
| VitaBench2 | 46.0 | 43.1 | 47.4 | 46.3 | 50.2 | 47.6 | 39.4 |
| $\tau^3$-Bench | 69.3 | 69.1 | 61.1 | 67.7 | 67.1 | 63.0 | 61.2 |
| PinchBench | 94.0 | 88.1 | 89.0 | 91.8 | 82.9 | 93.4 | 86.1 |
| ClawGym | 77.7 | 74.6 | 82.5 | 80.5 | 77.5 | 75.7 | 76.2 |
| SWE-Verified | 85.6 | 80.4 | 82.9 | 88.6 | 80.6 | 80.4 | 80.5 |
| TerminalBench 2.1 | 87.6 | 82.7 | 83.4 | 78.9 | 70.7 | 73.5 | 66.0 |
| DeepSWE | 58.4 | 54.9 | 70.0 | 58.0 | 10.0 | 18.0 | 20.0 |
| SWE Atlas QnA | 49.5 | 48.9 | 45.4 | 57.3 | 13.5 | 22.6 | 37.9 |
| UI4A-Bench | 87.8 | 67.1 | 72.1 | 75.9 | 60.3 | 62.5 | 63.0 |

Venti leads the listed values on ChatBench, LivingBench, $\tau^3$-Bench, PinchBench, TerminalBench 2.1, and UI4A-Bench. It trails Qwen 3.7 Max on VitaBench; GPT-5.5 and Opus 4.8 on ClawGym; Opus 4.8 on SWE-Verified and SWE Atlas QnA; and GPT-5.5 on DeepSWE.

Tall exceeded its Qwen3.6 base on all seven matched rows:

| Benchmark | Tall | Qwen3.6 base | Difference |
|---|---:|---:|---:|
| ChatBench | 54.9 | 48.0 | +6.9 |
| LivingBench | 48.4 | 47.1 | +1.3 |
| PinchBench | 86.2 | 82.5 | +3.7 |
| ClawGym | 64.0 | 58.6 | +5.4 |
| SWE-Verified | 75.4 | 73.4 | +2.0 |
| TerminalBench 2.1 | 56.2 | 52.5 | +3.7 |
| UI4A-Bench | 59.3 | 33.9 | +25.4 |

This is an end-to-end comparison rather than a parameter-matched ablation. The systems differ in parameter footprint, adapters, routing, harness behavior, and possibly generation configuration; consequently, the table does not identify which component caused the gains.

## 7. Limitations, evidence boundaries, and open problems

Macaron-V1 demonstrates practical multi-specialist routing, shared-base deployment, UI4A generation, adapter lifecycle management, configuration search, and end-to-end benchmark performance. It does not yet establish the strongest claims associated with open continual learning and collective intelligence.

The paper does not show multiple successive generations, cumulative improvement curves, transfer to unseen tasks, retention across generations, prevention of forgetting, or a controlled separation of weight and harness gains. The 122/122 configuration-search result involved a frozen model and therefore demonstrates harness search rather than model learning.

MoL limitations include routing only one complete user turn to one adapter, difficulty handling multiple intents within a single message, potential information loss through summary compression, additional routing and summarization latency, possible quality trade-offs from KV reuse, absence of broad held-out routing audits, and lack of demonstrated third-party adapter populations. An orchestrator capable of decomposing multi-intent turns into specialist subtasks and composing their outputs is planned but not in production.

Evaluation limitations include internal benchmarks derived from product failures, possible judge-family effects in ChatBench, absence of broad human-agreement and cross-family judge calibration, compressed long-horizon behavior in LivingBench, model-dependent simulator timing, curated rather than deployment-frequency sampling for UI4A, imported baseline values, heterogeneous metrics across benchmarks, and lack of confidence intervals or hypothesis tests.

The safety and governance evidence is also incomplete. The paper does not provide a complete safety or red-team evaluation, full consent and opt-in documentation for product-derived data, a detailed de-identification procedure, residual re-identification audits, data-retention and access controls, complete per-specialist training-data specifications, privacy evaluation for personalized adapters, or safety evaluation for high-stakes decision-support specialists. The authors therefore characterize Macaron-V1 as a systems release rather than evidence of suitability for safety-critical deployment.

Macaron-V1 is best understood as an inspectable systems architecture with four separately revisable layers:

1. **Frozen base model**: shared competence and representation.
2. **LoRA specialists**: differentiated capabilities.
3. **Harness and HCP**: tools, state, prompts, UI, execution, and runtime policy.
4. **MindForge and MinT lifecycle**: experience collection, evaluation, training, lineage, and deployment.

The released system provides evidence that these layers can be integrated operationally. Its claims of compounding continual improvement, capability-preserving evolution, causal MoL advantages, collective intelligence, reliable multi-intent orchestration, and safe open adapter composition remain subjects for future empirical validation.

Source: https://www.emergentmind.com/topics/macaron-v1