01
What it knows
Context
Typed knowledge nodes with provenance on every fact: where it came from, who last touched it, when it was verified. Compiled into a graph you can traverse, mass-update and build dashboards on.
Bevel is a vendor agnostic control plane where your company's AI agents, context, skills, tools and permissions are defined as files your company owns in its own infrastructure, served to any agent runtime over MCP.
Four things fully specify an agent.
01
What it knows
Typed knowledge nodes with provenance on every fact: where it came from, who last touched it, when it was verified. Compiled into a graph you can traverse, mass-update and build dashboards on.
02
How it works
Procedures written in plain Markdown, not prompt fragments buried in a config. Readable by the people who own the process, reviewable in a diff, portable to any runtime.
03
What it may do
Tool manifests with secrets held in a vault, and access rules that say which agent may read which file and call which endpoint. Changes go through review, like everything else.
04
Who it acts as
Each agent is a named actor with its own credentials and its own scope, not a shared service account. Every action it takes is attributable to it.
A company whose agents live inside a vendor's product doesn't own its agents.
Today context, tools, skills and permissions live inside a vendor's harness: instructions in the vendor's config, tool wiring in per-vendor connector panels, knowledge in per-vendor grounding stores, and the hard-won lessons scattered across chat logs nobody reads and no other agent can inherit. Switchover is extremely costly.
Where it lives today
Where it lives with Bevel (all within your infrastructure)
Your repo is the source of truth. Every runtime reads from it.
Your repository
your-company/ ├─ knowledge/ │ ├─ customers/… │ └─ processes/… ├─ skills/ │ ├─ qualify-supplier.md │ └─ draft-rfi-response.md ├─ tools/ │ ├─ salesforce.yaml │ └─ sharepoint.yaml ├─ agents/ │ └─ tender-desk.yaml └─ access/ └─ policy.yaml
Plain Markdown and YAML. Branches, change requests and diffs are git's, not features we rebuilt.
Any agent runtime
Agents connect and read exactly what they're permitted to read. One-click setup for the tools your employees already use, and the same governed surface for anything running unattended.
Working with
Supported by
What our customers say.
Built by the team behind UTCP and the first ever library for Code Mode (Code Execution for Tool Calling).
We build at the protocol layer this depends on.
Our team created the Universal Tool Calling Protocol, an open alternative to Anthropic's Model Context Protocol, championed by engineers at AWS, Adobe, Royal Bank of Canada and MuleSoft. It is what lets every capability in Bevel be exposed as a plain HTTP endpoint, with no proxy server in the middle. Our CodeMode library is what lets agents chain those tools through code instead of one call at a time.
Specification
utcp.io
The protocol, its docs, and how to describe tools you already have.
Source
GitHub
Reference implementations and SDKs, open source.
Library
CodeMode
Tool-chaining through code execution rather than one call at a time.
Thank you very much for building UTCP. It's incredibly helpful for multi-tenant agentic AI applications, where MCP isn't always the best fit. I was actually reverting MCP servers back to hardcoded tool descriptions for my agentic AI systems when I came across UTCP, and I think it's fantastic to finally have a universal standard for this. I fully support UTCP, as I see big value in it for building scalable, multi-tenant AI applications.
UTCP is a great addition to the agent-tooling space as an alternative to MCP. What I appreciate about UTCP is that it doesn't ask you to rebuild anything. You describe the tools you already have, and agents call them natively, with no proxy server in the middle, no extra hop to operate and secure. It turns “integrate AI with our APIs” from a project into a description.
Git-backed control plane for enterprise AI agents