Agents

[AnthonyRonning]

No description provided.

[coderabbitai]

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: 4f4e4d15-5e26-4f4b-813c-294cae37812c

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch agents

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[AnthonyRonning]

I don't think we need to persist description here. Probably best it is hardcoded into the code in case we need to configure this later

[AnthonyRonning]

do we need to enforce char_limit at the db layer or allow it to be configured? another case for this just being hard coded.

[AnthonyRonning]

remove kimi default from sql layer, we should always pass this in

[AnthonyRonning]

Latest status after a full review of the branch diff against origin/master (not just the latest commit):

Readiness

Yes, with caveats for a dev-server deploy.

I think the branch is architecturally sound enough for dev and is broadly the right long-term direction. I would not call it prod-ready yet, but I also do not think the core Sage-in-Maple model is likely to be rewritten again.

Scope reviewed

• 19 commits ahead of origin/master
• 34 files changed
• roughly +10.2k / -295

Main buckets:

• RAG foundation / encrypted embedding storage and search
• explicit agent system (agents, memory_blocks, conversation_summaries)
• DSRS-backed runtime, SSE loop, typing events, vision preprocessing
• main agent + subagents + shared memory model
• conversation integration (hide main agent, show subagents)
• dev-only reset/delete and agent history APIs

What feels stable / foundational

These look like the right long-term decisions and likely won't change much:

• explicit agents table
• 1 main agent + many subagents
• one conversation per agent
• shared per-user memory / recall
• per-thread summaries
• separate agent runtime from Responses runtime
• hide the main agent from generic conversation lists while keeping subagents visible
• prompts/models/tuning owned by code rather than user config rows

Main caveats before dev deploy

1. Shared recall looks only partially landed
   I did not find a clear Responses-path auto-embedding flow into user_embeddings, so the intended “main agent + subagents + Responses threads share recall” story does not look fully complete yet.

2. Main-agent reset semantics may still be incomplete
   DELETE /v1/agent resets conversations and memory blocks, but it does not appear to clear archival embeddings. That may be fine, but it should be an intentional product choice.

3. Agent-specific test coverage is still light
   The repo validates cleanly overall, but the new agent surface would benefit from stronger end-to-end coverage around bootstrap/chat/list/reset behavior.

4. Dev deploy plumbing still has one real caveat
   nix build .#default --dry-run is fine, but nix build .#eif-dev --dry-run currently fails because nitro-toolkit/traffic_forwarder.py is missing in the flake source path.

Bottom line

My current view is:

• good enough for dev server
• not prod ready yet
• core architecture looks durable
• most remaining work looks like integration/polish/testing/operational cleanup, not a likely re-think of the main-agent/subagent/shared-memory design

If we keep this direction, the next highest-value items look like:

• finish shared recall ingestion from the Responses path (if that is still the intended product model)
• clarify reset semantics around archival memory
• add stronger agent integration coverage
• fix the #eif-dev build path

[AnthonyRonning]

Pushed the latest backend/docs update in 1f3d36e.

I think the next follow-up work should be:

1. Fix the remaining cross-user device ownership leak: do not transfer an existing push_devices row across users, and add a worker-side guard that rejects any notification_event.user_id != push_device.user_id mismatch before send.
2. Make temporary FCM OAuth token-exchange failures retryable instead of permanently failing Android deliveries.
3. Add targeted tests for push registration ownership transitions, worker delivery state transitions, and APNs/FCM error classification/request shape.
4. Clean up small contract drift (collapse_key example in docs, and clarifying that encrypted_preview_enabled controls sending the encrypted preview envelope, not falling back to plaintext content).
5. After that, circle back to the Android encrypted-preview path as a separate follow-up rather than blocking these core server-side correctness fixes.

For the current privacy bar, I do not think the remaining provider-visible routing metadata is a blocker so long as plaintext assistant content never leaves the enclave or gets placed in the provider-visible notification shell.