Skip to main content
Two things an agent needs that are neither checks nor tools: what a market process is, and a door through which an orchestrator outside the bridge can see the same cases and the same previews an internal agent does. This is PR 7 of the agentic process support design.

​
Knowledge skills

A knowledge skill is one generated JSON file in src/scheduling_bridge/agents/knowledge/: a market process in the order a person would explain it - summary, goal, steps, deadlines with the rule they come from, message types, rejection codes with their meaning and what the bridge does about them, notes - and the sources it was generated from, pinned: a page of this documentation by its content hash, a document of the regulatory knowledge base by its id and version. Nothing in the files is edited by hand; the generator scripts/generate_knowledge_skills.py writes them, and the suite’s drift test fails when a pinned source moved and the generator did not run again - what the model is told never silently falls behind the page or the regulation it came from. The first three, for the German market communication of the BKV: A skill in the skill registry names the knowledge it carries (knowledge next to its checks and tools: de-mako-aperak for the APERAK routine and the MaKo check skills, and so on), and a round gets every knowledge skill of the agent’s skills once, rendered compactly under Market process knowledge in its standing context, after the policy, the rules and the tools. Partner free text never enters a knowledge skill (D10): they describe the process, not the traffic. Regenerating. From the repository root:
A page edit that changes the meaning is followed by an edit of the skill’s content in the generator and a run; a page edit that does not (wording, a typo) is followed by a run alone, which re-pins the hash. A KB source is added as kb("DE", "<document id>", "<version>", [chunk ids]) by whoever read the knowledge base for it, and the snapshot of KB versions (agents/knowledge/kb_versions.json, document id to version) is refreshed in the same step; the drift test compares the pins against that snapshot. The regulatory KB is reachable over the Engrate internal MCP, not from the bridge itself, so the snapshot is a person’s or an agent’s read, dated by the skills’ generated_at.

​
The process API over MCP

POST /v1/process/mcp is an MCP server (streamable HTTP in its plain JSON form: one JSON-RPC request in, one response out, no event stream; GET answers 405). It takes the process key like the console (X-API-Key) and is rate-limited and logged (api_call) like every other request. A client connects with
and gets what an internal agent gets, and no more: Resources: policy://shared and knowledge://<slug> serve the same texts. Methods: initialize (protocol versions 2025-06-18, 2025-03-26 and 2024-11-05), ping, tools/list, tools/call, resources/list, resources/read, prompts/list (empty); notifications are accepted with 202. A tool’s refusal (no such case, a refused plan) is the tool’s result with isError, not a protocol error. What is not on the surface, by design: approving or rejecting a proposal, executing anything, the pipeline steps, the configuration, the agents’ definitions. An external orchestrator - a partner’s, a platform’s - can propose exactly what an operator could propose and approve nothing: the people in the inbox stay the ones who decide (D2, D6). To give a partner a key of its own, add a named process key; its name is what the proposals carry.