← All Letters
Letter VI

What You Control, What You Don't

Omnia, Lucili, aliena sunt — The Val d'Aran Letter
By Enzo Duit · Epistulae Morales, I

"Omnia, Lucili, aliena sunt, tempus tantum nostrum est."

— Seneca, Epistulae Morales, I — Everything, Lucilius, belongs to others; time alone is ours.

In July 2026 I will run 110 kilometers through the Pyrenees at Val d'Aran. The weather is not in my control. The technical difficulty of the terrain is not in my control. The state of my legs at kilometer 70 is only partly in my control — it will be shaped by training, but training does not guarantee anything. The result of the race, ultimately, is not in my control.

What is in my control: the quality of the preparation. The precision of the training plan. The decisions I make about rest, nutrition, load management, and race-day pacing. The specification, not the output.

This is the Stoic insight that Marcus Aurelius returns to in almost every entry of his private journal, that Epictetus built his entire teaching around, that Seneca wrote into nearly every letter: the disciplined separation of what is ours to control from what is not. Not as fatalism — the Stoics were not passive. As clarity. You give your full attention and effort to the things that are genuinely within your sphere of influence, and you release anxiety about the things that are not.

"Id agere strenue cuius non interest utrum efficiatur necne: hoc est, in his quae ex nostro arbitrio sunt totam industriam collocare."

— Seneca, Epistulae Morales, XCII — Strive actively for what does not depend on whether it succeeds: that is, place all your effort in those things that are within our judgment.

The Output-First Architecture is Stoic philosophy applied to AI deployment. It sounds like a technical framework — it has a name, it has steps, it produces artifacts. But its underlying logic is Stoic: define what you are trying to produce (the output), concentrate your attention on the quality of the specification (what is in your control), and release attachment to whether the model produces it perfectly on the first run (what is not in your control).

This matters because the failure mode I see in almost every founder deploying AI agents is Stoic in nature, not technical. They deploy an agent and it produces something unexpected. They react to the unexpected output as though the agent has failed them — as though the output is the measure of the system. They feel betrayed. They give up, or they blame the model, or they declare the technology not ready.

The correct response is Stoic: you specified an input into a system you do not fully control. The output is information. What does it tell you about the quality of your specification? Where exactly did the specification fail to anticipate what the model would need? Fix that. Deploy again. You are iterating on what you control — the specification — based on what you cannot control — the output.

This is also training for Val d'Aran. Every long run in preparation tells me something about the quality of my training plan — about where the load was too high, where the recovery was insufficient, where I underestimated a particular kind of terrain. The run itself is information. I adjust the plan. I do not conclude that running is broken because my legs were tired at kilometer 35 of a 40-kilometer training run.

The parallel extends further. At Val d'Aran, there will be a moment — probably somewhere between kilometer 60 and kilometer 80 — where the situation is worse than I planned for. The weather changes, or I am slower than expected, or something else goes wrong. At that moment, I will do what I did at kilometer 65 in Ushuaia: assess the specific situation, adjust what I control, and continue.

In production AI deployment, that moment comes too. The agent is in a live environment and something fails that was not in any test. The specification is imperfect in a way that only real conditions reveal. At that moment you do the same thing: assess what specifically went wrong, adjust the specification, redeploy.

Neither the race nor the deployment is guaranteed to succeed. That is not the point. The point is that your domain — the specification, the training, the preparation, the adjustment — is the only domain you actually inhabit. Work there with full attention. Accept what happens in the domain you do not control without confusing it for a judgment on your worth.

"Omnia, Lucili, aliena sunt." Everything belongs to others. What is yours is the quality of what you bring to what you can control. Bring everything there. Release the rest.

That is the whole practice. Running and building and everything else.