Skip to content

Add service-owned subject turns for agent-backed automations #463

Description

@neubig

Problem or Use Case

Agent-backed automations currently have two incomplete execution paths. Event triggers can route later events to a deterministic subject conversation, but scheduled or programmatic automations cannot submit work for a subject through the same machinery. Extension workers therefore decode Agent Server URLs and session keys and attach to RemoteConversation themselves. This duplicates lifecycle code across extensions, exposes runtime details at the wrong layer, and makes local and Docker execution harder to keep identical.

GitHub issue, pull-request, and thread automations need a stable conversation per external subject. A poller should be able to identify a subject such as repository ID plus pull-request number and ask the Automation service to create or resume its conversation. The role implementation should only select work and provide the next turn.

Desired Behavior

Add a service-owned subject-turn operation that reuses the existing subject_key, conversation_id_for, subject locking, coalescing, and continue_conversation behavior.

The scanner remains an ordinary automation script: it needs neither a conversation nor a Docker runtime. Profile selection scopes the saved credentials available to that script and is independent of execution mode. Only the child agent work created by this operation provisions a local or Docker conversation runtime.

The caller supplies a stable opaque subject key, source, turn text, and idempotency key. The Automation service namespaces the key by organization and automation, creates the first conversation with the automation's selected agent profile, or appends and wakes the existing conversation. The service serializes turns for one subject and reports whether a request created, delivered, queued, or deduplicated work.

Expose the operation through the Automation service API. Authentication must restrict a running automation to submitting turns for itself. Agent Server operations continue through software-agent-sdk; conversation creation, attachment, profile resolution, secrets, local/Docker selection, wake-up, and cleanup remain outside extension code.

Event triggers continue using the existing declarative destination: continue_conversation path. Scheduled pollers use the same subject-turn operation programmatically. A GitHub reviewer can use the immutable repository ID plus PR number as its subject key and the head SHA as its idempotency key.

Subject conversations must have a bounded lifecycle: concurrent events are coalesced, closed/released subjects no longer route to an old runtime, and idle Docker resources can be reclaimed without silently attaching to an unrelated conversation.

Acceptance Criteria

  • A typed subject-turn request accepts source, subject_key, turn, idempotency_key, and wake_agent without accepting an arbitrary conversation ID.
  • The first request creates a deterministic conversation with the automation's selected agent profile; another request for the same subject resumes it, while different subjects and different automations remain isolated.
  • Duplicate idempotency keys do not deliver the same turn twice, and concurrent requests for one subject cannot create multiple conversations.
  • A running automation receives credentials that can submit subject turns only for its own automation and cannot attach to arbitrary conversations.
  • Extension code does not need Agent Server URLs, runtime session keys, workspace-kind checks, profile loading, or RemoteConversation.attach.
  • A profile-backed scanner runs without creating a conversation; only submitted agent work acquires a conversation runtime.
  • Event-triggered and programmatic subject turns share the existing routing and coalescing implementation.
  • Local and Docker-backed tests exercise the same public contract, including wake-up, failure, release, and bounded cleanup behavior.
  • Agent Server communication uses software-agent-sdk rather than private HTTP calls.

Additional Context

This builds on the execution boundary in #464 and tracked agent-turn runs in #465, and completes the general capability introduced by #362 rather than adding a second conversation identity system. It is needed to simplify agent-backed extensions such as GitHub issue triage and PR review, which should contain GitHub policy but no runtime attachment code.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requestready-for-devScoped for contribution; managed by repository readiness checks.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions