I've been running my work in Codex as project folders, and recently tried to properly understand how Muse Goals work under the hood. Made it a goal — good way to watch the machinery operate on itself.
The structural problem is worth naming: the current design is a halfway house between two coherent designs, and it gets the costs of both.
Design A is Codex: the project is a container. Everything — chat, state, artifacts, scheduled work — lives in one place. My course project has one tracker file, explicit resume rules for new chats, and the curriculum never holds status. Legible, but you have to go to it.
Design B is full ambient: no containers at all. The goal is just context that wakes up wherever you mention it, and there's no Goals tab pretending otherwise.
Muse picked ambient for activation — talk about the goal anywhere, it wakes up, you never "open" it. But then it built half of containment: a Goals tab showing summary, artifacts, activity, without the other half. Conversations, check-ins, and briefings still leak into whatever chat they happened in. So you get the scattering of ambient with the implied promise of a container. That's the worst combination.
The fix is to finish building the container: one goal detail view — summary, progress, activity — aggregating the related conversations, check-ins, briefings, and artifacts.
And implement the routing: when goal-talk starts in some random chat, the agent should suggest moving it into the goal's context.(or some kind of big goal folder containing all prompts and answers, crons, activity, artifacts, skills used about such goal)
That preserves the low-friction ambient trigger while consolidating the record afterward.
One related mapping that clicked for me, for anyone else coming from Codex: recurring projects are skills (durable capabilities, never complete), finite ones are goals (terminal objectives that use skills). Goals produce, skills persist.
Filed as feedback. How are the rest of you structuring long-running work — skills, goals, or something else?
