https://docs.all-hands.dev/ logo
Join Slack
Powered by
I'd like to propose that we use feature flags more...
# proj-agent-canvas
c
I'd like to propose that we use feature flags more. 🙏 Agents are good at figuring out where to place them, just tell it what you want to test out there. We can make a page somewhere in Settings, with its own menu item. Perhaps it could look like here or something. Do you have an opinionated take on what makes OpenHands better? 😅 Ship it under a feature flag. That way, it's not on by default, but we can tell people about it, let them enable it and see. Alternative: • make apps more capable, so we can ship ~anything as an app, or anything UI, such as, any UI modification. I'd love to know your thoughts!
1000000 1
e
I agree!
m
@calm-artist-7206 what would you like to see in apps? In general I would prefer to preserve feature flags for WIP or things that are not ready to deploy to all users.
c
Anything UI, such as, APIs for replacing text, slots, adding text in composer, rendering; widgets above/below the composer, etc. 
canvas.composer.setText()
Basically, what I have in mind is fairly full UI control/customization a la pi
nod 1
In general I would prefer to preserve feature flags for WIP or things that are not ready to deploy to all users.
OpenHands has done this in the past, with env vars. Undocumented env vars, and we can still do that, why not? What I mean is different: testing user-oriented features. See if people like a thing, get early feedback, before deciding what is the new default.
I'm thinking it may enable us to move faster, and with more confidence from early feedback, that the new thing is a thing people want. 🤔
h
It would help if we had something to use it on to start with. I can't think of any beta type features at the moment but in general I like when this is possible
e
oh i have a bunch of ideas! • "Ask clarifying questions" - encourages agent to check in more with questions • "Always create pull requests" - so it stops leaving things in local files and asking if i want a PR • "Automatically fix merge conflicts" • "Automatically fix failing status check"
c
The last three sound to me like we could have a "Proactive Agent" setting, WDYT? It seems a more proactive behavior
e
• “Automatically resume all sessions when I start one” • Include effort level picker next to session model picker”
The last three sound to me like we could have a “Proactive Agent” setting, WDYT? It seems a more proactive behavior
I think an always on agent is separate. I want that but that is different than having a reactive agent do certain things automatically as part of its turn by turn workflow
• One-click follow-up actions — after a turn, offer context-aware actions like “review this diff” or “add tests,” rather than having to type them every time. • Session inbox — group sessions by “needs my input,” “finished,” and “still working,” so I can manage several agents without opening each one.
nod 1
m
a Proactive Agent feature should definitely be a setting not an app
I think some of those could be set in the custom system prompt
but having a toggle might be better for discovery
e
wait, why don't i have a place to put in a system prompt?
but having a toggle might be better for discovery
Agreed. I think most people don't really know what to think to put in a system prompt. Advanced users obviously know but also having certain checks at the harness level can be a lot more deterministic than just putting it in the system prompt and praying
m
wait, why don't i have a place to put in a system prompt?
you should in localhost under localhost/settings/agents then select "Default + your instructions" under "System prompt" it's not in cloud yet, I'm working on closing the localhost - cloud gap
making power user things accessible for non power users sounds good
🙌 1
e
gotcha, I use cloud so thats a blocker for me.
Open in Slack
PreviousNext
Powered by