All vendors will have to implement test time code execution, solution exploration, etc. as it's a low hanging fruit with huge gains, so I see it as a great hire. Love Bun, happy for you guys!

Do you mean train time?

Hi Rob, thanks for your thoughts! We're not planning on expanding to watching expiring domains yet, we're focused more on finding domains that were never registered. But what you're interested in can be done by watching all the registered domains that you're interested in and either catching them when they expire (ex. https://www.expireddomains.net) or by registering a backorder (higher success rate but you have to pay, ex. https://www.gname.com/backorder)

Ah, thanks for that, very useful.

what are we gonna dooo?

pydantic is a _validation_ library, it does not do any kind of constraints by itself

im referring to pydanticai https://ai.pydantic.dev/

> we need to recognize that the felt necessity of sophisticated type systems is a signal that we’re using the wrong architectural foundations

I'd be forever ashamed if I wrote that.

this is coming to Claude Code

They have hinted at it?

> If you don't discuss hooks and subagents, i'm not sure what you're doing right now.

Agents have their own context and can be useful for tasks that can be parallelized, which is a minority of tasks. How are they critical to better performance for you?

This is the best question anyone has asked.

Let's consider context. At some level the more context you have is good. At some level, the more irrelevant context you have is bad.

Okay. We have at top level of context, a hook that forces a system prompt on every action.

Next level we have a ./claude/CLAUDE.md then we have the project level CLAUDE.md then we have a possible not required agent setup then we have the instructions you give it

We know that CLAUDE.md gets lost in the context, at any level. The system prompt level hooks don't.

Why does the CLAUDE.md get lost? Why are we losing ability with a longer context.

The problem is irrelevant context to the action. The Documentation agent doesn't require the Golang modernization rules. The Golang agent, doesn't require the planing coordinator rules.

So the question I asked myself last weekend was, what is the experience if you split the contexts to only the required information for the task.

I did head to head battles with agents, reading in the information, versus contextual specific information. The agents with context specific destroyed the competition. Like it was another world.

So then I ran head to head tests on the type of information. Etc etc. My current setup is the best level achieved in those tests.

So my argument is that removing the context that is entirely irrelevant for the agent improves performance dramatically.

But I'm one person doing tests... it's true for me. Maybe it's not true for others. People have to explore the conception and determine that.

I can only tell you what has worked best for me, and for me, it's like a model jump in performance improvements.

It's been my experience too, already prior to support for sub-tasks/agents.

I've been exploring the ways in which I could "lazy load" context depending on the task at hand. I've approached this by defining an AI "receptionist", a set of roles and a set of tasks.

The receptionist is the entrypoint of the system. It knows where to find roles/tasks but only loads very basic information about the roles.

Depending on the role I ask for, it then loads the right role file, which in turn loads additional context. Then I ask for whatever i want to do, and it loads specific task files based on what I asked. And the task files load additional context etc.

This works quite well because I end up with just the right context for the task at hand. And each role/task can actually be executed as a sub-task/agent

You stumbled on to the solution before the tools caught up to you. really cool.

> So my argument is that removing the context that is entirely irrelevant for the agent improves performance dramatically.

100% agree on building the optimal context, just have not seen parallel agents do better at sequential tasks. the documentation agent may have better initial context about how to write documentation, but it doesn't have the context of the changes, apart from what is passed to it / can explore. if we don't spawn a new session, and instead throw it a /document command - that would still get all the guidelines and rules for writing documentation, and it should have the same weight since it's at the bottom of the context.

for me the highest 'model jump level' performance booster is externalizing context and controlling the process - having claude initialize a plan file with a pre-defined template that makes it use that as its to do list and documentation place, and getting it to use that as its primary working area

I am doing that too. Perhaps I am misjudging which part is providing which benefit, but when using the plan system as well as the agent, the agents with this context setup perform much better.

It all builds on each other, so it can be slightly challenging to untangle which part is providing the majority of benefits.

ah, deep agents = agents with planning + agents as tools => so regular agents.

i hate how LangChain has always tried to make things that are simple seem very complicated, and all the unnecessary new terminology and concepts they've pushed, but whatever sells LangSmith.

I used to consult on this type of thing. I’m not entirely convinced this is what’s happening here but it’s close enough, and is a well trod playbook - dress up the mundane in theatre and performance, create a taxonomy that’s specific to you, then sell access to the thing.

Next step is to try flood the SEO zone with your thing. It’s great if you can piggyback other key terms (deep *, agents) and.. I’m already bored writing this up it’s so [what’s the word for sheer resigned exhaustion at the capitalist corporate soul kill that is this type of work]

This is on the cynical side, for sure.