Allow a separate model preset for the heartbeat notification evaluator

Problem / Motivation

The heartbeat notification evaluator currently uses the same provider and model as the main agent.

After a heartbeat task has been executed, nanobot performs a second LLM call to decide whether the resulting response should actually be delivered to the user (should_notify).

This evaluation is a relatively small classification task, but currently it is executed using the agent's main model. If the main agent uses a larger or more expensive model, this makes every executed heartbeat unnecessarily more expensive and potentially slower.

For example, an agent may need a capable model to perform the heartbeat task itself, while the final decision

"Should this result be delivered to the user?"

could usually be handled by a much smaller and cheaper model.

It would therefore be useful to configure the heartbeat notification evaluator independently from the main agent model.

Proposed Solution

Add an optional model preset for the heartbeat notification evaluator.

Conceptually, configuration could look like:

{
  "gateway": {
    "heartbeat": {
      "enabled": true,
      "evaluatorModelPreset": "luna"
    }
  }
}

If evaluatorModelPreset is configured, the post-run notification evaluator should use the provider/model defined by that preset. If it is not configured, the evaluator should keep the current behavior and inherit the main agent's provider/model. This would make the change fully backwards-compatible. The existing evaluator logic and semantics should remain unchanged:

• heartbeat task runs using the normal agent model
• the evaluator receives the task context and agent response
• it decides should_notify
• evaluator failures continue to fail closed / suppress notification as they do today The only change would be which model/provider performs the evaluation.

Alternatives Considered

Continue using the main agent model

This keeps configuration simple, but a potentially expensive model is used for a small classification decision after every executed heartbeat.

Hard-code a cheaper evaluator model

This would reduce cost, but would introduce provider-specific assumptions and would not work well for users with different providers or available models.

Use a dedicated non-LLM classifier

This could be useful in the future, but seems like a larger architectural change. Allowing a separate model preset would be a small and flexible first step and would also fit the existing model preset abstraction.

Related Component

Configuration

Additional Context

The current heartbeat implementation already separates task execution from notification evaluation.

The heartbeat task is executed first via the normal agent, and the resulting response is then passed to evaluate_response(). Currently the evaluator is called with the main agent's provider and model.

This proposal does not change the heartbeat execution or notification policy. It only makes the model used for the post-run evaluation configurable.

This could also provide a reusable pattern for other lightweight routing/evaluation decisions in nanobot in the future, without requiring that broader functionality as part of this issue.