This post seems to run somewhat counter to Anthropic's message that Claude Code (or a harness like it) together with skills is a path toward a generally-applicable agent for many tasks (something I believe is correct). I don't know if I hav a thought behind that, but I find that interesting.

Is plan + incremental work completing with "commitable" units + version control for work product generalizable? The post identifies this as an area of exploration. It feels like this can be stated in a more abstract manner that is widely applicable.

Some thoughts.

1. I'm not sure this requires a separate "initialization agent," vs instructions for how to plan, and instructions for how to perform development.

2. This feels like a universal problem for a harness/orchestrator working on a task of meaningful complexity for any domain.

To solve this, they encouraged the agent to do incremental work, commit it, and update the requirement status. This leaves the project in a clean state where a model with a fresh window can pick up a new requirement and the codebase and continue on.

The problem they saw is the model wanted to one-shot tasks, leading to poor and incomplete work. They created a first step of drafting a detailed set of requirements to work against; this led to window overflow which compaction didn't solve.

What’s especially unfortunate is we need to keep pulling more of the industry here, but there just isn’t a critical mass (or even near one) that would justify most folks only being here. Contributes to Twitter’s perpetual motion machine.

Thanks! This is the same realization I’ve had over the last 1-2 months too, starting with realizing that agents (with the right combo of prompt and tools, like memory and filesystem) are generalizable (i.e. “deep agents,” but bad term). And then agent skills was like a bolt of lightning

Those spirits can be given identities which are persistent. Under the hood, there is no “agent,” just an orchestrator, but you can operate with the fiction of them being a tangible persistent thing

(Thinking out loud), where I’m ending up is an agent ecosystem (say, within an enterprise) benefits from an “orchestrator” primitive, whereas with 1:1 spirit:body pairing wasn’t req’d. Orchestrator executes a spirit, whatever complexity it has (ranging in analogy from single agent to multi-agent).

In that sense, the “body” is infinitely copyable, and is more an actuator in an env for the spirit. But we still need the spirit+body to reason about what are the actors within an environment (I think). But it feels weird given that separation of spirit and body to recreate “agent” for that purpose

imo this distinction is relatively new and really important. “Agent” before was usually a singular combo of what you refer to as the spirit and body; now the spirit is separately definable and loadable. I am still struggling tbh with what is the primary unit to reason about, spirit or body

They hit on this in a post a few weeks ago: www.anthropic.com/engineering/... Skills really does feel like a durable phase change on top of model+tools

Yeah, that’s what’s captured my thoughts for the last few weeks. I’ve been experimenting with having Claude write skills for various things using primary source documents and it’s done a quite good job. A model doing that to formalize a task path seems very doable, and yeah, it is continual learning

Any new takeaways from this talk re skills? I’ve been pretty fascinated with their concept of “tool” being a script the model retrieves (rather than a function call) and runs in a sandbox, with the model able to also formalize paths it takes to solve tasks as skills in its sandbox

That makes sense. Knowledgebase/sources might be relevant to some fiction writing as well (to ground it, or even to create a knowledgebase for the fictional world to maintain consistency beyond context window horizon). Maybe. This would be a fun thing to play with with Claude

Kind of curious how much overlap there ends up being in process for writing of different types. Fiction, nonfiction, technical analysis, memos, etc. There’s probably a good agent skills angle to generalizing it

The library means we can add stuff over time to it and control what goes in our meal plans, while the meal plan list also creates a history of what we’ve cooked, so each week’s meal plan has variety. Quite useful, if boring.

For example, I use Reminders for a Grocery list. I have a weekly meal plan list, and is the basis for updating the grocery list. I also created a Recipe Library list. Using these, each week, and I can have Claude create a meal plan using the library and update the grocery list.