Start and Control Agents

Admit coding tasks, send durable follow-ups and cancel exact session targets with opt-in write credentials.

These source endpoints require matching Auth/Coding releases. They reuse the existing lifecycle; configured Temporal enables durable startup and Stop retries. HTTP 202 means accepted work, not completed coding or confirmed cancellation.

Prepare write access

After CLI login, configure the acting member’s native connection and issue a new key with explicit write scope:

lobby model-keys connect openai --input ./provider.key
lobby api-keys create --name automation --account ACCOUNT_ID --repository REPOSITORY_ID --scopes account:read,workspace:read,agent:write --output ./lobby-api.key

Keep both private files outside Git. Provider save does not validate live access. Existing keys remain read-only; revoke/replace to change immutable scopes. The member also needs current GitHub write access.

Requests and responses

Send Authorization: Bearer LOBBY_API_KEY without cookies.

Method and path	JSON body
`POST /api/v1/agents`	`requestId`, `repositoryId`, `task`, `modelAccess`, `adapter`, `model`; optional `keyProvider`, `branch`, `visibility`, `reasoningEffort`
`POST /api/v1/agents/CONVERSATION_ID/messages`	`messageId`, `text`
`POST /api/v1/agents/CONVERSATION_ID/runs/RUN_ID/cancel`	`messageId` matching the observed active prompt, or null if no active prompt ID exists

requestId and follow-up messageId are client UUIDs. Trimmed task/text must contain 1–20,000 characters; total JSON is at most 64 KiB. Unknown fields are rejected. Repository IDs are positive numeric IDs in key scope. Visibility defaults to shared; private creates an isolated workspace. Effort defaults to low, accepting existing product effort values; branch uses existing validation.

Use modelAccess: personal-codex with adapter: codex and an already connected model, or modelAccess: api-key with keyProvider: openai / adapter: codex or keyProvider: anthropic / adapter: claude. Supply a model accepted by that native connection. Projects, discovery starts, gateway access, attachments and retention options are outside this increment.

Accepted requests return 202:

{
  "conversationId": "CONVERSATION_UUID",
  "workspaceId": "WORKSPACE_ID",
  "runId": "RUNNER_SESSION_UUID",
  "messageId": "MESSAGE_UUID",
  "state": "accepted",
  "url": "https://lobby.abloatai.com/app/chats/CONVERSATION_UUID"
}

Use agent/run inspection for persisted state. runId identifies a runner session spanning prompts, not an independent per-prompt run. New follow-up after replacement may return a new session; replay returns the original admitted session even if it is now historical.

Retries and cancellation

Save the UUID and payload before sending. Retry the same UUID and normalized payload after interrupted responses. Starts deduplicate across concurrency and lost admission acknowledgements. Follow-ups read their durable message before waking compute, avoiding duplicate/restarted work. Different input under the same ID returns 409 conflict; do not generate a new ID merely because a response was lost. IDs persist with conversation/history records; rotating keys does not require new request IDs for the same member.

For Stop, read the selected session and send its exact activeMessageId. Do not blindly target the latest session after an uncertain response. Shared cancellation and, when configured, the workflow check that pair again and cannot cancel a newer prompt. Finished/superseded targets return 409 run_not_cancellable; reread state. Queued follow-ups that have not become active are not independently cancellable here.

Errors and remaining boundaries

No-store responses use the member API request-ID envelope: invalid_request (400), unauthorized (401), forbidden / model_unavailable (403), not_found (404), conflict / capacity_reached / run_not_cancellable (409), rate_limited (429), or auth_unavailable / unavailable (503). Raw service errors are withheld. Current identity, private visibility, repository permission and key scope are rechecked. Already accepted work may finish after revocation; later requests fail. Keys cannot decide approvals or authenticate browser/harness routes. Reads/writes share the existing 60/min per-key quota.

Activity replay/history, retained outputs, public approvals, per-prompt execution identity and model discovery remain separate work. Admission is not proof of task success.

Without Temporal, startup uses the existing background launch/attach path and Stop awaits the existing runner acknowledgement path. Web-process loss can strand accepted startup; replay returns its original admission without launching again. Automatic lifecycle recovery requires configured Temporal.