ARD Solves Discovery. But What Happens After Your AI Finds the Tool?

Agentic Resource Discovery may solve one of the biggest scaling problems facing AI agents:

How does an agent find a capability nobody explicitly installed for it?

That's a much bigger problem than it sounds.

Today we usually give an agent abilities by wiring things into it:

GitHub integration
Slack integration
database integration
MCP server
another MCP server
another tool
another connector

That works when an agent has ten capabilities.

It gets much less convincing when the future contains millions.

ARD proposes a much better discovery model.

Instead of pre-installing every possible capability, an agent can search for an appropriate agentic resource at runtime.

That resource might be:

an MCP server
an API
a Skill
another agent
a workflow
some future capability type

This is important enough that Google, Microsoft, GitHub, Hugging Face and others are actively contributing around the emerging specification.

But something about the architecture caught my attention.

The official ARD documentation makes its boundary explicit:

ARD sits before invocation.

It discovers the resource.

Then that resource is invoked using its native mechanism.

And that leaves a fascinating second problem.

Finding a capability is not the same as safely acquiring an ability

Imagine an agent searches for:

"Create a release branch in this repository."

Discovery might tell us:

Here is a suitable resource.
Here is its contract.
Here is its endpoint.
Here is its publisher.

Excellent.

Now what?

The agent still needs answers to a different collection of questions.

How do I understand this contract?

How do I execute it?

Who grants authority?

What exactly did the user approve?

Should the model ever see the credential?

What if execution redirects somewhere else?

What does success mean?

How do I prove the requested state actually changed?

Those aren't primarily discovery problems.

They're runtime problems.

I've been building an open-source experiment around exactly that boundary.

It's called RIGHTCLICK.

And the hypothesis behind it is:

Discovery should be able to change what an AI can do without changing the interface through which the AI does it.

What if the agent never received a GitHub tool?

Consider GitHub.

The normal agent integration model might eventually expose:

github_create_issue
github_update_issue
github_create_branch
github_merge_branch
github_create_release
github_comment_on_pr
...

And then we repeat the same thing for every provider.

RIGHTCLICK tries to invert that model.

The model gets a deliberately small generic interface.

context_runtime
context_inspect
context_actions
context_explain
context_run
context_run_status
context_providers

Capabilities can then arrive from different substrates behind it:

OpenAPI
GraphQL
gRPC
native application contracts
ARD
other RIGHTCLICK runtimes
...

They are reflected into a common capability model.

The protocol can change.

The provider can change.

The available software can change.

The model-facing interface doesn't have to.

So I made RIGHTCLICK use this model on RIGHTCLICK

Architecture diagrams are easy to draw.

I wanted a much less comfortable test.

Could RIGHTCLICK modify its own GitHub repository through a dynamically reflected capability — without adding a GitHub-specific tool for the action?

The runtime reflected GitHub's API.

It discovered a capability equivalent to:

Merge a branch

Its structured contract required values such as:

owner
repo
base
head
commit_message

The agent did not receive:

github_merge_branch

It still used:

context_run

RIGHTCLICK resolved the required authority at the execution boundary and invoked GitHub.

GitHub responded:

HTTP 201

And RIGHTCLICK deliberately did not call the operation successful.

It called it accepted.

Because this:

HTTP 201

does not logically prove this:

the user's requested repository state now exists

So a separate repository observation checked the resulting branch state.

Only after the state was independently observed could the outcome be treated as verified.

The resulting execution model looked like this:

ARD / discovery source
        ↓
capability found
        ↓
contract reflected
        ↓
normalized capability
        ↓
policy
        ↓
authority
        ↓
context_run
        ↓
provider accepts request
        ↓
independent observation
        ↓
verified outcome

The interesting result wasn't:

An AI merged a branch on GitHub.

Agents can already do that.

The interesting result was:

The AI gained the ability without RIGHTCLICK gaining a permanent github_merge_branch AI tool.

GitHub became another provider behind the capability runtime.

ARD and RIGHTCLICK therefore solve different halves of the problem

This is how I currently think about the stack.

                     USER INTENT
                          │
                          ▼
                 ┌────────────────┐
                 │      ARD       │
                 │    discovery   │
                 └───────┬────────┘
                         │
                  resource found
                         │
                         ▼
                 ┌────────────────┐
                 │   RIGHTCLICK   │
                 │     runtime    │
                 └───────┬────────┘
                         │
                    reflection
                         │
                    capability ABI
                         │
                      policy
                         │
                     authority
                         │
                     execution
                         │
                    observation
                         │
                   verification
                         │
                         ▼
                  VERIFIED STATE

ARD asks:

What resource exists that could help with this task?

RIGHTCLICK asks:

How does that resource become a capability this agent can safely execute and reason about without adding another provider-specific interface?

They aren't competing abstractions.

They fit together remarkably naturally.

Discovery cannot be permission

There's an uncomfortable implication to dynamic discovery.

If agents can discover new capabilities at runtime, then the set of things they know how to do can change while they're operating.

That makes one separation absolutely critical:

DISCOVERED
    ≠
AUTHORIZED

Finding:

Delete production database

does not grant permission to invoke it.

Likewise:

capability exists
capability applies
authority available
user approved
provider accepted
outcome verified

are six different facts.

A trustworthy runtime has to resist collapsing them into one Boolean called:

success = true

HTTP 200 is a surprisingly dangerous abstraction

This has become one of my favourite problems in agent systems.

Suppose an agent requests:

Create the customer account.

The API responds:

200 OK

What have we actually proved?

Maybe:

the request reached the provider

Possibly:

the provider accepted it

But not necessarily:

the customer account now exists correctly

That distinction becomes increasingly important as agents move from answering questions to changing durable state.

For consequential operations, I think the stack increasingly needs:

ACTION
   ↓
ACKNOWLEDGEMENT
   ↓
OBSERVATION
   ↓
POSTCONDITION
   ↓
VERIFIED OUTCOME

rather than:

ACTION
   ↓
200
   ↓
🎉

And the runtime should be able to learn — without learning permission

I've also started experimenting with procedural experience.

If a capability was encountered before, the runtime can retain bounded observations about what happened.

For example:

accepted but unverified
verification predicates passed
failed
unknown

But RIGHTCLICK deliberately prevents that history from becoming authority.

Previous experience cannot:

create a missing capability

resurrect a stale capability

grant credentials

skip user confirmation

change execution routing

replace fresh verification

I think this distinction is going to matter enormously.

Agents need memory.

Agents need procedural knowledge.

But:

“I have seen this before” must never silently become “I am allowed to do this.”

This starts to look less like an integration framework

The more I've built this, the less useful the word "integration" has felt.

The long-term model looks closer to an operating-system abstraction:

environment changes
        ↓
capabilities appear/disappear
        ↓
runtime discovers contracts
        ↓
contracts become typed capabilities
        ↓
policy determines admissibility
        ↓
authority is bound
        ↓
agent executes
        ↓
runtime observes
        ↓
outcome is verified

If a compatible application appears:

the agent gains an ability.

If an API comes online:

the agent gains an ability.

If ARD discovers a previously unknown resource:

the capability graph gets larger.

Without teaching the model another provider-specific language.

The question I'm now interested in

MCP gave us a standard interface for communicating with external capabilities.

ARD is tackling how agents discover those capabilities at ecosystem scale.

The next question may be:

What is the operating system between discovery and action?

Who normalizes all these foreign contracts?

Who owns policy?

Who holds authority?

Who binds approval to execution?

Who determines whether the action actually achieved what was requested?

And can we solve those problems once rather than rebuilding them independently for every provider?

That's the experiment behind RIGHTCLICK.

It's open source:

https://github.com/rossbuckley1990-hash/rightclick

I don't particularly want more provider integrations.

I'd rather find capability classes the runtime cannot yet understand.

If you're working on ARD, MCP, A2A, authorization, agent runtimes, capability security, OpenAPI, GraphQL or gRPC, try to break the architecture.

Because I think the agent ecosystem may be heading toward a stack that looks something like this:

Discovery
    ↓
Capability Runtime
    ↓
Authority
    ↓
Execution
    ↓
Verification

And if that's right, the endgame isn't:

Build an integration for everything.

It's:

Make integration itself disappear.