chore: bump agents from 0.17.4 to 0.23.0 in /client

[dependabot]

Bumps agents from 0.17.4 to 0.23.0.

Release notes

Sourced from agents's releases.

agents@0.23.0

Minor Changes

• #2193 87bd594 Thanks @​mattzcarey! - Extract facet ("sub-agent") machinery into packages/agents/src/dynamic-agents/, add the this.dynamicAgents capability facade, and reposition facets as an isolation primitive rather than the recommended way to model many chat sessions.

  Agent's facet routing, WebSocket forwarding, virtual connections, and registry (~2,400 of index.ts's ~12,150 lines) move into a dedicated module registered as a Lifecycle capability (capabilityId: "dynamic-agents"); its hot paths stay composition-root wired since the capability-runner hook contract can't express request-rewrite-and-continue or post-claim WebSocket forwarding. No wire- or storage-visible identifier changes.

  The public surface gains this.dynamicAgents.{get,abort,delete,has,list} plus the DynamicAgentClass and DynamicAgentStub type names. SubAgentClass and SubAgentStub remain as compatibility aliases. subAgent() / abortSubAgent() / deleteSubAgent() / hasSubAgent() / listSubAgents() are unchanged in behavior and now delegate to the same capability — @deprecated in place, not removed. /sub/ URLs, useAgent({ sub }), parentAgent(), and onBeforeSubAgent are untouched.

  docs/agents/sub-agents.md is rewritten: verified workerd facet semantics (separate isolate, own SQLite, no independent alarms, bounded nesting depth, machine-pinned tree), a corrected claim about WebSocket frame forwarding (every frame wakes the root parent — it was never true that frames go directly to the child post-upgrade), and an explicit decision rule for facets vs. independent Durable Objects. Two new examples: examples/next/dynamic-agents (a supervisor running user-submitted Durable Object code as facets via Worker Loader — what facets are for) and examples/next/chats (one top-level DO per chat plus a per-user push-based index — the recommended many-chats pattern), both with a React + Vite UI and workers-pool tests.

• #2175 8ffb3ad Thanks @​mattzcarey! - Lifecycle owns a durable job queue, driven as an alarm event loop.

  The thing in the queue is a job: a serialisable callback address — the owning capability plus a function name — with a due time and a payload. Capabilities and the host push jobs through the scoped jobs surface; Lifecycle drives due jobs in timestamp order when the alarm fires, owns dispatch retries and platform-failure deferral, arms a deadman pre-alarm before driving so an isolate death mid-drive still wakes the object, and derives the physical alarm purely from queue state (queue mutations re-arm automatically; an exclusive job suppresses ordinary candidates).

  class Cleanup extends LifecycleCapability {
    async scheduleSweep(time: number) {
      await this.lifecycle.jobs.push({ id: "sweep", fn: "sweep", time });
    }
    onJob({ job }: LifecycleJobContext) {
      // drive result: nothing = complete, { rescheduleAt } = suspend,
      // "yield" = leave due and wake again immediately
    }
  }

  The pull-based alarm-contribution model is removed: capability getNextAlarm()/onAlarm(), host getNextAlarm(), LifecycleServices.alarms (rearm/disabled), and AlarmContribution are gone. Host onAlarm() remains and runs once per alarm invocation after due jobs are driven. Terminal application failures reach the owner's onJobError(), whose drive result decides advancement.

  The alarm memory-limit circuit breaker (#1825) moves from Agent.alarm() into the Lifecycle event loop, targeting the exact executing job; Agent contributes domain policy through the new onAlarmMemoryLimit() host hook, and Scheduler's __DO_NOT_USE_WILL_BREAK__handleAlarmMemoryLimit escape hatch is gone. After recording a strike the breaker now finishes by resetting the isolate with ctx.abort(reason, { retryAlarm: false }) (retry of the handled alarm suppressed; the backoff alarm owns the next wake), and Agent.destroy() uses the same no-retry abort so a completed teardown's alarm cannot be retried into a fresh constructor that recreates

... (truncated)

Changelog

Sourced from agents's changelog.

0.23.0

Minor Changes

• #2193 87bd594 Thanks @​mattzcarey! - Extract facet ("sub-agent") machinery into packages/agents/src/dynamic-agents/, add the this.dynamicAgents capability facade, and reposition facets as an isolation primitive rather than the recommended way to model many chat sessions.

  Agent's facet routing, WebSocket forwarding, virtual connections, and registry (~2,400 of index.ts's ~12,150 lines) move into a dedicated module registered as a Lifecycle capability (capabilityId: "dynamic-agents"); its hot paths stay composition-root wired since the capability-runner hook contract can't express request-rewrite-and-continue or post-claim WebSocket forwarding. No wire- or storage-visible identifier changes.

  The public surface gains this.dynamicAgents.{get,abort,delete,has,list} plus the DynamicAgentClass and DynamicAgentStub type names. SubAgentClass and SubAgentStub remain as compatibility aliases. subAgent() / abortSubAgent() / deleteSubAgent() / hasSubAgent() / listSubAgents() are unchanged in behavior and now delegate to the same capability — @deprecated in place, not removed. /sub/ URLs, useAgent({ sub }), parentAgent(), and onBeforeSubAgent are untouched.

  docs/agents/sub-agents.md is rewritten: verified workerd facet semantics (separate isolate, own SQLite, no independent alarms, bounded nesting depth, machine-pinned tree), a corrected claim about WebSocket frame forwarding (every frame wakes the root parent — it was never true that frames go directly to the child post-upgrade), and an explicit decision rule for facets vs. independent Durable Objects. Two new examples: examples/next/dynamic-agents (a supervisor running user-submitted Durable Object code as facets via Worker Loader — what facets are for) and examples/next/chats (one top-level DO per chat plus a per-user push-based index — the recommended many-chats pattern), both with a React + Vite UI and workers-pool tests.

• #2175 8ffb3ad Thanks @​mattzcarey! - Lifecycle owns a durable job queue, driven as an alarm event loop.

  The thing in the queue is a job: a serialisable callback address — the owning capability plus a function name — with a due time and a payload. Capabilities and the host push jobs through the scoped jobs surface; Lifecycle drives due jobs in timestamp order when the alarm fires, owns dispatch retries and platform-failure deferral, arms a deadman pre-alarm before driving so an isolate death mid-drive still wakes the object, and derives the physical alarm purely from queue state (queue mutations re-arm automatically; an exclusive job suppresses ordinary candidates).

  class Cleanup extends LifecycleCapability {
    async scheduleSweep(time: number) {
      await this.lifecycle.jobs.push({ id: "sweep", fn: "sweep", time });
    }
    onJob({ job }: LifecycleJobContext) {
      // drive result: nothing = complete, { rescheduleAt } = suspend,
      // "yield" = leave due and wake again immediately
    }
  }

  The pull-based alarm-contribution model is removed: capability getNextAlarm()/onAlarm(), host getNextAlarm(), LifecycleServices.alarms (rearm/disabled), and AlarmContribution are gone. Host onAlarm() remains and runs once per alarm invocation after due jobs are driven. Terminal application failures reach the owner's onJobError(), whose drive result decides advancement.

  The alarm memory-limit circuit breaker (#1825) moves from Agent.alarm() into the Lifecycle event loop, targeting the exact executing job; Agent contributes domain policy through the new onAlarmMemoryLimit() host hook, and Scheduler's __DO_NOT_USE_WILL_BREAK__handleAlarmMemoryLimit escape hatch is gone. After recording a strike the breaker now finishes by resetting the isolate with ctx.abort(reason, { retryAlarm: false }) (retry of the handled alarm suppressed; the backoff alarm owns the next wake), and Agent.destroy() uses the same no-retry abort so a completed

... (truncated)

Commits

• 5f7ad7e Version Packages (#2174)
• b9142be fix(agents): preserve sub-agent onConnect connection state (#2233)
• d5d250e perf(sessions,think): memoise the auto-compaction estimate and drop per-turn ...
• 8c8f86d feat(agents): move Voice and Channels into agents package (#2225)
• 0966a0b perf(think,sessions): stop re-reading the transcript during a turn (#2219)
• dcca089 fix(codemode): truncate structured results structurally and keep the call log...
• dd8bf90 perf(chat): derive the recovery progress marker from the stream log (#2223)
• dd09d44 feat(streams): rollover block log and atomic stream → session cutover (#2216)
• ec93caf feat(agents): move sessions into a Lifecycle capability (#2196)
• 6da4c44 refactor(chat): run recovery continuations on Tasks (#2194)
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[dependabot]

Labels

The following labels could not be found: dependencies. Please create it before Dependabot can add it to a pull request.

Please fix the above issues or remove invalid values from dependabot.yml.