What happened
Factory’s public droid-sdk-typescript repository documents the package @factory/droid-sdk, a TypeScript SDK for integrating Droid into applications. Its stated scope includes running Droid, continuing conversations, streaming work, controlling tools, and connecting to a Droid daemon that is already running. The repository presents two entry points: @factory/droid-sdk/node for Node, and the root package entry point for browser or Node clients that connect to an existing daemon. The Node entry point can start Droid subprocesses, run prompts, manage local sessions, and define SDK MCP tools; the root entry point exposes daemon connections, browser-safe schemas, types, and REST helpers.
For a basic Node invocation, the README uses run() with a prompt and checks whether the result succeeded before reading its text. For multi-turn conversations it points developers to createSession(). By default, Node session APIs start the droid CLI from the system PATH and read FACTORY_API_KEY; session options can supply a custom executable, API key, or transport. To use a running daemon, an application can call connectToDaemon() from the root entry point. The documentation also describes sessions, streaming, attachments, structured output, permissions, AskUser, tools, skills, MCP, hooks, session replacement and cleanup, observability, and advanced resources.
The package is installed with npm install @factory/droid-sdk. The README advises Node.js 20 or later. Although the package declares Node.js 18, version 0.10.0 needs the global Web Crypto API, which Node.js 18 provides only with the --experimental-global-webcrypto flag. This is a version-specific runtime caveat in the supplied documentation, not a claim that all versions of the SDK have the same requirement.
The browser integration connects to a local daemon; examples let the user enter a daemon URL, API key, and working directory in the page rather than editing source code or injecting credentials through environment variables. Factory explicitly says this integration is intended for trusted local tools. It warns against shipping an API key in a public website, committing it to source control, or putting it in a URL. The repository includes Node and browser examples, as well as a mission example showing orchestrator and worker progress. It documents local test, typecheck, lint, formatting, and documentation-check commands. Live examples require both FACTORY_API_KEY and a Droid CLI on PATH, and use credits. The supplied source does not give a price for those credits or state when the SDK was released.
What the archive adds
An earlier Telegram post described Factory’s CLI, while another covered the company’s Series B and Droid availability. The SDK is a distinct integration surface: the new information here is that applications can use a TypeScript package to manage Droid runs and sessions, not just invoke the CLI. The supplied archive provides no link to those Telegram posts, so none is included here.
Trend signal
This supports Harness architecture outlives model choice: the SDK’s focus is the runtime around a Droid run—sessions, tools, permissions, streaming, daemon connections, and cleanup. That is a useful example of a harness being exposed as an application integration boundary. The source does not compare models or show that teams are choosing harnesses independently of model choice, so the evidence supports the pattern narrowly rather than proving its broader thesis.
Why now
The source establishes that the repository and SDK are available, but it does not explain the timing of the release or connect it to a particular event. The practical timing is therefore a matter of current availability, not a documented market or product trigger: teams evaluating a TypeScript integration can inspect the package and examples now.
Why it matters
A CLI is convenient for a developer at a terminal; an SDK makes it possible for an application to own the interaction. The documented methods give builders places to attach their own workflow: start a prompt, continue a session, stream progress, define tools, or connect through a daemon. That may be useful when Droid needs to operate as one component inside a product or internal system rather than as a standalone command.
The distinction between the Node and browser/daemon paths is also operationally important. Node applications can start local subprocesses, while browser clients connect to an existing daemon. Factory’s API-key warning makes clear that browser integration is not a safe way to expose credentials from a public site. Teams should treat the daemon and its key as trusted local infrastructure, and decide how sessions, permissions, tools, and cleanup fit their own application boundary. The README describes available mechanisms; it does not establish that they alone make an integration secure or production-ready.
Limits and uncertainty
The supplied source is the repository README and its documentation summary. It does not establish a release date, adoption, customer results, performance, model compatibility, or a price for API use or credits. It also does not explain the daemon’s deployment model beyond connecting to a running daemon, or provide independent security validation. Version 0.10.0 is mentioned only in relation to Node’s Web Crypto requirement; the source does not identify it as the latest release. Browser use is explicitly scoped to trusted local tools, not public websites.
Skill to build now
Build a small local proof of concept that starts a Droid run, streams its progress, and then continues the conversation through a session. Use the documented Node entry point and keep credentials in the local environment rather than browser code or URLs. If the application needs browser access, test it against a local daemon and verify how its API key, working directory, permissions, and session cleanup are handled. The repository’s runnable examples and non-live checks provide a starting point; live examples consume credits.
Reader takeaway
The SDK turns Droid from a CLI-only integration into a documented TypeScript surface for runs, sessions, tools, and daemon connections. That is useful for builders embedding Droid in an application, but the browser path is for trusted local tools, and the repository alone does not establish production readiness, pricing, or adoption.