What happened
The GitHub release notes for Datasette Apps 0.3a0 mark the version as a prerelease, published by Simon Willison on November 4. The notes describe it as “mostly improvements” for creating and editing apps with Datasette Agent. Datasette Apps is therefore not presented here as a general-purpose agent framework release; the changes concern the specific path through which an agent helps assemble and operate applications in the Datasette environment. The release notes do not state a price, a hosted-service offering, or a date for a stable version.
One change concerns how a person and the agent identify an existing app during chat. A user can now type # in Datasette Agent chat to tag an app. The resulting autocomplete list is limited to apps that the user has permission to view. That restriction matters because a convenient reference mechanism can otherwise become an accidental discovery surface for app names or resources outside a user's normal access. The notes describe an interaction constrained by existing viewing permissions, rather than an agent choosing among all apps without a visible access boundary.
The release also adds two tools: app_add_stored_queries() and app_remove_stored_queries(). These allow the agent to manage the set of stored queries that an app is permitted to call. The release notes say a user must approve the granting of a write query. The existing app_create() tool now checks that every requested stored query exists and that the user can view it. If any requested query can write, the tool asks the user for approval before the app is created. The stated sequence is important: existence and viewability are checked, while write capability receives an additional approval step.
Several changes address the handoff from tool activity to a usable app. “View app” buttons displayed by agent tools, along with links on # app references, now open the app full screen in the Datasette Agent panel. Tool results also include the app's relative path, which the notes say lets the agent link to the app instead of inventing a URL. Finally, 0.3a0 requires Datasette 1.0a41 or later, adds Python 3.15 support, and removes Python 3.10 support. Teams considering the prerelease therefore need to check both their Datasette version and Python compatibility before treating the changes as deployable.
What the archive adds
New Runtime's earlier coverage of Datasette 1.0a41 on October 1 described moves toward shared runtime visibility and plugin-interface consistency (Field Note). This is a new fact on that related product line rather than a restatement: Datasette Apps 0.3a0 applies explicit app references, stored-query selection, and approval behavior to Datasette Agent workflows.
Trend signal
This supports the pattern that agent-ready software exposes capabilities. Rather than asking an agent to operate over an unspecified data surface, the release defines callable stored queries, checks whether the user may view them, and puts a user decision before write-query access is granted. It is a narrow implementation example, not proof that the approach has become standard across agent products.
Why it matters
Agent-assisted app building becomes risky when an agent's apparent convenience hides the resources it can invoke. A data-backed application is not merely a generated interface: it is also a collection of callable queries, each with its own potential read or write effect. Datasette Apps 0.3a0 makes that set more visible and controllable in the app-management path.
For teams building their own agent-facing internal tools, the relevant lesson is architectural rather than product-specific. Make the agent request named capabilities; verify that a requested capability exists; check that the operator can access it; and require a separate decision for capabilities that can change data. This does not remove the need to review query design, authorization models, or resulting application behavior. It does make the control point concrete instead of relying on a model to infer which action is safe.
The relative-path change is smaller but useful. When an agent creates an artifact, a structured location returned by the tool is more dependable than asking the model to reconstruct a link from conversational context. That design reduces a routine class of incorrect output while keeping navigation inside the product's own interface.
Limits and uncertainty
The GitHub release notes label 0.3a0 a prerelease, so its stability, upgrade path, and schedule for a stable release remain unestablished. The notes specify the approval requirement for write queries but do not quantify how often approvals are requested, approved, or rejected in practice. They also do not report adoption, performance, security testing, or an independent assessment of the permission checks.
The release describes checks around stored queries and user visibility, not a complete account of the authorization model for every Datasette action. It is also unclear from the release notes how applications behave if permissions change after an app is created. Compatibility is explicit, however: users need Datasette 1.0a41 or higher, and environments still on Python 3.10 are outside this release's supported range.
Skill to build now
Audit one agent tool that can create, configure, or modify a data-backed application. List the named resources it can call, then separate read-only access from operations that can write. Add validation that requested resources exist and that the current user is authorized to use them. For write-capable operations, require an approval record at the moment access is granted, not merely an instruction in the agent prompt.
Reader takeaway
Datasette Apps 0.3a0 is a small prerelease with a durable design lesson: an agent should receive explicit, permission-checked capabilities, and a human should approve the transition to write access. The feature set is specific to Datasette, but the workflow applies broadly to teams exposing operational tools to agents.