Introducing Dropstone SDK 1.0: One Memory Across CLI, Chat, and Your Pipelines<br>Downloads<br>Contact Sales<br>Log inDownload

Contents<br>Introduction<br>Every Tool Starts from Zero<br>One Memory, Below the Tools<br>What This Looks Like in Practice<br>What Happens When a Pipeline Remembers<br>How It Decides What to Keep<br>Two Ways to Use the SDK<br>The Full Agent, as a Library<br>What 1.0 Means<br>What We Are Not Claiming<br>Get Started<br>Conclusion

Share

Today we are releasing Dropstone SDK 1.0, the first stable version of the TypeScript SDK for the Dropstone agent runtime.<br>The SDK gives you programmatic access to the same agent that runs in the Dropstone CLI and chat, and it carries the part we think matters most: one persistent memory per account, shared across every surface the agent runs on. We call it Continuity. Teach the agent something in the CLI and a session started from the SDK already knows it. Learn something in a CI pipeline at 2am and it is there the next time you open chat. There is nothing to export and nothing to sync, because there was never more than one memory in the first place.<br>This post covers why we built it this way, what changes when a pipeline can remember, and the limits you should know about before you build on it.

Every Tool Starts from Zero<br>If you use AI tools every day, you already know the routine. You correct the coding agent on Monday, and on Tuesday a different tool makes the same mistake. You paste the same architecture summary into a chat window because the chat window was not in the room when the decisions were made. None of this is dramatic on its own, but it adds up to a real cost: every tool you use starts from zero, every time.<br>The industry's answer over the past year has been a wave of memory plugins. Some sync your rules between editors. Some export your chat history into files. Some keep a shared note that every tool re-reads at the start of a session. They are sincere attempts, and they all share one assumption: that memory belongs to the tool, and the best we can do is copy it around.<br>We think that assumption is the actual problem. If memory lives inside tools, you end up building plumbing between them forever. So we moved it.

One Memory, Below the Tools<br>Software has made this move before. Application state used to live inside each application, and teams built endless tooling to keep the copies consistent. Then state moved into databases, a layer below the apps, and most of that tooling quietly disappeared because there was nothing left to keep consistent. Identity went through the same shift with single sign-on.<br>Continuity applies the same idea to what an agent has learned. There is one memory per account, held by the runtime rather than by any app. The CLI reads it. Chat reads it. VS Code reads it. The SDK reads it. When every surface shares one memory, cross-surface memory stops being a feature you configure and becomes a property you rely on.<br>This is also why the SDK matters beyond convenience. An SDK is how the agent gets into pipelines, scheduled jobs, internal tools, and places nobody has thought of yet. If those sessions shared nothing with the rest of your work, we would have built a faster way to create more silos. Because they share the same account memory, every new surface makes the whole system more useful.

What This Looks Like in Practice<br>Here is the simplest version we can show. Suppose yesterday, in the CLI, you corrected the agent once: this repo uses bun, not npm. Tonight this script runs in CI, on a clean runner, with no configuration copied over and no context pasted in:

ci-review.tsTypeScriptCopy

import { createDropstone } from "@blankline/dropstone-sdk"

const { client, server } = await createDropstone()

const session = await client.session.create({<br>body: { title: "CI dependency check" },<br>})

const reply = await client.session.prompt({<br>path: { id: session.data.id },<br>body: {<br>parts: [{ type: "text", text: "Add the install step for this repo." }],<br>},<br>})

// The agent already knows this repo uses bun.<br>// You taught it once, in the CLI, yesterday.<br>console.log(reply.data)

await server.close()

What Happens When a Pipeline Remembers<br>The demo above is deliberately small. The reason we care about the SDK is what the same property does at pipeline scale, because a pipeline is really just a surface that runs while you are asleep.<br>A release pipeline that remembers your last forty deploys does not need to be told your rollback convention again. A monitoring agent that remembers last month's incident does not start the next investigation from a blank page; it compares what it sees now against what it saw then. A security watcher that remembers the shape of a previous intrusion attempt recognizes the second attempt sooner, because recognition is what memory is for. A support agent that remembers what engineering decided last week stops giving customers last month's answer.<br>None of these require a smarter model. They are the same model with a past. And because the memory is shared,...