Describe the feature or problem you'd like to solve
If an interaction ends with a scheduled prompt, the harness still prints a bell despite not needing user interaction
Proposed solution
There are a few ways to go about this:
- Don't print a bell character if there is a prompt scheduled (unconditionally).
- Add a parameter to
manage_schedule (and /every, /after) to suppress bells so long as that prompt is still scheduled. (leave it up to the model to decide if a bell is needed)
- Allow the
agentStop custom hook to return a value to suppress the bell. (would allow a custom hook that looks for a sentinel phrase)
My preference is option 2, as it is the most flexible.
Example prompts or workflows
Example workflow:
A custom agent that queues a release (that takes a long time), waits for it to finish, then runs tests against it.
Currently, the agent would queue the release, then check its status, then queue a follow-up prompt to check the status again. Bell. Then when the scheduled prompt runs, another bell will play when that interaction ends. This will repeat until the release finishes. When the release does finish, the agent continues with the workflow, which may require more user interaction, causing more bells that the user has been now trained to ignore.
Basically, any workflow where the agent is polling via scheduled prompts. Currently, with each poll, the harness plays the bell even if there is no reason to. If you have multiple polling sessions, it can get quite annoying and it makes it impossible to know when you hear a bell if it's just the polling or if the agent needs something from you (or is really done).
Additional context
No response
Describe the feature or problem you'd like to solve
If an interaction ends with a scheduled prompt, the harness still prints a bell despite not needing user interaction
Proposed solution
There are a few ways to go about this:
manage_schedule(and/every,/after) to suppress bells so long as that prompt is still scheduled. (leave it up to the model to decide if a bell is needed)agentStopcustom hook to return a value to suppress the bell. (would allow a custom hook that looks for a sentinel phrase)My preference is option 2, as it is the most flexible.
Example prompts or workflows
Example workflow:
A custom agent that queues a release (that takes a long time), waits for it to finish, then runs tests against it.
Currently, the agent would queue the release, then check its status, then queue a follow-up prompt to check the status again. Bell. Then when the scheduled prompt runs, another bell will play when that interaction ends. This will repeat until the release finishes. When the release does finish, the agent continues with the workflow, which may require more user interaction, causing more bells that the user has been now trained to ignore.
Basically, any workflow where the agent is polling via scheduled prompts. Currently, with each poll, the harness plays the bell even if there is no reason to. If you have multiple polling sessions, it can get quite annoying and it makes it impossible to know when you hear a bell if it's just the polling or if the agent needs something from you (or is really done).
Additional context
No response