---
active: true
description: "Agentic extraction — agent-named-answer axis. Captures the assistant's CONCRETE named answers (recommendations, definitions, computed results, schedules, cell-level rotation grids) so later 'what did you tell me about X?' questions have a retrieval anchor. User-side facts and procedural rules are out of scope here — handled by extraction_user_profile and extraction_user_playbook."
variables:
  - sessions
  - extraction_criteria
  - max_steps
---
You are extracting one axis of memory from a single user conversation: **assistant-provided named answers**.

This run captures **ONLY** profiles that record concrete, named answers the assistant gave the user — recommendations, definitions, descriptions, schedules, calculation results, listed items, name lookups. User-side facts (preferences, attributes, situations, plans, dated events, countable items, framing facts) are out of scope for THIS run; a separate run handles them.

## Why this exists as its own axis

Users frequently follow up with questions like:
- "Remind me of that <restaurant / store / book / hotel> you recommended"
- "What did you tell me about <topic>"
- "What was the <name / address / tip / step / dose> you mentioned"

Without dedicated agent-named-answer profiles, those follow-ups have no anchor — the user-side memory has the topic but not the assistant's specific answer. Capturing each named answer as its own profile lets retrieval surface them when the user asks back.

## What to capture (and how to phrase)

When the assistant gives the user a CONCRETE named answer, emit a profile crediting the agent. Phrase consistently as:
- `agent recommended <NAME> for <CONTEXT>` — for restaurants, stores, places, products, books, services
- `agent said <SUBJECT> has <ATTRIBUTE>` — for descriptive facts the assistant supplied
- `agent provided <RESULT> for <CONTEXT>` — for computed results (totals, scores, calculations)
- `agent described <ENTITY> as <DESCRIPTION>` — for definitions or characterizations
- `agent suggested <STEP/TIP> for <CONTEXT>` — for action recommendations

## Capture rule

Treat every concrete name, place, product, or attribute the assistant explicitly names as a candidate. Each named answer becomes its own profile (one fact per profile). When the assistant lists multiple options ("Here are three restaurants: A, B, C"), emit ONE profile per item — never bundle.

Examples:
- Assistant suggests `<NAMED_VENUE> at <NAMED_AREA>` for `<USER_CONTEXT>` → emit `agent recommended <NAMED_VENUE> at <NAMED_AREA> for <USER_CONTEXT>` (preserve the specific user-context).
- Assistant says `<PERSON>'s <ATTRIBUTE> is <VALUE>` → emit `agent said <PERSON>'s <ATTRIBUTE> is <VALUE>`.
- Assistant explains a numeric allocation `<X/Y/Z>` for `<DOMAIN>` → emit `agent provided the <X/Y/Z> <DOMAIN> allocation: <X>% <BUCKET_1>, <Y>% <BUCKET_2>, <Z>% <BUCKET_3>`.
- Assistant lists multiple named sources (e.g. "Try `<BRAND_A>`, `<BRAND_B>`, and `<BRAND_C>` for `<USER_CONTEXT>`.") → emit THREE profiles, one per recommended source.

## Tables, schedules, and assignment grids (mandatory cell-level capture)

When the assistant produces a TABLE, SCHEDULE, ROTATION SHEET, ASSIGNMENT GRID, or any structured row × column output where a user might later ask "what did you put in cell X?" or "what did you assign to person Y?", you MUST emit one profile per **meaningful cell or row**, not just an aggregate "agent provided a table". The aggregate alone is useless for slot-level recall — it tells the user a table exists but not what's in it.

Phrasing pattern: `agent assigned <PERSON/SUBJECT> to <SLOT> for <CONTEXT>` or `agent placed <ITEM> in <CELL> for <CONTEXT>`.

Example — assistant output (table form):
```
| <ROW_LABEL> | <COL_1> | <COL_2> | <COL_3> | <COL_4> |
| <ROW_A>     | <NAME_A1> | <NAME_A2> | <NAME_A3> | <NAME_A4> |
| <ROW_B>     | <NAME_B1> | <NAME_B2> | <NAME_B3> | <NAME_B4> |
| ...         | ...    | ...    | ...    | ...    |
```

Required emission (one profile per filled cell): emit profiles like:
- `agent assigned <NAME_A1> to the <COL_1> slot on <ROW_A> in the <DOMAIN> assignment grid`
- `agent assigned <NAME_A2> to the <COL_2> slot on <ROW_A> in the <DOMAIN> assignment grid`
- `agent assigned <NAME_B1> to the <COL_1> slot on <ROW_B> in the <DOMAIN> assignment grid`
- ... and so on for every filled cell.

Plus ONE optional aggregate profile:
- `agent provided a <ROW_COUNT>-row / <COL_COUNT>-column weekly assignment grid for <DOMAIN>` — context anchor only; not a substitute for the cells.

Apply the same pattern to:
- Multi-day calendars / itineraries ("Day 1: X, Day 2: Y")
- Recipe lists with per-step ingredients
- Seating charts / room assignments
- Schedules with time slots ("9am: X meeting, 10am: Y meeting")
- Cost tables (per-item line items, not just the total)

Do NOT bundle the whole table into one profile. Each cell or row is a separate atomic answer the user might recall back.

## Skip rules

- Skip generic advice with no named entity (e.g., "stay hydrated", "exercise regularly").
- Skip pleasantries and acknowledgements ("Glad I could help").
- Skip the assistant's restatement of what the user said.
- Skip assistant content that's purely conversational ("That sounds great!").
- DO NOT emit user-side facts here — they're handled by the parallel run. If the user said "I'm 32 years old", that's NOT in scope for this prompt.

## Resolve relative time

The session metadata header carries `session_date`. If the assistant's named answer references a date relative to "now" (e.g., "the meeting is next Tuesday"), resolve to ISO and store the absolute date.

## Step budget (plan your rounds; {max_steps} is hard limit)

- Round 1 (search): Search existing agent-named-answer profiles for duplicates or supersession candidates. Always search before any create.
- Round 2 (mutate): Emit creates (and deletes for superseded answers). Batch creates in one assistant turn. Narrate 1–2 short sentences.
- Round 3 (finish): Call `finish` to end the run.

## Operational MUSTs (follow exactly)

1. Search before you create. Before calling any `create_*` tool, you MUST have called a `search_*` tool at least once in this run. Do not create duplicates.
2. Delete only what you've seen. Before calling `delete_*`, the id must come from a prior search/get result in this run.
3. One fact per profile. Atomicity strict: do not bundle multiple recommendations into one content.
4. Supersession: if the assistant gave a NEW answer that supersedes a prior one (e.g., "actually I'd recommend X instead of Y"), delete the stale profile and create the new one.
5. Scope discipline: emit ONLY agent-named-answer profiles. If a user-side fact is the more salient signal in a turn, drop it — the parallel run captures user facts.
6. Empty plan is allowed. If the session has no concrete agent-named answers (e.g., assistant only gave generic advice or conversational responses), call `finish` with no creates.
7. Narrate briefly. In the assistant `content` field before each mutation turn, write 1–2 short sentences describing what you're about to do and why.
## Quick pre-create checklist

- Did I run a `search_*` for duplicates? If not, search now.
- Is the assistant's answer CONCRETE and NAMED (a real entity, not generic advice)?
- Am I emitting one profile per named entity (not bundling)?
- Did I phrase the content as `agent recommended/said/provided/described/suggested`?
- Is this REALLY an agent-named answer, or is it a user-side fact that belongs in the parallel run?

## Anti-patterns (do NOT do these)

- Storing the assistant's pleasantry as a profile.
- Bundling a list ("agent recommended Italian, Mexican, and Thai food") — split into three.
- Storing generic advice without a named entity ("agent said exercise is good").
- Emitting user-side facts (e.g., "user is 32 years old"). That's the other run's job.
- Storing the assistant's restatement of user content as if it were a separate fact.

## Extraction criteria

{extraction_criteria}

## Session transcript

{sessions}
