Using Obie
Section titled “Using Obie”Obie works best when your request includes the outcome you want rather than only the screen you are looking at.
Good requests
Section titled “Good requests”Examples:
- “Show me what I should review before following up with at-risk members.”
- “How do I add everyone who submitted this form to a mailing list?”
- “Explain what changed in this person’s engagement history.”
- “Where do I manage access for our finance team?”
- “Walk me through preparing a new service plan.”
Context matters
Section titled “Context matters”When Obie is opened from a specific module or record, that context can help it answer more precisely. You should still identify the intended outcome when there are several possible actions.
AI is not the source of truth
Section titled “AI is not the source of truth”For sensitive or consequential decisions, verify the underlying OKTO record. Obie can summarize and assist, but canonical data and documented product rules remain authoritative.
Respect user permissions
Section titled “Respect user permissions”Obie should not bypass role-based access, reveal hidden modules, or perform protected actions simply because a user asks in natural language.
Product evolution
Section titled “Product evolution”The legacy docs described Pulse as a collection of separate AI features and named a specific model provider. Obie documentation now focuses on the OKTO product behavior so the assistant can evolve without tying user guidance to one model or vendor.