Beta: the SDK is usable, but its public surface is still evolving.
Inside a Play: describe the work
A Play handler uses runtime context methods to call tools, record steps, create datasets, compose compatible scalar children, and make recorded external requests. The runtime can inspect and retain those operations because they have explicit identities and supported contracts. A dataset is row-oriented work within the run. A scalar child Play is a reusable computation within its parent’s lifecycle. They are not interchangeable: a child with its own dataset or waiting boundary cannot automatically be embedded as an inline call. The authoring surface is more constrained than arbitrary application code. Deepline needs to admit a supported execution graph and bindings before it can run the artifact. TypeScript helps describe inputs and outputs, while authoring checks validate the supported shape. Neither proves the business answer.Outside a Play: own the request and its observation
An application starts an admitted Play and receives a job identity. That application decides where to persist the identity, how long to wait, and what to do with the result. A CLI or agent is another caller of the same remote work. An application’s HTTP lifetime is usually shorter than the job’s lifetime. If a worker stops polling, the run can continue. Recovering observation of the same run is therefore a separate operation from submitting new work. The SDK provides convenient handles for this distinction. Raw HTTP callers still have to interpret the response package and preserve the public run ID. Choosing a synchronous wait changes the caller experience, not the need to understand remote execution and failure.Named and prebuilt Plays share an invocation model
An owned Play preserves your business rule. A prebuilt Play supplies maintained logic with a published contract. Both can be invoked with an appropriate input; a prebuilt title alone does not establish that it accepts your file or desired identifier. A tool is lower-level: one provider-backed operation. A Play can combine tool results with validation, selection rules, and destination actions. The extra layer is useful when the outcome needs more than one request.Triggers extend the caller boundary
Schedules, inbound webhooks, and supported SQL listeners provide automated entry points. They supply timing and input to admitted logic. They do not move all workflow policy into a scheduler or make an external source a trusted fact. A Monitor remains a separate event-ingestion component. Its accepted rows can start a listener-driven Play, but setting up an SDK client alone does not subscribe the workspace to an external feed.Choose the practical guide
For exact methods, fields, and supported types, use the
SDK reference and
Runtime API reference.