The `slugify` function within an AI agent's long-term memory runtime, specifically its failure to handle non-ASCII input, leading to file naming collisions and data loss.

# slugify returns empty string for non-ASCII-only input, producing a nameless file

**Severity:** High
**File:** `packages/core/src/agent_memory/core/slug.py:14`

`slugify` strips all non-ASCII characters via `encode("ascii", "ignore")`, then removes
everything that is not `[a-z0-9-]`. For input that is entirely non-ASCII (CJK text,
Arabic, Cyrillic), the result is an empty string. `Store._write_one` uses
`slugify(abstract, ...)` as the name fallback when no explicit `name` is provided, so
a non-ASCII abstract produces a file named `.md` at the domain root.

```python
def slugify(text: str, max_length: int) -> str:
folded = unicodedata.normalize("NFKD", text).encode("ascii", "ignore").decode("ascii")
...
return cleaned[:max_length].strip("-") # can be ""
```

### Why it matters
A memory recorded with a non-ASCII abstract and no explicit name collides with every
other such memory — they all resolve to the same `.md` path and silently overwrite
each other. The `is_valid_slug` regex requires at least one `[a-z0-9]` character, so
validation would catch this, but `_write_one` calls `slugify` before `validate`, and
the empty name only fails at the validation step with a confusing "must be a
kebab-case slug" error instead of a clear "abstract is entirely non-ASCII" message.