BusDK

BusDK Update

Worker goals: set a goal, steer the worker, and survive restarts

A Bus Worker can now carry a standing goal: an objective, and when supplied, a token budget. The goal is worker state that can be created, inspected, and controlled through the worker API, so a human operator can direct autonomous work through durable controls as well as prompts.

This is early goal execution for Codex/GPT App Server workers. Claude-engine workers do not execute goals yet, so goal state should be treated as an App Server worker capability today.

June 21, 2026bus-workerworker APIApp Server goals

In brief

TL;DR

  • A worker goal gives autonomous work a durable objective instead of making every turn depend only on prompt text.
  • The worker API exposes goal controls, including control messages that do not need to carry a new text turn.
  • Codex/GPT App Server goal metadata and goal events are propagated through worker starts and preserved when the worker restarts.

BusDK is built to be operated by AI agents, but agents still need a control surface that a human can reason about. A goal gives that surface a stable shape. The objective says what the worker is trying to complete, the optional budget bounds the run, and the API lets the operator steer the worker without depending on a single chat turn as the only source of truth.

The June 21 worker changes connect that model across the worker stack. bus-worker added App Server goal controls in the CLI and allows goal control messages without extra text. bus-api-provider-worker exposes the goal surface through the workers API and accepts those control-only messages. bus-integration-worker carries App Server goals through worker starts, propagates goal controls to the running worker, and preserves App Server goal and plan events so the state survives restarts.

The practical effect is simple: autonomous work becomes manageable. A worker can be given a standing objective, the operator can inspect or steer it through the API, and a restart does not erase the goal context that the App Server worker should continue from. That makes long-running worker operation easier to supervise while keeping the maturity caveat explicit: goal execution is experimental and currently belongs to Codex/GPT App Server workers.

See docs.busdk.com for Bus Worker API and worker operation details.