Repository navigation
Run research workers on a remote document's attached Planner - #730
Merged
Merged
Conversation
Under HARNESS=remote, /research always failed with "Research could not be started": startup required BACKGROUND_JOBS=off because summary and research workers had no model on the server, so the research-evidence and research-answer jobs were never registered and every request was refused as not ready (409 "research workspace is not ready"). The agent connection already has an isolated session mode for background work, and the remote adapter only needed to know which document a worker belongs to. openWorkerSession now registers each worker as an isolated session of its job's document, so under HARNESS=remote the research, research brief, description and History summary workers run on the client attached as that document's Planner, calling only their stage's host tools (web_search for evidence) and returning JSON. The job runner leaves a remote document's jobs pending while no client is attached, and an attach wakes them. HARNESS=remote no longer refuses background jobs; BACKGROUND_JOBS=off still keeps them off the attached clients. Assistant-model: Claude Opus 5.5 (fast) Assistant-workflow: inline Assistant-duration: 14m converged, estimated unmeasured Assistant-verification: agent-browser manual scenario passed: reproduced on a HARNESS=remote deployment, /research showed "Research could not be started." and POST /api/channels/:id/research-requests returned 409 "research workspace is not ready" Assistant-verification: red-before-fix passed: the new link.test.ts background-worker tests failed with "HARNESS=remote runs only Planner sessions" without the worker-session change Assistant-verification: bun test unit passed: GIT_CONFIG_GLOBAL=/dev/null bun test (6736 pass, 0 fail) Assistant-verification: typecheck and lint passed: bun run types and bun run ci Co-authored-by: Alex Lavaee <lavaman131@github.com>
lavaman131
force-pushed
the
run-research-on-attached-planner
branch
from
October 27, 2026 03:08
5d4063d to
4a21890
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
/researchfailed on deployments that runHARNESS=remotewhile Chat and Build worked. Research now runs on the client attached as the document's Planner, the same machine that already runs its Chat turns.Cause. Startup refused
HARNESS=remoteunlessBACKGROUND_JOBS=off, because summary and research workers had no model on the server. With jobs off, theresearch-evidenceandresearch-answerdefinitions were never registered, soResearchWorkspaceServicerefused every request asnot-ready. Reproduced on aHARNESS=remotedeployment: the card said "Research could not be started." andPOST /api/channels/:id/research-requestsreturned409 {"error":"research workspace is not ready"}.Fix.
openWorkerSessiontakes the job'schannelIdand registers the worker as an isolated session of that document (registerRemotePlanner), unregistering it on close. UnderHARNESS=remotethe existing remote adapter then sends the worker to the document's attached client inisolatedmode: no client tools, no Decisions, only the stage's host tools (web_searchfor evidence), and a JSONresponseFormat. Other harnesses never read the registry.resolveActivePlannerreturns no owner while a remote document has no attached client, so its jobs wait instead of burning attempts. An attach already callsownerAvailable, which wakes them.config.tsno longer refuses background jobs underHARNESS=remote.BACKGROUND_JOBS=offstill keeps every worker off the attached clients.docs/hosted-agent.mdanddocs/self-hosting.mddescribe the new behavior.The protocol and connector don't change:
isolatedsessions, host tools and JSON results are already part of the agent connection.Deploying. A remote deployment had to set
BACKGROUND_JOBS=offbecause startup required it. Remove that variable (or set it toon) after this merges, otherwise/researchstays disabled. With jobs on, document descriptions and History summaries also run on the attached machine, the same way they run on the server under other harnesses.Tests.
link.test.ts: a research worker opened throughopenWorkerSessionand the realcreateRemoteAdapter()reaches a client attached over the real agent connection. The test checks that it starts asisolated, is offered onlyweb_search, gets a JSON response format, runsweb_searchon the server, and returns the parsed evidence. A worker for a document with no attached client is refused. Both tests failed before theworker-session.tschange with "HARNESS=remote runs only Planner sessions".worker-session.test.tschecks that the isolated registration is removed on close.config.test.tsnow accepts remote with background jobs on.Assistant-model: Claude Opus 5.5 (fast)
Assistant-workflow: inline
Assistant-duration: 14m converged, estimated unmeasured
Assistant-verification: agent-browser manual scenario passed: reproduced on a HARNESS=remote deployment, /research showed "Research could not be started." and the research-requests POST returned 409 "research workspace is not ready"
Assistant-verification: red-before-fix passed: the new background-worker tests in link.test.ts failed without the worker-session change
Assistant-verification: bun test unit passed: GIT_CONFIG_GLOBAL=/dev/null bun test (6736 pass, 0 fail)
Assistant-verification: typecheck and lint passed: bun run types and bun run ci
Co-authored-by: Alex Lavaee lavaman131@github.com