[_andrei_]

> 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?

[AndyNemmity]

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.

[dSebastien]

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

[_andrei_]

> 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