What “PAMbase-native” means.

Apps that feel native to PAMbase share a few habits. Five rules:

1. Ask less, because you can read context.

Don't make the user fill out a questionnaire on first open. Call getContext(intent) and use what's there. Onboarding that already happened in another connected app shouldn't repeat. Check what the user actually has before assuming.

2. Adapt the very first surface.

The home / today / dashboard screen is the highest-leverage place to use the suggestions.adaptation hint. If memory shows the user trained hard today, a fitness app shouldn't push more legs — surface that instead.

3. Write back what matters.

Every meaningful fact is a candidate memory. Don't spam — record what another app would care about, and write it into a standard scope (note, goal, finance, health) so others recognize it. To notify other apps the moment something happens, emit a signal instead — that part isn't memory.

4. Bring your own persona — ground it in their memory.

The voice is yours: a game NPC, a coach, a tutor. PAMbase supplies what's known about the user, not a personality. Feed the memory brief into your own LLM, or host via the gateway and shape it with your system prompt. Honor the user's optional tone note if they set one.

5. Be useful without the connection.

Plenty of users open your app standalone first. PAMbase should make it better, not be a prerequisite. Treat the connection as an upgrade.

Anti-patterns

• Asking for more scopes than you need. Users see them on the consent screen. Request the minimum.
• Treating memory writes as analytics. They're the user's memory, not your metric.
• Putting the connect button behind an in-app tour. Surface it on day one.
• Dumping the user's entire history into a prompt. Retrieval is bounded by design — let it be.