← Blog

· Hive AI

Knolo in Agent Frameworks: OpenAI Agents SDK, Pydantic AI, Langflow and Dify

Four new Knolo examples run the same pinned Knowledge Image through @knolo/mcp 0.2.0 in the OpenAI Agents SDK, Pydantic AI, Langflow and Dify, with no model call.

Knolo is the open-source, local-first Knowledge Image runtime and format from Hive AI. The runtime ships as @knolo/core on npm under Apache-2.0, and the read-only agent server ships as @knolo/mcp. Over the last few days the Knolo GitHub repo merged four new offline smokes that show the same pinned Knolo image working inside four agent frameworks: the OpenAI Agents SDK, Pydantic AI, Langflow and Dify.

This post walks through what each Knolo example does, what it deliberately does not do, and how to run one yourself.

One Knolo server, four hosts

Every example starts the same published server over stdio:

npx -y @knolo/mcp@0.2.0 --config /absolute/knolo-mcp.json

The config points at a Knolo V5 Knowledge Image, a policy and an audit directory. A shared fixture script, prepare-fixture.mjs, writes a two-chunk image, a deny-default policy and the knolo-mcp.json file under a temporary directory, so you can try it without any data of your own.

Because that fixture has no pinned graph, the server exposes four read-only tools: knolo_search, knolo_get, knolo_verify and knolo_status. The graph tools (knolo_kar_evaluate, knolo_kar_verify and knolo_cortex_verify) stay absent, and each smoke checks that they are absent.

The host owns the model in all four examples. Knolo does not call a model and does not read an API key.

Knolo with the OpenAI Agents SDK

examples/openai_agents_js uses MCPServerStdio from @openai/agents@0.21.0 to start knolo-mcp and run one knolo_search for enterprise refunds. It expects the refunds excerpt and a qr_ receipt id whose file version is openclaw-knolo-query-v1. It never constructs an Agent or calls run(). A host that does call a model passes the same server on mcpServers. Node.js 22 or newer is required.

Knolo with Pydantic AI

examples/pydantic_ai calls the same server with MCPToolset and FastMCP StdioTransport, pinning pydantic-ai-slim[mcp] 2.66.0 and fastmcp-slim[client] 4.1.6. Beyond the excerpt and receipt, it checks the hit object id and a sha256- state root. A host that calls a model passes the toolset on toolsets.

Knolo with Langflow

examples/langflow ships a Langflow 1.13.1 flow.json that wires Chat Input to an Agent, the Agent to Chat Output, and an MCP Tools component in tool mode to the Agent's tools port. The smoke loads the flow with Graph.from_payload, lists the tools and runs one search. The Agent model and API key stay empty, and the playground is not opened. Two practical notes from the README: a Langflow container needs Node inside the image for npx, and if mcp_server_allowed_packages is set it must include @knolo/mcp.

Knolo with Dify

examples/dify is the most honest of the four about limits. Dify 1.19.0's built-in MCP client registers a server by an http or https URL, and the Knolo server is stdio only. So the example checks the published pin in mcp.json, starts the server with the MCP Python SDK client and runs one search. It does not open a port, add a proxy, ship a Dify plugin or register a server inside Dify. A native Marketplace plugin is still unbuilt.

What a Knolo receipt means

All four READMEs repeat the same rule, and it is worth repeating here. Verification checks the image pin and the policy. It does not decide that a claim is true. A receipt is an integrity check, not proof. A policy denial returns ACCESS_DENIED, and an unwritable audit directory returns AUDIT_UNAVAILABLE with no hits. Search matches every space-separated term as a substring.

Run a Knolo smoke locally

From the repository root, with @knolo/core and @knolo/mcp built, the Pydantic AI smoke looks like this:

python -m pip install -r examples/pydantic_ai/requirements.txt
config="$(node examples/google_adk_python/prepare-fixture.mjs)"
export KNOLO_MCP_CONFIG="$config"
python examples/pydantic_ai/smoke.py

Each example also has its own CI job in the repo. None of these changes bumped a version or cut a release, so @knolo/mcp@0.2.0 and @knolo/core@6.2.0 remain the current published versions.

Next steps with Knolo