Skip to main content

In plain terms

The User Profile is a tidy profile card for each person: name, role, company, timezone, language — plus any custom fields you define. One value per field, like a CRM contact record.
The analogy: the contact card in your phone. Structured slots (name, number, company), not free-form notes.
It complements User Facts: Profile is the form with known fields; Facts are the free-form notes for everything you can’t predict.

When to use it

  • You have a fixed set of attributes you always want to know: name, role, timezone, plan tier, department.
  • You want clean structured values you can render in a UI or use in logic (for example, display profile.custom.department after validating its type).
  • Timezone-aware behavior — the agent can schedule or phrase things in the user’s local time.

When NOT to use it

  • For open-ended preferences (“likes dark mode,” “into sci-fi”) — those are unpredictable, so use User Facts instead.
  • For transient data — see the same guidance as User Facts.

Configuration

The built-in fields are name, preferredName, role, company, location, timezone, and language. customFields adds your own:
customFields guides extraction; it is not a strict authorization or runtime-validation boundary. The profile tool accepts a custom record. Validate values before rendering or using them, and obtain subscription entitlements from your authoritative account system rather than a model-extracted profile.

What gets stored

A single structured object per user:
This is injected into the system prompt as a clean block:

Direct access

Cross-references