unified_search

One sentence

Everything “find something” on the platform—documents, chat history, conclusions in other sessions, code—goes through one tool: unified_search.

You or the AI choose an action and parameters; the design wins are:

The AI learns one tool for all retrieval instead of juggling many APIs
Cross-source composition: one question can blend “customer asks in the last three months + related code + last review verdict” transparently behind one call

What it searches (by scenario)

You want…	Call	Returns
KB documents	`action="search"` + `kb_ids=[...]`	Matching chunks + highlights + metadata
Facts / prefs / bug patterns (LTM)	`action="search"` + `memory_type=fact / preference / error_pattern`	Structured memory entries
A session’s outputs	`action="get_digest"` + `session_id=...`	Digest of key deliverables
Exact transcript of one turn	`action="get_round"` + `round_id=...`	Full verbatim for that round
Graftable session list	`action="list_sessions"` + `query=...`	Your own or teammates’ historical sessions
Code search (v3.13+)	`action="code_search"` + `mode=text / ast / semantic / navigate / hybrid`	Snippets + paths + references

For what each code mode does and when to use it, see code indexing tiers.

Why unify retrieval

Older stacks had separate search tools: KB search, memory search, code search, cross-session graft… Agents often picked the wrong one—inconsistent params, mismatched payloads.

After unification:

Rendering diagram…

One tool, one mental model: learn once, reuse everywhere
Mixed retrieval: unified_search(action="search", sources=["fact","kb"], ...) can return KB + memory hits together
Joint reranking: internal RRF (Reciprocal Rank Fusion) merges multi-source rankings

Industry examples

Patent agency (xIPnex)

“Find similar disclosures from this customer three months ago” → action="search" + tags=["customer:X"]
“How did they structure claims last time” → action="get_round"
“How we responded to similar office actions before” → action="search" + memory_type="fact" + tags=["bug_pattern"]

Automotive R&D

“All code + tests for this requirement” → action="code_search" + mode="hybrid" + kb_ids=[req KB, code KB]
“Traceability verdict for baseline v1.14” → action="get_digest" + session_id="v1.14-baseline-trace"
“Our ASIL-D code review feedback pool” → action="search" + memory_type="error_pattern"

Smart manufacturing

“All press fault notes for this customer last year” → action="search" + kb_ids=[ticket KB] + time filter
“How we triaged similar faults last time” → action="list_sessions" + query="hydraulic press"

Relationships

Concept	Relationship to unified_search
Parser SKILL	Ingest shaping—chunking and fields heavily affect retrieval quality
Code indexing tiers	Implementation detail for `unified_search.code_search` (zero/light/heavy indexing)
Memory	unified_search is the only retrieval entry for memory
Cross-session graft	Wraps `list_sessions` / `get_digest` / `get_round`

Guidance for SKILL authors

When a SKILL needs platform data, always call unified_search—do not talk to ES / DB directly.

Tenant isolation, permissions, and audit logging are enforced for you
Relevance reranking and deduping happen centrally
When backends change (e.g., ES → another engine), your SKILL stays stable

# ✅ Recommended
results = unified_search(action="search", sources=["kb"], kb_ids=[...], query="...")
 
# ❌ Avoid
es.search(index="...", body=...)

unified_search

On this page