2 posts tagged with "tools"

Many Agent systems describe a harness as one loop: send a user message to a model, execute the Tool Call returned by the model, and send the result back. That loop matters, but it does not answer an earlier question. Does the user's next message continue the current task, change the phase within the same Session, or fall outside the responsibility of this specialist Session?

xAgent handles that question before the business Agent loop. The original input first becomes a Session fact. One constrained semantic call then returns a task relationship together with Skill, Tool, and Memory recall terms. Brain applies a deterministic state transition, and Orchestrator adds capabilities only when the task is first established or its phase changes.

This task-understanding, AI agent tool selection, and environment-preparation path shipped in 0.0.10.beta. This article explains its responsibility boundaries and execution order inside the Harness.

Skills, Tools, and MCP are often discussed as if they were three competing ways to extend an AI agent. They are not. A Tool performs a concrete action. A Skill supplies a reusable method for completing a class of tasks. MCP is the protocol that lets an external server expose capabilities such as Tools to an agent application. An MCP Tool is therefore still a Tool; its distinguishing feature is where it comes from.

We tested those boundaries in a real xAgent session. The session loaded the deep-research Skill, connected to an MCP Server containing the official Model Context Protocol documentation, called two MCP Tools, wrote a report, and reopened the report for validation. The validation step also caught an inaccurate lifecycle description in the first draft and forced a correction.