Agent Registries Are Not Decision Infrastructure

The next layer of the agent stack is becoming visible.

Not models. Not prompts. Not tools.

Registries.

AWS made its MCP Server generally available, giving coding agents secure, auditable access to AWS services through MCP, IAM guardrails, CloudWatch metrics, CloudTrail logging, sandboxed scripts, and Agent Skills. AWS and Cisco described an AI Registry for MCP servers, A2A agents, and Skills, with unified discovery, security scanning, disabled states, and audit history. Anthropic acquired Stainless, explicitly tying SDKs, CLIs, and MCP server tooling to the reach of agents. Salesforce is now saying the quiet part directly: agents do not just answer; they act.

This is the right direction. Agent sprawl is real. Tool sprawl is real. MCP servers, A2A agents, and Skills cannot remain scattered across Slack threads, local config files, and undocumented team conventions.

But registries solve a different problem than most teams think they solve.

An agent registry can tell you what exists.

It cannot prove that a proposed action is valid.

Discovery is not authority

An agent registry answers operational questions:

• Which MCP servers are available?
• Which agents are registered?
• Which Skills can be loaded?
• Which components were scanned?
• Which assets are disabled, pending review, or approved?
• Which team owns a tool or agent?

That matters. Without a registry, enterprise agent infrastructure becomes invisible. Security teams cannot review what they cannot see. Platform teams cannot govern components they cannot inventory. Compliance teams cannot audit assets that were never registered.

But discovery is not authority.

Knowing that a refund tool exists does not mean this refund is allowed. Knowing that a CRM update agent passed a security scan does not mean this account should be updated. Knowing that a Skill is approved does not mean its procedure applies to this customer, contract, jurisdiction, date, or exception.

The registry establishes that a component is known.

The decision still needs to be validated.

That validation happens at a different layer: decision infrastructure.

Scanning is not applicability

Security scanning is necessary. It catches real risks: malicious MCP servers, prompt injection in agent metadata, hardcoded credentials, exfiltration endpoints, schema abuse, vulnerable Skills, and suspicious communication patterns.

The AWS and Cisco registry pattern is valuable because it moves security review from manual bottleneck to automated control. A new MCP server or A2A agent can be scanned before it becomes available. If the scanner finds a serious issue, the asset can be disabled until an administrator reviews it.

That is a strong supply-chain control.

It is not applicability logic.

Applicability asks a different set of questions:

• Does this policy apply to this customer segment?
• Is this pricing rule still effective today?
• Does this contract contain an override?
• Is the requester inside the right scope?
• Has a newer approval superseded the old one?
• Is the agent allowed to execute this action now, given the current state?

A scanner evaluates a component. Applicability evaluates a proposed decision.

That distinction is structural. A component can be safe in general and wrong in a specific case. A tool can be approved and still be invalid for this workflow. A Skill can be well written and still apply to the wrong jurisdiction.

Registries govern inventory. Context graphs govern applicability.

Control planes still need decision boundaries

The market is converging on the language of control planes. That is useful. Enterprises need a place to manage identity, lifecycle, access, deployment, discovery, monitoring, and security state across agent fleets.

But an agent control plane is not the same as a decision context graph.

A control plane manages the agent estate.

A decision context graph validates the action the agent is about to take.

The difference becomes obvious in a sales workflow. Imagine an agent that drafts a discount approval email. The CRM connector is registered. The pricing Skill is approved. The email agent is known to the control plane. The MCP server passed its scanner. The agent has permission to read the account and write the draft.

Everything looks governed.

Then the agent offers a 15 percent discount to an account already below margin threshold.

The registry did its job. The component was known. The tool was approved. The agent was visible. The logs exist.

The decision still failed.

Salesforce uses a similar margin-policy example to argue that governed data and policy checks must run before the agent responds. That is the real boundary. Not whether the agent can reach the system. Whether the proposed action survives pre-execution enforcement.

This is where registries and context graphs should be composed, not confused.

The missing handoff

The registry should answer:

This agent may use this tool.

The context graph should answer:

This action is valid for this entity, under these policies, at this time, with this evidence.

The handoff between the two layers is the architectural gap.

When an agent chooses a tool, the registry can verify that the tool is approved, scanned, and available. Before the tool call executes, the proposed action should be converted into a decision request:

• actor
• target entity
• intended action
• affected systems
• policy scope
• retrieved evidence
• current state
• expected side effect

That request is evaluated against the context graph. The graph traverses policies, contracts, account state, temporal validity, exception records, approval history, and scope bindings. It returns a deterministic allow, block, or escalate outcome. It also emits a causal decision trace.

Now the registry and the graph are doing different jobs cleanly.

The registry makes the agent estate governable.

The graph makes the decision accountable.

This is the pattern Rippletide is built around: not replacing the operational control plane, but adding the decision substrate that proposed actions must cross before execution.

The category mistake to avoid

The enterprise agent stack is maturing fast. MCP solved a large part of the connection problem. A2A creates a vocabulary for agent-to-agent coordination. Skills give agents curated procedural knowledge. Registries make those assets discoverable, reviewable, and scannable.

All of that is infrastructure.

None of it is decision validity.

The category mistake is treating inventory governance as decision governance. It feels safer because there is a dashboard. It feels auditable because the component has metadata. It feels controlled because the server was scanned and the agent was registered.

But production failures do not only come from unknown tools. They come from known tools used in the wrong context.

The next serious agent architecture will have both layers:

• an agent registry or control plane for inventory, lifecycle, access, scanning, and operational governance
• a decision context graph for applicability, temporal validity, scope isolation, policy enforcement, exception handling, and causal traces

Without the first, the agent estate becomes invisible.

Without the second, visible agents still make invalid decisions.

That is the line teams need to draw now. Agent registries are necessary. They are not enough.

The Context Graph publishes technical memos on production agent reliability, decision infrastructure, and governed context. Start with the context graph glossary for the canonical vocabulary behind accountable agents.