Grundlag

Escape the app model

Think about the apps on your phone. Each one exists to serve a purpose — it holds some data, does some things, reacts to some events. That’s fine right up until you want something their designers didn’t build for you. Automate a task? It all runs through the interface. Pull data out of one app, reshape it, push it into another? Only if two vendors agreed to make their data interchange. The capability is real, but it’s trapped behind the app.

Grundlag inverts that. The primitives — the things you can do (actions), the things you know (data), and the things that happen (events) — live in a shared layer instead of inside any one app. You can still build an app-like experience on top and get back everything you have today, but the walls are gone: data can be read, transformed, and moved freely — into another Grundlag-based system, or out of it entirely. Data, action, and reactivity freedom.

Thinking “but everything already has an API”? Why Grundlag? answers that head-on — it’s the difference between integrating each service once and re-integrating it into every platform you touch.

Building blocks, not a product

Grundlag doesn’t hand you a server to host or an assistant to run — it hands you the pieces to build your own, to your exact specification. A provider models a capability once — a calendar, a messaging service, a device network — as typed actions, searchable entities, and reactive events, with nothing about a specific app leaking in. It’s the foundation the rest stands on, which is where the name comes from. And because the primitives are shared, a provider you write once slots into everything you build on top afterward — no re-integration.

Everything above the providers is a block you compose and customize, all driving those same primitives over whatever a server has loaded:

• The server — a library you assemble into your own host, not something you deploy as-is.
• The agent — code you shape to your use case; the makings of an assistant over everything you own (a Siri you actually control).
• The automation engine — embeddable wherever you want it: give an agent a way to author automations, or build an app for hand-crafting them; both share the same actions and data and operate on the same automations.

Model each capability once; build the interactions later. AI is one thing you can build here, not the point of it.

Want to see it in practice? A day with Grundlag follows one server of shared providers as it powers a voice assistant, a to-do app, and a nightly script — all at once.

Build a provider

Adapt an external system into typed actions, searchable entities, and reactive events. Persist local state with a built-in database helper, and file blobs with buckets.

Start building →

Build an agent

Turn provider actions into tools an LLM can call. Stream output, persist the conversation, and pause for human approval mid-run.

Run an agent →

Run scripts safely

Execute TypeScript in a hermetic, deterministic sandbox with a replayable call log — resume long-running scripts exactly where they left off.

Run a script →

Host it yourself

Compose your own HTTP host from the server package, register your providers, and expose them over a typed API and a script eval endpoint.

Compose a host →

Build across the network

Generate a client typed against a running host, call its actions and entities, and run a sandbox or agent over HTTP-backed tools — the same runner on either side of the gap.

Generate a client →

Who is this for?

• Provider authors — you have a system (a calendar, a messaging service, a device network) and want to expose it to agents and automations. Start with Build your first provider.
• Agent & sandbox integrators — you want to build agents or execute scripts against a set of actions. Start with Run an agent or Run a sandbox script.
• Host authors — you want to compose and run your own platform. Start with Compose your own host.