Hide agent profiles for this release (backend exists but is gated off) and
sync the guide, api-reference, openapi, and llms.txt to the User Profiles
feature head.
Agent removal:
- Drop "users and agents" framing, the entity_type="agent" get_profile
example, and the "profiles for agents" FAQ from the guide.
- Reduce entity_type to user-only in the read path/param/response and the
jobs request body in openapi.json; drop "or agent" from the api-ref and
llms.txt descriptions.
Code sync (verified against the feature head):
- Read example + prose now include generation_count alongside profile,
status, entity_type, entity_id, updated_at.
- Sample flow corrected: sample_profiles returns a job; poll get_profile_job
and read each result's entity, instead of iterating a non-existent
results field on the create response.
- Bulk regenerate is gated off for v1 (FULL_REBUILD_ENABLED=False): remove
it from the guide, openapi operation enum, and the 501 note; keep only
sample and trigger. Idempotency-Key marked required to match the backend.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Adds the profile surface to both SDKs and documents it.
Python (MemoryClient + AsyncMemoryClient) and TypeScript gain:
get/generate profile, get/update settings, sample, regenerate.
A profile's keys come from the customer's own JSON Schema, so the TS
client keeps `profile` opaque and passes `schema` through untouched in
both directions. Camel-casing them would return field names that do not
match the schema the customer wrote.
Reads use the v2 envelope, where a known entity with no profile yet is a
200 carrying a status rather than a 404, so an empty state is
distinguishable from an error.
Verified against a live environment running this API: settings
round-trip, a partial update leaves the schema intact, generation
produces a profile under the configured schema, and sample, regenerate,
cooldown and the 400/404 paths all answer as documented.
