The Ondemand AI SDK, now available on PyPI, marks a significant step forward for developers building scalable automations on the Ondemand platform. By wrapping the powerful Temporal workflow engine with opinionated, batteries‑included tooling, the SDK removes much of the boilerplate traditionally required to connect workers, report progress, and manage artifacts. This release arrives as organizations increasingly seek to orchestrate AI/ML pipelines, data processing jobs, and multi‑step business processes in a cloud‑native, observable way. Rather than assembling disparate libraries for task queuing, logging, and storage, teams can now rely on a single, coherent abstraction that works seamlessly with Google Kubernetes Engine Autopilot and KEDA‑driven scaling. The result is a faster path from idea to production, with built‑in safeguards for reliability and visibility.
At the heart of the SDK lies the OndemandWorker, a purpose‑built Temporal worker that adds automatic log capture and graceful shutdown handling. When the process receives a SIGTERM signal—common in container orchestrations where pods are terminated for scaling or updates—the worker finishes in‑flight activities, flushes logs, and exits cleanly, preventing orphaned tasks or lost progress. This removes a common source of friction in self‑managed Temporal deployments, where engineers must manually implement shutdown hooks and log forwarding. By embedding these concerns into the worker itself, the SDK lets developers focus on workflow logic rather than infrastructure lifecycles, improving both reliability and operational simplicity.
Progress reporting is handled by the ActivityReporter, which pushes step updates to the Ondemand portal via a STEP_REPORT webhook each time an activity changes state. Unlike batching approaches that delay visibility, each call fires immediately, ensuring the portal can reflect the latest status through Server‑Sent Events (SSE) with minimal latency. The SDK defines a clear set of step statuses—RUNNING, SUCCEEDED, FAILED, WARNING, and SKIPPED—that the portal translates into color‑coded indicators for rapid visual scanning. This real‑time feedback loop is invaluable for long‑running automations, allowing stakeholders to spot bottlenecks, failures, or warnings as they happen rather than after the fact.
One of the most developer‑friendly aspects of the SDK is its seamless local development experience. When the ONDEMAND_WEBHOOK_URL environment variable is absent, all reporting methods become no‑ops, meaning that calls to log progress or upload artifacts do not trigger external network requests. This design eliminates the need for mocking services or adjusting configuration during unit tests or iterative coding sessions. Developers can run workflows locally, inspect logs in the console, and verify behavior without worrying about inadvertently hitting production endpoints. The same code then runs unchanged in the managed environment, where the platform injects the appropriate webhook URL at runtime, guaranteeing parity between dev and prod.
Logging receives a first‑class treatment through an automatically configured handler that the OndemandWorker installs at startup. This handler captures every log line emitted by the workflow and its activities, forwarding them to two destinations: the Ondemand portal for live viewing and a Cloudflare R2 bucket for durable archival. The console format follows a clean, readable pattern—timestamp – module – LEVEL – message—while the portal applies semantic color coding (e.g., red for errors, green for success) to accelerate triage. Because the handler is attached without any manual setup, teams gain consistent, observable logging across all automations, reducing the chance of critical traces being lost in noisy stdout/stderr streams.
Before the introduction of ActivityReporter, the SDK relied on a query‑based step tree reporter that stored workflow state inside Temporal itself and exposed it via the Temporal Query API. While functional, this approach introduced polling overhead and added latency to UI updates, as the portal had to repeatedly query the workflow for the latest state. The SDK documentation now positions this method as a legacy option, recommending that new automations adopt ActivityReporter for its push‑based, low‑latency characteristics. The query‑based reporter remains available for specialized scenarios where a direct Temporal query is preferable, but the forward‑looking guidance favors webhooks for their simplicity and responsiveness.
To enrich log semantics, the SDK provides a custom logger that defines a SUCCESS level (numeric value 25) sitting between the standard INFO and WARNING thresholds. This level offers a concise way to denote expected, positive outcomes without the verbosity of INFO or the urgency of WARNING. Accompanying helpers for structured output enable developers to emit key‑value pairs or JSON blobs that downstream log‑processing pipelines can easily parse. By encouraging a uniform logging vocabulary across teams, the SDK simplifies the creation of alerts, dashboards, and retrospective analyses, turning raw log streams into actionable intelligence.
Artifact management is delegated to Cloudflare R2, an S3‑compatible object storage service accessed through the familiar boto3 library. The SDK abstracts bucket configuration, automatically creating scoped output directories for each workflow run and passing references between steps as needed. Whether storing trained model files, intermediate data sets, or diagnostic screenshots, developers can rely on a reliable, cost‑effective storage backend that integrates natively with the platform’s logging and reporting features. This tight coupling ensures that artifacts are not only persisted but also discoverable via the portal, linking execution logs directly to the data they produced.
Human‑in‑the‑loop (HITL) capabilities address a critical gap in fully automated systems: the need for manual judgment at key decision points. The SDK exposes helpers that pause a workflow execution and wait for an approval signal from the Ondemand portal, resuming only after a human operator clicks “Approve” or “Reject.” Typical use cases include validating model performance before promotion, confirming data quality after ingestion, or enforcing compliance checkpoints in regulated industries. By encapsulating the pause/resume pattern in a reusable abstraction, the SDK reduces the risk of ad‑hoc implementations that could lead to inconsistent states or missed notifications.
Runtime safety is reinforced by the platform’s automatic injection of two crucial environment variables: ONDEMAND_RUN_ID and ONDEMAND_WEBHOOK_URL. These are set by the activity interceptor when a workflow executes inside the managed environment, ensuring that each run has a unique identifier and a valid webhook target for progress reporting. Developers are explicitly advised never to set these variables manually, as doing so could disrupt the platform’s correlation and telemetry mechanisms. For local experimentation, the variables can be defined manually or sourced from a .env file, allowing developers to simulate the production contract without exposing secrets to version control.
Licensing under the permissive Apache 2.0 license, the SDK targets Python 3.9 and higher, depending on well‑established libraries such as the Temporal SDK, boto3, and various utilities for structured logging. Publishing internal extensions or plugins to PyPI requires a configured API token (typically stored in ~/.pypirc or supplied via TWINE_PASSWORD), a detail the documentation highlights to prevent accidental credential leaks. The SDK’s arrival coincides with a broader market shift toward managed workflow platforms that combine scalable compute (e.g., GKE Autopilot + KEDA) with observable, developer‑centric tooling, positioning Ondemand as a compelling option for teams seeking to reduce operational overhead while retaining control over their automation logic.
To get the most out of the Ondemand AI SDK, begin by evaluating whether your use case aligns with the platform’s managed Temporal + KEDA model—particularly if you benefit from automatic scaling to zero and built‑in logging/artifact pipelines. Start with a minimal workflow containing a single activity to verify that logging, progress reporting, and R2 storage function as expected in both local and deployed contexts. Monitor pod scaling events and associated costs through GKE Autopilot’s dashboards, adjusting KEDA’s cooldownPeriod if you observe premature scale‑downs during spiky workloads. Incorporate HITL steps for any manual gatekeeping, and leverage the custom SUCCESS level to enrich your logs for easier alerting. Finally, consider contributing feedback or enhancements back to the SDK; as the ecosystem grows, community‑driven improvements will help shape the next generation of cloud‑native automation tooling.