@agent-native/core 0.7.51 → 0.7.53

package/docs/content/template-mail.md

@@ -14,6 +14,7 @@ When you open the app, you'll see your inbox on the left, the open thread in the
 - **Read and triage email** with keyboard shortcuts (`J`/`K` to move, `E` to archive, `R` to reply, `C` to compose).
 - **Connect multiple Gmail accounts** — personal and work in one inbox.
 - **Ask the agent to do anything you can do.** "Summarize my unread emails." "Draft a reply that politely declines." "Archive all Netlify bot emails older than a week."
+- **Queue drafts for review.** Teammates and Slack users can ask the agent to prepare an email for an org member; the owner reviews, edits, and sends it from Mail.
 - **Auto-triage with rules.** Set up automation rules in plain English ("from a newsletter") with actions (label, archive, mark read, star, trash).
 - **Track opens and clicks** on the emails you send.
 - **Search across every connected inbox** with one query.
@@ -96,6 +97,8 @@ agent-native add-app
 
 **Multiple compose drafts.** The compose panel supports multiple draft tabs at once. Each draft is stored as an `application_state` entry at `compose-{id}` and syncs live between the agent and the UI. The agent can create a new draft with `manage-draft --action=create`, edit your in-progress draft with `--action=update`, or close tabs with `--action=delete`. Drafts use markdown in the body field; the TipTap editor renders it as rich text and converts to HTML on send.
 
+**Queued draft review.** Drafts requested by teammates or Slack are durable SQL rows in `queued_email_drafts`. The agent uses `queue-email-draft` to assign a draft to an org member, returns a review URL such as `/draft-queue/<id>`, and waits for the owner to review or explicitly send. The queue supports listing assigned drafts, editing them, opening one in the compose panel, dismissing it, and sending one or all reviewed drafts.
+
 **AI triage via automations.** Mail supports automation rules that run against new inbox email using AI. A rule has a natural-language condition (for example, `"from a newsletter"` or `"subject contains invoice"`) and a list of actions (`label`, `archive`, `mark_read`, `star`, `trash`). Manage them via `pnpm action manage-automations --action=create|list|update|delete|enable|disable`, or through the Settings page. Rules fire automatically and can be triggered manually with `pnpm action trigger-automations`.
 
 **Send tracking.** Sent messages get open-pixel and link-click tracking injected automatically. Settings live under `mail-settings.tracking` with `tracking.opens` and `tracking.clicks` (both default `true`). Only links in the new portion of a reply or forward are rewritten — quoted content is left alone. Pull stats for any sent message with `pnpm action get-tracking --id=<message-id>`, or from `GET /api/emails/:id/tracking`. Open and click events are stored in the `email_tracking` and `email_link_tracking` tables.
@@ -132,6 +135,7 @@ When a Google account is connected, email lives in Gmail — the app is a view o
 | `getSetting("labels")`        | System and user labels, with unread counts                     |
 | `getSetting("mail-settings")` | User profile, tracking preferences, signature, aliases         |
 | `getSetting("aliases")`       | Email aliases                                                  |
+| `queued_email_drafts` table   | Teammate-requested drafts awaiting owner review/send           |
 | `email_tracking` table        | Open-pixel events for sent messages                            |
 | `email_link_tracking` table   | Link-click events for sent messages                            |
 | `application_state` table     | `navigation`, `navigate`, `compose-{id}` entries (ephemeral)   |

package/docs/content/template-video.md

@@ -124,7 +124,7 @@ User edits (track values, parameter values, prop overrides, composition settings
 
 The agent always knows which composition you have open. Navigation state (`{ view, compositionId }`) is written to the framework's `application_state` table, and the `view-screen` action returns it plus a hint pointing at `app/remotion/registry.ts`. You don't have to tell the agent which composition you're on — ask it to act on "this one" and it will.
 
-Under the hood the agent calls actions like `navigate`, `create-composition`, `generate-animated-component`, and edits `app/remotion/registry.ts` and `app/remotion/compositions/*.tsx` directly. Every change shows up in the timeline.
+Under the hood the agent calls actions like `navigate`, `save-composition`, and `generate-animated-component`. SQL-backed composition records are created or updated through `save-composition`; code-backed Remotion components still live in `app/remotion/compositions/*.tsx` and are registered in `app/remotion/registry.ts`.
 
 ### Data model
 
@@ -151,10 +151,10 @@ The template folder is `templates/videos/` (the user-facing slug is `video`, but
 
 - `view-screen.ts` — returns current navigation state for the agent.
 - `navigate.ts` — navigate to a composition (`--compositionId <id>`) or the home view (`--view home`).
-- `create-composition.ts` — scaffold a new composition with the standard camera and cursor tracks.
-- `generate-animated-component.ts` — generate a new animated component file with boilerplate.
+- `save-composition.ts` — create or update a SQL-backed composition record.
+- `generate-animated-component.ts` — generate a new Remotion component file with boilerplate.
 - `validate-compositions.ts` — check all registered compositions for structural problems.
-- `list-compositions.ts`, `get-composition.ts`, `update-composition.ts`, `delete-composition.ts`, `save-composition.ts` — CRUD over the SQL table.
+- `list-compositions.ts`, `get-composition.ts`, `update-composition.ts`, `delete-composition.ts` — read, update, and delete SQL-backed composition records.
 
 **Routes** — `templates/videos/app/routes/`
 

package/docs/content/tools.md

@@ -26,6 +26,26 @@ Tools are different:
 
 Use app code for features that are core to the product. Use tools for everything else — one-off utilities, personal dashboards, quick integrations, monitors, and things you want to spin up in seconds.
 
+## When to build a tool vs. a template feature {#when-to-build}
+
+A quick decision rubric:
+
+**Build a tool when:**
+
+- It's for one user or one team, not the whole product.
+- It's a quick utility, dashboard, or widget you want now, not next sprint.
+- No new database schema is needed (or per-tool key-value storage is enough).
+- You want to ship it inside a single chat turn, no deploy.
+
+**Add a template feature when:**
+
+- Every user of the template should get it.
+- It needs new SQL tables, migrations, or shared schema changes.
+- The UI is complex enough to warrant React components, routes, and proper testing.
+- It's part of the product surface — something you'd advertise on a landing page.
+
+When in doubt, start as a tool. Promoting a tool to a template feature later is straightforward; rolling back a half-shipped product feature is not.
+
 ## Creating a tool {#creating}
 
 ### From the sidebar
@@ -58,16 +78,56 @@ Tools render with modest canvas padding by default so simple widgets and dashboa
 
 ## Persistent storage {#persistent-storage}
 
-Every tool has access to a built-in key-value store. Data is automatically scoped per tool and per user — your data stays yours.
+Every tool has access to a built-in key-value store via the `toolData` helper. Data is automatically scoped per tool and per user — your data stays yours.
 
 When you ask the agent to "add persistence" or "remember state" in a tool, it uses this built-in storage. No database tables to create, no migrations to run.
 
+### Scopes
+
+All `toolData` methods accept an optional `{ scope }` option:
+
+- `'user'` (default) — private to the current user.
+- `'org'` — shared across the user's organization.
+- `'all'` — list/get only; returns both user-scoped and org-scoped items.
+
+```html
+<script>
+  // Private to me
+  await toolData.set('notes', 'note-1', { title: 'My Note' });
+
+  // Shared with my org
+  await toolData.set('notes', 'team-note', { title: 'Team Note' }, { scope: 'org' });
+
+  // List my notes (default)
+  const mine = await toolData.list('notes');
+
+  // List both mine and the org's
+  const everything = await toolData.list('notes', { scope: 'all' });
+</script>
+```
+
 ## API keys and secrets {#secrets}
 
 When a tool needs an API key (for GitHub, OpenAI, a weather service, etc.), the agent will tell you what's needed and where to get it. You add the key through the Settings UI in the agent sidebar.
 
 Keys are encrypted and stored securely. Each key is restricted to specific domains — a GitHub token can only be sent to `api.github.com`, never anywhere else.
 
+### Secrets in tools {#secrets-in-tools}
+
+Tools reference secrets in `toolFetch()` calls using the `${keys.NAME}` template pattern. The proxy substitutes the encrypted value server-side; the actual key never reaches the browser.
+
+```html
+<script>
+  const res = await toolFetch('https://api.github.com/user', {
+    headers: {
+      Authorization: 'Bearer ${keys.GITHUB_TOKEN}',
+    },
+  });
+</script>
+```
+
+When a tool needs a one-off key, the agent can register an ad-hoc secret via `POST /_agent-native/secrets/adhoc` with a `urlAllowlist` that pins which domains the secret may be sent to. A request to any other host is rejected before the proxy fires. Combined with SSRF and private-network protections, this means a leaked tool can't exfiltrate secrets to an attacker-controlled URL.
+
 ## Sharing {#sharing}
 
 Tools are **private by default** — only you can see and use a tool you create.
@@ -79,6 +139,8 @@ You can share tools with your team:
 
 Shared tools have their own URLs, so you can link to them directly.
 
+Under the hood, tools use the same ownable-resource model as the rest of the framework — `ownableColumns()` on the `tools` table and a standard `createSharesTable()` for grants. That means tools plug into the same share dialog, access checks, and audit surfaces as documents, decks, dashboards, and any other shareable resource. See [Security](/docs/security) for the full access model.
+
 ## Security {#security}
 
 Tools run in a secure sandbox:
@@ -89,6 +151,38 @@ Tools run in a secure sandbox:
 - **Private network protection** — tools can't reach internal/private network addresses.
 - **Authentication required** — only logged-in users can use tools.
 
+## Tool API reference {#api-reference}
+
+Every tool runs inside a sandboxed iframe with the following helpers injected on `window`. They are the complete surface area — anything else a tool needs has to go through one of these.
+
+| Helper                                      | Purpose                | Example                                       |
+| ------------------------------------------- | ---------------------- | --------------------------------------------- |
+| `toolData.set(collection, id, data, opts?)` | Persist data per-tool  | `toolData.set('notes', id, { text: '...' })`  |
+| `toolData.list(collection, opts?)`          | List persisted items   | `toolData.list('notes', { scope: 'all' })`    |
+| `toolData.get(collection, id, opts?)`       | Get a single item      | `toolData.get('notes', 'note-1')`             |
+| `toolData.remove(collection, id, opts?)`    | Delete persisted item  | `toolData.remove('notes', 'note-1')`          |
+| `appAction(name, params)`                   | Call any app action    | `appAction('list-emails', { view: 'inbox' })` |
+| `dbQuery(sql, args)`                        | Read from SQL          | `dbQuery('SELECT * FROM tools')`              |
+| `dbExec(sql, args)`                         | Write to SQL           | `dbExec('INSERT INTO ...')`                   |
+| `appFetch(path, options)`                   | Call any app endpoint  | `appFetch('/api/settings')`                   |
+| `toolFetch(url, options)`                   | External API via proxy | `toolFetch('https://api.github.com/...')`     |
+
+`appAction` is the preferred way to trigger app behavior — it routes through the same actions the agent and the frontend use, so authorization and access scoping happen automatically. Drop down to `dbQuery`/`dbExec` only when there's no action that fits.
+
+### Routes {#routes}
+
+The framework mounts the following endpoints under `/_agent-native/tools/`. Tools themselves rarely call these directly — they're useful when integrating tools with external scripts or custom UI.
+
+| Method | Path                              | Purpose                                      |
+| ------ | --------------------------------- | -------------------------------------------- |
+| GET    | `/_agent-native/tools`            | List tools (filtered by ownership + sharing) |
+| POST   | `/_agent-native/tools`            | Create a tool                                |
+| GET    | `/_agent-native/tools/:id`        | Get a single tool                            |
+| PUT    | `/_agent-native/tools/:id`        | Update (supports `patches` for diffing)      |
+| DELETE | `/_agent-native/tools/:id`        | Delete a tool                                |
+| GET    | `/_agent-native/tools/:id/render` | Render the iframe HTML                       |
+| POST   | `/_agent-native/tools/proxy`      | Authenticated proxy with secret injection    |
+
 ## Examples {#examples}
 
 Here are some things people build as tools:

package/docs/content/tracking.md

@@ -1,5 +1,5 @@
 ---
-title: "Analytics Tracking"
+title: "Tracking & Analytics"
 description: "Server-side analytics with pluggable providers — PostHog, Mixpanel, Amplitude, or custom webhook"
 ---
 

package/docs/content/what-is-agent-native.md

@@ -120,7 +120,7 @@ The vision: fewer handoffs, one person doing the work of a small team.
 
 ## Fork and customize {#fork-and-customize}
 
-Agent-native apps follow a fork-and-customize model. You start from a **cloneable SaaS** template — Mail, Calendar, Analytics, Slides, Clips, Forms, Dispatch — and make it yours:
+Agent-native apps follow a fork-and-customize model. You start from a **cloneable SaaS** template — Mail, Calendar, Analytics, Slides, Clips, Design, Forms, Dispatch — and make it yours:
 
 1. Pick a template on [agent-native.com/templates](/templates)
 2. Use it immediately as a hosted app (e.g. mail.agent-native.com)
@@ -177,5 +177,7 @@ One action, four surfaces: the agent calls it as a tool, the UI calls it as a ty
 - [**Getting Started**](/docs) — pick a template and run it
 - [**Key Concepts**](/docs/key-concepts) — the architecture: SQL, actions, polling sync, context awareness, portability
 - [**Cloneable SaaS**](/docs/cloneable-saas) — templates as complete products you own
-- [**Workspace**](/docs/workspace) — the per-user customization layer (skills, memory, instructions, MCP)
+- [**Workspace**](/docs/workspace) — the per-user customization layer (skills, memory, instructions, MCP) backed by SQL, not files
+- [**Dispatch**](/docs/dispatch) — the workspace control plane: secrets vault, Slack/email inbox, cross-app delegation
+- [**Tools**](/docs/tools) — sandboxed mini-apps the agent creates instantly without code changes
 - [**Drop-in Agent**](/docs/drop-in-agent) — mount `<AgentPanel>` into any React app

package/docs/content/workspace-management.md

@@ -1,13 +1,13 @@
 ---
-title: "Workspace Management"
-description: "Branching strategies, code ownership, PR review, and governance practices for agent-native workspaces."
+title: "Workspace Governance"
+description: "Branching, CODEOWNERS, PR review, and how Dispatch handles runtime governance alongside git-level governance."
 ---
 
-# Workspace Management
+# Workspace Governance
 
 This guide covers the operational side of running an agent-native workspace — how to branch, who reviews what, how to set up code ownership, and how the dispatch control plane fits into your governance model.
 
-For workspace setup, shared auth, and deployment, see [Multi-App Workspace](/docs/multi-app-workspace).
+For workspace setup, shared auth, and deployment, see [Multi-App Workspaces](/docs/multi-app-workspace).
 
 ## Branching
 
@@ -179,7 +179,7 @@ When reviewing PRs in this environment:
 
 ## Dispatch as Governance
 
-The dispatch app is the workspace's runtime control plane. It complements git-level governance with runtime governance:
+The [Dispatch](/docs/dispatch) app is the workspace's runtime control plane. It complements git-level governance with runtime governance:
 
 | Concern                         | Git / GitHub                  | Dispatch                                   |
 | ------------------------------- | ----------------------------- | ------------------------------------------ |

package/docs/content/workspace.md

@@ -5,7 +5,9 @@ description: "Claude-Code-level customization per user — skills, memory, instr
 
 # Workspace
 
-Every agent-native app ships with a **workspace**: the customization layer that makes the agent yours. It contains team instructions (`AGENTS.md`), per-user memory (`learnings.md`), skills the agent pulls in on demand, custom sub-agents, scheduled jobs, and connected MCP servers — everything you'd expect from a Claude Code / Codex setup.
+> **See also:** Deploying multiple apps as one workspace? See [Multi-App Workspaces](/docs/multi-app-workspace). Governance, branching, and CODEOWNERS? See [Workspace Governance](/docs/workspace-management).
+
+Every agent-native app ships with a **workspace**: the customization layer that makes the agent yours. It contains team instructions (`AGENTS.md`), shared learnings (`LEARNINGS.md`), personal structured memory (`memory/MEMORY.md`), skills the agent pulls in on demand, custom sub-agents, scheduled jobs, and connected MCP servers — everything you'd expect from a Claude Code / Codex setup.
 
 The twist: **it's SQL rows, not filesystem files.** Each user gets their own workspace stored in the database. There's no dev-box to spin up, no container per user, no files to mount. A multi-tenant SaaS can give every user a fully-customizable agent for essentially free, because all of it is rows — personal memory, personal MCP servers, personal skills, personal sub-agents — and the shared codebase hosts all of them at once.
 
@@ -15,7 +17,7 @@ The twist: **it's SQL rows, not filesystem files.** Each user gets their own wor
 | One codebase per developer       | One codebase, many users                           |
 | Needs a dev-box or container     | Runs on any serverless/edge host                   |
 | Customization at `~/.claude/`    | Customization per-user, scoped `u:<email>:…`       |
-| Per-project `CLAUDE.md` / skills | Per-app `AGENTS.md` + per-user `learnings.md`      |
+| Per-project `CLAUDE.md` / skills | Per-app `AGENTS.md` + workspace memory resources   |
 | MCP config in a JSON file        | MCP config in JSON _or_ the settings UI, per scope |
 
 Same capabilities. Different economics. See [Cloneable SaaS](/docs/cloneable-saas) for why this matters for SaaS.
@@ -30,19 +32,20 @@ The **Workspace** tab in the agent sidebar is where you and the agent share pers
 - Create files with the `+` menu. Upload with the upload button. Edit inline (visual or code view).
 - **Personal** is just you. **Shared** is your team/org.
 - The agent can read, write, and rename any of these files as part of a conversation.
-- Special files the agent always reads: `AGENTS.md` (team rules) and `learnings.md` (per-user memory the agent auto-updates when you correct it).
+- Special files the agent preloads: shared `AGENTS.md`, shared `LEARNINGS.md`, and personal structured memory at `memory/MEMORY.md`.
 
 ## What goes in here? {#what-goes-in-here}
 
-| File / path                 | What it's for                                                                                                  |
-| --------------------------- | -------------------------------------------------------------------------------------------------------------- |
-| `AGENTS.md` (Shared)        | Team instructions the agent reads every turn — tone, rules, domain context, skill references.                  |
-| `learnings.md` (Personal)   | **Agent memory.** Per-user file the agent auto-writes to on corrections/preferences and auto-reads every turn. |
-| `skills/<name>.md`          | Focused domain guidance the agent pulls in on demand (invoked with `/` slash commands).                        |
-| `agents/<name>.md`          | **Custom agents** — reusable sub-agent profiles the agent can delegate to (invoked with `@` mentions).         |
-| `remote-agents/<name>.json` | A2A manifests for connected remote agents — edited via a form, not raw JSON.                                   |
-| `jobs/<name>.md`            | Scheduled tasks that run on a cron (see the recurring-jobs docs).                                              |
-| Anything else               | Notes, prompts, config, dataset snippets — any text file.                                                      |
+| File / path                 | What it's for                                                                                          |
+| --------------------------- | ------------------------------------------------------------------------------------------------------ |
+| `AGENTS.md` (Shared)        | Team instructions the agent reads every turn — tone, rules, domain context, skill references.          |
+| `LEARNINGS.md` (Shared)     | Shared corrections, conventions, and durable project memory the agent preloads.                        |
+| `memory/MEMORY.md`          | Personal structured memory the chat preloads for the current user.                                     |
+| `skills/<name>.md`          | Focused domain guidance the agent pulls in on demand (invoked with `/` slash commands).                |
+| `agents/<name>.md`          | **Custom agents** — reusable sub-agent profiles the agent can delegate to (invoked with `@` mentions). |
+| `remote-agents/<name>.json` | A2A manifests for connected remote agents — edited via a form, not raw JSON.                           |
+| `jobs/<name>.md`            | Scheduled tasks that run on a cron (see the recurring-jobs docs).                                      |
+| Anything else               | Notes, prompts, config, dataset snippets — any text file.                                              |
 
 ## Overview {#overview}
 
@@ -93,7 +96,7 @@ Change how the agent behaves, in 60 seconds.
 - **Skills** (`+` → **Skill**) — focused how-to files invoked in chat with `/skill-name`.
 - **Agents** (`+` → **Agent**) — reusable sub-agent personas invoked with `@agent-name`.
 - **Scheduled Tasks** (`+` → **Scheduled Task**) — prompts that run on a cron.
-- **learnings.md** — your Personal file the agent auto-updates whenever you correct it.
+- **Memory** — shared `LEARNINGS.md` and personal `memory/MEMORY.md` keep durable context available across conversations.
 
 ## How the Agent Uses Resources {#how-the-agent-uses-resources}
 
@@ -124,11 +127,16 @@ Be concise. Lead with the answer.
 | data-analysis | `skills/data-analysis.md` | BigQuery and data workflows |
 ```
 
-### learnings.md — agent memory {#learnings-md}
+### Memory {#memory}
+
+The workspace has two current memory surfaces:
+
+- `LEARNINGS.md` in **Shared** scope for project-wide conventions, corrections, and durable team knowledge.
+- `memory/MEMORY.md` in **Personal** scope for structured memory about the current user.
 
-`learnings.md` is the agent's long-term memory about _you_. It's a **Personal-scope** resource (one per user) that the agent auto-reads at the start of every conversation and auto-writes to whenever it picks up something worth remembering.
+The resource system also seeds a personal `LEARNINGS.md` for compatibility with older workspaces, but the chat preload path is shared `LEARNINGS.md` plus personal `memory/MEMORY.md`.
 
-**What gets saved.** When you correct the agent ("no, always use X instead of Y"), share a preference ("I prefer concise answers"), or reveal context ("my team calls this 'the dispatch layer'"), the agent appends the learning to `learnings.md` so it doesn't repeat the mistake or have to re-ask next time. This behavior lives in the framework system prompt (the `capture-learnings` skill spells out the rules for when and how).
+**What gets saved.** When you correct the agent ("no, always use X instead of Y"), share a preference ("I prefer concise answers"), or reveal context ("my team calls this 'the dispatch layer'"), the agent can capture that learning so it doesn't repeat the mistake or have to re-ask next time. Project-wide learnings belong in shared `LEARNINGS.md`; user-specific memory belongs under `memory/`. This behavior lives in the framework system prompt and the `capture-learnings` skill spells out the rules for when and how.
 
 **What it looks like.**
 
@@ -150,13 +158,14 @@ Be concise. Lead with the answer.
 
 **Where it fits.**
 
-| Surface        | Scope    | Written by                | Read when                    |
-| -------------- | -------- | ------------------------- | ---------------------------- |
-| `AGENTS.md`    | Shared   | Humans / agent on request | Every turn                   |
-| `learnings.md` | Personal | Agent, automatically      | Every turn                   |
-| `skills/…`     | Shared   | Humans / agent on request | On demand (`/slash` command) |
+| Surface            | Scope    | Written by                | Read when                    |
+| ------------------ | -------- | ------------------------- | ---------------------------- |
+| `AGENTS.md`        | Shared   | Humans / agent on request | Every turn                   |
+| `LEARNINGS.md`     | Shared   | Humans / agent on request | Every turn                   |
+| `memory/MEMORY.md` | Personal | Agent / humans            | Every turn                   |
+| `skills/…`         | Shared   | Humans / agent on request | On demand (`/slash` command) |
 
-Users can edit `learnings.md` directly in the Workspace tab — it's a regular resource. Delete lines the agent got wrong or promote them into `AGENTS.md` if they apply to the whole team.
+Users can edit these memory files directly in the Workspace tab — they're regular resources. Delete lines the agent got wrong, keep personal preferences in `memory/MEMORY.md`, or promote team-wide rules into `AGENTS.md`.
 
 ## Skills {#skills}
 
@@ -220,7 +229,7 @@ Recommended conventions:
 There are two agent types in Workspace:
 
 - **Custom agents** — local profiles in `agents/*.md`, executed inside the current app/runtime
-- **Connected agents** — remote A2A peers described by manifests in `agents/*.json`
+- **Connected agents** — remote A2A peers described by manifests in `remote-agents/*.json` (legacy `agents/*.json` manifests are still recognized)
 
 Use custom agents for delegation within one app. Use connected agents when you need to call another app over A2A.
 
@@ -284,13 +293,13 @@ If no skills are configured, the dropdown shows a hint with a link to these docs
 
 The resource system works identically in both modes. The difference is what additional sources are available for `@` tagging and `/` commands:
 
-| Feature                  | Dev Mode                                                                | Production                                             |
-| ------------------------ | ----------------------------------------------------------------------- | ------------------------------------------------------ |
-| @ tagging                | Codebase files + workspace resources + custom agents + connected agents | Workspace resources + custom agents + connected agents |
-| / slash commands         | .agents/skills/ + resource skills                                       | Resource skills only                                   |
-| Agent file access        | Filesystem + resources                                                  | Resources only                                         |
-| Workspace panel          | Full access                                                             | Full access                                            |
-| AGENTS.md / learnings.md | Available                                                               | Available                                              |
+| Feature            | Dev Mode                                                                | Production                                             |
+| ------------------ | ----------------------------------------------------------------------- | ------------------------------------------------------ |
+| @ tagging          | Codebase files + workspace resources + custom agents + connected agents | Workspace resources + custom agents + connected agents |
+| / slash commands   | .agents/skills/ + resource skills                                       | Resource skills only                                   |
+| Agent file access  | Filesystem + resources                                                  | Resources only                                         |
+| Workspace panel    | Full access                                                             | Full access                                            |
+| AGENTS.md / memory | Available                                                               | Available                                              |
 
 ## Resource API {#resource-api}
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@agent-native/core",
-  "version": "0.7.51",
+  "version": "0.7.53",
   "type": "module",
   "description": "Framework for agent-native application development — where AI agents and UI share state via files",
   "license": "MIT",