A day with Grundlag

The clearest way to see what Grundlag is for is to watch an ordinary day run on top of it.

Meet Sofia. On a small server at home she runs three providers:

• a Calendar provider — events she can create, move, and search;
• a To-dos provider — tasks with due dates and notes;
• a Wiki provider — pages she can read, write, and search.

That is the whole foundation. Each provider models its capability once — as typed actions (“create event”, “add task”), searchable entities (the events, tasks, and pages themselves), and events it emits when something changes. Nothing above the providers knows or cares how the calendar actually talks to her calendar service. From here on, everything is just a different way of using the same primitives.

Morning — the voice assistant

Sofia built her own voice assistant, and it is two agents, not one. A small, fast agent stays on the microphone with just a few tools — read the calendar, read and check off to-dos — so it can answer instantly.

“What’s on today?” The fast agent calls the calendar’s search action and the to-do list action, and reads back her morning in under a second.

“Plan my week around the Thornbury deadline and draft a prep doc.” That is not a quick answer. The fast agent hands the job to a second, slower worker agent and keeps listening. The worker takes its time — reading the calendar, rearranging tasks, writing a page into the wiki — and drops the result on a queue. A minute later the fast agent picks it up: “Done — I blocked out Tuesday and Wednesday, and there’s a prep doc in your wiki.”

Two agents, her exact design, built from the same tools. Grundlag did not hand her an assistant; it gave her the parts to build the one she wanted.

Midday — the to-do app

On her laptop, Sofia uses a perfectly ordinary to-do app: lists, checkboxes, a due-date picker. Nothing about it looks like a “platform.” But it has no backend of its own — it is a UI over the To-dos provider. The tasks it shows are the same tasks the assistant checked off this morning; when the worker agent rearranged her week, the list re-ordered itself.

The app also has a small built-in agent, wired to only the to-do tools: “break this into subtasks”, “clear anything overdue and irrelevant.” It cannot touch her calendar or wiki — it was handed a narrow slice of the same shared layer, and that slice is all it can reach.

Overnight — the script

Sofia climbs. Her gym publishes its class schedule on a public web page and nowhere else — no API, no calendar feed. So she wrote a short script that runs each night: it scrapes the page and, for every class, calls the calendar’s create-event action (or updates the one that moved).

No app gave her permission to do this. The script simply uses the same create-event action the assistant and the to-do app use. And the moment it runs, those climbing sessions appear everywhere — in the to-do app’s agenda widget, in tomorrow’s “what’s on today?”, in the worker agent’s planning. One write, every surface.

Reactivity ties it together

Because providers also emit events, surfaces can react instead of poll. When the script adds a new climbing session, the Calendar provider emits an “event created” signal. Sofia wrote one small automation that listens for it and adds a “pack gym bag” task the evening before. She wrote the rule once; it fires forever — no matter whether the script, the app, or the assistant created the event.

The point

Look at what is not here. There is no “calendar app” that owns her events, no “to-do app” that hoards her tasks behind its own screens. The calendar, the to-dos, and the wiki are capabilities, not apps — and the voice assistant, the to-do UI, the scraper, and the automation are all just different consumers of the same actions, entities, and events.

• Build a provider once, and every surface gains it.
• Give each surface exactly the slice it needs — a narrow agent, a full app, a one-off script.
• Nothing is trapped: the data is hers to read, transform, or move somewhere else entirely.

Sofia’s setup is imagined, and a few pieces of it — like an end-user automation builder — are still on the roadmap. But every capability it leans on is the same handful of primitives the rest of these docs teach you to build.

Ready to build the foundation? Start with Build your first provider, or read the mental model first.