{"slug": "what-happens-when-an-ai-agent-stops-being-a-disposable-session", "title": "What happens when an AI agent stops being a disposable session?", "summary": "Blankline Research released Dropstone SDK 1.0, the first stable TypeScript SDK for the Dropstone agent runtime, featuring Continuity, a persistent memory per account shared across CLI, chat, and pipelines. The SDK enables programmatic access to the same agent with one memory, eliminating the need to sync or export context between sessions. This design moves memory below the tools, similar to how databases centralized application state, allowing any new surface to benefit from shared knowledge.", "body_md": "# Introducing Dropstone SDK 1.0: One Memory Across CLI, Chat, and Your Pipelines\n\n[Blankline Research](/about)2026.08.17 · 10m read\n\nToday we are releasing Dropstone SDK 1.0, the first stable version of the TypeScript SDK for the Dropstone agent runtime.\n\nThe 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.\n\nThis 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.\n\n## Every Tool Starts from Zero\n\nIf 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.\n\nThe 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.\n\nWe think that assumption is the actual problem. If memory lives inside tools, you end up building plumbing between them forever. So we moved it.\n\n## One Memory, Below the Tools\n\nSoftware 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.\n\nContinuity 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.\n\nThis 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.\n\n## What This Looks Like in Practice\n\nHere 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:\n\n``` js\nimport { createDropstone } from \"@blankline/dropstone-sdk\"\n\nconst { client, server } = await createDropstone()\n\nconst session = await client.session.create({\n  body: { title: \"CI dependency check\" },\n})\n\nconst reply = await client.session.prompt({\n  path: { id: session.data.id },\n  body: {\n    parts: [{ type: \"text\", text: \"Add the install step for this repo.\" }],\n  },\n})\n\n// The agent already knows this repo uses bun.\n// You taught it once, in the CLI, yesterday.\nconsole.log(reply.data)\n\nawait server.close()\n```\n\n## What Happens When a Pipeline Remembers\n\nThe 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.\n\nA 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.\n\nNone of these require a smarter model. They are the same model with a past. And because the memory is shared, the learning compounds in both directions: something the pipeline discovers overnight is available to you in the CLI the next morning, and something you teach the CLI in the morning shapes what the pipeline does that night.\n\n## How It Decides What to Keep\n\nA memory that keeps everything is a landfill, so Continuity keeps two kinds of things and treats them differently.\n\nA rule is a standing instruction. Always use arrow functions. Never add a dependency without asking. Rules apply to every task without being searched for, because a preference that only shows up when the task looks related will quietly stop applying the moment the subject changes. A fact is something that happens to be true right now: the staging database is behind the VPN, this project pins Node 22. Facts are recalled only when they are relevant, since pulling every fact into every conversation would be noise.\n\nThe agent records a lesson the moment you correct it, reject an approach, or state a preference, rather than waiting for the end of a task. When it cannot tell whether something is a rule or a fact, it stores a fact, because a missed rule costs you one reminder while a wrong rule follows you everywhere. You can ask at any time what it has learned, and it forgets only when you tell it to. And if memory is ever unavailable, the session simply continues without it. Memory should be an advantage, never a dependency.\n\n## Two Ways to Use the SDK\n\nFor CI, automation, and serverless, you do not need the CLI installed at all. The headless client talks directly to the Dropstone API with an API key, and the API follows the chat completions shape that most AI tooling already uses, so switching an existing integration over is usually a base URL change.\n\nAPI keys are created inside your account, and memory access follows the account the key belongs to. A session started from a pipeline key shares the same account memory as your CLI and chat, because the key is just another door into the same account:\n\n``` js\nimport { createDropstoneApi } from \"@blankline/dropstone-sdk\"\n\n// Reads DROPSTONE_API_KEY from the environment.\nconst dropstone = createDropstoneApi()\n\nconst resp = await dropstone.chat.completions.create({\n  model: \"dropstone-pro\", // or \"dropstone-fast\" / \"dropstone-heavy\"\n  messages: [\n    { role: \"user\", content: \"Summarize the nightly test failures.\" },\n  ],\n})\n\nconsole.log(resp.choices[0].message.content)\nconsole.log(\"Cost: $\" + resp.usage?.cost)\n```\n\n## The Full Agent, as a Library\n\nThe second mode embeds the complete agent. A single call spawns the same runtime the CLI uses as a local subprocess and hands you a typed client against it: sessions, file operations, tools, streaming, structured output, and the same account memory the CLI and chat use. Sign in once with the CLI and every SDK session inherits the same memory.\n\nBecause it is the same runtime, the safety model carries over unchanged. Every tool call, file edit, and shell command sits behind an approval gate before it executes. The model behind the agent changes from cycle to cycle. That boundary does not, because it lives in the runtime rather than in the weights.\n\n## What 1.0 Means\n\nCalling something 1.0 is a stability promise, so here is what we mean by it. The client is fully typed, with TypeScript definitions generated from the server's OpenAPI specification. Every request body, query parameter, and response autocompletes in your editor and maps one-to-one to the documented API.\n\nThe v1 surface stays backward compatible. New endpoints land on the v2 subpath export, which mirrors the newer Effect HttpApi contract, so existing integrations keep working while new ones get the richer surface. The SDK is used in production and ships on a fast cadence, so pin the version range you depend on.\n\nTwo things worth knowing about how it is built. Most of the SDK was written by Dropstone itself, working in the same codebase it now helps maintain, which is the product working as intended. And memory is the part of the runtime we are continuing to develop most actively. Continuity gets better from here; 1.0 is a promise about the API surface, not a claim that the memory work is finished.\n\n## What We Are Not Claiming\n\nMemory requires being signed in. If you are not signed in, nothing is stored and the memory tools are not loaded.\n\nContinuity stores what you explicitly teach it: rules, facts, and corrections. It is not a recording of your sessions, and session context is not kept after a session ends. If you want to see everything it holds, ask. If you want something gone, say so.\n\nFinally, memory makes an agent consistent, not correct. A wrong rule will be applied faithfully until you remove it. We think that is the right trade, because the alternative is an agent that never improves, but it is a trade, and you should make it with your eyes open.\n\n## Get Started\n\nThe SDK is on npm at [https://www.npmjs.com/package/@blankline/dropstone-sdk.](https://www.npmjs.com/package/@blankline/dropstone-sdk.) Install it with:\n\n```\nnpm i @blankline/dropstone-sdk\n```\n\n“Memory was never a feature of a tool. It is infrastructure, and it belongs below the tools, not inside one of them.”\n\n## Conclusion\n\nDropstone SDK 1.0 is live on npm today: npm i @blankline/dropstone-sdk. The package is at [https://www.npmjs.com/package/@blankline/dropstone-sdk,](https://www.npmjs.com/package/@blankline/dropstone-sdk,) the full reference is at [https://docs.dropstone.io/cli/sdk,](https://docs.dropstone.io/cli/sdk,) and the memory model is documented at [https://docs.dropstone.io/cli/memory.](https://docs.dropstone.io/cli/memory.)\n\nModels are rented. Tools are rented. What your agent has learned is the only part of the stack that compounds, and it should belong to you. That is what one memory below the tools means, and it is what 1.0 ships.", "url": "https://wpnews.pro/news/what-happens-when-an-ai-agent-stops-being-a-disposable-session", "canonical_source": "https://www.dropstone.io/blog/dropstone-sdk-1-0", "published_at": "2026-08-17 11:57:20+00:00", "updated_at": "2026-08-17 12:11:20.557622+00:00", "lang": "en", "topics": ["ai-agents", "developer-tools", "ai-infrastructure"], "entities": ["Blankline Research", "Dropstone SDK 1.0", "Dropstone agent runtime", "Continuity", "TypeScript"], "alternates": {"html": "https://wpnews.pro/news/what-happens-when-an-ai-agent-stops-being-a-disposable-session", "markdown": "https://wpnews.pro/news/what-happens-when-an-ai-agent-stops-being-a-disposable-session.md", "text": "https://wpnews.pro/news/what-happens-when-an-ai-agent-stops-being-a-disposable-session.txt", "jsonld": "https://wpnews.pro/news/what-happens-when-an-ai-agent-stops-being-a-disposable-session.jsonld"}}