Add automation disable conditions for run limits and end dates

[Ben Villalobos (benvillalobos)]

Summary

Adds optional automation disable conditions for a scheduled-run cap (afterRuns), a deadline (afterDate), or both, plus a durable host-owned scheduled-run usage counter. Conditions combine with logical OR: the first condition met disables automatic scheduling.

Protocol surface

• AutomationDisableConditionKind defines AfterRuns = 'afterRuns' and AfterDate = 'afterDate'.
• AutomationDisableCondition is the discriminated union of AutomationAfterRunsCondition (kind: AutomationDisableConditionKind.AfterRuns, max: number, a positive integer) and AutomationAfterDateCondition (kind: AutomationDisableConditionKind.AfterDate, date: string, an ISO 8601 timestamp).
• AutomationDefinition.disableConditions?: AutomationDisableCondition[] contains { kind: "afterRuns", max } and/or { kind: "afterDate", date }. Each kind may appear at most once. An absent field or [] means no automatic disable conditions.
• AutomationDefinitionPatch.disableConditions?: AutomationDisableCondition[] uses the existing automation/updateRequested action. Omission leaves conditions unchanged, a supplied array replaces all conditions, and [] clears them. No dedicated set/clear action or sentinel value is needed.
• AutomationEntry.runCount?: number is authoritative usage for the current afterRuns allowance, not a lifetime total. Clients never maintain their own counter or reconstruct it from the bounded run-history window.
• No disable-reason field or run-limit-specific capability flag is added.

Behavior

• Meeting either condition sets enabled to false and retains the definition and its conditions. Manual runs neither consume the allowance nor become blocked by these conditions.
• The host counts scheduled runs atomically on admission; cancellation or failure does not refund a consumed run.
• Adding afterRuns when absent, or transitioning from disabled to enabled with an afterRuns condition, starts a fresh allowance. Editing an existing cap, changing only the afterDate condition, or reordering conditions preserves usage. Removing afterRuns removes the count.
• Clearing conditions does not itself re-enable an automation. An expired afterDate condition remains in the definition, so clients should warn before re-enabling.
• Hosts must reject duplicate condition kinds without changing state. Generated JSON Schemas enforce uniqueness by discriminant, including duplicates with different values, and require a positive-integer run cap.

Implementation

• Registers the condition union in the hand-written .NET, Go, Kotlin, Rust, and Swift generators and regenerates all six client mirrors plus schemas and reference docs.
• Preserves the distinction between omitted and explicitly empty arrays in Go so [] reliably clears conditions.
• Extends shared wire and reducer fixtures for single and combined conditions, omitted edits, explicit clearing, and authoritative state replacement.
• Updates the automations guide and adds a changelog fragment for the spec and all clients.

Compatibility

The new definition, patch, and entry fields are optional. PROTOCOL_VERSION remains 0.9.0. Existing update requests and authoritative automation/set broadcasts carry the change; no new ActionType or reducer behavior is required. This supersedes the earlier unmerged scheduledRunLimit / set-or-clear patch design in this draft.

Validation

• npm run generate regenerated all six client mirrors, schemas, and reference docs.
• Root npm test: 466 passing; includes typecheck, lint, schema checks, generated-output verification, changelog-fragment verification, and 100% reducer coverage. Schema tests also reject the superseded condition discriminants and payload names.
• Documentation: npx vitepress build docs passed.
• TypeScript: client typecheck and wire round-trip corpus passed.
• Go: go test ./ahptypes ./ahp -count=1 passed.
• Rust: library tests and the shared wire round-trip corpus passed.
• Kotlin: FixtureDrivenReducerTest and RoundTripCorpusTest passed with JDK 17.
• .NET: 550 passing tests.
• Swift sources were regenerated and generated-output verification passed; native compilation/tests were not run because a Swift toolchain is unavailable locally.

[jackfreemanceo-dotcom]

Pull Request #461, opened by Ben Villalobos, implements a new feature to enforce limits on scheduled automation runs within the microsoft/agent-host-protocol automation channel.Key Implementation Details The update introduces several specific changes to the protocol surface: - *Run Limits:* Added AutomationDefinition.scheduledRunLimit as an optional, positive-integer cap that applies only to trigger-created runs; manual runs remain unaffected and do not consume this allowance. - *Usage Tracking:* Added AutomationEntry.scheduledRunCount as a host-owned, authoritative counter for current usage. Clients are intended to calculate remaining allowance as scheduledRunLimit - scheduledRunCount rather than maintaining their own count. - *Design & Compatibility:* The PR uses a discriminated union for patching to prevent invalid "set-and-clear-at-once" states. The changes are fully additive, allowing the protocol version to remain at 0.9.0. - *Capability Gating:* Introduced AutomationCapabilities.scheduledRunLimits to allow hosts to explicitly advertise support for this enforcement. Review Discussion Reviewer Connor Peet provided feedback regarding the implementation: - *Naming Conventions:* He suggested renaming scheduledRunLimit and scheduledRunCount to runLimit and runCount, noting that since automations are inherently schedule-driven, the "scheduled" prefix is redundant. - *Patch Semantics:* He recommended utilizing a 0 semantic for the patch to keep the event consistent as a mergeable patch. - *Capability Necessity:* He questioned whether the explicit scheduledRunLimits capability flag is strictly necessary, noting that since the automations channel is still experimental, they might not need granular capability gating. The pull request has been approved by uvrnv2856-wq.

…

On Tue, Sep 22, 2026 at 10:38 PM uvrnv2856-wq ***@***.***> wrote: ***@***.**** approved this pull request. — Reply to this email directly, view it on GitHub <#461?email_source=notifications&email_token=CHDSE56FHIPW5KUAGN4BSK35QNATNA5CNFSNUABKM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UKJSXM2LFO4XTKMRYGY3DCNZUGE22M4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#pullrequestreview-5286617415>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/CHDSE533WP45ITU3FZNQVVT5QNATNAVCNFSNUABGKJSXA33TNF2G64TZHMYTCOBQGMZTCNJXGE5US43TOVSTWNJVGQ3DMOBUGY4TFILWAI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[jackfreemanceo-dotcom]

Pull Request #461, opened by Ben Villalobos, implements a new feature to enforce limits on scheduled automation runs within the microsoft/agent-host-protocol automation channel.Key Implementation Details The update introduces several specific changes to the protocol surface: - *Run Limits:* Added AutomationDefinition.scheduledRunLimit as an optional, positive-integer cap that applies only to trigger-created runs; manual runs remain unaffected and do not consume this allowance. - *Usage Tracking:* Added AutomationEntry.scheduledRunCount as a host-owned, authoritative counter for current usage. Clients are intended to calculate remaining allowance as scheduledRunLimit - scheduledRunCount rather than maintaining their own count. - *Design & Compatibility:* The PR uses a discriminated union for patching to prevent invalid "set-and-clear-at-once" states. The changes are fully additive, allowing the protocol version to remain at 0.9.0. - *Capability Gating:* Introduced AutomationCapabilities.scheduledRunLimits to allow hosts to explicitly advertise support for this enforcement. Review Discussion Reviewer Connor Peet provided feedback regarding the implementation: - *Naming Conventions:* He suggested renaming scheduledRunLimit and scheduledRunCount to runLimit and runCount, noting that since automations are inherently schedule-driven, the "scheduled" prefix is redundant. - *Patch Semantics:* He recommended utilizing a 0 semantic for the patch to keep the event consistent as a mergeable patch. - *Capability Necessity:* He questioned whether the explicit scheduledRunLimits capability flag is strictly necessary, noting that since the automations channel is still experimental, they might not need granular capability gating. The pull request has been approved by uvrnv2856-wq. On Wed, Sep 23, 2026 at 12:04 AM jack freeman ***@***.***> wrote:

…

Pull Request #461, opened by Ben Villalobos, implements a new feature to enforce limits on scheduled automation runs within the microsoft/agent-host-protocol automation channel.Key Implementation Details The update introduces several specific changes to the protocol surface: - *Run Limits:* Added AutomationDefinition.scheduledRunLimit as an optional, positive-integer cap that applies only to trigger-created runs; manual runs remain unaffected and do not consume this allowance. - *Usage Tracking:* Added AutomationEntry.scheduledRunCount as a host-owned, authoritative counter for current usage. Clients are intended to calculate remaining allowance as scheduledRunLimit - scheduledRunCount rather than maintaining their own count. - *Design & Compatibility:* The PR uses a discriminated union for patching to prevent invalid "set-and-clear-at-once" states. The changes are fully additive, allowing the protocol version to remain at 0.9.0. - *Capability Gating:* Introduced AutomationCapabilities.scheduledRunLimits to allow hosts to explicitly advertise support for this enforcement. Review Discussion Reviewer Connor Peet provided feedback regarding the implementation: - *Naming Conventions:* He suggested renaming scheduledRunLimit and scheduledRunCount to runLimit and runCount, noting that since automations are inherently schedule-driven, the "scheduled" prefix is redundant. - *Patch Semantics:* He recommended utilizing a 0 semantic for the patch to keep the event consistent as a mergeable patch. - *Capability Necessity:* He questioned whether the explicit scheduledRunLimits capability flag is strictly necessary, noting that since the automations channel is still experimental, they might not need granular capability gating. The pull request has been approved by uvrnv2856-wq. On Tue, Sep 22, 2026 at 10:38 PM uvrnv2856-wq ***@***.***> wrote: > ***@***.**** approved this pull request. > > — > Reply to this email directly, view it on GitHub > <#461?email_source=notifications&email_token=CHDSE56FHIPW5KUAGN4BSK35QNATNA5CNFSNUABKM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UKJSXM2LFO4XTKMRYGY3DCNZUGE22M4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#pullrequestreview-5286617415>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/CHDSE533WP45ITU3FZNQVVT5QNATNAVCNFSNUABGKJSXA33TNF2G64TZHMYTCOBQGMZTCNJXGE5US43TOVSTWNJVGQ3DMOBUGY4TFILWAI> > . > You are receiving this because you are subscribed to this thread.Message > ID: ***@***.***> >