Una memoria de Dropstone para chat, CLI y SDK
La memoria de cuenta que te sigue en Dropstone Chat, la CLI y el SDK, qué la comparte y qué no, y cómo mantener el aprendizaje de una integración fuera de tu propia memoria.
La memoria es lo que une las superficies de Dropstone. Enséñale algo una vez, en cualquiera de ellas, y estará en las demás: una memoria por cuenta, no una por herramienta.
Qué la comparte
| Superficie | Cómo se ejecuta | Comparte la memoria |
|---|---|---|
| Dropstone Chat | con sesión iniciada | Sí |
| La CLI | con sesión iniciada mediante dropstone login | Sí |
| El SDK, cliente local de agente | inicia un servidor como tu cuenta | Sí |
| El SDK, cliente sin interfaz | una clave de API contra el endpoint público | No |
| Un chat de incógnito | lee la memoria, no escribe ninguna | Lee, no escribe |
La regla detrás de la tabla es simple: una superficie que se ejecuta como tú tiene tu memoria, una superficie diseñada para pipelines no la tiene, y un modo lee sin escribir. El endpoint sin interfaz no tiene estado a propósito, de modo que la misma entrada da la misma respuesta sin importar lo que le enseñaste a Dropstone la semana pasada. Un chat de incógnito es al revés: trabaja con lo que Dropstone sabe y no conserva nada de lo que produce.
Por qué importa en el código
Un agente que conoce tus convenciones vale más que uno al que tienes que instruir en cada llamada. Una regla que estableces en Chat se mantiene en una sesión que tu aplicación inicia, y un dato que una sesión del SDK registra está ahí la próxima vez que abras la CLI. Esa es la parte que se acumula: cuanto más tiempo trabajas con Dropstone, menos hay que explicarle a cada superficie. Consulta Cómo aprende un agente mientras trabaja.
Mantener una integración separada
Si un servicio debe tener su propia memoria en lugar de la tuya, dale su propia cuenta, o una cuenta de miembro de organización dedicada a esa integración. Así aprenderá sobre la integración y nada más, y tu propia memoria seguirá siendo tuya. Consulta Memoria y tu privacidad.
El editor y las demás integraciones
La extensión del editor, la API y el resto de las integraciones están documentadas en la referencia de la CLI, que es el lugar para la configuración específica de cada superficie: la extensión de VS Code en sí, la configuración de VS Code, la integración con IDE y la API HTTP.
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.