An AI agent that chats, writes code, operates tools, and builds interfaces places very different demands on one model. When very different skills are repeatedly merged into the same post-training parameter space, updates can become harder to validate and may introduce regressions in capabilities that were not meant to change.
A specialist-adapter architecture offers another path: keep shared knowledge in a stable base, train smaller modules for distinct workloads, and route each request to the right execution context. The design pays off only when the team also controls routing, handoffs, and adapter lifecycle.
The architecture described for Macaron-V1 provides a concrete example, with separate LoRA specialists for chat, agent work, coding, and generative interfaces layered on a frozen base model.It is a useful case study in modular post-training, rather than evidence that the same decomposition is optimal for every multi-skill agent.
Look for Specialization Pressure
Do not split a model merely because a product has several menu items. Specialization is justified when workloads need materially different data, evaluation, tools, or update schedules.
Coding offers a clear example. It depends on repository context, terminal actions, test feedback, and precise file edits.
A conversational assistant may need stronger preference handling, ambiguity resolution, and restraint. An interface generator must connect visual structure with valid code and interaction behavior.
These workloads can share language and world knowledge while demanding different post-training signals. If a coding update improves terminal use but weakens conversation, or if interface training must ship on a different cadence, the system is experiencing specialization pressure.
Measure that pressure before redesigning the architecture. Track regression frequency across workloads, the amount of task-specific training data, evaluation time, release cadence, and how often one update must be rolled back because it harmed another capability.
Where possible, compare a shared-adapter baseline against task-specific adapters under similar data and trainable-parameter budgets. Specialization pressure is strongest when improving one workload consistently produces measurable regressions in another.
Give Each Layer One Clear Job
A modular agent needs more than a collection of adapters. Define the role of the base model, each specialist, the router, and the harness.
The base model should hold broad capabilities that every workload needs. An adapter should encode a bounded behavioral or task specialization. The LoRA paper introduced low-rank trainable matrices while freezing pretrained weights, reducing the number of parameters changed for downstream adaptation.
The router selects a specialist from the user’s request and available context. The harness coordinates tools, execution rules, observations, and any external context or memory services the agent depends on. Keeping these roles explicit prevents teams from assigning a routing problem to more training or trying to repair a weak tool interface with another adapter.
Write an ownership statement for each layer. For example, “the coding specialist decides how to modify a repository, while the harness enforces file permissions and runs validation.” That sentence gives evaluators a place to assign failures.
Choose Boundaries by Workload, Not Organization Chart
Specialists should follow stable differences in behavior. Team boundaries are a poor substitute because two groups may work on tasks that need the same model behavior, while one group may own several incompatible workloads.
Define each candidate specialist with four fields: target tasks, reasoning pattern, allowed tools, training sources, and release tests. Merge two candidates when those fields overlap heavily. Split them when evaluation shows repeated interference or when their release schedules cannot be coordinated safely.
Avoid creating a specialist for every narrow feature. Too many adapters increase routing ambiguity, evaluation combinations, handoff complexity, and serving overhead, including the cost of switching model state or rebuilding cached context. A small set of well-defined specialists is easier to observe than dozens of modules with overlapping responsibilities.
Use a fallback path for requests that span boundaries. The router may select a general agent specialist first, then delegate a repository change to coding and return a concise result summary. The user should not have to restate the original goal at each handoff.
Treat Routing as a First-Class System
An accurate specialist is useless when the router sends it the wrong work. Build a routing dataset from real request shapes, including short prompts, mixed-intent requests, corrections, and tasks that change direction halfway through.
Evaluate more than top-choice accuracy. Record the cost of each mistake.
Sending a coding question to chat may produce a weak answer, while sending an ordinary request into a tool-enabled workflow could create unwanted actions. High-risk routes need a stronger confidence threshold or a confirmation step.
Log the selected specialist, the routing event, confidence or candidate scores where the router exposes them, and any later transfer between specialists. Review cases where the user repeats the request, corrects the agent, or abandons the task. These signals often reveal routing failures that a static label set misses.
Keep routing separate from specialist evaluation. First test whether the right module was selected, then test how that module performed. A single end-to-end score cannot tell the team which layer needs work.
Design Handoffs Around Completed Work
Passing the entire conversation between specialists can waste context and spread irrelevant details. Passing too little can erase decisions the next specialist needs. Summary handoffs therefore create a compression trade-off: they reduce repeated context processing, but can also drop constraints or provenance that later specialists need. Evaluate handoff loss explicitly rather than assuming a shorter context is always better.
Use a structured handoff with the user goal, confirmed constraints, completed actions, produced artifacts, unresolved questions, and permission boundaries. Include evidence or references needed to continue, but omit abandoned reasoning paths and raw tool output unless they affect the decision.
Before taking a consequential action, the receiving specialist should verify that the handoff contains the required constraints, artifacts, and permission state. Missing information should trigger clarification rather than silent reconstruction.
Test handoffs with tasks that return to an earlier specialist. For example, chat gathers requirements, coding builds a prototype, and chat explains the result. The final response should preserve the user’s original priorities and accurately describe what was produced.
Control the Adapter Lifecycle
Frozen base weights reduce the scope of a model update, but they do not eliminate system regressions. A new adapter can still conflict with the router, harness, tools, or summary format.
Version every adapter with its base model, training data snapshot, target modules, configuration, and evaluation set. Promote it only after specialist tests, routing tests, handoff tests, and shared regression tests pass. Version adapter + base as one deployable compatibility unit. Treat the base revision and adapter revision as a compatibility pair; promotion records should identify both, not only the adapter version.
Do not assume adapters are interchangeable across base-model revisions. Compatibility must be tested and recorded. When the base changes, rerun the full portfolio because shared behavior may shift even if specialist weights stay the same.
Monitor production by layer. Track route changes, tool errors, handoff retries, specialist-specific quality, and cross-specialist task completion. Layered telemetry makes rollback faster because the team can isolate the module associated with the change.
Decide With a Limited Pilot
Start with two workloads that show clear interference or different release needs. Keep the base and harness fixed, train one adapter for each workload, and compare them with the existing monolithic update process.
Keep the comparison controlled. Use the same frozen base, harness, task data, and evaluation suite, and report differences in trainable parameters, training compute, routing overhead, and serving latency. Otherwise, an apparent specialization gain may simply reflect a larger update budget.
The pilot should answer four questions: Did task quality improve? Did unrelated regressions fall?
Did release and rollback become easier? Did routing and handoff costs remain acceptable?
Did specialization improve enough to justify its serving and evaluation complexity?
If the answer is no, more specialists will add complexity without solving the underlying problem.
Specialist adapters are most useful when modular training aligns with modular operations. Stable boundaries, measurable routing, concise handoffs, and controlled promotion are the pieces that let a shared model support distinct skills without forcing every capability change through the same post-training and release path.
