Add governed decisioning without rebuilding your agent stack

Where Knowledge fits

You have already assembled a stack : an agent runtime, tools, business APIs, identity, observability, possibly one or more existing rule engines. The question this page answers is not what endpoints do we offer, but where does Knowledge go in what you already run, and how much has to change.

The answer : very little.

Before Knowledge :

With Knowledge :

Knowledge does not replace your agent runtime or your business systems. It adds a governed policy decision, and where required, an enforcement point at the tool boundary. Everything upstream and everything downstream stays as it is.

Choose your integration path

Three architectural choices depending on what your stack already looks like. Same underlying model, different insertion points.

Already use MCP ?

Two paths depending on which side of the conversation Knowledge sits on.

Knowledge as an MCP server. Wire the Knowledge MCP server into your agent's MCP host. The agent calls knowledge_check, knowledge_resolve, knowledge_request_approval and the rest as tool calls, without your code driving REST. See Quickstart : Knowledge as an MCP server.

MCP tool-call interceptor. For gating your own MCP tools with Knowledge enforcement, wrap each tool invocation with verify_verdict before executing. Pattern documented at Wrap your own MCP server with enforcement ; a reference implementation lives in the monorepo to copy and adapt to your stack.

Your tools are Python functions ?

Python SDK - knowledge-runtime. Wrap selected tools with a decorator :

from knowledge_runtime import governed_tool

@governed_tool(action="refund.execute", resource="tx", bind=["amount"])
def refund(tx: str, amount: int):
    return refund_api.execute(tx, amount)

The decorator consults Knowledge on each call, verifies the signed decision, and only runs the underlying function if the operation was authorized. Structurally compatible with LangChain, LlamaIndex and custom Python runtimes.

Custom architecture ?

REST API + custom PEP. Any language, any framework. Your runtime calls Knowledge's REST endpoints, verifies the returned JWS envelope against Knowledge's public JWKS, then decides in your own enforcement layer whether to invoke the business API.

Best fit when your agent stack is not Python or MCP, or when you want complete control over where policy evaluation and enforcement happen.

Excel or another back-office spreadsheet ?

A workbook can consume a signed decision the same way an agent tool does : call POST /v1/resolve, receive a verdict + JWS envelope, and act on it. The signed verdict is transport-agnostic.

The concrete integration path depends on your IT constraints — typically a small bridge or internal broker between the workbook and Knowledge, sized for your gateway, auth and deployment posture. We scope the shape as part of a design-partner engagement.

Keep your existing business systems

Knowledge does not require centralizing every rule in your organization. It gives the decisions you choose to govern an independent policy authority, and coexists cleanly with everything else.

Two patterns cover most integrations :

• Knowledge owns the decision — for a new class of agentic decisions that needs an independent policy authority.
• Knowledge coexists with domain engines — some decisions naturally stay in ODM / FICO / ServiceNow / custom code, and Knowledge governs the ones that were previously handled through procedures, spreadsheets or human judgment.

Fit into your enterprise infrastructure

Available today

Explore the API

Three endpoints do most of the work in an agent integration :

• POST /v1/resolve - determine policy from available context, get back what is still needed if incomplete
• POST /v1/check - evaluate with a full context, strict input contract
• POST /v1/approvals - route decisions that require human authority

Full endpoint reference, request and response schemas at API reference. OpenAPI spec at /api/openapi-v3.json.

Related