You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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
RemoteConversationthemselves. 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, andcontinue_conversationbehavior.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_conversationpath. 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
source,subject_key,turn,idempotency_key, andwake_agentwithout accepting an arbitrary conversation ID.RemoteConversation.attach.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.