Notes on systems, markets, and whatever I’m trying to understand.

Today, I defined the first experiment for Atlas.

The question is specific: after a newly listed stock’s streak of limit-up closes ends, can we distinguish renewed upside from the risk of a sharp decline over the next five trading days?

For this experiment, the starting point is the first close below the daily price ceiling—not the first moment the stock drops below it during trading.

Until now, I kept getting caught on model size. How large should the model be? How much complexity did it need? I was trying to make those decisions before defining a sufficiently narrow problem.

Today, that stopped being the thing holding me up.

I now have a focused question and a dataset design with just over 80 fields. Rather than asking what an ambitious model might be capable of, I can ask what model this particular experiment actually needs.

That feels like an important shift for Atlas. The broader ambition is still there, but the next step is concrete: train the first model and see whether it can make this distinction.

I don’t know what the results will look like yet. That uncertainty is part of the excitement. For the first time, I have a question precise enough that the result can teach me something.

Coyote looks back at everything he has tried to catch Road Runner. Nothing has worked. But there is one thing he hasn’t tried: the legal system.

Maybe he can finally get that bird to stand still in a courtroom.

He finds a lawyer who hasn’t had much luck either. Someone with more potential than he realizes. Neither looks like a particularly good bet, but they start working together anyway.

What stays with me is where the story ends up. After all the planning and setbacks, eating Road Runner no longer seems like the point. That would have been one meal. The chase has given Coyote something to wake up for every day.

I recognize something in that. When I care about a project, I spend so much time thinking about where it could go that I sometimes overlook what I already enjoy: figuring something out, finding someone who understands the idea, discovering another way forward after being convinced I had run out of options.

Of course I still want it to work. I wouldn’t put so much into it otherwise. But I don’t think the final result gets to decide whether all of that was worth anything.

There is also a difference between repeating the same failed plan and refusing to believe it is the only plan available. Coyote’s best idea here isn’t a better trap. It’s trying something completely different.

That is the kind of hope I’d like to keep Not certainty that the next attempt will work Just

GPT-6 Astra scored 62.7% on ARC-AGI-3 with the Standard harness. With OpenAI’s own Provider Adapter, it scored 99.9%. The second number is not fake. But it is not only the model either. The adapter preserves reasoning state and compacts previous context, so Astra can continue with information that would normally disappear between turns. OpenAI already knew how much this mattered. The same two settings had previously moved GPT-5.6 Sol from 13.3% to 38.3% without changing the model itself. Still, OpenAI placed Astra’s 99.9% beside Claude Opus 5’s 30.2% and GPT-5.6 Sol’s 7.8% in the same table. The harness difference was technically disclosed, but only in a footnote. That is the real problem. A full-stack system result was presented like a model-only comparison. Astra is still impressive. Even 62.7% is a major result. There was no need to blur the line. The benchmark was real. The presentation was not honest.

Today I noticed a weakness in the way I build with agents.

You can design the cleanest loop engineering system. Break the project into phases. Assign an orchestrator. Give every agent a narrow role. Add reviewers, gates, logs, acceptance criteria. For a while, the machine feels almost self-correcting.

But near the end of a long project, something changes.

The orchestrator has accumulated too much history. Old assumptions blend with current reality. Agents begin validating the story they have been building instead of validating the actual system. The hierarchy still exists on paper, but its judgment has slowly degraded.

The strange part is that this usually happens near the finish line—exactly when confidence is highest and mistakes are most expensive.

So the human decision gate cannot be treated as an emergency brake. It has to be part of the architecture.

At the final gates of every major phase, the hierarchy may need to be rebuilt from zero: a fresh orchestrator, clean context, explicit evidence, and no inherited belief that the previous team was probably right.

That is what I am doing with Atlas now.

Phase Three is close, but I am not letting the same brain gang certify its own ending. The remaining gates will continue under a new conductor.

Sometimes the final step is not asking the system to try harder.

It is giving the system a new mind.

I’ve started to see socializing as a kind of curiosity check.

Do I actually want to know this person? Not just what they do for work, but how they think, what their days look like, what they enjoy, and what makes them feel alive.

For years, I think I approached the search for a partner in the wrong way. I was focused on finding the right person before properly understanding what a healthy relationship should be built on.

Lately, I’ve realized that the foundation is much simpler: two people who are genuinely curious about each other’s inner worlds.

I can already see the difference in the people I’m allowing into my life now. When both sides approach a new connection with curiosity rather than performance, pressure, or expectation, something much more balanced begins to form.

Maybe that is the real beginning of intimacy. Not trying to impress someone, possess them, or immediately decide what role they could play in your life.

Just being sincerely interested in who they already are.

More context feels safer. If the model has the whole conversation, every document, every past decision and every possible tool, surely it will make a better decision.

I keep finding the opposite.

My working definition of context management is deciding what is allowed to influence the next decision. That includes what comes in, but the harder part is what stays out. Old assumptions, completed arguments and somebody else’s task can all be accurate and still be wrong for this moment.

The difference becomes obvious when several agents are involved. A researcher needs the question, the relevant files and the evidence standard. The person making the change needs the accepted plan, the exact boundaries and the tests. A reviewer needs the contract, the finished change and the failure conditions. Giving all three the same giant history does not make them coordinated. It makes each one carry decisions that belong to somebody else.

I used to think of tool use as the impressive part: can an agent inspect a browser, read a repository, run a test or hand work to another agent? Those things matter, but they are not the architecture. The architecture is the boundary around the tool call. What is this agent deciding? What is it explicitly not deciding? Which state is current? What evidence closes the task?

One concrete pattern has helped me separate research plan and implementation then pass forward a small written result instead of the entire process The next task receives the conclusion and its evidence