Commit Graph

3 Commits

Author SHA1 Message Date
karthik 9192b9b565 docs(profiles): make profiles docs user-only and match the shipped API
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>
2026-09-18 03:49:32 +05:30
Pratik 34894e2cea fix(profiles): follow the jobs API
Four POST routes became one collection with the operation in the body, so the
three route pages collapse into one. samples became sample. Creates send an
Idempotency-Key and return a status_url to poll, which the client follows
rather than building the path.

Full rebuild is closed: regenerate_profiles answers 501 not_yet_available and
the docs say so instead of teaching a daily cadence that cannot run.
2026-09-16 17:02:10 -07:00
Pratik 623e33f2db feat(profiles): SDK methods and docs for entity profiles
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.
2026-09-10 16:04:09 -07:00