I have used Unity and Blender MCPs and I am not sure I am seeing why this is not a needed concept (or is a bad implementation).

If Unity updates the version (and the MCP server with it) - my agents immediately see the new surface. They weren't trained on the features of the new version of Unity, but they know about them as soon as they are added.

Context bloat is a thing - but you only turn on the MCP servers for what you are actually working with. If I am only in Blender, I don't need the Unity MCP. So it can be disabled.

These are just two example pieces of software but the concept applies to all of them with MCPs.

When you call via the API and want it to roleplay as a pirate or fix broken YAML in the coding harness - it doesn't need to know about the sports scores lookup tool or the recipe creation tool.

There are different use cases for the same underlying model.

They also can't tell Opus it might be a Fable handoff when Fable didn't exist when Opus was created. They need to be able to change them.

I found this on Vimeo. Very interesting.

https://vimeo.com/127605643

> but you don't see "load bearing" nearly as often in prose written by people

Unfortunately, we're starting to now.

Thanks to Claude.

Yes but one of the key things about subagents is they keep all of their tool calls and exploration out of the parent context.

If you plan on continuing on in the parent, and aren't going to necessarily be touching the systems the other agents are exploring, it can be worth it.

It's useful in certain situations where the parent context may need the "10,000 foot" view of something without going back in there. But subsystem-specific AGENTS.md/CLAUDE.md files are still superior and accomplish the same thing. The problem with those is they can become stale.

It seems like there could be a useful strategy of writing a plan with a main agent, and then instead of spawning subagents to implement, fork the main context to write each part. Then use one last fork to verify the work. That way you keep reusing the same context without polluting your main context for when you are ready to continue.

I've started doing this by hand in OpenCode and it works pretty well. But there's no UI support for maintaining a tree of related session forks so there's a little bit of manual fussing involved with session naming to keep organized. I also like to end a session with an "AI-friendly terse but detailed summary" (or some equivalent prompt) that I can then dump out to a Markdown file and then the mainline session can still get info back from the branch session. I don't know how much of this is automatable with OpenCode plugins, or in another hackable harness like Pi.

They are just making the point that it makes sense that subagents would use more tokens because they have none of the parent's context.

Right, so it’s a trade off between contexts. There are two reasons to use subagents, parallelism and tailoring of context. For the second, there is the “personality” of the subagents as well as how much context is injected from the main agent. Ignoring the personality, you ideally want the injected context to be small and focused on a single task so the subagent doesn’t get distracted. You want the main agent to be orchestrating all the subagents, but not reading all the same files they are reading, otherwise you’ll be paying for the same tokens in multiple contexts. IMO, this is where prompt engineering comes in, to be able to guide the main agent as to where subagents are desired and where not.

That is true of Anthropic's implementation but not inherent in sub-agents in general.

For the sake of accuracy Claude Code has a "fork" feature which does what you'd expect and based on traces I skimmed this morning it seems under some circumstances you get fork behavior for subagents as well.

Yes - Anthropic badly needs this same "here's a reset, use it when you want".

It's vastly better this way. Sure, it may impact the bottom line but it's a huge customer satisfaction win.

When Anthropic randomly resets me and I've only used 2%, that's worthless. When OpenAI tells me I have 3 resets available to use whenever I want - it's wonderful.

Although they can technically do it, I wouldn't be asking LLMs to generate binary files like PNG with alpha channels, no matter how simple that may seem. If it's easy enough to manually create one yourself, I would do that.

The best way for LLMs to do this is likely to write a scratch program (which is what it seems to have reached for in the second half), write code (which they are good at) and have the library create the image.

At some point it is just easier to handle such things yourself, and use them with text-based formats.

This is an excellent and very interesting write-up.

It's so refreshing to read technical articles that are clearly written by a knowledgeable human and explained perfectly like this. By walking the reader through this with the example screenshots it unfolds and gets more interesting as you continue reading.

It's also strange to realize that these days, most articles are not like this.

heh, a friend actually pointed out a typo on a first draft and said "maybe you shouldn't fix it to show it's not LLM written".

Be careful with this sort of logic ("reflection=expensive").

Everything should obviously be measured.

I've worked with large .NET code bases that used attributes for things like plugins and it was completely negligible for overall performance in the grand scheme of things.

I always use a standard workflow and it has never been a problem.

- Define the task and the goal, write a short spec document (markdown is fine)

- Point the agent at it in plan mode and have it write the plan to disk with phases. Iterate on its plan if necessary here and now.

- Have each agent tackle a phase and have it update it as a living document (switch models if some phases are more difficult than others)

- Clear and repeat until done

I've never had to overcomplicate this and it's worked both on enterprise-scale projects and personal projects. I am not sure what I'm missing - if anything.

I think what you are doing is good, I also have a similar workflow, but the idea here is to automate some of your manual approval work with coded tests. Since they are easy to generate, have as many as possible, think hard about what to test for, and the agent will deviate less and be more autonomous.