@nuxtagentic/prompt

Prompt

@nuxtagentic/prompt owns decision providers, prompt dispatch, schema-based query interpretation, and the plan/review/execute lifecycle. It installs Data and has no dependency on a particular collection UI. The root app supplies the prompt and review dialog; installed features supply their tools, model views, and resource adapters.

This shared prompt engine serves the workspace input. The separate @nuxtagentic/agents package manages saved agent definitions and their runs. The /api/agent endpoints and agentOperation confirmation model retain their existing names.

The prompt uses registered feature aliases, tools, and model views. Agents, Integrations, and Automations contribute their navigation and planning metadata. New domain features can add structured parsing and natural-language actions through the same contracts without a separate prompt engine.

Setup

Include agentOperationsModels from @nuxtagentic/prompt/schema in the host's cloud.config.ts, then generate, review, and apply the CloudConfig migration. The confirmation store must exist before planning mutations.

Set NUXT_DECISION_PROVIDER to typesafeAI (default) or openAI, and configure NUXT_TYPESAFE_API_KEY or NUXT_OPENAI_API_KEY on the server. NUXT_OPENAI_DECISION_MODEL overrides the default OpenAI decision model, gpt-6-luna. Restart or redeploy after changing settings. Provider keys stay out of public runtime config.

Follow a request

Both providers select typed choices for resources, operations, fields, operators, and literal values. Choices come from registered schemas and the request text. The application constructs and validates filters and writes; providers do not supply arbitrary SQL or execute tools. Missing required fields produce a specific clarification. Unsupported values and ambiguous timestamps remain reviewable errors.

Feature metadata enters through #workspace/client and #workspace/server. A feature's runtime/shared/agent.ts contributes public views, tools, aliases, and exclusions. Its runtime/server/contribution.ts can add authenticated resource factories for its own data and actions. There is no host-level action or model-view configuration file.

Only models contributed through installed resource aliases or model views enter the agent catalog. Keeping a removed feature's schema does not expose its records or internal workflows. Custom models retain schema-derived fields and operations; register their aliases or views to make them available.

Editor commands live in each feature's runtime/actions.ts and execute through Workspace's registered handlers. They remain separate from database mutations.

Mutation guarantees

Every mutation opens a review. Updates and deletes require an ID, current selection, or a nonempty filter matching at most 25 accessible records. LIMIT cannot silently truncate mutation targets. Singular requests select one record; plural requests can select a subset.

Reviews bind the proposed input, candidate IDs, and fingerprints to the account and session and expire after ten minutes. Execution accepts the key and reviewed IDs, not replacement fields or filters. It checks authorization and freshness, claims the review atomically, and stores the receipt for retries.

Batches execute sequentially. A partial failure records completed IDs and prevents replay. This is not a cross-model transaction; an uncertain execution stays blocked until its outcome is known. CloudConfig still enforces model rules, validation, hooks, and storage cleanup for each write.

Find the code

How search works covers local parsing, collection registration, and provider boundaries. Regression tests live in tests/; the host's pnpm test:workspace includes them. Default verification remains pnpm typecheck.