Skip to main content
The other recipes push data into the workspace. Once it’s there, the same REST API and MCP surface let you build custom apps on top of it — dashboards, bots, portals, embedded widgets. These are starting points teams ship in a day or two; each maps to a small set of endpoints already documented in the API reference.

​
The general shape

Every template above is variations on three primitives:
A typical template’s backend is fifty lines of glue: an x-api-key header on each call, a couple of GET /files/content reads, a PUT /files/content write when the user submits, an optional POST /api/agent/message when a model should be in the loop. No new schema, no separate database, no sync code to maintain — the workspace is already the source of truth.

​
When to build a template vs. just use arg.ai directly

  • Build a template when the audience can’t or shouldn’t be inside arg.ai itself — customers, prospects, parents, regulators, the marketing site’s CMS editor.
  • Build a template when the data model is domain-specific enough that a generic file UI hurts more than it helps — a sales rep wants a deal card, not a folder of JSON.
  • Skip the template when the audience is internal and technical. The arg.ai UI already renders .csv, .kanban, .mdx, .whiteboard, .html natively — that may be the dashboard.