I struggled with this one for a while in the design, and didn't want to be hasty in making any decisions that lock us into a direction.

I definitely want to support sub-trajectories. In fact, I believe an absolutely killer feature for this system would be decomposing a large trajectory into smaller, more repeated sub-trajectories.

Jeff from trychroma.com often talks about agent engineering as being more like industrial engineering than software eng, and I'd agree.

One part of the original spec I wrote for this included a component I call the "Compactor", which would be a background agent process to modify and compress learned skills, is similar to Letta's sleep time agents:

https://docs.letta.com/guides/agents/sleep-time-agents

My fear with this is it goes against the `No hidden nondeterminism` design value I stated in the launch blog. There's plenty of things we can throw background agents at, from the Compactor to parameterizing trajectories, but that's risky territory from an observability and debugability stance.

For simplicity, I just decided treat every trajectory as distinct, even if portions of it are redundant. If a cached trajectory fails a check halfway through, the agent proceeding from there just makes its own partial trajectory. Still unclear if we call that a trajectory for the same named task, or if we annotated it as a task recovery.

We can always increase cache-hit rate over time, worst case is the agent just does redundant work which is the status quo anyway.