Describe the bug

Long-running connector jobs expose an incomplete control contract. Status must be polled manually using an advisory recommended polling interval, with no blocking wait or completion-watch operation. Submission can then fail because an undisclosed active-job limit has already been reached.

When a job terminates unsuccessfully, the returned error can be a broad sanitized message covering unrelated causes such as credentials, connectivity, schema, permissions, disk, database execution, or output processing, without a stable error category or retryability. In the observed session these gaps caused repeated status calls, a loop-guard intervention, a shell-sleep workaround, an avoidable capacity rejection, and blind query rewrites.

To reproduce

1. Submit two long-running connector jobs.
2. Call the job-status tool while they run and observe that it returns an advisory polling interval but provides no blocking wait or watch parameter or completion notification.
3. Attempt to submit another job and observe that submission is rejected because two jobs are already active, although the maximum capacity and current availability were not exposed before submission.
4. Submit or monitor a job that terminates unsuccessfully.
5. Observe a broad sanitized failure message without a stable error code, a sufficiently actionable failure phase, or retryability guidance.

Expected behavior

The asynchronous-job contract should:

• Support an efficient native wait or watch operation, or a blocking status call.
• Expose active and maximum job capacity before submission, or queue excess jobs.
• Return privacy-safe structured errors with stable error codes, execution phase, and retryability.

Agents should not need rapid polling, shell sleep, trial submissions, or blind query rewrites.

Suspected cause

Medium confidence because the connector implementation itself was outside the checked Biorouter repository, but the session and advertised tool schemas establish the interface gaps. The status tool accepts only a job identifier; it returns a recommended polling interval but offers no wait duration, blocking timeout, or event subscription. The submission tool exposes query and output controls but no capacity information, and no job-list or capacity tool was advertised.

The connector instructions make manual polling the intended workflow. Biorouter's v1.93.2 agent-loop review in docs/history/agent-loop-review/subsystem-reviews/core-loop-and-tool-dispatch.md separately identifies the general lack of adaptive per-tool waiting and partial progress as an architecture weakness. The two-job rejection confirms a connector resource limit that is enforced only at submission.

The terminal ValueError text intentionally withholds raw details, which is reasonable for data protection, but it also collapses distinct actionable causes. This likely needs a shared asynchronous-job result contract in Biorouter plus adoption by the connector: a wait_for_job operation or blocking status, active_jobs and max_active_jobs metadata or queuing, and sanitized error_code, phase, and retryable fields.

Additional context

This report is intentionally limited to the asynchronous job-control contract. It does not cover the working-directory path jail or the separate problem of terminal operation failures appearing as successful outer tool calls.

Do not attach a diagnostics bundle from the originating private chat to the public issue because it contains the conversation unredacted.

Verification status

Reported behavior is being checked against current source with synthetic reproductions. No originating private transcript or diagnostics bundle is attached. Related connector implementations: BaranziniLab/UCSFOMOPAgent and BaranziniLab/CDWAgent.