Dev Loop & Remote Workers

Your repo, the dev shell, and sync to an isolated remote worker per builder

The dev loop & remote workers

Audience: Customer developers. This is the inner loop: how the code you write becomes a running workflow on your own isolated remote worker — with no local runtime to operate.

You develop against a remote environment. There is no local Temporal, no local worker, no docker compose to babysit. You edit code, commit, and the platform rolls your code onto a personal isolated worker. One worker per developer, so your changes never disturb a colleague.

Requirements

• Python 3.11+, git, and uv (uv installs the SDKs and runs the dev shell).
• A GitLab token with the read_api scope — the SDKs install from the Agentic Hub GitLab package registry (not public PyPI). A read_registry-only token is for the container registry and will 403; use read_api.
• A reachable Agentic Platform dev environment (your instance). Installing needs only the token and network; the environment is needed once you actually run a workflow.

Your repository

The platform provisions your repo from a template. You edit a small, well-defined surface:

Import rule: in workflow/ (and agent/) code you may import only agentic_sdk, workflow_sdk, and the Python standard library. This is validated in CI — it keeps your workflow code portable and reproducible on the worker.

Configure and run

cp .env.sample .env
# edit .env: GITLAB_REGISTRY_USER = <any username>
#            GITLAB_REGISTRY_TOKEN = <your GitLab token, scope read_api>
git checkout -b feature/my-workflow    # the dev loop refuses to run on main (see below)
./dev.sh

dev.sh loads .env, installs/updates the SDKs from the registry, then starts the dev shell (agentic dev). The platform endpoints are baked into dev.sh at provisioning time — you never set (or mis-set) them. There is no login token in .env: signing in is interactive (device-flow OAuth2) the first time the shell needs it.

What happens on each commit

The dev shell watches your repo. Every time you commit, it re-syncs:

＋−⟲
⛶ Full Screen
Scroll to zoom · Drag to pan · 100%

Key points:

• The commit is the unit of sync. Your wheel's version is 0.1.0+<git-sha>, so each commit is an immutable, identifiable build. The dev shell won't sync a dirty tree — commit first, or the registered workflow and the worker's code would diverge.
• One isolated worker per developer, on its own task queue dev-<id>. Rolling a new build tears down your previous worker and starts a fresh one; colleagues are unaffected.
• No local runtime. The wheel is installed on the remote worker; you just watch progress (Building → Publishing → Rolling → Verifying → Ready).

Two guard rails

The dev loop enforces two rules so builds stay reproducible:

1. Run on a feature branch, not main. The loop builds a wheel per commit and reserves main for releases. On main it stops with a hint to git checkout -b feature/<name>.
2. Commit before you sync. A dirty working tree is refused (the version is the HEAD sha). The shell also nudges you if you edit files without committing.

Git flow → deployment

Today, the loop maps one commit on a feature branch → your personal remote worker. Promoting a workflow tenant-wide (a release everyone uses) is a separate, versioned step.

＋−⟲
⛶ Full Screen
Scroll to zoom · Drag to pan · 100%

Release (tenant-wide) is coming soon. The versioning and immutable-build mechanics exist, but the promote/deploy stage — publishing a workflow for your whole tenant across environments — is not yet enabled. For now, the dev loop gives every developer a personal, isolated runner.

Next: Building a workflow.