One memory across every surface
The account memory that follows you across Dropstone Chat, the CLI, and the SDK, what shares it and what does not, and how to keep an integration's learning out of your own memory.
Memory is what ties Dropstone's surfaces together. Teach it something once, on any of them, and it is there on the others: one memory per account, not one per tool.
What shares it
| Surface | How it runs | Shares the memory |
|---|---|---|
| Dropstone Chat | signed in | Yes |
| The CLI | signed in with dropstone login | Yes |
| The SDK, local agent client | starts a server as your account | Yes |
| The SDK, headless client | an API key against the public endpoint | No |
| An incognito chat | reads memory, writes none | Reads, does not write |
The rule behind the table is simple: a surface that runs as you has your memory, a surface built for pipelines does not, and one mode reads without writing. The headless endpoint is stateless on purpose, so the same input gives the same answer whatever you taught Dropstone last week. An incognito chat is the other way round: it works with what Dropstone knows and keeps none of what it produces.
Why it matters in code
An agent that knows your conventions is worth more than one you brief on every call. A rule you set in Chat holds in a session your application starts, and a fact an SDK session records is there the next time you open the CLI. That is the compounding part: the longer you work with Dropstone, the less each surface has to be told. See How an agent learns as it works.
Keeping an integration separate
If a service should have its own memory rather than yours, give it its own account, or an organization member account dedicated to that integration. It then learns about the integration and nothing else, and your own memory stays yours. See Memory and your privacy.
The editor and the other integrations
The editor extension, the API, and the rest of the integrations are documented in the CLI reference, which is the home for surface-specific setup: the VS Code extension itself, VS Code setup, IDE integration, and the HTTP API.
Related articles
- Memory across chat, CLI, and SDKDropstone 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.
- How Dropstone remembers youDropstone keeps a persistent memory that follows your account across chat, the CLI, and the SDK. Correct it once and it should not need correcting again, anywhere you use it.
- Dropstone SDKA typed TypeScript and JavaScript client for the Dropstone agent, with two entry points: one for headless API calls from CI or a serverless function, one that runs the agent locally with the same account memory as the CLI and Chat.
- Using the API with your planCall Dropstone over HTTP with an API key. The endpoint is OpenAI-compatible, billed pay-per-use from your credit balance, and works from any language. Keys, errors, rate limits, and what the API does not carry.
- Dropstone CLI overviewThe Dropstone CLI is an agent for your terminal that reads your codebase, edits files, runs commands, and shares memory with everything else on your account. Install it in one command. The full reference is at docs.dropstone.io.