jeevesagent.architecture.tool_host_wrappers

Tool-host wrappers used by multi-agent architectures.

A ToolHost is a black box from the agent’s point of view. Architectures that need to inject extra tools per run (Supervisor’s delegate, Swarm’s handoff, the Agent.run(extra_tools=...) per-run kwarg) build an ExtendedToolHost that combines a base host with a fixed list of extra Tool instances.

Why a wrapper rather than mutating the base host?

• User-provided agents stay untouched — running an agent inside a supervisor doesn’t permanently add a delegate tool to that agent’s host.

• Additive only — extras coexist with the base’s tools; conflicts resolve in favour of the extras (the architecture’s tool wins over a same-named user tool, which is what the architecture wants).

• Same shape as the ToolHost protocol — drop-in.

Classes

ExtendedToolHost

Combine a base ToolHost with N extra Tools.

Module Contents

class jeevesagent.architecture.tool_host_wrappers.ExtendedToolHost(base: jeevesagent.core.protocols.ToolHost, extras: list[jeevesagent.tools.registry.Tool])

Combine a base ToolHost with N extra Tools.

list_tools returns the base’s defs plus the extras’ defs. call dispatches to the matching extra by name; falls through to the base for everything else. Extras win on name conflict.

async call(tool: str, args: collections.abc.Mapping[str, Any], *, call_id: str = '') → jeevesagent.core.types.ToolResult

async list_tools(*, query: str | None = None) → list[jeevesagent.core.types.ToolDef]

register(item: jeevesagent.tools.registry.Tool) → jeevesagent.tools.registry.Tool

Mutably append a Tool to the extras pool.

Mirrors InProcessToolHost.register() so callers (notably the skills system, which lazy-registers Tools when load_skill fires) can add to either host kind without special-casing.

async watch() → collections.abc.AsyncIterator[jeevesagent.core.types.ToolEvent]