Skip to content

[Improve] Offer bounded monitoring for ongoing processes - #2291

Draft
roomote-roomote[bot] wants to merge 1 commit into
developfrom
feature/ongoing-process-follow-up-2ss2irs229l3v
Draft

[Improve] Offer bounded monitoring for ongoing processes#2291
roomote-roomote[bot] wants to merge 1 commit into
developfrom
feature/ongoing-process-follow-up-2ss2irs229l3v

Conversation

@roomote-roomote

Copy link
Copy Markdown
Contributor

​Opened on behalf of @daniel-lxs. Follow up by mentioning @roomote-roomote, in the web UI, or in Slack.

Related issue

Requested in the linked task discussion; no linked issue. Inspected #2268, which remains open and proposes specialized required-check notifications; this change neither imports nor depends on that policy.

Why this PR exists

  • A maintainer explicitly invited this PR in the linked issue or discussion
  • I am a maintainer / this is internal Roomote work

Useful verification can happen after the current turn. Fast should offer that follow-up when it can resolve a concrete outstanding outcome, without turning every closeout into a monitoring pitch.

What changed

  • Add three generic Fast prompt rules for bounded ongoing-process follow-up, rather than modifying individual workflows.
  • Gate offers on a concrete unresolved outcome and actual verification capability. Ask one specific consent question with timing and a stop bound; never imply deployment or completion without evidence.
  • Require acceptance before scheduling an offer while preserving direct scheduling for explicit monitoring requests. Revalidate capability, reuse equivalent wakeups, keep monitoring quiet and finite, and avoid duplicate notifications or repeated offers.
  • Add three focused prompt-contract tests. No scheduling infrastructure or notification handlers changed.

How it was tested

  • 88 tests passed: Fast prompt and wakeup args, parser and schedule suites via package-scoped Vitest.
  • pnpm --filter @roomote/cloud-agents check-types and git diff --check passed.
  • Normal pre-commit formatting and pre-push oxlint, residual lint, fast typechecks and Knip passed. Knip emitted one non-failing existing configuration hint.
  • Browser proof is not applicable to this prompt-generation change. No live-model behavioral evaluation or real monitoring schedules were run; contract tests verify prompt content, not model compliance. Full root test suite and root pnpm lint/pnpm check-types were not run.

Checklist

  • The PR title follows the repo convention: [Fix], [Feat], [Improve], [Refactor], [Docs], or [Chore] followed by a user-facing description
  • This PR is small and scoped to one change
  • pnpm lint and pnpm check-types pass locally
  • I added tests or included a clear manual validation note above
  • I removed secrets, tokens, private keys, and customer data from code, logs, and screenshots
  • If this change should appear in the changelog, I ran pnpm changeset

@roomote-community

roomote-community Bot commented Sep 6, 2026

Copy link
Copy Markdown
Contributor

1 issue outstanding. See task

  • packages/cloud-agents/src/server/fast-agent/fast-agent-prompt.ts:342 The bounded-monitoring rule conflicts with the wakeup tool guidance that permits unbounded monitors.

Reviewed caa5a80


## Ongoing Process Follow-Up
- Proactively offer a specific bounded check only when an ongoing process has a concrete unresolved outcome worth verifying later and available tools can actually verify it. Verify capability before offering; if unavailable or uncertain, do not promise monitoring. Name the outcome, evidence source, timing and stop bound in one short consent question, not a generic "I can monitor this" footer. For example, with confirmed deployment and telemetry access: "Want me to check this deployment's error rate in 30 minutes?" Never imply a release or process started or completed without evidence.
- An offer is not authorization: create no wakeup until the user accepts. Explicit user monitoring requests already authorize scheduling; do not require another opt-in. Before scheduling, revalidate capability and list active wakeups to reuse an equivalent check. Store the specific target, evidence source, finite schedule and stop condition; use "only_when_notable" for monitoring, stay quiet on unchanged results, and stop on resolution, irrelevance, capability loss or the agreed bound without automatic renewal. Missing evidence is not success.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This requires every monitoring schedule to be finite, but MANAGE_WAKEUPS_TOOL_DESCRIPTION still tells the model that monitors run until cancellation/resolution and presents unbounded every 10m as a normal choice. The scheduler also permits those schedules, so the conflicting tool guidance can still create an indefinitely running monitor. Align the wakeup guidance (or enforce a bound) so the new bounded-follow-up contract is reliable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant