I’m one of the contributors to the AI Agent templates in the community.
I updated the instance to the latest version and noticed that the workflow tool node for agents has been changed - now you can’t specify input there.
This is really important and here is why:
The same sub-workflow could be used for several tools - it is very convenient not to duplicate dozens of workflows, simplify maintenance and follow the DRY rule.
You can’t specify JSON schema for input - it’s 100% important for developing stable agents. I can specify example JSON in sub-workflow trigger, but it’s not the same as JSON schema. JSON schema allows me to provide details about enum lists, optional variables and so on. It’s the basis for building stable and scalable AI agents.
In my opinion N8N should not cut basic features that let developers build complex things to replace them with simplified things - we are here and love this tool bcs it is low-code tool that is as simple as no-code tools and powerful as code tools - please don’t make another Zapier from N8N.
Many guides have been created based on previous functionality - new updates generate dozens of QAs and make it impossible to use old guides. It’s a big kick in the teeth for all creators.
As a solution I can offer you to keep both option - let people specify everything on tool side or use definition of sub-workflow if needed.
Here is an example of our approach to building agents - this way I can easily generate new tools with simple prompts to GPT and manage them all within one workflow.
thanks so much for your feedback and apologies that this change has not met your expectations. I’d love to go over each point from you:
You should still be able to use the same sub-workflow for multiple workflows. Since inputs are generally not mandatory, you could just define more inputs and only use the ones you need in your use case. That being said, we saw with many users that used their AI flows in production, that it was much better to define one tool with its expected inputs for one use case. This way it was easier to understand what the sub-workflow tool is doing and what it expects.
The schema example is taking the JSON schema from the example under the hood. It is true though, that we lose sophisticated things like enums, etc. That is something that we should probably bring back.
Very valid point. We probably underestimated the amount of videos that are out there with the old functionality and I fully understand that this is causing pain. I think it’s one of our strength that n8n moves very quickly. That might mean that some functionality goes stale pretty quickly sometimes unfortunately.
I hope you can understand some of my points. Would love to hear your thoughts on that.
I understand the reason for simplification and of course I can keep the old version of N8N or copy non-existing nodes from the old workflow.
A little context - I have already 5 years in no-code and used all tools like Zapier, Make and N8N. I have worked with 100+ customers and have some vision on the no-code market.
In my opinion, talking about product development and UX: main paid customers are enteprises and SMBs who build their complex workflows with developers and scale them (not b2c). These workflows need more flexibility - not less. People who build their own workflow will sooner or later run into complexity (and reach agencies like mine), so trying to simplify the process for them is a never-ending race.
So it’s really about positioning N8N in the market - whether it’s a Swiss knife for tech developers or a magic wand for non-tech people that turns text into automation.
It would be great if it could serve both audiences, but it’s complex to achieve.
I worked as a QA in Make, used it for 4 years and moved from there to N8N last year simply because it had more features.
E.g., in Zapier, where everything is simplified and users can’t make mistakes because they are limited, the main users (aka developers) are non-technical people from teams in large companies.
For n8n, the main customers are the most technical people in the no/low code market who want to have more control over the steps, write code and custom nodes.
So based on that, this step of “simplifying” and cutting features looks strange. It’s better to extend it and keep both options for PRO and newbies.
Fully agree @Mark_S, the feature is also not meant to make the tool less flexible - which is why I also think we should bring back the JSON schema option.
It’s a little bit like comparing Javascript and Typescript, where you can still do anything with Typescript, you only have to type things. That’s exactly what we’re aiming for here as well.
Hey @Disowned-factory, the new tools should not get “deactivated” on their own. Did you maybe disactivate it by mistake? Any chance you could share how your workflow tool that is throwing the error is set up? If you define input fields in your sub-workflow, that error should not be happening.
It is everything well configured but the issue persist…
By the way, Gemini models are dropping this responses instead of actually calling the tools: print(default_api.Guardar_datos(producto=‘hoodies’, unidades=40, color=‘negro’)) print(default_api.Prenda_gratis())
Maybe this things are related, but it would be necessary to solve all this things ASAP…
Hey @Disowned-factory, fully agree that those things should be resolved ASAP. I’m trying to learn a little more about your workflow and sub-workflow right now. Would you mind pasting me both via a DM so that I can try to reproduce some of the things you mentioned? Also, what version are you on?
