REGISTRY

Defining what can exist and execute

Defining what can exist and execute

The Waxell Registry is the system of record for governed AI agent execution — a central inventory of every agent, workflow, and tool permitted to run, referenced by identity rather than copied into code, and the foundation on which Waxell's policy enforcement and observability operate.

The Registry is Waxell's system of record for every agent, workflow, and tool in your system. Before anything can run, it must be registered. Before any tool can be called, it must be known.


In a governed system, execution is not ad hoc. Every component has an identity. Every call traces back to a registered definition. Governance, observability, and policy enforcement all depend on that boundary being explicit.

Free during beta. 2-line setup.

Why Does an AI Agent Registry Matter in Production?

Why Does an AI Agent Registry Matter in Production?

Why Does an AI Agent Registry Matter in Production?

As agentic systems grow, the hardest problem is not generating outputs. It is knowing what is actually running — whether execution matches what teams believe the system is doing.


The Registry closes that gap. The Registry makes execution structure explicit, inspectable, and enforceable rather than inferred.

What Does Waxell Register?

Waxell registers three kinds of components, in a fixed hierarchy:


Agents own execution. They are the top-level entities in Waxell's governance model — the things that have identities, accumulate cost, and are subject to policy.


Workflows define how execution is structured inside an agent. An agent may contain one or more workflows.


Tools are atomic operations — the points where data changes or external systems are called. Tools exist only as part of a workflow; they cannot be called directly.


This hierarchy is not a design convention. It is enforced. Components that don't fit the structure can't participate in governed execution.

How Does Waxell's Registry Work?

How Does Waxell's Registry Work?

The Registry is a first-class system of record in Waxell's governance plane — not a configuration file.


Components are defined centrally and referenced by identity. Execution always refers back to a single authoritative definition — there are no local copies embedded inside agents or workflows. When a definition changes, the change propagates consistently across every workflow that references it.


Teams do not have to reason about which version of a component is actually running.

The Code Reality DAG

For every registered workflow, Waxell derives a Code Reality DAG — a structural representation of execution derived directly from live code.


This is not a diagram you draw. It is not a modeled plan or a design-time artifact. The Code Reality DAG is derived from the actual code that defines the workflow, and it reflects the execution structure as it exists in the system right now — not as it was intended to exist when the workflow was written.


Most teams operate agent systems based on design intent. They know how a workflow is supposed to behave and which tools it is supposed to use. The Code Reality DAG makes it possible to verify that. Expected execution structure and observed execution structure can be compared directly. Drift becomes visible instead of silent.


Execution behavior — what agents actually do when they run — is captured through Waxell Observe.

Most teams find out their execution structure drifted when something breaks. The Code Reality DAG surfaces it before that — derived from live code, updated automatically, no diagrams to maintain.

The Code Reality DAG

For every registered workflow, Waxell derives a Code Reality DAG — a structural representation of execution derived directly from live code.


This is not a diagram you draw. It is not a modeled plan or a design-time artifact. The Code Reality DAG is derived from the actual code that defines the workflow, and it reflects the execution structure as it exists in the system right now — not as it was intended to exist when the workflow was written.


Most teams operate agent systems based on design intent. They know how a workflow is supposed to behave and which tools it is supposed to use. The Code Reality DAG makes it possible to verify that. Expected execution structure and observed execution structure can be compared directly. Drift becomes visible instead of silent.


Execution behavior — what agents actually do when they run — is captured through Waxell Observe.

Most teams find out their execution structure drifted when something breaks. The Code Reality DAG surfaces it before that — derived from live code, updated automatically, no diagrams to maintain.

What Does the Registry Mean for MCP and Tool Access?

In an ungoverned system, agents can potentially call any tool they discover — including tools added or modified after the agent was deployed.


Waxell's Registry closes that surface. Only registered tools can be called. Every tool has an identity, every call traces back to a known definition, and changes to tool definitions are versioned and explicit.


For agent systems that access external tools — including through MCP — with the Registry, the set of callable tools is always bounded and auditable. Unregistered tools cannot participate in execution — and every registered tool is subject to Waxell's policy enforcement.

Ownership and change management

Registry entries are managed deliberately.


Agents, workflows, and tools are versioned explicitly and referenced by identity. Changes to definitions update the execution structure they produce.


Because execution refers to registered components rather than embedded definitions, updates do not introduce silent drift or inconsistency.

Ownership and change management

Ownership and change management

Registry entries are managed deliberately.


Agents, workflows, and tools are versioned and referenced by identity. Changes to definitions update the execution structure they produce. Because execution refers to registered components rather than embedded definitions, updates don't introduce silent drift or inconsistency across the system.


Changes are explicit. Their effects are traceable.

POLICY A

POLICY B

POLICY C

POLICY D

Designed to scale

Centralized, reference-based policies scale cleanly across workflows, teams, and environments.


They are suitable for systems where execution is continuous, changes are expected, and governance must remain consistent over time.


Policies do not become harder to manage as automation expands. They become more important.

CallSine automatically finds and researches each prospect by analyzing their website, LinkedIn profile, and company information. Get comprehensive insights instantly without spending hours on manual research. It even works with your existing database.

From here

Waxell is available now.


Install the SDK, connect to your instance, and start capturing what your agents actually do. Governance, policy enforcement, cost tracking, and full telemetry — running from the moment you initialize.

Free during beta. 2-line setup.

From here

Waxell is available now.


Install the SDK, connect to your instance, and start capturing what your agents actually do. Governance, policy enforcement, cost tracking, and full telemetry — running from the moment you initialize.

Free during beta. 2-line setup.

FAQ

What is an AI agent registry?

An AI agent registry is a system of record that defines which agents, workflows, and tools are permitted to exist and execute in a governed system. Rather than allowing ad hoc execution, a registry requires every component to be registered and identified before it can participate in a workflow. Waxell's Registry enforces this boundary — unregistered components cannot execute, and every call traces back to a known, versioned definition.

What is the Waxell Code Reality DAG?

The Code Reality DAG is a structural representation of a workflow derived directly from live code — not a drawn diagram or a design-time artifact. It reflects the actual execution structure of a workflow as it currently exists in the system. Teams use the Code Reality DAG to compare expected execution structure against actual execution structure, making drift visible before it causes failures in production.

How does Waxell's Registry support MCP tool governance?

In a system using Model Context Protocol, agents access external tools at runtime. Without a registry, the set of callable tools is implicit and unauditable. Waxell's Registry requires every tool — including MCP tools — to be registered and identified before it can be called. The set of callable tools is always bounded, every call is traceable to a known definition, and changes to tool access are explicit and versioned.

Can existing agents be registered in Waxell without being rebuilt?

Yes. Waxell instruments existing Python agents in two lines of code — install the SDK, initialize before your imports, and agents are registered and governed automatically. Waxell is framework-agnostic and works with LangChain, CrewAI, LlamaIndex, and custom Python agents. No changes to existing agent logic are required.

How does the Registry prevent unauthorized tools from executing?

Waxell's Registry enforces a strict execution boundary: only registered tools can be called as part of a workflow. Tools cannot be invoked directly — they exist only as part of a registered workflow. This means any tool added after deployment, or any tool not associated with a known workflow identity, cannot execute. The boundary is structural, not rule-based.

Waxell

Waxell provides observability and governance for AI agents in production. Bring your own framework.

© 2026 Waxell. All rights reserved.

Patent Pending.

Waxell

Waxell provides observability and governance for AI agents in production. Bring your own framework.

© 2026 Waxell. All rights reserved.

Patent Pending.

Waxell

Waxell provides observability and governance for AI agents in production. Bring your own framework.

© 2026 Waxell. All rights reserved.

Patent Pending.