Gate registry
The
inbox gate carries one tool, request_from_user, through which an
implementation session asks you for a credential, access or a file; Kapso
injects the gate’s three variables for each session when inbox.enabled
is true, so the gate always resolves. See the inbox.
GateDefinition.required_env checks for a non-empty value. That establishes
that a dependency is configured; it does not make a network request or prove
that a credential is valid.
What a campaign records
Every session’s MCP tool calls are tallied per gate into the node’s phase telemetry (<gate>_calls and <gate>.<tool> under ideation and
implementation), so the checkpoint keeps what each node consulted. The
tally appears on the node-completed line in the log and status file, on each
row of kapso watch --tree, and as “Knowledge consulted” totals in the final
summary. Leeroopedia answers carry the account’s remaining credits, so the tree
and the summary also show “leeroopedia 761 → 747 remaining”: the balance after
the campaign’s first answer to the balance after its last. A configured gate
that cannot resolve is named once in the launch banner with its fix, for
example a missing LEEROOPEDIA_API_KEY.
What the agent is told
Each gate owns its own “when to call these tools” text, one prompt file per phase under the strategy’sprompts/gates/ directory, and a session’s prompt
carries the guidance of exactly the gates it mounted. A gate that did not
resolve — no key, a skip policy, a Codex ensemble member that runs without
MCP — is not described, so the prompt never names a tool the session does not
have. Leeroopedia’s guidance places its tools at decision points (plan before
code, priors before fixing a value, diagnosis on the first failed run) and
asks for [PageID] citations where an answer shaped the work.
Failure policies
resolve_gates accepts three policies:
Unknown gate names and unknown policy names are always configuration errors;
they are never skipped.
Building agent configuration
get_mcp_config resolves capabilities first and returns servers and allowed
tools only for enabled gates:
python
executable on PATH. If all internal gates are omitted, no empty bundled server
is created. A hosted gate is handed to the CLI as a streamable-HTTP server under
its own name and tool-name prefix; its address and per-call timeout live in the
packaged config’s gates: block, and {VAR} placeholders in the address are
filled from the gate’s required environment when the session launches, so the
key rides on the URL and is never written into code or config.
Generic search
The generic strategy defaults towarn, because its knowledge integrations are
optional enrichment:
error for a reproducible campaign where every configured knowledge source
is mandatory. Use skip when optional capabilities are expected to vary across
machines and warnings would be noisy.
Adding a gate
Dependencies belong beside the tool definition, not in a search strategy:ToolGate class in GATE_CLASSES. For a
hosted gate, set both url and server_name and put the address in the
gates: block of config.yaml. Add hermetic resolution tests for missing and
available dependencies; live credential tests should remain opt-in.
Related
Search strategies
Configuration
pip install leeroo-kapso · Every page as plain text: llms.txt.