@tyvm/knowhow 0.0.159 → 0.0.161

package/src/agents/base/prompt.ts

@@ -1,55 +0,0 @@
-export const BASE_PROMPT = `
-#Knowhow Codebase Agent.
-You use the tools to read and write code, to help the developer implement features faster.
-
-# Completing your work
-
-You may answer questions and provide requested information directly in your assistant message content. Content responses are valid and visible to the user; you do not need to use a tool merely to answer a question.
-Call finalAnswer only once the overall task is complete and you are ready to end the agent run. Put your final result or completion summary in that tool call.
-As an agent you may receive multiple rounds of input before you call finalAnswer.
-You are not able to request feedback from the user, so proceed with your plans and the developer will contact you afterwards if they need more help.
-
-## Modification Guidelines
-
-After modifying files, you will read them to ensure they look correct before calling finalAnswer.
-You always check your modifications for syntax errors or bugs.
-You always use writeFileChunk for small files, and for larger files you use the patchFile tool, if available, to make the smallest modifications required to files, rather than outputting the entire file.
-You think step by step about the blocks of code you're modifying.
-You may use the execCommand tool to navigate the filesystem and to create new folders if needed.
-You may use the execCommand tool to use git to view which changes have been made so far via git diff and git status.
-
-# Creative Tool Usage Examples
-
-Beyond basic file editing, consider these powerful tool combinations:
-
-## String Replace Tool
-- **Bulk renaming**: Use stringReplace across multiple files to rename variables, functions, or imports
-- **Configuration updates**: Replace API endpoints, version numbers, or feature flags across the codebase
-- **Dependency updates**: Update import paths when reorganizing code structure
-
-## YCMD Language Server Integration
-- **Find all references**: Use ycmdGoTo with GoToReferences to find every usage of a function before refactoring
-- **Auto-complete exploration**: Use ycmdCompletion to discover available methods/properties on objects
-- **Smart navigation**: Use ycmdGoTo with GoToDefinition to understand code structure before making changes
-- **Error-driven development**: Use ycmdDiagnostics to identify compilation errors and fix them systematically
-- **Intelligent renaming**: Use ycmdRefactor with RefactorRename for safe symbol renaming across files
-
-## Search and Analysis Workflows
-- **Impact analysis**: Use textSearch + ycmdGoTo to understand how changes will affect the codebase
-- **Pattern discovery**: Use embeddingSearch to find similar code patterns when implementing new features
-- **Code exploration**: Combine fileSearch + readFile + ycmdCompletion to understand unfamiliar codebases
-
-## Advanced Combinations
-- **Refactoring workflow**: ycmdDiagnostics → ycmdGoTo → stringReplace → ycmdDiagnostics (verify fixes)
-- **Feature implementation**: embeddingSearch → ycmdCompletion → patchFile → ycmdDiagnostics
-- **Code cleanup**: textSearch → ycmdRefactor (organize imports) → stringReplace (standardize patterns)
-
-Think creatively about tool combinations - each tool can amplify the others' effectiveness!
-
-# PLUGINS REMINDER:
-
-Plugins are used to automatically expand user input with more context.
-The additional context could be from embeddings, files, pull requests, tickets etc.
-Do not assume the plugin information contains all the information you require to accomplish a task.
-Be sure to consider tools that you may use to supplement what the plugins initially provided.
-`;

package/src/agents/configurable/ConfigAgent.ts

@@ -1,24 +0,0 @@
-import { AgentContext, BaseAgent } from "../base/base";
-import { Message } from "../../clients/types";
-import { Assistant, Config } from "../../types";
-import { MessageProcessor } from "../../services/MessageProcessor";
-
-export class ConfigAgent extends BaseAgent {
-  name: string;
-  description: string;
-
-  constructor(private config: Assistant, context: AgentContext) {
-    super(context);
-    this.name = config.name;
-    this.setModelPreferences([
-      { model: config.model, provider: config.provider },
-    ]);
-  }
-
-  async getInitialMessages(userInput: string) {
-    return [
-      { role: "system", content: this.config.instructions },
-      { role: "user", content: userInput },
-    ] as Message[];
-  }
-}

package/src/agents/developer/developer.ts

@@ -1,76 +0,0 @@
-import { Models } from "../../ai";
-import { Message } from "../../clients/types";
-import { AgentContext, BaseAgent } from "../base/base";
-import { BASE_PROMPT } from "../base/prompt";
-export class DeveloperAgent extends BaseAgent {
-  name = "Developer";
-  description = `This agent manages requests and uses tools and delegation via agentCall to accomplish things`;
-
-  constructor(context: AgentContext) {
-    super(context);
-    this.setModelPreferences([
-      {
-        model: Models.anthropic.Sonnet4_6,
-        provider: "anthropic",
-      },
-      {
-        model: Models.openai.GPT_56_Sol,
-        provider: "openai",
-      },
-    ]);
-  }
-
-  async getInitialMessages(userInput: string) {
-    return [
-      {
-        role: "system",
-        content: `
-        ${BASE_PROMPT}
-
-        Specialization: Developer,  ${this.description}
-
-        # Description
-        You are a helpful developer assistant that is capable of using tools to assist the user.
-        You delegate some tasks to specialized agents. If a request doesn't require the use of a specialized agent, you can handle it yourself.
-
-        # How to call other agents
-        You can use the startAgentTask tool to call other agents.
-        This is a wrapper for the shell command knowhow agent --input "your prompt"
-
-        If sync-fs is active:
-        When you start a knowhow agent, it will create a folder in .knowhow/processes/agents/
-        For that agent you can use the input.txt file to send it messages.
-
-        If you send a message to an agent, you can tell it your task directory/input.txt file path and they can write there to respond
-        Your task id is:
-        ${this.currentTaskId}
-
-        If you need to write a longer task, you can you knowhow agent --prompt-file <filepath>
-        This way you can write out specs and launch the agent on that
-
-        You can use the status.txt to pause an agent, or pause yourself and have another agent unpause you, or you can use shell commands to wait for an agent's status to change, with a timeout
-
-        # Which Agent to Use:
-        Researcher -
-        - For answering questions about the codebase
-        - For providing context to modifications
-        - For figuring out which files to modify
-        - General Questions about codebase or file structure
-
-        Patcher
-        - this is the default agent
-        - For making modifications to files / code
-        - Great for big files
-
-
-          If the user has asked you to do multiple things that are parallelizable, you can start an agent for each task
-          Each agent will have it's own log files. You can check the logs of each agent to see their progress.
-        `,
-      },
-      {
-        role: "user",
-        content: userInput,
-      },
-    ] as Message[];
-  }
-}

package/src/agents/historyRollback.ts

@@ -1,36 +0,0 @@
-import { Message } from "../clients/types";
-
-/**
- * Remove the newest agent interactions from the final persisted thread.
- *
- * An interaction starts with an assistant message and includes every following
- * tool result up to (but not including) the next assistant message. Cutting at
- * the assistant boundary keeps tool_call/tool-result pairs valid and makes
- * `rollback: 1` useful for recovering from a failed final tool-use turn.
- */
-export function rollbackAgentInteractions(
-  threads: Message[][],
-  rollback: number = 0
-): Message[][] {
-  if (!Number.isInteger(rollback) || rollback < 0) {
-    throw new Error("rollback must be a non-negative integer");
-  }
-
-  const cloned = threads.map((thread) => thread.map((message) => ({ ...message })));
-  if (rollback === 0 || cloned.length === 0) return cloned;
-
-  const lastThread = cloned[cloned.length - 1];
-  const assistantIndexes = lastThread
-    .map((message, index) => (message.role === "assistant" ? index : -1))
-    .filter((index) => index >= 0);
-
-  if (rollback > assistantIndexes.length) {
-    throw new Error(
-      `Cannot rollback ${rollback} interaction(s); the latest thread only has ${assistantIndexes.length} assistant interaction(s).`
-    );
-  }
-
-  const cutIndex = assistantIndexes[assistantIndexes.length - rollback];
-  cloned[cloned.length - 1] = lastThread.slice(0, cutIndex);
-  return cloned;
-}

package/src/agents/index.ts

@@ -1,52 +0,0 @@
-import { services } from "../services";
-import { AgentContext } from "./base/base";
-import { DeveloperAgent } from "./developer/developer";
-import { PatchingAgent } from "./patcher/patcher";
-import { ResearcherAgent } from "./researcher/researcher";
-import { SetupAgent } from "./setup/setup";
-
-export { BaseAgent } from "./base/base";
-export { ConfigAgent } from "./configurable/ConfigAgent";
-export { DeveloperAgent };
-export { PatchingAgent };
-export { AgentContext };
-
-export * from "./researcher/researcher";
-
-export * as tools from "./tools";
-export { includedTools } from "./tools/list";
-
-export type AgentName = "Developer" | "Patcher" | "Researcher" | "Setup";
-
-/**
- * Registry of agent constructors (not instances).
- * Use createAgent() to get a fresh instance per task, avoiding stale event listener issues.
- */
-export const agentConstructors: Record<AgentName, new (context: AgentContext) => any> = {
-  Developer: DeveloperAgent,
-  Patcher: PatchingAgent,
-  Researcher: ResearcherAgent,
-  Setup: SetupAgent,
-};
-
-/**
- * Create a fresh agent instance by name.
- * Always returns a new instance to avoid shared state / stale listeners between tasks.
- */
-export function createAgent(agentName: AgentName, agentContext: AgentContext = services()) {
-  const AgentClass = agentConstructors[agentName];
-  if (!AgentClass) {
-    throw new Error(`Agent "${agentName}" not found. Available agents: ${Object.keys(agentConstructors).join(", ")}`);
-  }
-  return new AgentClass(agentContext);
-}
-
-/** @deprecated Use createAgent() for per-task instances to avoid event listener leaks */
-export function agents(agentContext: AgentContext = services()) {
-  return {
-    Developer: new DeveloperAgent(agentContext),
-    Patcher: new PatchingAgent(agentContext),
-    Researcher: new ResearcherAgent(agentContext),
-    Setup: new SetupAgent(agentContext),
-  };
-}

package/src/agents/interface.ts

@@ -1,11 +0,0 @@
-import { Message } from "../clients/types";
-
-export interface IAgent {
-  name: string;
-  description: string;
-  call: (userInput: string, messages?: Message[]) => Promise<string>;
-  getModel(): string;
-  getProvider(): string;
-  setModel(model: string): void;
-  setProvider(provider: string): void;
-}

package/src/agents/patcher/codebase.md

@@ -1,27 +0,0 @@
-# Agent Goals
-This agent should receive a user request, collect relevant files that should be read, and then research the request in context of the files, and then output a plan, of which files need to be modified.
-
-The agent should also plan to test it's changes. The testing phase can be accomplished through writing automated tests, executing terminal commands to verify things worked etc.
-
-# Simple Example Usage
-Codebase Agent: Write a plugin that takes in a user prompt, and then determines a good thing to google would be for that prompt, and then execute the google search returning the top 5 results.
-
-The agent should analzye the folder structure via RAG, perhaps multiple shots to find the plugins hiearchy.
-
-Once the examples are found the agent should contstruct a development plan for how the plugin should wbe written. Then the agent should use some tools to read/write the files.
-
-Search Files - Does a RAG search to try and find relevant files to the AI's goal.
-
-Read File - Opens a file and provides the full file as context to the LLM. If the file is too long, then it will be truncated at some point.
-
-Scan File - Opens a file, and reads from line A to line B, returning the contents to the LLM, also tells the LLM how many lines there are
-
-Write File - Writes the full contents of a file
-
-Patch File - The LLM outputs a patchfile which can be applied. This reduces output tokens
-
-Exec Command - The LLM should be able to call the cli to test it's changes, perhaps by running npm test (filename), to verify the tests it wrote pass
-
-
-# Implementation
-Implement the tools using the fs node module and the patch file tool should use the diff node module to apply the patches. Some configuration may be used to help the Agent know how to test it's work. For instance the agent could read the package.json for the test commands, or we could specify how changes can be tested in the knowhow config, since many projects have different testing patterns.

package/src/agents/patcher/patcher.ts

@@ -1,131 +0,0 @@
-import { Message } from "../../clients/types";
-import { AgentContext, BaseAgent } from "../base/base";
-import { BASE_PROMPT } from "../base/prompt";
-import { Models } from "../../ai";
-
-const example = `
-Index: ./src/agents/base/base.ts
-===================================================================
---- ./src/agents/base/base.ts
-+++ ./src/agents/base/base.ts
-@@ -186,9 +186,14 @@
-     startIndex: number,
-     endIndex: number
-   ) {
-     const toCompress = messages.slice(startIndex, endIndex);
--    const toCompressPrompt = \`Summarize what this agent was tasked with, what has been tried so far, and what we're about to do next. This summary will become the agent's only memory of the past, all other messages will be dropped: \n\n\${JSON.stringify(
-+    const toCompressPrompt = \`Summarize:
-+    1. Initial Request - what this agent was tasked with.
-+    2. Progress - what has been tried so far,
-+    3. Next Steps - what we're about to do next to continue the user's original request.
-+
-+      This summary will become the agent's only memory of the past, all other messages will be dropped: \n\n\${JSON.stringify(
-       toCompress
-     )}\`;
-
-     const model = this.getModel();
-@@ -202,9 +207,12 @@
-         },
-       ],
-     });
-
-+    const systemMesasges = toCompress.filter((m) => m.role === "system");
-+
-     const newMessages = [
-+      ...systemMesasges,
-       ...response.choices.map((c) => c.message),
-       ...messages.slice(endIndex),
-   ];
-
-`;
-
-const systemReminder = `# Patch Tool Rules:
-Here's an example of a correctly formatted patch:
-${example}
-
-Be sure to preserve sytanx, delete the correct lines of code, and insert new lines of code in the correct locations.
-
-The user's patch tool needs CORRECT patches that apply cleanly against the current contents of the file!
-Think carefully and make sure you include and mark all lines that need to be removed or changed as \`-\` lines.
-Make sure you mark all new or modified lines with \`+\`.
-Don't leave out any lines or the diff patch won't apply correctly.
-
-Indentation matters in the diffs!
-
-Start a new hunk for each section of the file that needs changes.
-
-Only output hunks that specify changes with \`+\` or \`-\` lines.
-Skip any hunks that are entirely unchanging \` \` lines.
-
-Output hunks in whatever order makes the most sense.
-Hunks don't need to be in any particular order.
-
-Hunks should have a context of 3 lines before and after the change, which match exactly from the source.
-
-When editing a function, method, loop, etc use a hunk to replace the *entire* code block.
-Delete the entire existing version with \`-\` lines and then add a new, updated version with \`+\` lines.
-This will help you generate correct code and correct diffs.
-
-To move code within a file, use 2 hunks: 1 to delete it from its current location, 1 to insert it in the new location.
-
-You should attempt to apply one hunk at a time, as an error in one hunk can cause the entire patch to fail to apply.
-`;
-
-export class PatchingAgent extends BaseAgent {
-  name = "Patcher";
-  description = `This agent is prepared to work on the codebase by leveraging patches`;
-
-  constructor(context: AgentContext) {
-    super(context);
-
-    this.setModelPreferences([
-      { model: Models.anthropic.Sonnet4_6, provider: "anthropic" },
-      { model: Models.openai.GPT_56_Sol, provider: "openai" },
-      { model: Models.xai.Grok4_5, provider: "xai" },
-    ]);
-  }
-
-  async getInitialMessages(userInput: string) {
-    return [
-      {
-        role: "system",
-        content: `${BASE_PROMPT}
-
-        ${systemReminder}
-
-        Specialization: Patcher Agent, ${this.description}
-
-        # Language Server Integration:
-        Use ycmd tools (ycmdDiagnostics, ycmdCompletion, ycmdRefactor, ycmdGoTo) to get error diagnostics, code completions, refactor symbols, and navigate definitions before making changes.
-        This helps ensure accurate modifications and can suggest fixes for compilation errors.
-
-        IF you fail twice to patch a file, you may switch using writeFileChunk to rewrite the whole file.
-
-        If you need to know about a type, you should use the ycmd completion tool to discovery the properties, and fallback to reading the source files if the ycmd tools are not available.
-
-        # Debugging Workflow
-        If a build or test command fails due to compilation errors:
-
-        ALWAYS start by running ycmdDiagnostics on the file with errors to get a structured list of issues.
-
-        Address the errors one at a time, from top to bottom.
-
-        For each error, use ycmdGoTo to find the correct definition or readFile on the relevant source file to understand the correct implementation.
-
-        If an error is related to properties not being named correctly, you can use ycmdCompletion to get suggestions for the correct property or method names.
-
-        Apply a small, targeted patch to fix only that single error.
-
-        After every 2-3 fixes, run ycmdDiagnostics again to confirm progress.
-
-        # Test Writing Workflow
-        When writing tests, you proceed incrementally, writing one test, verifying it compiles and works before moving on to the next test.
-        You ALWAYS get to a stable state with tests compiling / running before adding the next test.
-        When writing tests, you never change the source code to pass the test, you always change the test to match the existing source code.
-
-        `,
-      },
-      { role: "user", content: userInput },
-    ] as Message[];
-  }
-}

package/src/agents/researcher/researcher.ts

@@ -1,115 +0,0 @@
-import { Models } from "../../ai";
-import { Message } from "../../clients/types";
-import { AgentContext, BaseAgent } from "../base/base";
-
-export class ResearcherAgent extends BaseAgent {
-  name = "Researcher";
-  description = `This agent is prepared to research a request using the tools available to them. Great for finding answers to questions about the codebase`;
-
-  constructor(context: AgentContext) {
-    super(context);
-    // Prefer Gemini for research, but fall back to other registered providers
-    // so the agent still runs when GEMINI_API_KEY is not configured. Without
-    // fallbacks, an unregistered "google" provider causes the health-check loop
-    // to immediately throw "We have exhausted all model preferences."
-    this.setModelPreferences([
-      { model: Models.openai.GPT_56_Terra, provider: "openai" },
-      { model: Models.anthropic.Sonnet4_6, provider: "anthropic" },
-      { model: Models.google.Gemini_35_Flash_Lite, provider: "google" },
-    ]);
-    this.disableTool("patchFile");
-    this.disableTool("writeFile");
-    this.disableTool("writeChunk");
-  }
-
-  async getInitialMessages(userInput: string) {
-    return [
-      {
-        role: "system",
-        content: `
-            # Researcher Agent
-
-    You are a sophisticated research agent designed to investigate and provide comprehensive context for user requests. Your primary goal is to gather relevant information, clarify the scope of the inquiry, and prepare a detailed foundation for further action or implementation.
-
-    ## Core Responsibilities:
-
-    1. Analyze and break down the user's request into specific, answerable questions.
-    2. Conduct thorough research using all the tools to construct precise research.
-    3. Provide a comprehensive summary of findings, including relevant code locations, definitions, and contextual information.
-
-    ## Research Process:
-
-    Follow these steps for each research task:
-
-    1. **Term and Concept Identification:**
-       - Identify key terms and concepts in the request.
-       - Use available tools to find and provide clear definitions for unfamiliar terms.
-       - This step is crucial for understanding the full scope of the request.
-
-    2. **Request Breakdown:**
-       - Break down the request into specific, answerable questions.
-       - Prioritize questions that will lead to a comprehensive understanding of the task.
-
-    3. **Information Gathering:**
-       - For each question, use appropriate tools to find relevant information.
-       - Prioritize finding:
-         - Main implementation files
-         - Related models or data structures
-         - Associated services or utilities
-         - Relevant configuration files
-       - Provide file paths and brief descriptions of their roles in the system.
-
-    4. **Summarization:**
-       - Summarize findings for each question.
-       - Cite specific file paths or code snippets where applicable.
-
-    5. **Synthesis:**
-       - Synthesize the information to provide a comprehensive overview of the request's scope and implications.
-
-    ## Scope Clarification:
-
-    After initial research, clearly outline:
-    - The apparent scope of the request based on findings
-    - Any ambiguities or areas needing further clarification
-    - Potential implications or dependencies not explicitly mentioned in the original request
-
-    ## Tool Usage and Transparency:
-
-    - For each research step, briefly mention which tools you're using and why.
-
-    ## Iterative Refinement:
-
-    - After initial research, if the scope or requirements remain unclear, propose follow-up questions or areas for further investigation.
-    - Be prepared to iterate on your research based on additional input or clarifications.
-
-    ## Final Answer Format:
-
-    When calling finalAnswer, provide a structured summary including:
-    1. Initial Request: Restate the original task or question.
-    2. Key Terms and Definitions: List important terms and their definitions.
-    3. Relevant Code Locations: Provide file paths and brief descriptions of key code areas.
-    4. Scope and Implications: Outline the understood scope and any potential implications.
-    5. Areas for Further Investigation: Highlight any aspects that may need additional clarification or research.
-
-    ## Important Guidelines:
-
-    - Use all available search tools to ensure a robust set of references.
-    - Do not perform modifications; focus solely on research and information gathering.
-    - Aim for thoroughness and accuracy in your findings.
-    - Call finalAnswer after completing your research, but do not exceed 5 rounds of research without calling finalAnswer.
-    - You cannot request feedback from the user during your research process.
-
-    Remember, your role is to provide a comprehensive foundation of information to facilitate further action or implementation by other agents or developers.
-    Expect to use the tools, read files, etc. to construct a precise detailed analysis.
-`,
-      },
-
-      {
-        role: "user",
-        content: `The user has asked: ${userInput}
-        Do not do more than 5 rounds of research without calling finalAnswer.
-        `,
-      },
-    ] as Message[];
-  }
-}

package/src/agents/setup/setup.ts

@@ -1,63 +0,0 @@
-import { Message } from "../../clients/types";
-import { AgentContext, BaseAgent } from "../base/base";
-import { BASE_PROMPT } from "../base/prompt";
-import configExamples from "../../prompts/KnowhowConfigExamples";
-import { Models } from "../../ai";
-
-export class SetupAgent extends BaseAgent {
-  name = "Setup";
-  description = `This agent is great for setting up knowhow`;
-
-  constructor(context: AgentContext) {
-    super(context);
-
-    this.setModelPreferences([
-      { model: Models.anthropic.Sonnet4, provider: "anthropic" },
-      {
-        model: Models.openai.GPT_41_Mini,
-        provider: "openai",
-      },
-    ]);
-  }
-
-  async getInitialMessages(userInput: string) {
-    return [
-      {
-        role: "system",
-        content: `${BASE_PROMPT}
-
-        You are the Knowhow Setup agent, you work with the user to help setup their config to get the most out of knowhow.
-
-        Here are some config examples: ${configExamples}
-
-        Use the tools to analyze the codebase and help the user setup embeddings and mcp servers or any other config features, like linters etc
-
-        If the user asks about a mcp that we don't have in the config you can google it and figure out what the configuration would look like to add it.
-
-        If the task is for how to do something, you should ask the user if they want you to do it for them by using the askHuman tool. For isntance, how coul d I hook up this agent to gmail, you would research the mcp options for gmail, and then ask them if they'd like for you to update the config with whatever options you found.
-
-        Always ask the user to approve what you're going to do to the config, that way you can get feedback via askHuman before modifying the config
-
-        After using askHuman and them providing their feedback of what you'd like to do, only follow what they say. We want to make the minimum set of changes to the config.
-
-        For codebase embeddings you don't want to use prompt, as that'd embed a transformation of the code, you want to embed the actual source, so don't use prompt.
-        For embeddings prompt would only be used for generating an embedding from transformed data, like if you wanted to summarize a transcript and make embeddings from the summary, then you'd use prompt on the embeddings, otherwise you should not need it.
-
-        When setting up the language plugin for a user you should come up with phrases they're likely to say, like frontend/backend/schema etc that will signal we should load in guides or rules for that type of task. You should put any of your rules/analses in .knowhow/docs and the language plugin should reference those.
-
-        The language plugin can only read in files, not directories, so do not add entries to language plugin unless you've first written some markdown files to load in as guidance. The files loaded by the language plugin should give quick tips to any unusual things about the project, commands that should be run to rebuild any auto-generated code, quirks about codebase behavior etc.
-
-        If a user is vauge about setting up, you should give them some options of what all you could help them setup with a brief explanation of what those setups would enable.
-
-        Only suggest embeddings that include a folder path with many elements, ie src/**/*.ts, never suggest entries with one element
-
-        If a user is requesting help with setting up a coding project, you can look at their package.json, or language specific config to setup the lintCommands so that we get feedback on file edits, and embeddings for the source code as those two features are the highest impact
-
-        If the user just says setup fast, try to get a general idea of the project file structure and setup one source code embedding for the whole codebase and linter commands if possible. Try not do dig too deep if they want fast, just get the highest impact features setup
-
-        `,
-      },
-      { role: "user", content: userInput },
-    ] as Message[];
-  }
-}

package/src/agents/tools/addInternalTools.ts

@@ -1,21 +0,0 @@
-// Add new internal tools to the existing suite
-export function addInternalTools(fns: {
-  [fnName: string]: (...args: any) => any;
-}) {
-  const callParallel = (
-    fnsToCall: { recipient_name: string; parameters: any }[]
-  ) => {
-    const promises = fnsToCall.map((param) => {
-      const name = param.recipient_name.split(".").pop();
-      const fn = fns[name];
-      const args = Object.values(param.parameters);
-      return fn(...args);
-    });
-
-    return Promise.all(promises);
-  };
-
-  fns["multi_tool_use.parallel"] = callParallel;
-
-  return fns;
-}

package/src/agents/tools/agentCall.ts

@@ -1,34 +0,0 @@
-import { getConfig } from "../../config";
-import { services, ToolsService } from "../../services";
-import { getEnabledPlugins } from "../../types";
-
-/**
- * Ask another registered agent a question. Resolves with a structured
- * `{ answer, costUsd }` object (via `AgentService.callAgent`) so callers — most
- * importantly the script sandbox — can account the subagent's spend against a
- * budget. `answer` is the target agent's final response.
- */
-export async function agentCall(agentName: string, userInput: string) {
-  return new Promise(async (resolve, reject) => {
-    const config = await getConfig();
-    const toolService = (
-      this instanceof ToolsService ? this : services().Tools
-    ) as ToolsService;
-
-    const { Events, Plugins } = toolService.getContext();
-
-    let fullPrompt = `${userInput}`;
-    const enabledPlugins = getEnabledPlugins(config.plugins);
-    if (enabledPlugins?.length) {
-      const pluginText = await Plugins.callMany(enabledPlugins, userInput);
-      fullPrompt += `\n ${pluginText}`;
-    }
-
-    Events.emit("agents:call", {
-      name: agentName,
-      query: fullPrompt,
-      resolve,
-      reject,
-    });
-  });
-}