Context engineering

The model is fixed. We don't train it, and most days we don't even change its settings. The only thing we control — and therefore the entire craft of building a good pal — is what the agent perceives on each turn. That's context engineering, and at pal.fun it's the product.

Generated vs stored

Everything that goes into a pal's context is one of two kinds, and keeping them separate avoids a whole category of bugs:

• Stored content is owned by the pal and the user, and it's written down per pal: SOUL, IDENTITY, USER, MEMORY. This is character and history — the stuff that should persist and drift over time.
• Generated content is owned by the platform and composed fresh on every load: the Charter, the operating manual, the live tool catalog. It's never frozen into a per-pal copy.

The reason is drift. If the platform's rules or tool list were copied into every pal at creation, then improving them later would mean migrating thousands of stale copies. By generating them at load time, every pal always runs the current version, and there's no migration debt. The rule of thumb: mechanics get generated; character gets stored.

The constitution sits on top

Context is assembled in a deliberate order, and at the very top — above even the pal's SOUL — sits the constitution: a visible Charter (how to be a good pal) and a hidden safety floor. Putting them first means they frame everything the pal reads after. (The constitution covers what's in each and why only one is public.)

Built to stay cheap and bounded

A persistent relationship can't grow its context forever — that would make every message slower and more expensive without end. So the assembly is disciplined:

• History is loaded as a bounded window of recent turns (a sort-by-newest, limit query — the cost scales with what we keep, not with how long the relationship has run).
• Aged-out turns don't vanish; they roll into memory on a schedule.
• The stable parts of the context are arranged so they can be cached between turns, and the volatile parts (live calendar state, the latest memory) are placed where they don't blow that cache away.

These aren't premature optimizations. On a per-message-billed product running a frontier model, context size and the number of round-trips are the two biggest cost levers, and we treat them as first-class. The honest version of "we care about cost" is a visible price in the product itself — a forcing function that dares the pal to be worth it.

Every hard bug is a context bug

The throughline: when a pal gets something wrong — forgets something, claims it did something it didn't, narrates instead of acting — the fix is almost never "prompt it harder." It's almost always "fix what the agent perceived." Get the context right and the behavior follows.