Hearth Turns Family Notes Into Apps

Hearth is a Show HN project built by its creator for his own family: a shared household workspace for plans, notes, schedules, people, rituals, and small apps. It deals with a question many agentic coding teams keep circling: what happens when an AI agent is not just in a repo, but inside the context where work actually happens? The useful takeaway is simple: the safer agent pattern is not “let it do everything,” but “give it a bounded workspace, clear context, and reviewable outputs.”

A household agent workspace is a shared place where people, notes, calendar-like data, and generated tools live together under one context boundary. Hearth makes that idea feel concrete because the agent can build apps on top of the family’s notes and run those apps inside the same workspace.

Start with the household, not the agent

The interesting part of Hearth is not that it has an AI agent. Lots of products do.

The interesting part is the unit of context. Hearth is organized around a household: travel plans, recurring family rituals, schedules, people, notes, and the small bits of operational memory that usually end up scattered across messages, docs, calendars, and someone’s head.

In the Show HN post, the author described it as “kind of like a shared Obsidian with an agent,” and also said the agent can build apps inside that same workspace. Examples included a calendar app, a travel app, and a separate Hearth used to manage company operations.

That last detail is why developers cared. Hearth is not just a family dashboard. It is a small test case for what happens when an agent can read a shared knowledge base, create tools from it, and keep those tools close to the source material.

The trap is treating this like a generic chatbot feature. A chatbot answers from context. Hearth’s stronger claim is that context can become software.

The app-building trick is the real signal

Hearth points at a pattern that keeps showing up in agentic coding: the agent becomes more useful when it can create a narrow tool instead of producing one-off text.

A family travel note might turn into a packing checklist app. A recurring dinner plan might turn into a lightweight rotation app. A school schedule might become a view that shows only the next action for each child.

That is not glamorous software. It is exactly why it matters.

Most internal tools are small, contextual, and too annoying to build by hand. Hearth’s pitch is that an agent with the right household context can generate those tools where the users already live, instead of asking someone to open a ticket, explain the domain, wait for a backlog slot, and maintain yet another app.

For Cursor users, this maps cleanly to the IDE. Cursor, Anysphere’s AI code editor, gives developers an agent that can work across code and project context. Hearth asks the same design question from the other side: what if the workspace itself is the product, and the generated app is just another object inside it?

The trap is skipping the boring permissions question. If an agent can build apps from shared context, it also needs boundaries around which notes it can read, what it can change, and who approves a generated tool before everyone depends on it.

Developers cared about interfaces and devices

The Hacker News response quickly moved from “cool demo” to “how would this work in a real home?” One natural question was how Hearth could connect to different devices in the house. Another was what the interface looks like for different family members.

Those are not side issues. They are the product.

A household workspace has to survive uneven users. One person may want a dense planning surface. Another may only want a phone notification. A child may need a simplified view. A guest or caregiver may need temporary access to one list, not the whole family archive.

The same lesson applies to engineering workflows. Agentic coding is rarely blocked by model capability alone. It is blocked by unclear surfaces: where the agent may act, what it may see, and how a human can review the result without replaying a whole chat transcript.

This is where MCP, the Model Context Protocol, becomes relevant without turning Hearth into an infrastructure story. MCP is an open protocol for connecting AI systems to external tools and data sources. If a Hearth-like workspace ever talks to home devices, calendars, or private stores, the connector boundary matters as much as the agent prompt.

The trap is wiring everything together before deciding what should be read-only. The first useful integration is often the safest one: show the family schedule, do not rewrite it.

Try the pattern in Cursor before copying the product

You do not need to build a family operating system to learn from Hearth. Try the pattern on a tiny internal workflow first: one shared context file, one generated app or script, and one review checklist.

A good Cursor experiment is a “team ritual helper” in a repo. Put the ritual in docs/rituals/release-note.md, add a rule that tells the agent what it may touch, and ask it to generate a small script or page that turns the note into a reviewable artifact.

This is where the related training topic becomes practical. Good AI coding governance is not a binder of policies. It is a set of small boundaries that make agent output easy to inspect.

Here is a lightweight Cursor rule stub for the experiment:

# .cursor/rules/release-ritual.mdc
---
description: Use when updating the release-note ritual helper or generated release checklist.
globs:
  - "docs/rituals/release-note.md"
  - "scripts/release-checklist.*"
  - "app/release-checklist/**"
---

The agent may read docs/rituals/release-note.md and generate helper code from it.

Do not edit package manager files, deployment config, auth code, or database migrations.

Before changing code, summarize:
- which ritual text is being converted into behavior
- which files will change
- what a human should review manually

Generated UI must show the source note path and last edited date when available.

That little rule does three useful things. It narrows the workspace. It forces the agent to name the source context. It gives reviewers a short receipt before code changes land.

The trap is asking the agent to “make a dashboard for our process” with no boundary. That is how a useful experiment turns into a mystery diff.

Use this fit check before you try it

Hearth is worth studying when the context is shared, repeated, and annoying to translate into tools by hand. It is overkill when the job is a single note, a one-off answer, or data that should not be exposed to an agent at all.

Fit	Good sign	Watch out
Shared household or team context	The same people reuse the same plans, schedules, and rituals	Private notes need clear visibility rules
Small internal apps	The app is mostly a view or workflow over existing notes	The generated app becomes critical infrastructure too early
Device or service connections	Read-only access would already save time	Write access can surprise people fast
Cursor-style repo experiment	The agent can work inside a narrow file boundary	Reviewers cannot tell which context shaped the output
MCP connector idea	One external system has a clear permission model	Too many integrations arrive before trust does

A safe first experiment should be boring. Pick one repeated workflow, one source document, and one generated output. If nobody can explain the boundary in one sentence, shrink it.

This also connects to other agent routing experiments, like FEDERaiDE Routes Agents in Your Terminal, where the useful question is not “can the agent act?” but “which agent gets which context and which permission?”

Common questions

• Is Hearth an AI coding tool?

  Not exactly. Hearth is a shared household workspace with an AI agent that can build apps inside that workspace. Developers care because it demonstrates an agentic coding pattern outside the IDE: generate small, contextual software from shared notes, then run it near the context that produced it.

• How can Hearth connect to devices in my home?

  The public Show HN discussion raised that question, but the available project description does not specify a device integration model. The safe design would start with read-only connectors, clear permission prompts, and separate access for calendars, sensors, or home automation systems before allowing write actions.

• What does Hearth look like for different family members?

  The project description frames Hearth as a shared household workspace, so different views are the natural hard problem. A parent, child, guest, or caregiver should not need the same interface or permissions. The important artifact is a permission table, not a prettier chat box.

• Should an engineering team copy Hearth’s pattern?

  Yes, but only at the pattern level first. Try one shared context file and one generated helper before building a platform. In Cursor, that means a scoped rule, a narrow glob, and a review checklist that shows which source context shaped the agent’s code.

• Where does MCP fit in this story?

  MCP fits when the workspace needs external context from tools like calendars, databases, document stores, or home systems. It should not be the first thing you add. The first boundary is local: what the agent can read, what it can edit, and what humans must approve.

Best ways to use this research

• Best for: Cursor users thinking about how coding agents should work over shared context, not just isolated files.
• Best first artifact: A small .mdc rule that limits the agent to one ritual, one generated helper, and one reviewable diff.
• Best comparison angle: Compare Hearth-style embedded apps with IDE agents: one starts from household context, the other starts from code context.
• Best safety question: Ask what should be read-only first. If the answer is unclear, the workspace is not ready for write-capable agents.

Further reading

• Cursor — Agent
• Model Context Protocol — specification
• Claude Code — getting started
• Hearth — project site

Keep the experiment small

Hearth is a useful signal because it makes agent-built software feel domestic, specific, and reviewable. Try the smallest version in Cursor: one shared note, one generated tool, one boundary file, and one human review before the agent touches anything wider.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.