Repository navigation
A coworker created as Built in still cannot hand work on #399
Description
Activity
Seems like the main issue is with the "Built in" option not functioning as expected when a managed Bot is present. I'd check how the
createfunction is handling the coworker types in those scenarios.Still reproducible on
main(2e096d6).profile-store.ts:423-425still falls back tomanagedConfigurationwhen no endpoint is given, so a "Built in" coworker on a deployment with a managed Bot is stored asremote_ag_ui, andagentRunsHeresays no. #579 fixed the edit path for these coworkers and, as its description says, left this question open.I'm happy to take this on once you've picked a direction. Option 1 looks like the smaller diff: store endpoint-less creates as
built_ineven when a managed Bot exists. For the existingremote_ag_uirows pointing at the managed endpoint, I'd propose a migration that converts the ones whose endpoint equalsMANAGED_AGENT_AG_UI_URL. Without it the roster keeps both shapes, as the issue notes.Before I start: does #673 ("Bots work as coworkers") already change
createoragentRunsHere? If so I'll stay out of its way.Thanks @jerelvelarde for tracking this so it survived the PR that half-answered it, and @Chebaleomkar for re-checking it against
mainand offering to take it on.The good news is that the part people actually hit should be fixed now. #673 merged the day after your comment. It lets any Bot hand work on, including one running at its own endpoint, by calling back through the signed tool callback. A coworker created as "Built in" on a deployment with a managed Bot is stored as
remote_ag_ui, and it now getsmessage_botandask_personlike everyone else. The oldagentRunsHerecheck is gone. Its replacement isagentCanHandOninserver/src/plugins/store.ts, andserver/tests/remote-coordination.test.tscovers the remote path.That leaves the storage question, and I'd suggest we don't do the migration. Storing these coworkers as
built_inwould do more than change a label. It would move them off the managed Bot onto the in-process runtime. That changes their model, how their prompt is assembled, and whether they get the person's standing instructions. A migration keyed onMANAGED_AGENT_AG_UI_URLwould also miss rows written under an earlier value of that setting. Since handoff no longer depends on the storage shape, the cost doesn't seem worth it.So I think this can close. @Chebaleomkar, if you'd like to confirm on a deployment with a managed Bot that a wizard-created "Built in" coworker completes a hop, that would be the last check. If it doesn't, let's reopen and look at what it does. If you'd rather "Built in" always meant in-process, happy to talk that through as its own design question.
Tracking the design question #317 deferred on purpose, so it survives the PR that half-answers it.
From that PR's description:
What #331 covers
#331 takes the first option, because the interview it adds cannot end by asking somebody for a URL.
store.createwrites abuilt_incoworker running on its role description where there is neitheran endpoint nor a managed Bot — which on the one-container image the README recommends is every
coworker.
That buys back exactly what the note was about, in that case:
agentRunsHereisrow.type === "built_in"(plugins/store.ts), andgrantableon the handoff answer comes from it,so a coworker created that way can be handed work on.
What is still open
Where the deployment does have a managed Bot,
createstill prefersmanagedConfiguration, therow is still
remote_ag_ui, and nothing changes: the coworker can be asked and cannot hand work on.The wizard's "Built in" option is only offered on exactly those deployments, so the case #317
described is the case still outstanding.
Two ways out, both from the original note:
built_ineven when a managed Bot exists. Smallest diff, andit makes "Built in" mean one thing everywhere rather than two things depending on configuration.
The question is what happens to coworkers already stored the other way — they keep working, but
the roster then holds both shapes with no way to tell them apart except the endpoint string.
reachable from outside the run loop. Larger, and it puts a new server-minted address into a
surface that currently only issues tokens.
Not proposing either — this is #317's question and the choice is its author's. Filing it so it does
not disappear when #331 merges and the no-managed-Bot half stops being visible.