ViewMarkdown

Sandcastles

Software used to be something you consumed. Someone else decided what it did, what it looked like, and what problems it solved. If the tool didn't fit your exact workflow, you adapted to the tool — or you opened a ticket and waited.

Sandcastles flip that. They are interactive web applications the AI builds for you through conversation. Describe what you need — an approval tracker, a vendor scorecard, an intake form, a reconciliation dashboard — and the AI plans it, scaffolds it, and iterates on it with you until it works. The result is a real application with persistent data, backend logic, and tool integrations, not a mockup or a chart.

Sandcastles are disposable by design. They solve your specific problem, for your specific team, right now. If the problem changes, you change the app — or you build a new one. There is no migration plan, no feature backlog, no vendor roadmap. The app is yours.

This is how software works when creating it is as easy as describing it: you stop adapting to tools and start creating tools that adapt to you.

Who can create sandcastles

  • Any workspace member can create a sandcastle by asking the AI to build one in chat.
  • Workspace admins can see and manage all sandcastles in the workspace.

Who can use a sandcastle

Access is controlled by your workspace's permissions system. A sandcastle can be shared with individual users or groups at different permission levels:

  • View — open the app and see the data.
  • Execute — use interactive features (buttons, forms, filters) and trigger data changes through the app.
  • Edit — modify the app's code, rebuild, and manage its data collections.
  • Admin — everything Edit allows, plus manage who else has access and delete the sandcastle.

The person who created the sandcastle gets Admin automatically.

What you can build

Sandcastles are full React single-page applications. They render in the browser with Material-UI components, support local and persistent state, and can include multiple views, forms, tables, charts, and interactive elements. Common examples:

  • Approval workflows with kanban boards and status tracking.
  • Data dashboards that pull from persistent collections.
  • Intake forms that write submissions to a collection for processing.
  • Inventory browsers with search, filters, and drill-down detail views.
  • Scorecard apps that rank vendors, customers, or internal metrics.

Tool execution

Sandcastles are not just frontends. They can execute the same workspace tools that LLMs and subagents use — custom tools that hit your WMS, ERP, CRM, ticketing system, email, Slack, or any other system you have built tools for. When the user clicks a button in a sandcastle, the app can call a tool directly, with the user's credentials, in real time.

This means a sandcastle is a full application with backend logic. An approval tracker can send an email when a request is approved. An inventory browser can query your WMS on every search. A vendor scorecard can pull fresh data from the ERP when the user clicks "Refresh." The tools run in the same secure, sandboxed environment they run in everywhere else in Assist — schema-validated inputs, managed credentials, logged execution.

When you scaffold a sandcastle, you can declare tool requirements — the tools the app needs to function. These are synced to the linked subagent's whitelist automatically, so the app and its subagent share the same capabilities.

What sandcastles cannot do

  • Make arbitrary network calls from the browser. External system access goes through workspace tools, which enforce credential management, network allow-lists, and audit logging.
  • Store files. Sandcastles store structured JSON documents in collections, not files. For file storage, use the linked subagent's filesystem.
  • Be accessed without logging into Assist. There are no public URLs today.

How sandcastles work

When you ask the AI to build an app, it works in three phases:

Plan mode

Before any code is written, the AI generates a design document — a plain-language spec that describes what the app will do, which data collections it needs, which views to build, which tools it will call, and the implementation steps. The plan is a few hundred words, not code. You read it, push back, and iterate until it matches what you actually need.

Plan mode exists because the hardest part of building software is not writing the code — it is agreeing on what the code should do. A ten-minute conversation about the plan saves hours of rework after scaffolding. Get the collections right, get the workflow right, get the tool requirements right, and the rest follows.

Scaffold

Once you approve the plan, the AI scaffolds the app in one step: the sandcastle record, the data collections, seed data, a linked subagent, and the first version of the code. You get a link to a live preview immediately.

Edit

You and the AI iterate on the app view by view. Each edit creates a new version. You describe what you want changed ("make the overdue items red", "add a filter for department", "move the summary cards above the table") and the AI makes targeted code edits. You can preview after every change.

Every version is saved. You can roll back to any previous version if an edit goes wrong. The app is never "deployed" — it is always live at its preview URL, always showing the latest published version.

State collections

Each sandcastle has its own set of collections — persistent document stores similar to a simple database. A collection holds JSON documents, each with a unique ID. The app reads and writes to these collections through built-in hooks (useSandcastleQuery, useSandcastleMutation), and the linked subagent can also read and write to them through state tools.

Collections are created during scaffolding and can be added later. There is a limit of 100 documents per query, so collections are best suited for operational data (hundreds to low thousands of records), not analytics-scale datasets.

Sandcastles and subagents

Every sandcastle with state collections gets a linked subagent automatically. The subagent:

  • Has read/write access to the sandcastle's collections through state tools.
  • Can be scheduled to run maintenance, sync data, or send notifications.
  • Can be wired to a Slack channel so the team can interact with the app's data through chat.
  • Cannot be deleted while the sandcastle link is active (to prevent orphaning the app's operator).

See Subagents overview for the full picture on what subagents can do.

Related guides