CopilotKit / CopilotKit/OpenBot
A coworker created as Built in still cannot hand work on
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 5.2k
- Forks
- 655
- Avg merge
- 11h 56m
- Merged PRs (30d)
- 370
Description
Tracking the design question #317 deferred on purpose, so it survives the PR that half-answers it.
From that PR's description:
A coworker created as "Built in" through the wizard is stored as
remote_ag_uipointed at the
managed endpoint. Its tool callbacks work (the deployment-token path), but the handoff tool is
minted only inside this deployment's own run loop, so such a coworker can be asked but cannot
itself hand work on. […] Fixing it properly means either storing endpoint-less creates as
built_intype, or adding a server-minted hop endpoint to the callback surface — worth its own PR
either way.
What #331 covers
#331 takes the first option, because the interview it adds cannot end by asking somebody for a URL.
store.create writes a built_in coworker running on its role description where there is neither
an 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: agentRunsHere is
row.type === "built_in" (plugins/store.ts), and grantable on 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, create still prefers managedConfiguration, the
row 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:
- Store endpoint-less creates as
built_ineven when a managed Bot exists. Smallest diff, and
it 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. - Mint a hop endpoint on the callback surface. Leaves storage alone and makes the handoff tool
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.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Read the deferred design in #317 and the behavior described in #331, then inspect plugins/store.ts, especially the agentRunsHere and managedConfiguration paths. Compare the endpoint-less built_in storage option with minting a hop endpoint on the callback surface, and document the chosen behavior for deployments with an existing managed Bot and for coworkers already stored as remote_ag_ui.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- backend-api-design
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100