Dropstone Support

Memory across chat, CLI, and SDK

Dropstone memory belongs to your account, not to one app. A rule you set in the CLI applies in chat, and something learned in chat is available to the SDK. One memory, every surface.

Dropstone runs in several places: a chat app in your browser, a CLI in your terminal, an SDK in your own code, and a VS Code extension. Most tools that exist in more than one place keep a separate memory in each. Dropstone keeps one.

This is what Dropstone means by Continuity. Your memory is attached to your account, and every surface reads from and writes to the same one.


What that means in practice

Teach it once, anywhere. Tell the CLI you never want function declarations, and the next time you ask chat to write a helper, it uses arrow functions. Correct chat about how your team names branches, and the CLI follows it on your next commit.

Study once, use everywhere. Ask chat to study a library's documentation, and the SDK has that knowledge the next time your code calls it.

Pick up where you left off. Start a conversation in chat about a migration, close the laptop, and open the CLI on the same project. The context is there.

One place to manage it. Ask "what do you remember about me?" on any surface and you get the same list. Remove something once and it is gone from all of them.


Which surfaces share memory

SurfaceReads memoryWrites memory
Dropstone Chat (chat.dropstone.io)YesYes
Dropstone CLIYesYes
Dropstone SDKYesYes
VS Code extensionYesYes
Incognito chatYesNo

An incognito chat is the one surface that reads without writing: what Dropstone already knows about you is available to it, and nothing the conversation produces is kept. It is the mode for work you do not want remembered, not for hiding from an assistant that already knows your conventions.

Every surface above requires the same Dropstone account. The CLI signs in through dropstone login; chat and the dashboard share a session in the same browser; the SDK's local client uses the CLI's sign-in, and its headless client, which takes an API key, has no memory at all. See One memory across every surface.


How a memory reaches a conversation

When you send a message on any surface, Dropstone checks your memory for what is relevant and brings it into that turn. Standing rules always come along. Facts, studied knowledge, and past-conversation context come along when they bear on what you asked.

Each turn also keeps a short record of which memories it was given, so if you ask afterwards "did you use my memory just now?" it can answer from that record rather than guess. It will name what it drew on, and it will say which memories it was handed but did not need.


What is not shared

Memory is shared across your surfaces. It is not shared across accounts, and it is not shared with other people unless you are in an organization and deliberately share a specific memory with your team. See Memory in teams and organizations.

Project files you upload in chat belong to that project, not to memory. They are available in conversations inside that project, on the surface where you uploaded them. What Dropstone learns from working with those files can become memory; the files themselves do not.

Related articles

Ctrl+I