An agent can answer a question about your data and even sketch a dashboard. But the answer often ends where the chat ends. To make it useful tomorrow, a teammate needs to find it, trust what it reads, and know that sharing it will not quietly share access to the underlying data.

That gap is why Grove has Grove Apps. An agent can create a small web app that lives in Grove, reads live sources through named connections, and can be revised and published as a maintained tool. The important part is not that an agent can write HTML. It is that the result has a home, a reviewable history, and a controlled way to reach data.

The missing step after “that’s useful”

Many data questions start as conversations: What changed in spending? Which customers are at risk? How is this workflow performing? An agent can help answer, but a chat transcript is a poor interface for a question people ask repeatedly. Copying the answer into a spreadsheet or dashboard creates a second problem: the copied result can go stale, and its relationship to the source data is easy to lose.

Handing an agent a database credential and asking it to generate a page is not a good shortcut. A page served with broad credentials could expose more than its viewer is allowed to see. Arbitrary code could send query results somewhere else. And once several people edit or publish the page, it can become unclear which version is in use.

Grove Apps gives that agent-authored interface a managed place to live. An operator can ask Ranger or another MCP-connected agent to build an app, then review, revise, and publish it in Grove.

A small app, backed by named operations

A Grove App is a versioned web bundle paired with a manifest of named data bindings. A binding can run a read-only SQL query against a Databricks connection or Grove Volume, call a read-only connector operation, or run a Grove workflow. The interface requests a binding by name with typed parameters; Grove executes the operation on the server and returns its result.

This design keeps app code away from raw credentials and direct database access. SQL is stored as part of an app version, checked as a single read-only query, and bound to parameters rather than assembled from user input. An operator can preview a binding while authoring, then publish the version that should be available to viewers.

Because bindings can call workflows as well as read sources, an app can present the result of a repeatable process—not just a one-time query. That keeps the app focused on the question its users need answered while Grove retains the workflow and execution record behind it.

Sharing an app does not share a data grant

The central question for a shared dashboard is: whose permissions apply when it loads data? In Grove, every binding runs as the viewer. If that viewer cannot use the connection or run the workflow, the binding is denied. Grove checks permission before serving a cached result too, so a revoked grant does not remain available through the cache.

Grove also checks the author and publisher’s access when an app is saved and published. That matters because the app’s JavaScript can see the results it requests. An author should not be able to write an app that exposes data they could not access themselves to a more privileged viewer.

The app itself runs in a sandbox with no direct network access. Its route to data is the set of bindings in its published version. This gives teams a concrete review point: they can inspect what an app is allowed to request, who authored and published it, and which version viewers will see.

A maintained tool, not a disposable chat artifact

Grove versions each app change. An edit starts from a specific base version, so concurrent authors cannot silently overwrite one another. Publishing selects the version viewers see; an older version can be republished to roll back. Draft versions remain available to editors while viewers see the published version.

Agents can author through Grove’s MCP tools, Ranger’s app tools, or the grove apps CLI. Arborist provides the place to browse and view apps. That means an operator can use the agent they already work with, while the app, its data contract, and its release state remain in Grove.

The workflow is simple: find the data, describe the recurring question, have an agent build a first version, preview its bindings, then publish the app for the people who need it. The next change becomes another version rather than another disconnected copy.

Give useful answers somewhere to live

An agent’s answer can be a good starting point. For recurring work, the team needs something more durable: an interface that stays connected to current data, a clear record of changes, and permissions that still apply when the result is shared.

Grove Apps make that next step part of Grove’s governed workflow. Explore the Grove documentation to learn more.