[kovtcharov]

GAIA couldn't follow up on anything by itself. "Check on the build in 2 hours" or "remind me tomorrow at 9" got a cheerful "Set!", but nothing ever ran or alerted. A reminder was just a memory note that came up the next time you chatted (#5681). Now the agent schedules its own one-shot follow-ups. At the set time, even with no chat open, GAIA runs the task, posts a desktop notification, and opens your next chat, in the terminal app or the Agent UI, with the result. It builds on the daemon's existing clock, which until now had no executor at all, as docs/plans/autonomy-engine.mdx §5 planned.

Test plan

• pytest tests/unit/test_daemon_followups.py tests/unit/test_follow_up_tools.py: 27 pass. They use the real daemon clock and store on a temp DB, with the agent call and notification stubbed. They cover:
  • time phrases, and the limits (1 minute to 7 days, at most 10 waiting);
  • a due follow-up running, notifying and keeping its answer;
  • one that isn't due not running;
  • a failure being kept so the user hears about it;
  • a failed notification still keeping the answer;
  • each result reported once;
  • the routes;
  • the tool sending the chat's model;
  • the per-turn check only attaching to a running daemon, never starting one.
• test_memory_mixin.py adds a test that the timed-reminder rule appears only where follow-ups exist. 577 pass across the memory, scheduler, bundle, relay-profile, prompt-context, registry and capability-matrix suites. All 783 daemon tests pass except one that fails on main too under a custom GAIA_HOME.
• vitest (components): 1042 pass; tsc clean.
• Live on macOS, DeepSeek via Fireworks, an isolated daemon:
  • "In 2 minutes, count the .txt files under …" fired on time and answered correctly (8, each listed), with a banner. The next session opened with the result, and the one after didn't repeat it.
  • "Remind me in 2 minutes to stretch" fired with a banner.
  • "Remind me tomorrow morning to call mom" became a job for 9:00, and cancelling one worked.
  • In the 24-step memory suite, every step still passes. "Dentist next Tuesday at 3pm" now also schedules a 2:30pm heads-up on its own.
• Fixed during live testing: the first fired run used the local default model instead of the chat's cloud model, and the next tried a shell command that an unattended run must refuse. Follow-ups now carry the chat's model, and the fired prompt names the no-approval tools to use.
• Memory and tool-selection eval categories on the next RC: this adds tools, a memory-prompt line for timed reminders, and a sentence in the Agent UI scheduling line.

Not in this PR: the cheap pre-fire gate and the agent noticing on its own that it's waiting (§5, #3969). No Windows banner yet: the existing notification sink only supports macOS and Linux, and on Windows the result is still kept and shown in the next chat.

Part of #555 (the agent schedules its own follow-ups; proactive messaging beyond that is still open there).

[github-actions]

Verdict: Request changes

This PR gives GAIA working follow-ups: "check on the build in 2 hours" now runs on the daemon's clock, posts a desktop notification, and the result shows up in the next chat. The design holds up: real limits, a fired run that can't use approval-gated tools, and tests that run the real clock and store. One delivery bug needs fixing before merge, because it can stop the user from ever hearing a result.

• One follow-up's run can hide another's result. Each turn, the agent collects unseen results and marks them seen. That includes the unattended turn the daemon starts for a fired follow-up. If two follow-ups fire before the user chats again, the second run takes the first one's result. The first result then reaches the user only if the second answer happens to repeat it. The fired run should skip that step, or results should be marked seen only once a user-facing turn has used them.
• A failed turn loses the result. Results are marked seen before the model answers. If that turn errors (backend down, timeout), the result is gone. Also, if marking them seen fails, the error escapes and breaks the turn. That step can also start a daemon, which the code says a turn must never do.
• Agent UI screenshot still to come. The description shows live runs as text, which is fine for the daemon and tool path. The Agent UI part (new activity labels, plus the new line in its scheduling prompt) has no before/after screenshot yet. Please add one, but don't hold the merge on it.

Real-world evidence

N/A: no evidence bundle was produced for this run. This verdict comes from reading the code, plus the author's own live macOS test notes in the PR description (scheduling, firing, notification, cancelling, each result shown once). Nothing was re-run here.

🔍 Technical details

🟡 Fired follow-up run consumes other follow-ups' results (src/gaia/agents/tools/follow_up_tools.py:539-570, src/gaia/daemon/followups.py:1105)
ask_sidecar sends the fired prompt to the gaia sidecar's /query. That runs MemoryMixin.process_query → get_memory_dynamic_context() → follow_up_context(), which GETs every unseen result for agent_id="gaia" and marks it seen (memory.py:3474). Scenario: A fires at 10:00, B fires at 10:05, and the user next chats at 11:00. B's run marks A seen, and the 11:00 turn sees only B. A test covers "each result reported once", but not two results firing before a user turn. Options:

• The daemon passes a marker on the fired body (e.g. a follow_up_run field on the query, or a header), and follow_up_context returns "" for that run.
• Or tag results with an origin and skip them in daemon-initiated turns.
  Add a test with two jobs firing back to back, followed by one user turn.

🟡 Results marked seen before delivery; mark-seen failures uncaught (follow_up_tools.py:569, :515)

• _mark_follow_ups_seen runs before the LLM call. A turn that then fails drops the result for good. Consider marking seen after the turn completes (e.g. in _after_process_query), keeping the fetched ids on self.
• _mark_follow_ups_seen sits outside the try, so a DaemonError propagates out of get_memory_dynamic_context and fails the whole turn. That breaks the docstring's promise ("logged and leaves the turn without the line").
• It calls followups_request with the default start=True, which contradicts the "attach only" comment a few lines up. Minimum fix:

        try:
            self._mark_follow_ups_seen([r["job_id"] for r in results])
        except DaemonError as e:
            logger.info("follow-up results not marked seen this turn: %s", e)
        return "\n".join(lines)

Also pass start=False, timeout=3.0 through _mark_follow_ups_seen when it's called from the per-turn path. The same uncaught raise exists in _list_follow_ups. There it fails a tool call, which is less severe.

🟢 parse_when uses a fixed UTC offset (followups.py:872, :914)
datetime.now().astimezone() gives a fixed offset. "Tomorrow at 9am" across a DST change fires an hour off. zoneinfo/tzlocal-aware arithmetic would fix it. Low impact.

🟢 registry.py import reflow is unrelated to the feature
The GPU_CTX_SIZE, NPU_CTX_SIZE import collapse is a drive-by change. Harmless, but it's outside the PR's scope.

Strengths

• The executor reuses the existing clock's claim, heartbeat and fail-marking. A failed run is recorded and re-raised, so nothing is swallowed, and _record is idempotent across stale-lease recovery.
• Strong guardrails against a runaway agent: one-shot jobs, 1 minute to 7 days ahead, at most 10 waiting, a cap on task length, and a fired prompt that states the no-approval tool limits.
• Every bundled doc changed together, consistently (README, SPEC, SKILL, CHANGELOG, capability matrix, tool counts).

[kovtcharov-amd]

A follow-up scheduled from a chat with internet turned off, or from a private chat, ran later with internet on and memory saving. Fixed in 25972b5: the fired run now carries the chat's internet and memory switches along with its model.

The other permission paths hold: a fired run that reaches an approval-gated tool ends with a refusal the user sees in the next chat, rather than waiting or approving. The earlier review's delivery findings are addressed by f4d5cfa.

🔍 Technical details

• The fired /query used a fresh follow-up-<id> session and sent neither internet_off nor memory, so the sidecar fell back to its defaults (internet_off=False, memory on).
• _run_switches() in follow_up_tools.py records internet_off and, when the agent is incognito, memory: "private" | "off". CreateFollowUp accepts both (memory is a Literal, so an unknown mode gets a 422). followups.run_settings() forwards only model, internet_off and memory, so other payload keys can't reach the query body.
• AskAgent's third argument went from model to a settings dict. The tests cover the payload round trip, the route, the ask_sidecar body, and the private, memory-off and internet-off chats.
• Gate check: with can_answer_questions: false, _declare_who_answers sets nobody_answers, and needs_confirmation ends the stream with _confirmation_refusal (test_server_query.py). The only way past it is the process-wide GAIA_AUTO_APPROVE opt-in, the same as for any unattended run.

[kovtcharov-amd]

Holding this for eval results: the permission fix checks out, but the new always-on "remind me" tool sits right on top of memory scenarios that use "remind me" to mean "tell me again", and there are no eval numbers yet showing the agent still recalls instead of scheduling.

Before merge, please run gaia_memory, memory, gaia_tool_selection and tool_selection (memory, gaia-signal, gaia-tasks and tools lanes in eval_flagship.yml), plus gaia_skills_tasks, and compare against the flagship baseline.

🔍 Technical details

Why this plausibly shifts baselined behaviour

• schedule_follow_up joins the always-on set (16 → 17), so every turn's tool list carries it. Its bundle description leads with "remind", and the new memory-prompt line tells the model to call it for "A reminder at a time … tomorrow morning".
• Baselined turns that say "remind me" but mean recall:
  • gaia_memory/mem_correction_in_passing: "remind me, where do I live?"
  • gaia_memory/mem_forget_then_verify: "I need to book a cleaning — remind me who my dentist is?"
  • gaia_memory/mem_long_horizon_distractors: "OK — remind me when and where my talk is?" This one also seeds a dated event. The PR's own live test notes that a dated appointment now gets a heads-up scheduled without being asked.
• gaia_skills_tasks/task_checkin_follows_up scores "follows up" behaviour and ends on "run starts tomorrow.", which is a natural spot for an unrequested schedule_follow_up.
• The Agent UI scheduling line now steers one-off requests to the tool, which touches tool_selection and gaia_tool_selection.

What I checked and found sound

• Fired runs send can_answer_questions: false. run_settings() filters the payload to model/internet_off/memory before it is spread into the body, so nothing can override that flag. _declare_who_answers then sets nobody_answers, and gated tools refuse instead of waiting.
• No Always-allow grant carries over. session.permissions.attach is per session, and each fired run uses a fresh follow-up-<job_id> session.
• 25972b5: _run_switches() forwards internet_off and, when incognito, memory: private|off. The sidecar's _apply_internet_switch/_apply_memory_mode honour both, and tests cover the route, the payload and the ask_sidecar body.
• CI is green on 5ed1da9 (84 pass, 12 skipped), there are no conflicts, and the earlier review's delivery findings are addressed by f4d5cfa.