The main workflow reads three workflows in the Tools folder:
dummy retrieval tool => retrieves revenue for profit center A, B, C… works fine and outputs revenue value via Tool message output
Product Master Data retrieval tool: Allows retrieving All Products and their prices for a specific Product Group A, B or C. Output is a data table that is provided to Workflow Output node => seems to work fine
SumUpPrice Tool: Receives Input data table via Workflow Input Node - this is supposed to be the data fetched from the Product Master Data retrieval tool above. Prices in that table are aggregated and provided to Tool Message Output node ==> this does not seem to work or only works arbitrarily - Once the agent provided the correct value, but I was not able to verify that the full logic and tool chain worked, once I discovered Message Part Extractor I was not able to reproduce this - agent seems to successfully retrieve the Product Master Data, but then doesn’t pass it to the next tool
Using gpt-4.1
Agent seems getting stuck as it only sees the schema, but my understanding is KNIME should be able to process the data returned from Workflow Output node further…
Last Agent message typically goes like this:
I’ve retrieved the products and their prices for Product Group C. Now, I need to send this data to the SumUpPriceTool to calculate the total price for all products in that group.
However, I need the actual data (not just the schema) to proceed. Could you please provide the product data for Product Group C, or let me know if you want me to proceed differently?
It may also be that this is not supposed to work the way I understood it… Steps to reproduce:
1.
2.
3.
4.
5.
Thank you for trying out the new agentic features.
Luckily, the issue you ran into is one of prompt engineering as gpt-4.1 seems to not understand how data access works (interestingly the smaller models gpt-4-1-mini and gpt-4.1-nano are less susceptible to this).
We are already working on improving the prompts, to make this less likely to happen. In the meantime you could add the following to your system message:
## Tools and Data
Some tools can consume and produce data. The available data is tracked in a data repository.
Each data item in the repository is represented by an ID as well as a spec.
The actual data is not available to you but you can pass the data to tools by ID.
For tools that consume data, you need to provide the ID of the data to the tool and then the tool receives the data.
If a tool produces data, that data is added to the data repository under a new ID and you can use it for future tool calls.
At least for me that solved the problem in the workflow you provided.
Please let us know if you run into more problems like this.
Wanted to understand first, whether what I tried to do is actually possible / meant to work, so was reluctant to start prompt engineering to avoid trying to solve a lost cause
Based on the brief description in the hacking days guidance I thought so, but was not 100% sure.
If there’s any additional guidance / explanatory document (even if in draft for now), that could be really helpful to take the agentic stuff for a proper spin in the next week!
Will certainly find some time this week to test the above and experiment further!
you guessed right then!
Our plan is to make it easy to build agents and tools that work with data.
In 5.5 it will only be tables but we plan to extend it to more port types in future releases.
Before we can do that, though, we obviously need to improve our prompts a bit more to make it work robustly with different models.
We are currently working on documentation for agents and tools, and I was able to get a draft of the document for you: Agents & Tools 2.0.pdf (248.7 KB)
Mind you, this is still in the works (especially the data part), so any feedback is highly appreciated.
Agent is very interesting in KNIME, happy to see it.
Can we see the Agent Chat view when Agent Prompter is running?
Correct me if I’m wrong. The main design logic of Agent Prompter is that after we design our prompt through Agent Chat view, then we using Agent Prompter to fix that process. The result can only be seen when it is fully executed.
Apologies for taking some time to get back to you on this one!
The guide was very helpful - I did not have to change the prompt, but had to give the Product Master Data retrieval tool a Tool Output Message (was missing).
The guide made it clear that this is mandatory for any tool and also explained why it was not working - other than that a tool was called the AI wouldn’t have know that the tool executed successfully.
It now worked with 4.1 and 4.1 nano as well a couple of times… 4.1 managed to get it done with fewer prompts, whereas nano needed some “tries” in using the different tools.
No, the Agent Prompter currently does not have a view but it outputs the conversation as a table, so you can follow each step the agent took.
You can of course do that but that was not our main goal. We envision the two nodes for separate usage scenarios: On the one hand the Agent Chat View is for building highly interactive chat bots where a user has a multi-turn conversation with an end user. On the other hand the Agent Prompter is meant for non-chatbot use-cases that might not involve user interaction.
There are also some technical reasons why we went with a two-node solution, for example that views can’t output data at the moment. In the past we did have views that output data but that came with its own set of challenges. That being said, we want to also enable the Agent Chat View to output data in the future, it just didn’t make it for 5.5.
I hope that answers your questions, if not please let me know and I’ll give it another shot
well you already blew my mind a little with your example
I am really glad to see you and the community picking this up quickly and especially that it’s not too much of a hassle to turn existing workflows agentic We plan to make it even easier in future releases, though
Thanks a lot for the explanation. I’d like to offer a couple of suggestions.
While the ability to convert entire workflows into tools is undoubtedly very important, I was hoping there might also be a more lightweight way to create tools.
For example, let’s say I have a single Python node that just generates the current date. I wouldn’t want to turn it into a whole new workflow. Instead, I’d prefer to just add that single node as a tool directly into my current workflow that contains an agent prompter.
You could compare this idea to programming: sometimes you don’t want to abstract a small piece of logic into a formal function; you just want to use something simple, like a lambda function.
On another note, I’m genuinely excited to see the development of Agents within KNIME. KNIME is so powerful with tabular data, and I hope to see that we can easily build workflows to evaluate various models and prompts.
thank you for the feedback, out of curiosity, how would you expect these “lambda tools” to be provided to the agent prompter?
We are considering a node that turns a workflow captured via Capture Workflow Start/End into a tool. Then you don’t need a separate workflow to create tools.
If a tool workflow does not have a Tool Message Output node, a default message should be generated informing the agent about the successful execution of the tool (or the error message if the tool failed).
It can and often will help to provide a custom tool message to better inform the agent about what’s going on but in cases where it’s just a simple success message, it shouldn’t be necessary to add the Tool Message Output node.
Hi, @nemad I do prefer like this, ... add a new lambda tool to Agent Prompter.
In fact, lambda tools are not necessarily just lambda tools. They can actually be agents that combine other tools. In this way, we can use agents to call agents. The layering and abstraction of agents are obviously beneficial.
Maybe we need new data type “Agent”
Common tool is just an agent with one tool(Agent description and AI provider are None).
Lambda Tools is just an agent with one tool(Agent description and AI provider are None).
The input agent for final Agent Prompter is just an agent with multiple tools.(the input agent can have different AI provider than final smarter Agent Prompter’s AI provider)
I think providing that custom tool output message is what likely did it for me in terms of making this “tool chaining” reliable… I will keep testing when I find some time and have already some ideas for even more “complex” scenarios I’d like to tackle!
Maybe an idea that is probably not too hard to add:
I was thinking about how agents with multiple tools can potentially be scaled in an organization- one of the challenges I see is if everyone uses let’s say the same data app to interact with an agent right now they’d have all access to the same tools.
What if finance only should use finance tools, but not marketing?
Idea: is it possible to read any „tags“ that are added in the workflow description and show them in the Worlflow to tool node output?
These could easily be used to implement „Row Level Security“ by only passing tools that a user should have access to…
We plan to make it even easier in future releases, though 
