How to set up agentic AI in Home Assistant

As of August 25, 2026, the practical answer is: yes, you can set up agentic AI for smart home automation in Home Assistant, but the reliable version is a bounded assist layer, not a household autopilot. Natural-language control over a small, deliberate set of exposed entities is usable. Automation and configuration drafting are useful when a human reviews the diff. Long autonomous chains that decide, modify, and act across the home without an approval gate still belong in Investigating for a normal household.

The dated baseline matters. Home Assistant 2024.6 first let LLM-based agents such as Gemini and ChatGPT control the home through exposed entities, while keeping the platform’s deterministic intent system in front for known commands and using the LLM where language needed interpretation [1]. The local path is real too: the Ollama integration arrived in Home Assistant 2024.4, is reported by Home Assistant as used by 2.2% of active installations, and its own documentation warns experimenters to expose fewer than 25 entities because smaller local models make more mistakes [2]. In 2025, Home Assistant added more of the pieces that make an agent layer worth wiring carefully: AI Tasks with structured JSON output, MCP client/server integrations, OpenRouter access to 400+ models, AI-powered Suggest, and streaming TTS improvements [3].

What “agentic” means in this Home Assistant setup

Here, agentic AI does not mean giving a chatbot every switch, lock, climate device, script, and YAML file in the house. It means connecting a model to Home Assistant’s Assist pipeline so it can interpret a request, choose from a limited set of exposed entities or tools, return structured output where needed, and draft changes that a person can approve.

That distinction keeps the setup useful. “Turn on the kitchen prep lights for cooking” can map to the right light group if you exposed it. “Draft an automation that lowers the blinds when the west room gets hot” can become a reviewable proposal. “Watch the house, infer what everyone wants, change climate schedules, silence notifications, and rewrite automations overnight” is where the maintenance burden quietly moves from the model demo to the person who has to fix the home later.

Start with a verification loop, not an install day

Before choosing a model, write down the current Home Assistant version, the model or provider, the entity exposure list, and the date you tested it. If that sounds tedious, it is still less tedious than discovering three weeks later that a release, pricing change, or model update turned a working voice command into a creative interpretation of your hallway.

Make a full Home Assistant backup first. If the hub, Wi-Fi, Thread border router, or voice satellite is already fragile, fix that before adding an agent layer. For homes where local control matters during utility events, the same dependency thinking applies as in a grid-emergency Home Assistant setup or a power-outage alert stack: the AI layer should fail closed, not become another reason the house is confusing when the network is stressed.

Choose the model before you expose the home

Model selection is the first real setup decision because it decides your latency, privacy posture, tool-calling behavior, cost ceiling, and tolerance for mistakes. “Cloud” and “local” are not moral categories. Cloud can be faster to make useful and easier to compare. Local can be private and cheap to run, but only if the hardware and model are strong enough for the job you give them. Use the Home LLM Leaderboard as a starting point for model comparison, then rerun the same household tests in your own setup [3].

For a first working setup, use a capable cloud model if you care most about getting the Assist path working quickly, or use Ollama/home-llm if your priority is local experimentation and you accept more testing. If your real goal is YAML drafting rather than live control, a separate drafting workflow is often cleaner; the same boundary shows up in a Gemini Gem Home Assistant coach setup, where the model helps write automation logic without being handed the house.

Cost is usually not the deciding number for small households, but it is worth anchoring. SmartHomeScene’s mid-2026 table listed approximate input-token prices of $0.15 per 1M tokens for gpt-4o-mini, $0.50 for Gemini 3 Flash, and $1.00 for Claude Haiku, with a typical Home Assistant AI interaction estimated at 500–2000 tokens [6]. Those figures can move, so put provider pricing on the monthly re-test list rather than baking it into your idea of what the setup costs.

Expose entities like you expect to debug them

Entity exposure is where most of the safety and reliability work happens. Home Assistant’s fewer-than-25-entities guidance for local LLM experiments is not a cute beginner limit; it is a useful discipline even when the model is hosted and powerful [2]. The smaller the visible world, the easier it is to predict what the agent can do, read the trace when it fails, and keep another household member from becoming your bug report.

Start with entities that are reversible and low consequence: lights, helper booleans, a test script, maybe a media player volume control. Leave locks, garage doors, alarm modes, water valves, ovens, and high-impact climate changes out of the first exposure set unless you have a separate confirmation path. If you need to include climate, expose a script such as “set comfort mode” rather than handing over every raw setpoint.

• Expose groups or scripts with household language, not every underlying device. “Kitchen prep lights” is safer than six individual bulbs with similar names.
• Keep deterministic automations deterministic. If a motion sensor turns on a hallway light today, do not replace that with an LLM decision.
• Give the model nouns it can distinguish. Avoid names such as light one, lamp, lamp old, and lamp new.
• Expose read-only sensors freely only when the information is useful and not sensitive. More context is not automatically better.
• Log every test command with the entity it touched, the model used, and whether the action matched the request.

This is the same shape as least privilege in agent security: restrict tools, scope permissions, validate outputs, and make high-impact operations harder to reach than low-impact ones [7]. Home Assistant’s deterministic-first approach helps here because known intents can still be handled by the non-AI intent engine, with the LLM filling the language gap instead of owning every command path [1][3]. For contrast, ordinary YAML automations such as smart plug routines or a thermostat-and-air-purifier heatwave setup should stay boring unless natural language genuinely removes friction.

Wire Assist before adding extra tools

Use Home Assistant’s “Create a personality with AI” tutorial as the setup anchor for the conversation side: add the AI provider or local model integration, create the conversation agent, define restrained instructions, assign it to an Assist pipeline, and test it in text before voice [8]. Keep the first instruction set plain. The model needs clear boundaries more than it needs a backstory.

1. Install and authenticate the chosen AI integration, or connect the local model endpoint.
2. Create a dedicated conversation agent for testing instead of replacing the household’s working Assist pipeline.
3. Write a short instruction block that says what the agent may control, what it must refuse, and when it should ask for confirmation.
4. Assign the agent to a test Assist pipeline.
5. Run text-only tests against five to ten commands before enabling voice.
6. Only then move the pipeline onto a voice satellite, phone, dashboard microphone, or speaker path.

Do not skip the text phase. It is much easier to see whether the model selected the wrong entity, invented a capability, or answered instead of acting when you are not also debugging microphone pickup, wake words, speech-to-text, and TTS.

Make the voice path responsive enough to survive real use

Voice control fails socially before it fails technically. If the kitchen command takes long enough for someone to repeat it, walk to the switch, or blame Home Assistant, the setup is not done.

Home Assistant’s 2025 streaming-TTS benchmark is why this layer deserves a separate test. In the reported benchmark, time-to-start-speaking dropped from 6.62 seconds to 0.51 seconds for a cloud TTS path, a 13x improvement, and from 5.31 seconds to 0.56 seconds for local Piper, a 9.5x improvement [3]. That number measures when speech starts, not when the whole answer is finished, but it changes the feel of an Assist interaction.

For the first week, test voice with boring commands: turn on a named light group, set a helper mode, ask for a sensor value, and trigger one harmless script. Weather announcements and TTS paths can reuse patterns from a Home Assistant severe-weather alert flow, but the agent should not be the only way a critical alert gets spoken.

Add MCP servers after the conversation agent is boring

MCP is where the setup starts to feel agentic instead of conversational. Home Assistant’s MCP integration documentation covers the client/server path for connecting models and tools [9]. The safe order is still dull: first prove the model can control the small exposed entity set, then attach one MCP server, then test one tool, then add another.

A useful first MCP tool is not the most powerful one. Prefer a read-only or low-impact tool: fetch a calendar summary, inspect a limited Home Assistant state view, or prepare a draft message. Avoid giving the agent broad file access, broad shell access, or unrestricted configuration writes at this stage. If a tool can change the home, decide whether the change is reversible and whether a human should approve it first.

The Home Assistant Community build log “Friday’s Party” is worth reading because it shows the texture of a private agentic build rather than pretending the setup is a single toggle. It works through voice-assistant tooling, private-agent ambitions, and the practical glue needed to make the pieces talk to each other [10]. Treat that kind of build log as evidence of workflow and failure points, not as proof that every local stack will behave the same way in your house.

Use AI Tasks when you need a structured answer

AI Tasks are a better fit than a free-form chat reply when the next step depends on predictable output. Home Assistant’s 2025 AI feature set describes AI Tasks with structured JSON output [3]. That matters because a JSON object can be checked before it becomes a notification, dashboard card, automation draft, or service call.

{
  "task": "draft_automation",
  "allowed_domains": ["light", "input_boolean", "script"],
  "must_not_control": ["lock", "alarm_control_panel", "cover"],
  "output": {
    "summary": "Plain-English description for review",
    "yaml_draft": "Automation draft only, not applied",
    "risks": ["List assumptions and possible unsafe matches"],
    "needs_human_approval": true
  }
}

That example is only an output contract, not a magic safety layer. The useful part is that it forces the model to declare assumptions and keeps the next system from treating a charming paragraph as an instruction. If the output cannot be parsed, validated, and reviewed, it should not proceed.

Let the agent draft configuration, then approve the diff

The reason for a draft-first pattern is not theoretical. Evan King’s HomeGPT experiment documented a model hallucinating a “party scene” field that did not exist in the Hue API, which is exactly the kind of plausible output that looks helpful until a real integration has to reject or survive it [11]. The engineering problem is not getting an LLM to produce something that looks like configuration. The problem is filtering, validating, and containing it.

The Home Assistant Configuration Agent example shows the safer shape for actual changes: diff before apply, automatic backups, check_config validation, atomic writes, rollback, path-traversal protection, AppArmor hardening, and auto_approve off by default [12]. That is the pattern to copy even if you do not use that exact project.

1. Agent drafts the automation, script, helper, or configuration change.
2. The system renders a diff against the current Home Assistant files.
3. Home Assistant configuration validation runs before anything is applied.
4. A backup is created automatically.
5. A human approves the change.
6. The change is applied atomically, then tested with the actual entity states.
7. Rollback remains available if the household reports weird behavior later.

This is where agentic AI can be genuinely useful. It can turn “make the entry lights act occupied when we are away” into a first draft faster than starting from a blank file. It still should not silently decide that your alarm mode, lock state, or HVAC schedule needed improvement while you were asleep.

Do not overread the research benchmarks

Research systems are useful for direction, not household guarantees. IoTGPT, published on arXiv in January 2026, reported up to 85.43% higher successful-task rates, 78.40% lower latency, and 44% lower cost versus Sasha and SAGE in its evaluation; the same paper reported SAGE taking up to 151 seconds and $4.2 per instruction on complex tasks, and Sasha reaching only 49.48% success on GPT-4o [13]. Those are strong benchmark claims, but the evaluation was on a virtual SmartThings testbed, not a messy consumer Home Assistant deployment with your entity names, Wi-Fi, household habits, and half-forgotten automations.

Use benchmarks to decide what to test next. Do not use them to skip the test. A model that performs well on a published task set can still confuse two similarly named lights, call the wrong service, ignore a household convention, or draft YAML that validates but does the wrong thing on Tuesday night.

The first-week test plan

Run this before the setup graduates from experiment to household feature. Keep the exposed set under 25 entities for the first pass, even if you chose a strong cloud model. Use the same commands each time so a later model or integration change has something to be compared against.

Verification checklist for August 25, 2026

Use this as the status sheet for the setup described above. The labels are deliberately conservative: Confirmed means the platform capability exists and can be verified in a narrow Home Assistant setup; Workaround means it can be useful with extra constraints; Investigating means it should not be trusted for ordinary household control without more evidence and containment.

That is the durable setup: narrow, explicit, reversible, and re-tested monthly. If Home Assistant releases, model behavior, integration docs, or provider pricing change, yesterday’s Confirmed can become tomorrow’s Workaround or Investigating.

References

1. AI agents for the smart home. Home Assistant. 2024-06-07.
2. Ollama. Home Assistant.
3. Building the AI-powered local smart home. Home Assistant. 2025-09-11.
4. acon96/home-llm. GitHub.
5. Transforming smart home privacy and latency with local LLM inference on Arm devices. Arm Developer. 2025-08.
6. Home Assistant AI: Everything You Need To Know. SmartHomeScene.
7. AI Agent Security Cheat Sheet. OWASP.
8. Create a personality with AI. Home Assistant.
9. Model Context Protocol. Home Assistant.
10. Friday's Party: Creating a Private, Agentic AI using Voice Assistant tools. Home Assistant Community.
11. HomeGPT. Evan King.
12. Introducing HA Configuration Agent - AI-Powered Home Assistant Configuration Assistant with Approval Workflow. Home Assistant Community. 2025-10.
13. IoTGPT. arXiv. 2026-01.