The thing is, ages ago, I was told by the scripting evangelist at Adobe Systems that a certain process (adding sub, sub-sub, and sub-sub-sub entries) to an index entry was impossible --- problem was, my boss had already promised a script to do that to a client....

Turns out it is possible, one just has to have the script check to see if each level of a given index entry exists or no, then if it does not yet exist, create it before making the next lower level by adding that sub-entry to the one above it.

An LLM is only going to code what it has documented as possible/working and may not be able to do what needs to be done.

So that was our assumption too while building it, but I'm genuinely surprised by how well frontier models can work with large and 'lightly-documented' SDKs.

I think a big part of it comes from deliberately exposing lowest-level atomic actions; not higher-level wrappers with use-case specific documentation. Instead, we supply very technical/'dry' documentation (inputs, action/effects, return values and types). We leave it to the developer (or the LLM) to write scripts that assemble these pieces together to solve problems.

If you try it with Cowork and Opus 4.7 (recommended), you'll probably see it try a few different technical approaches and iterate; as it tries to accomplish this task. While that's less token efficient, the benefit is flexibility/power, and once you have a solid script, you can just save it and use it again and again without any token costs.