Multi-Agent Systems: Applied Smart-Home Case

Until now, all our examples revolved around the same domain: an HR assistant. Useful for building a shared vocabulary, but with the risk of making you think these patterns are tricks specific to “office bots”. In this chapter we change the domain radically — a smart home automation system — to show that the same concepts generalize to any problem that requires coordinating multiple specialists.

The scenario: automating a smart apartment

Imagine an apartment with biometric locks, smart thermostats, motorized blinds, security cameras, a refrigerator with an internal camera, and a voice assistant. The user’s command: “Get the house ready, I’m on my way.”

This means setting the temperature to 22°C, opening the blinds, preparing security recognition, checking the refrigerator inventory (and adding to the shopping list if something is missing), and turning on welcome lights if it is night.

A single monolithic agent would have to hold all these rules in one prompt, mixing climate, security, shopping, and lighting — the same problem we saw in HR when a single agent tried to handle vacations, expenses, and sensitive complaints at once.

The architecture: hierarchical decomposition with parallel elements

Using the vocabulary of Agentic architecture patterns: this system is, mainly, a hierarchical task decomposition — the Orchestrator Agent is the “root agent” that receives the command and decomposes it into sub-tasks. But it has a parallel pattern element mixed in: unlike the total-compensation example (where the sub-tasks were synthesized into a single proposal), here the agents act independently — with no final synthesis step, each one executes its part.

Agent	Responsibility	Tools
Orchestrator	Single point of contact; decomposes commands and distributes tasks	System prompt + MCP coordination
Movement and Biometrics	Tracks geolocation and produces preliminary movement or identity signals	GPS, sensors, entry camera
Climate	Controls thermostats and blinds; optimizes consumption	Thermostat API, blinds, energy
Security	Validates identity and applies restrictions by profile and confidence level	Cameras, biometric locks, profile database
Pantry	Monitors inventory; generates shopping lists	Refrigerator camera, supermarket API

Why this does not work as a single agent — the microservices analogy

A single agent handling biometrics, climate control, security, and shopping at the same time would be like a single employee who is simultaneously a receptionist, accountant, HVAC engineer, and security guard — it cannot be an expert in everything. The microservices analogy helps make sense of the separation:

Microservices	Specialized Agents
Each service has a bounded responsibility	Each agent has a bounded domain and tools
They communicate via well-defined APIs	They communicate via MCP or structured messages
A service can evolve behind a stable contract	An agent can be updated if it keeps its input and output contract
The API Gateway routes requests	The Orchestrator decomposes and distributes tasks
Failures can be isolated with timeouts and circuit breakers	Failures can be contained with limits, validation, and fallbacks

What you gain: maintainability (the security agent can be updated without touching climate logic), scalability (each agent uses the model or component its task justifies — movement can be deterministic or cheap, security may need more capacity), and reuse (the same Climate Agent could feed a separate “building energy optimization” flow that did not exist when it was originally designed).

What you do NOT gain: speed automatically. Each extra call and each network hop adds coordination cost — total latency approaches the maximum of the branches when they run in parallel, or the sum when they depend on one another.

The analogy has a limit: separating prompts does not by itself create operational isolation. To get properties similar to microservices you need versioned contracts, timeouts, bounded retries, observability, and truly independent deployments.

The real risk: implicit trust, with a concrete case

In multi-agent systems, a central risk is implicit trust — agents accept other agents’ outputs as absolute truths, with no secondary verification.

Practical case — the visitor mistaken for the owner: the Movement Agent produces an incorrect preliminary identification because of poor lighting or an odd camera angle: identity = "owner", confidence = 0.65. The Security Agent blindly trusts that output, decides “it’s the owner, I can disable restrictions”, and grants access to restricted areas, including disabling the stove lock designed for children. The visitor, a 10-year-old child, reaches the kitchen unsupervised.

The failure mechanism: the first agent is wrong with a confidence insufficient for a high-impact decision; the security agent propagates that misinformation without verifying it; there is no human checkpoint and no secondary signal. It is the same failure mechanism we saw with Finnbot in Part III: a low-level component is wrong and the next one propagates the misinformation because the design assumed total trust.

The mitigation: explicit confidence thresholds

def process_access(identification):
    confidence = identification.confidence

    if confidence >= 0.90:
        return grant_full_access()
    elif confidence >= 0.70:
        return ask_user("Is that you coming in?")
    else:
        return guest_mode()

This turns implicit trust into explicit trust with thresholds: no high-impact decision is taken on intermediate confidence without additional verification, and with low confidence the system restricts instead of assuming the best.

The numbers are illustrative, not universal. A 0.90 score only has that meaning if the model is calibrated: among the predictions it labels with 90% confidence, approximately 90% should be correct under representative conditions. Thresholds should be chosen with evals, separate false positives from false negatives, and be raised when the impact of an error is greater.

When you DO need an LLM orchestrating (and when you do not)

Remembering the Anthropic compiler note from Agentic architecture patterns:

	C compiler (Anthropic)	Our home-automation system
Nature of the task	Technical, with deterministic verification (GCC)	Open-ended interpretation of language and context
Orchestration	By infrastructure (git, file locking)	By LLM (the Orchestrator)
Needs an LLM to orchestrate?	No	Yes, for the open-ended scope described

Interpreting “get the house ready, I’m on my way” requires deciding what “ready” means depending on time, weather, and preferences. An LLM is useful when commands are open-ended and ambiguous. If the system only admitted a closed catalog of commands, deterministic rules could be simpler and safer. The right question is not “use more or less AI?”, but “does this task need to interpret open-ended language, or can it be solved with verifiable states and rules?”.

How a system like this evolves over time

This system does not have to be born complete — it can evolve in phases, each one adding real complexity:

1. Single agent: one call generates instructions for all the systems. It works for simple cases, but degrades when it mixes too many domains.
2. Specialization: the agents are separated — the Orchestrator distributes and each specialist has its own prompt, contract, and tools.
3. Advanced coordination: some agents communicate with each other, not only with the Orchestrator — for example, Climate consults an Energy Agent to optimize consumption. This requires controlling dependencies, permissions, and traceability so you do not create an opaque network.
4. Growing autonomy: the Orchestrator delegates more decisions — the Pantry Agent not only detects that milk is missing, but proposes when to buy it based on price and habits. Purchases with real effects remain subject to limits and approval defined by the user.

Each phase adds complexity and demands more evals (LLM judges and evals), observability, and guardrails (Part III). Sophistication is not free, and you do not need to jump to phase 4 just because it is technically possible.

Chapter summary

• Switching from HR to home automation shows that architecture patterns are general, not tricks of one case.
• This system combines hierarchical decomposition (the Orchestrator) with parallel execution of specialists, with no final synthesis.
• The microservices analogy helps reason about specialization, reuse, and maintainability, but those properties require real isolation and contracts.
• Implicit trust between agents is mitigated with secondary validation and explicit thresholds on calibrated scores.
• Not everything needs an LLM orchestrating: it depends on whether the task requires interpreting open-ended language or can be solved with deterministic logic.
• The system can evolve from a single agent to specialization, agent-to-agent coordination, and greater autonomy, with proportional controls at each phase.