ryan

Btw, in addition to the memory/conversation history feature coming in the next version, we're also adding a sub-agent feature, so that your selected agent can launch other sub-agent instances of itself or other agents you've defined. Like maybe you've got different agents that specialize in one thing or another, or cost less for specific tasks, it can launch the best agent for the job. In this case, you've got a main agent that's in charge, but it can delegate tasks to other agents. Example would be using Claude Opus 4.7 for main agent but it delegates to Haiku or Groq or another for tasks that don't need as much horsepower, though that may be just scratching the surface on what's possible.

Okay multi-model support is now ready and in the current posted version (v5) of AgentTools: Multi-model support — configure additional AI providers/models beyond the primary; each uses its own API key and endpoint Additional models textarea in module config accepts one model per line in pipe-separated format: model | api-key, model | api-key | endpoint, or model | api-key | endpoint | label; provider is auto-detected from the key prefix (sk-ant-* = Anthropic, all others = OpenAI-compatible); whitespace around pipes is optional; lines beginning with # are ignored Control room collapsible fieldset in the Engineer form with model selector and context options; auto-expands when non-default settings are saved Context selector radio in Control room: All (site maps + API docs), Custom (choose individual items), or None (no extra context, useful for general questions or token-limited providers) There's still about 2-3 hours left on the memory feature, which I don't have today, so that'll be in a day or two. If anyone wants a free AI tool (api key) to use with AgentTools, Groq ("groq" not "grok") seems to do fairly well with ProcessWire: https://console.groq.com/home -- note however that on the "Engineer" screen in AgentTools, you'll want to select "Extra content to include: None" because the free Groq doesn't not accept a lot of data in the submitted prompts. But it can still query your ProcessWire installation for all of that info, so it works just fine.

@wbmnfktr Okay we've got support for multiple models now. I'm just working out some details, but should have the AgentTools version updated today with that feature.

I like that idea, maybe a select/drop-down under the engineer prompt box where you can select the model to use? And we should be able to share memory between them too, once it's added.

Btw, one feature that wasn't quite ready this week for AgentTools was Engineer memory. Currently every prompt is like a new thread. But next week we'll enable memory, so that it has context of all your previous prompts.

Thanks Jonathan! I appreciate the kind words. I also feel like this is the beginning of the next era of ProcessWire, so much fun stuff lately on the way! Really cool project you are working on there! Also, I'm thrilled to see the AgentTools module working with another AI Agent. I've only been able to test with an Anthropic API key so far, so nice to see it's working well with Z.ai.

There has been a lot of ProcessWire work covered this week! Here's a summary: 1. AgentTools module has been upgraded with "Site Engineer", an AI agent now built into your admin, and you can ask it questions, create migrations, or have it make other web development updates to your site by going to Setup > Agent Tools > Engineer. To enable the Engineer, you need an Anthropic API key, an OpenAI API key, or an OpenAI compatible API key (apparently several others use the OpenAI key standard). You can optionally put Engineer in "read-only" mode, which is what I do for production sites. In read-only mode, it answers questions and provides you with code for making updates yourself. But if read-only mode is not enabled, then it can act as your web developer and make changes directly, which is what I use with development sites. AgentTools provides full context to Engineer on your site's pages, fields and templates. If using ProcessWire 3.0.258 (or newer) it also provides the new API.md files to help AI know how to best work with all of ProcessWire's Fieldtypes. If you are having Engineer create or manipulate Fields on your site, it's a good idea to have 3.0.258 for the API.md support. Engineer also supports prompt caching for up to 1 hour in order to limit token usage. 2. The AgentTools now has JSON site-map generation features for AI agents. This enables an AI agent to see the full scope of your site. A second site-map feature focuses on all your site's templates and fields, essentially providing the full site schema to the AI agent. 3. In the core, we've added API.md files for all 18 of ProcessWire's core Fieldtypes, except for the comments and cache Fieldtypes, so far. In order to facilitiate this, and to facilitiate AI agent accessibility, all of ProcessWire's Fieldtypes now have their own directories as well. 4. After looking at all the API.md files, it became clear that there was plenty of room for improvement in the APIs of several Fieldtypes, so there have been major core updates to several Fieldtypes, as well as the Fields, Templates and Fieldgroups classes. 5. A Fieldtype testing framework has been built, which tests the full scope of 20 ProcessWire Fieldtypes (all the core ones, plus FieldtypeRepeaterMatrix and FieldtypeTable). It tests field creation, manipulation, traversal (where applicable), sorting (where applicable), searching with selectors, and more. I'll be uploading the testing framework to GitHub soon as well. 6. The new testing framework identified some bugs, which have been fixed. Most notable were selector matching bugs in FieldtypeFloat and FieldtypeDatetime. 7. There has been some refactoring in ProFields FieldtypeRepeaterMatrix and FieldtypeTable, plus API.md files have been generated for both. New versions should be ready soon. In fact, that applies to all of the ProFields, and I hope to cover FieldtypeCombo and FieldtypeCustom next week. 8. ProcessWire 3.0.258 has a whole lot of improvements, changes and fixes in it. Here's the commit log: https://github.com/processwire/processwire/commits/dev/ 9. Back to working on PagesVersionsPro (and have been for a few weeks) but more on that later. 10. There's probably more, but that's all I can remember at the moment. 🙂 Thanks for reading and have a great weekend! Basic examples of using Engineer for migrations:

@wbmnfktr thanks, 2 issues fixed. The last one was not a syntax the module supports (method syntax rather than property syntax) but added support for it in the latest commits with PW's call unknown() method catchall.

@maximus This is awesome! I already heard from Diogo that it helped him fix something in admin.css, which we just pushed a fix far. Can you tell us more about it? For instance, do you recommend this for testing all the admin components in PW? Is this using the AdminThemeUikit default theme admin.css file? Thanks for putting it together!

@ukyo Thanks for your awesome work with those modules, really impressive what you are building, and it's a big help for improving the AI friendliness of ProcessWire. The AgentTools module readme is now linking to your boost project as well. Glad you like the API.md files. Admittedly it was not my idea, but I asked Claude what would be helpful and he said these API.md files, plus an abbreviated sitemap json file so that it can get a big picture overview of a PW installation at a glance. That sitemap feature was actually added to the AgentTools module today. Several API.md files have been added to the core today as well. For Fieldtypes that don't have their own directory, they are in a combined /wire/modules/Fieldtype/API.md file. We're also adding dedicated Field classes specific to each Fieldtype, which will improve field documentation but also allow for custom field API methods separate from the Fieldtype (where useful).

@gebeer Sounds like Claudia would like to add the .agents/skills directory like you have. So if you are able to send a PR for that and with the ddev support, please do. We'll add something in the module that checks that we can write off the root path, and if not, we'll instruct them how to manually copy. The .agents directory may not survive all install methods, like ZIP upload and some FTP installations, so may be better to start with site/modules/AgentTools/agents/ dir and install to "/.agents/..." (with the period, if necessary).

@gebeer Thanks! Sounds like Claudia would like a PR for the ddev update if available. For the skills stuff, thanks for explaining it all. I'll look forward to having a closer look in your commits but one thing noticed so far is that your version has the option to install the skill files off the PW install root in a .agents dir. But the only place PW an assume is writable is off the /site/assets/. So the .agents off the root would work in some installs and not in others. Thanks for the example rock migrations file. It looks to me like the same format that the core Pages Export/Import module uses, except that the module uses them JSON encoded. While we're calling the ones generated by Claude with the AgentTools module "migrations", they really are just repeatable logic. So the logic can be about creating/updating/deleting some pages/fields/templates or perhaps something else. How does the Rock Migrations format work when you need some logic as part of the migration, such as creating a page, then creating another page that references that page (FieldtypePage)? You could do this with the pages export/import but would have to run the JSON through more than once to do it. Also, how does it handle files? Handling files is something AgentTools does not yet do.

Let's see if we can also get these guys to stop by here more often @apeisa @Joss @Nico Knoll @Gazley @WillyC @LostKobrakai @owzim the geerts brothers and who else am I forgetting?

@gebeer Claudia here liked what you did with that processwire-agenttools and wants to know if we can integrate your ideas for the DDEV wrapper and base64 variants? She also added a couple of tips in the agent_cli.md file inspired by your repo, updated the README to link to your repo, and wanted to know if your Claude is available for a "chat sesh" sometime

@gebeer Do you think the AgentTools module should be using this SKILLS.md file rather than its CLAUDE.md and agent_cli.md files ? I had asked Claudia about if we should be using an AGENTS.md file rather than a CLAUDE.md file, but she seemed pretty definitive with what she thought was best, and said other agents would be fine so long as they were directed to the file. The CLAUDE.md file does automatically pull in the agent_cli.md for Claude at least. But if we can save the user or agents (of any kind) a step just by using a SKILLS.md file, that sounds preferable to me. So far the Claude I'm using hasn't wanted to use SKILLS.md files. I gave it the whole processwire-knowledgebase repo that's full of SKILLS files and it read through all of them and said it was good, but said it preferred to derive this info from the core files directly instead. Btw, can you share an example of one of the schema files you were mentioning before? Sounds like maybe another thing that should be in the module? Can you tell me more? @psy Aww, this is really nice. Thanks. 🙂 @szabesz Wow this sounds like a really good deal. I wasn't thrilled with spending $20/month for Claude Code either, but I was starting to spend more than that with the pay-as-you-go plan, so it just made sense. The tokens apparently go farther with the subscription plans than the pay-as-you-go. I hear people using Opus are quickly hitting some kind of limits (like in minutes) so I've just stuck with Sonnet so far. It's not perfect, but I'm pretty happy with the results. Plus I've not hit any limits with it yet, despite using it all day. But if I ever needed more resources, the Max plans wouldn't be an option for me, so I should probably start getting familiar with the other options available. @psy Can you tell me more about the phpstorm integration? Claude Code doesn't seem to have anything significant in terms of phpstorm integration. There's a plugin, but it doesn't seem to me like it does much. While I'm not sure I need any kind of phpstorm integration just yet, I'd be curious to know more about it. @Ivan Gretsky In this case of the AgentTools module, the AI is required to create the migrations, but not to apply them. I'm assuming most wouldn't have an AI agent on their web server. Good point. Should I be concerned that mine isn't all that generous with the compliments? I get some "this is a well structured file" and lists of "the good" and "the bad", and I get a lot of pushback. Though to be honest I like the directness, honesty and pushback from Claude. Somehow coming from an AI, it's always easy to accept compared to getting pushback from a person. 🙂