Problem
The v2 API only exposes notebook-scoped search (POST /api/v2/workspaces/{workspaceId}/notebooks/{notebookId}/search). There is no way to search across all notebooks in a workspace in a single request.
Why it matters
AEGIS uses MindSpring in its recall pipeline during every dispatch — recall.ts fires a semantic query in parallel with the Memory Worker to inject relevant context before generating a response. Currently this only hits the legacy global search endpoint (GET /api/search), which covers the original conversation archive.
We've now built a write pipeline that pushes extracted facts to per-topic notebooks (e.g. aegis, infrastructure, project) and session transcripts to a session_history notebook. These are dark at query time — ingested but never retrievable — because querying them would require:
- Listing all notebooks in the workspace
- Firing N parallel search requests (one per notebook)
- Merging and re-ranking results
That's too expensive per-dispatch (adds N subrequests + latency on the hot path).
Proposed endpoint
POST /api/v2/workspaces/{workspaceId}/search
Body: same shape as notebook search — { query, limit?, threshold? }
Response: results with a notebook_id + notebook_title field on each hit so callers can attribute the source.
This would be a one-line change in recall.ts:
/api/search?q=... → /api/v2/workspaces/aegis-daemon/search (POST, body: { query, limit, threshold })
And would make all notebook content — session history, extracted facts, topic archives — retrievable on every AEGIS dispatch with zero added latency.
Alternative considered
Hardcoding specific notebook IDs in recall and firing parallel per-notebook searches. Rejected: IDs change across environments, and N parallel subrequests on the hot path is worse than one workspace search.
Problem
The v2 API only exposes notebook-scoped search (
POST /api/v2/workspaces/{workspaceId}/notebooks/{notebookId}/search). There is no way to search across all notebooks in a workspace in a single request.Why it matters
AEGIS uses MindSpring in its recall pipeline during every dispatch —
recall.tsfires a semantic query in parallel with the Memory Worker to inject relevant context before generating a response. Currently this only hits the legacy global search endpoint (GET /api/search), which covers the original conversation archive.We've now built a write pipeline that pushes extracted facts to per-topic notebooks (e.g.
aegis,infrastructure,project) and session transcripts to asession_historynotebook. These are dark at query time — ingested but never retrievable — because querying them would require:That's too expensive per-dispatch (adds N subrequests + latency on the hot path).
Proposed endpoint
Body: same shape as notebook search —
{ query, limit?, threshold? }Response: results with a
notebook_id+notebook_titlefield on each hit so callers can attribute the source.This would be a one-line change in
recall.ts:And would make all notebook content — session history, extracted facts, topic archives — retrievable on every AEGIS dispatch with zero added latency.
Alternative considered
Hardcoding specific notebook IDs in recall and firing parallel per-notebook searches. Rejected: IDs change across environments, and N parallel subrequests on the hot path is worse than one workspace search.