NNyquest docs

Using Artifacts in Chat

Artifacts reach a conversation exactly one way: you inject them. There is no automatic recall for artifacts.

Artifacts are never recalled automatically

The vault lives in your browser's local storage, so the server-side recall layer cannot see it. Recall searches your memory facts and nothing else — however relevant a saved artifact is, it will never appear in a reply on its own.

So if you saved a Rust function as a code artifact and later ask "how should I structure my error handling?", that function is not in context unless you put it there. There is no setting for this and nothing to switch on; it follows from where the vault is stored.

Memories work the other way round — those are recalled automatically. See Recall and Surfacing.

Explicit injection

When you want a specific artifact in the next message, you put it there. The vault detail panel has an Inject action (or similar — chassis-specific):

  1. Open the artifact in the detail panel
  2. Click Inject (or "Use in chat" / "Send to chat")
  3. The current chat input is populated with a reference block:
[From artifact: My Rust auth function]
fn authenticate(token: &str) -> Result<User, AuthError> {
    ...
}
  1. Add your question/instruction below
  2. Send

The model sees the artifact content as part of your prompt. This is the only route an artifact takes into a conversation, so if you want it considered, inject it.

Artifact-aware agent runs

In Agent Mode, the planner has access to a read_artifact tool. It can list and read your artifacts as part of a multi-step plan.

Example: "Look through my saved code artifacts and find the one for OAuth handling." The agent uses read_artifact to scan the vault and return the match.

This is documented in The 6 Tools.

Embeddings: what's sent to the embedding model

When you save an artifact, the platform computes an embedding by sending the content to the embedding provider (typically the same provider as your active model, or a fallback to a small embedding model).

  • Content is sent over TLS
  • Provider's embedding policy applies (most don't train on embedding inputs but check your provider's policy)
  • The embedding (a vector) is stored locally in IndexedDB; the original content is also local
  • The platform itself does NOT store either centrally — only the embedding and content live on your device

If you're saving sensitive content as an artifact and your embedding provider's policy concerns you, you can:

  • Disable embedding by editing the save dialog (skips semantic search for that artifact)
  • Use a BYOK embedding key for a provider with stronger guarantees

Common patterns

  • "Reference codebase" — save core utility functions as code artifacts, tag with lib. Inject the relevant one when you ask an implementation question.
  • "Style guide" — save your preferred code style as a markdown artifact. Inject it early in a session to keep replies consistent.
  • "Recurring prompts" — save complex prompts you reuse often. Inject them as starting points for related work.
  • "Examples library" — save annotated examples (good and bad) for the model to learn from. Inject the ones that fit the task you're starting.

Limitations

  • One artifact at a time for explicit injection (no multi-select inject yet)
  • Nothing happens automatically — if you forget an artifact exists, it will not turn up on its own. Vault search and tags are how you find it again
  • No "always inject this artifact" flag — pinning only affects display order in the vault, not what reaches the chat

Where to next