Welcome to home-assistant-vibecode-agent Discussions!

[Coolver]

👋 Welcome!

We’re using Discussions as a place to connect with other members of our community. We hope that you:

• Ask questions you’re wondering about.
• Share ideas.
• Engage with other community members.
• Welcome others and are open-minded. Remember that this is a community we
  build together 💪.

To get started, comment below with an introduction of yourself and tell us about what you do with this community

[olomouckyorel]

​Hi, following up on the MCP discussion. I’d like to share a concept for an autonomous development pipeline for self-learners (e.g., in Home Assistant), where I see a crucial role for your tool.
​The concept is built on 4 layers, ranging from static data to collective intelligence:
​Knowledge Base (Deep Research): "Distilled data" (MD files created from documentation and forums) serve as a Single Source of Truth to prevent AI hallucinations.
​Context Injection (Cursor Rules): We feed this data directly into the project context (via .cursorrules), so the model knows hardware limits and best practices before it writes a single line of code.
​Orchestration (Agentic Workflow): Using Composer to simulate sequential roles: Architect (design) -> Analyst (check against the Knowledge Base) -> Coder (final output).
​Evolution & Error Sharing (The Missing Link):
​This is where the system is currently blind. We need a feedback loop mechanism where failed solutions (what didn't work) are automatically fed back into the base as "negative examples."
​The goal is a shared community database of "fails & fixes." When one user encounters an automation error, their agent learns from it, and your agent won't make that same mistake tomorrow.
​Question regarding MCP integration:
Most solutions handle data flow "in" (reading state). Does your MCP bridge allow (or do you plan to support) flow "out" – i.e., writing back to some shared knowledge structure?
​I imagine MCP not just serving context, but acting as an interface for synchronizing this "community wisdom," so a local Cursor instance can learn from the global errors of other users.
​Thanks for your thoughts!

[Coolver]

@olomouckyorel thanks a lot for sharing this - this is honestly one of the most thoughtful “big picture” ideas I’ve seen around HA + MCP + self-learning workflows

I really like your 4-layer model:

Knowledge Base (distilled docs / forums)

Context Injection via rules / prompts

Agentic Orchestration (Architect → Analyst → Coder)

Evolution & Error Sharing (the missing feedback loop)

I’ve been thinking in a similar direction myself, but every time I got to layer 4, I kept running into non-technical problems.

On the “feedback loop” idea

“We need a feedback loop mechanism where failed solutions are fed back as negative examples… so your agent won’t make that same mistake tomorrow.”

In theory - absolutely yes.
In practice, there are a few tricky questions:

How does the system know that something is truly “good” (or “bad”)?
The only reliable label is the user’s feedback:

“Thanks, this works perfectly” ✅

“No, this is wrong” ❌
Most of the time users:

just stop (because the task is done), or

change topic, or

get tired and drop the session.
From the system’s point of view, that’s ambiguous: was the last solution good enough, or did they just give up?

Poisoning / malicious patterns
If we start automatically feeding “community wisdom” back into a global knowledge base, we also open the door to:

users intentionally crafting prompts / patterns that do harmful things,

and those patterns later being reused by others without them realizing it.

Because of this, a completely autonomous “everyone feeds in, everyone consumes” loop can drift into something unsafe or low-quality pretty quickly.

How MCP fits: “in” vs “out”

Right now my HA MCP server is mostly focused on “in”:

giving the IDE/LLM eyes and hands inside Home Assistant

reading config, entities, logs

making targeted changes in a git-tracked, reversible way

Technically, nothing stops MCP tools from also supporting “out” flows, e.g.:

writing structured records (fail/success + context) into a local knowledge store (MD files, JSON, a repo),

or calling an external API to submit anonymized “fail & fix” examples to a shared service.

So yes, MCP can absolutely be the interface for synchronizing that “community wisdom”. It’s just not implemented in my agent yet, and I’d want to think very carefully about:

what exactly is shared (no raw configs / secrets / private HA details),

who curates it (trusted maintainers vs fully open),

how examples are validated before they’re treated as “best practice”.

A pragmatic path I see

The most realistic first step (in my opinion) would be:

Start with a curated set of trusted contributors
People who:

already build good HA setups,

are willing to share patterns and “fail & fix” stories,

and use the agent as a tool to produce those examples.

Moderate and review before publishing
Don’t let raw logs/flows go straight into a global KB.
Instead:

extract patterns,

clean and anonymize,

tag them (“sensor lag issues”, “template error”, “race condition in automation”, etc.).

Then gradually automate parts of this
Once we have a clear idea of what “good examples” look like, we can start teaching the system to:

propose candidates for “fail & fix” snippets,

auto-summarize them,

and suggest them to a human for approval.

Over time that can evolve into something close to the autonomous learning loop you describe – a kind of “community brain of HA fails & fixes” that MCP clients can pull context from.

Where I stand now

So to answer your direct question:

Does your MCP bridge allow (or do you plan to support) flow “out” - i.e., writing back to some shared knowledge structure?

Right now:
The HA Vibecode Agent + MCP server mostly support reading from HA and writing back to HA (config, automations, dashboards) with git-based safety. There is no global/shared knowledge sync yet.

Technically:
MCP is a good fit for exactly this sort of “outbound sync” - adding tools that append to a local KB, or submit anonymized examples to a shared service.

Conceptually:
I really like your idea, but I’d want to design it carefully around trust, privacy and validation, not just “log everything and hope for the best”.

I’d be very happy to keep thinking about this together - especially if we can define what a minimal first version of that “fails & fixes” loop would look like (on-disk format, anonymization rules, who writes/reads it, etc.).

Because yes, I think we’re all a bit tired of copy-pasting Markdown into prompts just to stop the model from repeating the same mistakes every time

[kristof-dragon]

Hi,

would you consider releasing the agent as a standalone docker instead of an add-on?

[Coolver]

@kristof-dragon Great question - I’ve actually been thinking about this, but I haven’t yet found the best way to approach it.
Right now the agent runs as a Home Assistant OS add-on, which under the hood is already a Docker container. The important part is that HAOS/Supervisor sets up the environment for it automatically:

mounts the right folders (like /config),

wires it into the internal HA network,

exposes the internal APIs it needs.

With a standalone Docker image it gets trickier, because it would be running in all kinds of different environments. There’s no single docker-compose.yml that would “just work” for everyone - most likely I could only provide a template, and each user would need to fill in:

where their /config actually lives,

how to reach Home Assistant (HA_URL, network, ports),

what token/credentials to use, etc.

I’m definitely open to providing a Docker image, but I’d like to understand better what you expect from it in your setup.

How do you imagine such a container should look in practice?
For example:

Are you running HA in Container / docker-compose / Proxmox / k8s?

What volumes / env vars / ports would you expect to configure?

Do you have an example of a similar “sidecar” container for another tool that you like?

If you’re willing to share your ideas or a reference implementation you like, that would really help me design a Docker version that’s actually usable and not just “here’s a random image, good luck wiring it”

[kristof-dragon]

Hi @Coolver ,

Thank you for the detailed response and I feel that I might approach this from a niche perspective.
I am running multiple Home Assistant instances as docker-compose (Core) installations and really enjoy that I can move the instances freely between arm sbcs and x86 based docker hosts. This allows me to run a smaller instance on an rpi3 docker (very very light use), for a different environment on an Orange Pi 5+ and in an other environment on an Orangepi 3B sbc. I migrated to the OP5+ from x86 docker and HA OS.

I am not familiar with what functions (as in ports, folders and other/internal API connection points) the Add-ons provide, but I get the seamless nature of the installation method. I would be happy to trade the seamlessness for the small upfront "inconvenience" of configuring the additional service (the vibe coding agent) in the docker-compose.yml as an additional service to keep the lightweightness and mobility of the whole installation.

I used Z2MQTT docker as an additional service/docker along the core installation but then switched to ZHA as that was more then sufficient for my needs. (but that is the extent of a "sidecar" container example I can give, that I used)

Would the standalone/"sidecar" docker implementation pose a restriction to the agent?

Again, as I prefer using bind mounts compared to volumes I have the mind set, that everything that is required can be mapped into the same folder where the docker-compose.yml lives. (I might be overlooking things)
By default the whole of the /config folder is mapped to the folder where the compose.yml lives, which includes pretty much all folders. (I might be wrong here)

For me the idea would be to add the agent alongside the core installation to allow one desktop/main computer to connect to several instances and manage the automations and other tasks separately without requireing a fully blown HA OS either bare metal or in a VM (which in most cases implies an x86 based virtualised environment).

Happy to test run things or help.

[erasmus83]

+1 for the Docker capability. I also run HA in a standalone Docker instance, which is not unusual.

Happy to provide info & participate in testing