Main idea

A context engine breaks down into three functions and no more: something that reasons about information, rules that say how to work, a memory that survives the conversation. Written that way, porting to a consumer assistant stops being a rebuild. ChatGPT already reasons; the instructions of a ChatGPT Project already carry the rules; only the third function is missing, because an assistant conversation fades. Google Sheets supplies it.

The move therefore consists of inventorying the functions, recognizing the ones the platform already provides, and building only the rest. That is the opposite of the usual reflex, which is to port a system by reimplementing it function by function on the new foundation — and which fails less from technical difficulty than from pointless load.

Why it matters

It changes what you look at before deciding whether a system is portable. The question is no longer "can this platform do what my system does?", it is "which of my functions does this platform already provide, and what is left?". A port judged impossible on the first question often turns out modest on the second.

It also gives an upstream design criterion: a system broken down into named functions is portable, a system whose responsibilities are tangled is not, because you cannot tell what could be delegated to the foundation.

Nuances and limits

The breakdown into three parts belongs to a context engine; it does not generalize to every system. A system that needs to execute code, call APIs or maintain an execution environment has more than three, and the port stops there.

And a function provided by the platform is provided on the platform's own terms: Project instructions carry the rules, but with a size cap that was not in the original system. Delegating a piece means inheriting its constraints.

Open questions

• How do you recognize, before trying, that a function provided by the platform is provided faithfully enough that you can stop porting it yourself?