The ML engineer reviewing the architecture document read the line twice: thirty models. Not one foundation model fine-tuned for multiple tasks. Not two models with a routing layer. Thirty. She had spent five years deploying large language models at a cloud platform company, and the instinct was immediate: this is fragile, this is expensive, this is over-engineered. Then she read the constraint set, and the decomposition started to make sense.
The constraints are five, and they compound. A single model large enough to handle all thirteen concierge domains at production quality cannot run on an edge device. A model that runs in the cloud cannot meet sub-100-millisecond latency for safety-critical functions like fall detection or medication interaction checking. A monolithic model cannot be updated incrementally: improving the nutrition analysis requires retraining the entire model, touching capabilities that were working fine. A model that requires continuous cloud connectivity fails the person when the internet goes down, which happens precisely when reliability matters most. And a monolithic model cannot be split across compute zones with different privacy boundaries, which forecloses the three-zone deployment architecture that the rest of the platform depends on.
No single model satisfies all five constraints simultaneously. Thirty specialized models satisfy all of them.
The five constraints#
Latency is the first constraint and the hardest. When the Safety Monitor detects a potential fall, the response time budget is 200 milliseconds from sensor signal to alert. A cloud round-trip adds 50 to 150 milliseconds of network latency before the model even begins inference. A large model adds inference time proportional to its parameter count. The math does not work. The Safety Monitor must run on the edge device, which means it must be small enough to load into device memory and fast enough to infer within the remaining time budget after sensor processing.
Privacy is the second constraint. Health data, financial data, cognitive assessment data, and personal correspondence contain information that should never leave the person’s device unless she explicitly consents. A cloud-only architecture means every query sends this data to a remote server. An edge architecture means the data stays on the device, processed by models that run locally. The privacy constraint is not about encryption in transit. It is about whether the data leaves at all. For a person whose health data includes cognitive assessments, medication lists, and daily behavioral patterns, the difference between “encrypted in transit” and “never transmitted” is the difference between a privacy policy and privacy.
Incrementality is the third constraint. The Nutrition Guide model needs updating when new dietary research emerges. In a monolithic architecture, updating the nutrition capability means retraining or fine-tuning the entire model, risking regression in unrelated capabilities. Regression testing for a 7-billion-parameter model across all thirteen domains takes days and catches only the regressions the test suite covers. In a decomposed architecture, the Nutrition Guide is a 50-million-parameter model that can be retrained independently in hours on consumer-grade hardware. The validation scope is nutrition only. The Medication Assistant, the Safety Monitor, and the twenty-seven other models are unaffected. No regression testing needed for capabilities that were not touched.
Resilience is the fourth constraint. The person the system serves is 78 years old, lives in a house where the internet drops during storms, and needs the system most when conditions are worst. A cloud-dependent architecture fails during outages. An edge architecture continues operating. The Safety Monitor still detects falls. The Medication Assistant still tracks schedules. The Orientation Assistant still provides memory support. The system operates in a degraded mode during outages: complex reasoning that requires cloud resources is deferred, but safety monitoring, medication management, and cognitive support continue uninterrupted. Degraded capability in some domains is acceptable. Complete failure in all domains is not.
Deployability is the fifth constraint. The thirty models distribute across a three-zone compute architecture (BMT-06.03). Privacy-critical models target Zone 1, the Local Pane device in the person’s home, for subscribers who have one. For those subscribers, cognitive, emotional, voice, and safety inference happens on hardware she can see and touch. Heavy inference models target Zone 2, a regional Community Pane node that serves 150 to 500 subscribers from a co-location facility or care agency office, for subscribers in regions where Zone 2 has deployed. Zone 3 (the cloud reasoning layer) handles deep multi-domain reasoning, novel queries beyond Zone 2’s capacity, and the full inference workload for subscribers without a Local Pane and outside a deployed Zone 2 region. A monolithic model cannot be split across zones with different privacy boundaries, and a monolithic model cannot be selectively deployed to different subscribers based on which zones they have access to. A decomposed portfolio can do both: it places each model where its task requirements dictate (the Cognitive State Estimator targets Zone 1 because that is the strongest privacy posture available for cognitive data; the Response Generator targets Zone 2 because conversational generation benefits from access to the full context); and it routes each subscriber’s queries through her available zones rather than requiring uniform hardware. The decomposition is what makes the three-zone architecture both deployable and equitable: the architecture serves subscribers with a Local Pane, subscribers without a Local Pane in a Zone 2 region, and subscribers without either (Zone 3-only path), as first-class deployments.
The five model categories#
The thirty models organize into categories defined by function, not by domain.
Core Interaction models handle the person-facing conversation. The Conversation Manager maintains dialogue state across multi-turn exchanges. The Intent Classifier determines what the person is asking for, routing the query to the appropriate concierge domain. The Emotion Detector reads affective signals from text, voice tone, and interaction patterns, enabling the system to adjust its communication style when the person is frustrated, confused, or distressed. The Response Generator produces natural language output. The Safety Monitor screens every interaction for safety-critical signals: fall indicators, medication errors, signs of cognitive crisis, expressions of self-harm. The Empathy Responder generates responses calibrated to emotional context, handling moments where the correct response is empathetic acknowledgment rather than information delivery. The Clarification Agent handles ambiguous queries by generating targeted follow-up questions. The Voice Tone Analyzer processes audio signals for stress, confusion, or distress markers that the text content alone may not reveal. These eight models form the conversational surface that the person interacts with directly.
Memory Care models serve the cognitive support domain. The Orientation Assistant provides temporal and spatial grounding for people with memory conditions, answering questions like “What day is it?” and “Where am I?” with patience and without condescension regardless of how many times the question is asked. The Memory Anchor reinforces important information through structured repetition calibrated to the person’s retention patterns. The Cognitive State Estimator tracks cognitive function continuously through interaction patterns, response latency, and linguistic complexity, providing a real-time cognitive profile without requiring formal assessment. The Repetition Handler responds to repeated questions with consistent information while varying the phrasing to feel natural. The Agitation Detector identifies behavioral markers of agitation or distress through voice patterns, interaction frequency, and language changes. The Sundowning Specialist manages late-afternoon cognitive changes specific to dementia, adjusting interaction style, lighting recommendations, and caregiver notifications based on time-of-day cognitive patterns. These six models constitute the most safety-critical category, where latency and accuracy requirements are highest and where failure has the most immediate human consequences.
Context Management models power the personalization layer. The MoC Router (BMT-05.01) selects context layers for each interaction, determining which of the five memory layers to activate. The Context Compressor reduces context packages to fit within model input limits while preserving the information most relevant to the current query. The Preference Learner implements P-RLHF (BMT-05.02), continuously updating the person’s preference model from behavioral signals. The Pattern Detector identifies behavioral patterns across time: daily routines, weekly cycles, seasonal variations. The Temporal Reasoner processes longitudinal data to detect trends and transitions. The Relationship Mapper tracks the person’s social network and relationship dynamics, understanding who matters to the person and in what context. These six models are infrastructure: the person never interacts with them directly, but every interaction depends on them.
Domain Expert models provide specialized knowledge. The Medication Assistant handles drug interactions, side effects, and adherence tracking, drawing on pharmacological databases to flag potential conflicts before they reach the person. The Health Monitor processes vital signs and health metrics from connected devices, maintaining running baselines and alerting when readings deviate from the person’s established norms. The Activity Suggester recommends activities calibrated to capability and preference, adjusting for weather, energy level, mobility, and social context. The Nutrition Guide provides dietary guidance informed by the person’s conditions, medications, cultural preferences, and budget. The Sleep Analyzer processes sleep pattern data from wearable sensors to identify disruptions and correlate them with medication changes, activity levels, or environmental factors. The Exercise Coach manages physical activity recommendations within the bounds of the person’s medical clearance and physical capability. These six models apply domain expertise to the person’s specific context, and each connects to the MoC personalization layer to calibrate its recommendations to Margaret rather than to the population average.
Specialized Function models handle cross-cutting tasks. The Speech-to-Intent model converts voice input to structured intent representations, enabling the person to interact by speaking rather than typing. The Text Simplifier adjusts language complexity based on the person’s cognitive state and preferences, translating clinical language into plain language when the person needs it and preserving clinical precision when the person prefers it. The Cultural Adapter adjusts content framing for cultural context, including language register, dietary norms, family role expectations, and communication style. The Privacy Filter screens outgoing data to ensure consent compliance before any information leaves the system (BMT-05.05). These four models serve every concierge agent rather than belonging to any single domain.
The resource budget#
The decomposition produces a system that is smaller than a single general-purpose model. Total stored parameters across all thirty models: approximately 1.55 billion. After AWQ 4-bit quantization, total storage: approximately 1.7 gigabytes. Active parameters per inference: approximately 450 million, because the MoE models activate only relevant experts per query and most interactions invoke five to eight models, not all thirty.
The active parameter count is the number that matters for inference speed and power consumption. A query about medication interactions activates the Intent Classifier, the Safety Monitor, the Medication Assistant, the MoC Router, the Context Compressor, the Response Generator, and the Privacy Filter. Seven models. Approximately 300 million parameters active. The remaining twenty-three models are dormant: loaded in memory but not consuming compute cycles. The effective model during any given interaction is smaller than many single-purpose chatbots.
The budget fits comfortably on the three-zone deployment architecture. Zone 1 (the Local Pane in the home) holds approximately 850 million parameters across eight privacy-critical models, fitting in roughly 425 megabytes after quantization, well within the 8-to-16-gigabyte memory budget of the consumer edge device. Zone 2 (the regional Community Pane node) holds approximately 1.15 billion parameters across the remaining twenty-two models, fitting in roughly 575 megabytes, with abundant headroom on the regional node’s compute capacity. The system is not competing for memory on either tier. It is a small tenant in a large space at each zone.
At launch (Phase 1), no proprietary models run in any subscriber-facing zone. Zone 1 has not deployed for any subscriber and Zone 2 has not deployed in any region. Zone 3 (the cloud reasoning layer fulfilled by a commercial provider under a healthcare data processing agreement) handles every query for every subscriber. The thirty-model portfolio described in this article is the Phase 3 maturity target, not the launch-day deployment. The pipeline that produces the proprietary SLMs from synthetic data and accumulated real-interaction data is described in BMT-06.04. The portfolio deploys over twenty-four to thirty-six months: Zone 1 Tiny LMs first for subscribers who acquire a Local Pane (Phase 2), then the broader Zone 2 portfolio as regional nodes deploy (Phase 3). Zone 3 continues throughout, handling deep reasoning and serving Zone 3-only subscribers in full.
The comparison to a monolithic alternative clarifies the economics. A 7-billion-parameter general-purpose model, quantized to 4 bits, requires approximately 3.5 gigabytes of storage and loads the full 7 billion parameters for every inference regardless of query complexity. The thirty-model portfolio stores 1.55 billion parameters and activates 450 million per inference. Smaller storage, fewer active parameters, faster inference, better privacy, incremental updateability. The decomposition is not a compromise. It is an improvement on every axis that matters for this deployment context.
The incrementality argument#
The practical consequence of decomposition is that the system can improve one capability at a time. The Nutrition Guide needs retraining because new research on protein requirements for older adults has been published. In a monolithic architecture, this update touches everything. In the decomposed architecture, the team retrains a 50-million-parameter model, validates it against the held-out test set, deploys it alongside the current version for A/B testing, and promotes it to production when it passes. Total retraining time: hours, not days. Total affected capability: nutrition guidance. Total regression risk: zero for the other twenty-nine models.
This incrementality is what makes continuous improvement practical. The system does not need a major release cycle to improve one domain. It needs a model update, a validation pass, and a deployment swap. The person gets better nutrition guidance next week. She does not wait for the next platform release.
The incrementality also enables specialization depth that monolithic models cannot match. Each model can be trained on domain-specific data, evaluated against domain-specific benchmarks, and optimized for domain-specific accuracy targets. The Medication Assistant is trained on pharmacological data and evaluated against drug interaction databases. The Cognitive State Estimator is trained on clinical cognitive assessment data and evaluated against neuropsychological benchmarks. A monolithic model trained on all domains simultaneously must balance competing optimization targets. The decomposed portfolio lets each model pursue depth in its domain without compromising other domains.
Cross-References#
BMT-02.03 The Thirty Models. The orchestration-level view of how the thirty models are coordinated by the SLM Orchestrator, compared to this article’s focus on why thirty models exist.
BMT-06.02 The Right Architecture for the Right Task. Architecture selection per model, explaining why different models use SSMs, MoE, Transformers, or hybrid architectures.
BMT-09.01 Where It Runs. Device tier deployment, mapping the thirty models to specific hardware targets and quantization levels.
Technical Appendix BMT-06.01-A is available to partners and investors at partners.bluemirror.tech.