memory_lookup
Retrieve past engineering incidents, ownership, and patterns by memory type or anchor path to inform edits on security-sensitive or buggy files.
Instructions
Retrieve engineering-memory entries for one or more memory types, optionally narrowed to specific anchor paths. Use before editing a security-sensitive or historically buggy file to surface prior incidents, ownership, and patterns tied to it. WORKFLOW: call with detail:"index" FIRST — each row carries id, title and tokens_estimate (the cost of fetching it) — then fetch full bodies via memory_get ONLY for the ids you will actually use, batching multiple ids into one call. Reads agents/memory/<type>/*.yml plus the agents/memory/intake/*.jsonl signal log. Read-only. Returns the v1 retrieval envelope: a status field plus per-type slices carrying the matched entries.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| keys | No | Optional anchor paths or globs to match entries against (e.g. a file you are about to edit). | |
| limit | No | Maximum entries to return per type. Defaults to 5. | |
| types | Yes | Memory types to scan, e.g. `historical-patterns`, `incident-learnings`, `ownership`. At least one required. | |
| detail | No | 'index' returns compact priced rows (id, title, tokens_estimate) instead of full bodies — call this first, then memory_get the ids you need. 'full' (default) returns complete entries. | full |
| token_budget | No | Optional token budget. When set, entries are rendered as one-line compact rows (id, type, confidence, `line`) and the row set is hard-cut at token_budget × 4 chars; omitted hits appear as a top-level `truncation` hint naming a concrete next step. Absent → the envelope is unchanged. |