[BUG] Special tools cause doGenerateWorkflow to crash in node.js environment

[yiwenlu66]

Description

Special tools cause doGenerateWorkflow to crash in node.js environment

Steps to Reproduce

1. Run the following workflow generation code in the node.js environment:

    // Initialize Eko
    const eko = new Eko({
      llm: "claude",
      apiKey: config.anthropicApiKey,
      options: {
        baseURL: config.anthropicBaseUrl
      }
    });

    // Register browser tool
    eko.registerTool(new nodejsTools.BrowserUse());

    // Generate workflow
    console.log(`Generating workflow for task: ${config.taskId}`);
    const workflow = await eko.generate(config.taskPrompt);

2. Error occurs:

Task execution failed: Error: Workflow contains undefined tools: browser_use,cancel_workflow,human_input_text,human_operate
    at WorkflowGenerator.doGenerateWorkflow (/home/yiwen/browser-use-eval/eko/dist/index.cjs.js:959:23)
    at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
    at async Eko.generate (/home/yiwen/browser-use-eval/eko/dist/index.cjs.js:9666:26)
    at async main (/home/yiwen/browser-use-eval/eko-task-runner/main.ts:138:22)

Expected Behavior

Workflow generates successfully with only the browser_use tool.

Environment

node.js, eko ff32aab

Additional Context

This error should be caused by the following code in doGenerateWorkflow:

    // Forcibly add special tools
    const specialTools = [
      "cancel_workflow",
      "human_input_text",
      "human_operate",
    ]
    for (const node of workflowData.nodes) {
      for (const tool of specialTools) {
        if (!node.action.tools.includes(tool)) {
          node.action.tools.push(tool);
        }
      }
    }

If I got this correctly, these tools should be available only in the browser extension environment. Why are they not already included in the default tools and need to be added "forcibly"? I would recommend against enumerating the environment- (and usage-) specific tools in the workflow generation code, this they are not part of the platform-agnostic core logic.

[HairlessVillager]

Thank you for raising this issue. I haven't tested it in a Node.js environment yet.

Firstly, the code you provided seems to be only a partial snippet, and it lacks definitions for variables such as config, nodejsTools. This prevents me from compiling the code and reproducing the bug you encountered. I have previously only run the code in a browser environment and am not familiar with development in a Node.js environment. Therefore, could you provide more detailed steps to reproduce the issue? This would help me reproduce the bug locally and quickly locate the problem.

Secondly, regarding the three tools cancel_workflow, human_input_text, and human_operate, my understanding is that they are general-purpose tools that should function in both browser environments and computer use (or as you mentioned, Node.js) environments. The descriptions of these tools and their use cases in a computer use environment are as follows:

• cancel_workflow: Eko automatically invokes this tool to end the workflow when a tool fails to run. For example, if a user needs to read the content of a file but enters the wrong filename, causing the file_read tool to report an error, Eko will invoke cancel_workflow to cancel the workflow.
• human_input_text: The large model asks the user a question, and the user provides an answer. For example, if the user needs to read the content of a file but does not specify further actions, Eko will invoke human_input_text to ask the user what to do next.
• human_operate: The large model decides to hand over control, providing a reason to the user, who then performs an operation and describes what they just did. For example, if the user needs to read the content of a file but the file is not in the current directory, causing the file_read tool to report an error. In this case, Eko will invoke human_operate to allow the user to copy or move the file to the current directory.

In summary, these three tools are universal and useful in both browser and computer environments, so I will include them in each workflow. However, due to various reasons, I used a less elegant implementation, which you mentioned as "Forcibly add special tools". Of course, I hope for a better implementation. You suggested adding them to the default tools, which I think is a good idea and these tools could be considered as a configurable option.

Additionally, I noticed that the error message mentions the browser_use tool in addition to the three tools discussed above, which was not forcibly added. Have you tried removing the "Forcibly add special tools" code snippet? What were the results? I suspect it would still report an error saying "Workflow contains undefined tools", but only for the browser_use tool.

Lastly, the code of the Eko framework you are using is from a week ago. Perhaps you should use the latest version of the code (e.g., the develop branch)? Although the bug mentioned in this issue persists regardless of whether the latest code is used, it is a good habit to keep your local code synchronized with the develop branch.

[yiwenlu66]

thx @HairlessVillager ! The simplest way to reproduce this issue is using the integration test included in the source code :) Put the following in .env:

ENABLE_INTEGRATION_TESTS=true
ANTHROPIC_API_KEY=your-api-key

and run yarn test test/integration/workflow.generation-and-execution.test.ts. And yes, removing the "forcibly add special tools" resolves this issue.

---

On design philosophy: imho as an agentic programming framework, we should definitely not restrict ourselves to interactive use. People would need the agent to have the capability to run autonomously, or even headlessly. From this angle, even browser use / computer use are plugins to the framework separate from the core workflow logic. So we shall discuss the aforementioned tools separately:

• cancel_workflow: it is indeed essential to the core workflow logic. It might be unnecessary to declare this tool explicitly in the workflow definition though, since this is like a "system tool" that can be called by the LLM at any time to control the execution flow. Similar logic applies to write_context and return_output -- we may consider unifying the logic of implementing these "system tools".
• human_*: these shall not be discussed at the same abstraction level as the system tools. We may define them in parallel with browser_use and computer_use, and provide platform-specific implementations (browser, GUI, CLI). We shall also provide developers with the option of enabling/disabling human interactions.

---

Apologies for limited availability of personal time lately. If you feel that this design choice needs further discussion, feel free to leave this issue open for the time being.