DEV Community

Cover image for AI Runtime That Gains New Abilities Without New Integrations
Ross
Ross

Posted on

AI Runtime That Gains New Abilities Without New Integrations

#ai #mcp #agents #api

I Built an AI Runtime That Gains New Abilities Without New Integrations

What if installing software could give your AI a new ability — without anyone building another MCP server, plugin, connector, or provider-specific tool?

There is something about the current AI agent ecosystem that has been bothering me.

We keep making agents more intelligent.

Then we give them abilities in one of the least scalable ways imaginable.

Want the agent to use GitHub?

Build a GitHub integration.

Want Slack?

Another integration.

Want a database?

Another integration.

A new SaaS product?

Another connector.

A new internal API?

More tools.

And eventually the agent ends up staring at an enormous catalogue of things like:

github_create_issue
github_merge_branch
slack_send_message
notion_create_page
jira_update_ticket
...
Enter fullscreen mode Exit fullscreen mode

That works.

But I started wondering whether we're solving the problem at the wrong layer.

What if the agent didn't need to know the provider?

What if instead we could say:

software/service appears
        ↓
its capabilities are discovered
        ↓
those capabilities are normalised
        ↓
the AI can inspect them
        ↓
authority and policy are applied
        ↓
the capability executes
        ↓
the outcome is independently verified
Enter fullscreen mode Exit fullscreen mode

No new AI integration.

No permanent provider-specific tool.

No rebuilding the agent.

That experiment became RIGHTCLICK.

RIGHTCLICK is an open-source dynamic capability runtime for AI.

And the idea behind it is simple:

Software appears. Your AI learns what it can safely do.

The integration problem gets ugly surprisingly quickly

MCP has been a huge step forward.

It gives models a standard way to communicate with external capabilities.

RIGHTCLICK actually speaks MCP.

But I think there is another problem sitting above the transport layer.

MCP helps answer:

How can an AI call this tool?

There is another question:

How did the AI acquire that capability in the first place?

Today, the answer is usually some variation of:

provider
    ↓
developer builds integration
    ↓
integration exposes tools
    ↓
agent receives those tools
Enter fullscreen mode Exit fullscreen mode

RIGHTCLICK experiments with a different model:

provider
    ↓
provider exposes a capability contract
    ↓
RIGHTCLICK discovers it
    ↓
RIGHTCLICK reflects it
    ↓
capability enters a live graph
    ↓
agent uses the same interface it already had
Enter fullscreen mode Exit fullscreen mode

The provider changes.

The capability changes.

The environment changes.

The model-facing interface does not.

Seven operations

The entire RIGHTCLICK agent interface is deliberately small.

context_runtime
context_inspect
context_actions
context_explain
context_run
context_run_status
context_providers
Enter fullscreen mode Exit fullscreen mode

That's it.

The goal is that adding a new provider should not mean adding a new top-level AI tool.

OpenAPI operation?

context_run.

GraphQL operation?

context_run.

Native application capability?

context_run.

A capability exposed by another RIGHTCLICK runtime?

Still context_run.

The provider protocol becomes an implementation detail behind a common capability model.

That invariant is probably the most important part of the project.

The first experiment surprised me

One of the earliest tests involved BBEdit on macOS.

The question was simple:

Could installing an ordinary application cause an AI to gain new capabilities without writing BBEdit-specific acquisition code?

Before installation:

36 capabilities
0 third-party capabilities
Enter fullscreen mode Exit fullscreen mode

After installation:

41 capabilities
5 BBEdit capabilities
Enter fullscreen mode Exit fullscreen mode

BBEdit-specific RIGHTCLICK acquisition code added:

0
Enter fullscreen mode Exit fullscreen mode

That was the moment the project became much more interesting to me.

Because the important result wasn't “RIGHTCLICK supports BBEdit”.

That would just be another integration.

The interesting result was:

The environment changed, so the capability graph changed.

That's a very different architecture.

Then I started applying the same idea to APIs

Native application discovery is only one capability substrate.

RIGHTCLICK has since been extended to reflect supported capabilities from things including:

macOS capability contracts
OpenAPI
GraphQL
gRPC reflection
ARD-discovered capability artifacts
other RIGHTCLICK runtimes
Enter fullscreen mode Exit fullscreen mode

Each substrate has its own discovery mechanism.

But once reflected, the capabilities enter the same runtime.

Conceptually:

                    ┌───────────────┐
                    │      AI       │
                    └───────┬───────┘
                            │
                    seven operations
                            │
                            ▼
                    ┌───────────────┐
                    │  RIGHTCLICK   │
                    └───────┬───────┘
                            │
                    capability graph
                            │
          ┌─────────┬───────┼───────┬──────────┐
          │         │       │       │          │
        macOS    OpenAPI  GraphQL  gRPC    federation
          │         │       │       │          │
          └─────────┴───────┼───────┴──────────┘
                            │
                            ▼
                     Capability ABI
                            │
                            ▼
                          policy
                            │
                          authority
                            │
                         execution
                            │
                        observation
                            │
                       verification
Enter fullscreen mode Exit fullscreen mode

And this matters for another reason.

It means discovery mechanisms can also evolve independently.

Bonjour can discover something.

ARD can discover something.

A registry could discover something.

An enterprise service catalogue could discover something.

A future protocol could discover something we haven't invented yet.

Those systems don't have to become the architecture.

They're just ways of finding capability contracts.

Then RIGHTCLICK used RIGHTCLICK

This is probably my favourite experiment so far.

While developing RIGHTCLICK, I needed to modify the RIGHTCLICK GitHub repository.

Instead of adding:

github_merge_branch
Enter fullscreen mode Exit fullscreen mode

as another permanent AI tool, RIGHTCLICK reflected the GitHub API generically.

The runtime discovered a capability equivalent to:

Merge a branch
Enter fullscreen mode Exit fullscreen mode

with structured arguments including:

owner
repo
base
head
commit_message
Enter fullscreen mode Exit fullscreen mode

The AI still invoked it through:

context_run
Enter fullscreen mode Exit fullscreen mode

RIGHTCLICK then called GitHub.

GitHub returned:

HTTP 201
Enter fullscreen mode Exit fullscreen mode

And this is where another important design decision appears.

RIGHTCLICK did not call that success.

It recorded that GitHub had accepted the request.

Then a separate repository read checked whether the expected branch state actually existed.

Only the observation of the resulting state established the outcome.

So the real flow was:

discover GitHub operation
        ↓
reflect capability
        ↓
resolve authority
        ↓
context_run
        ↓
GitHub: HTTP 201
        ↓
ACCEPTED — not yet verified
        ↓
independent repository observation
        ↓
expected state exists
        ↓
VERIFIED
Enter fullscreen mode Exit fullscreen mode

There was still no github_merge_branch top-level RIGHTCLICK tool.

GitHub was simply another capability provider.

That is RIGHTCLICK dogfooding its own architectural thesis.

HTTP 200 is not the same thing as success

This became another core principle.

Agents routinely receive a successful transport response and assume the job has been completed.

But these statements are not equivalent:

the request was sent

the provider accepted it

something changed

the requested thing changed

the requested outcome is true
Enter fullscreen mode Exit fullscreen mode

RIGHTCLICK therefore separates states including:

CAPABILITY EXISTS

CAPABILITY APPLIES

AUTHORITY IS AVAILABLE

CONFIRMATION IS REQUIRED

PROVIDER ACCEPTED REQUEST

REQUESTED OUTCOME VERIFIED
Enter fullscreen mode Exit fullscreen mode

The distinction might sound pedantic.

For autonomous systems it is not.

Imagine:

"Delete the old deployment"

"Transfer £500"

"Update the production record"

"Merge the release branch"

"Create the customer account"
Enter fullscreen mode Exit fullscreen mode

A 200 OK tells you remarkably little about whether the user's actual objective is now true.

Discovery must not equal authority

There is an obvious danger with dynamic capability discovery.

If an agent can suddenly discover new things it can do, you absolutely do not want discovery itself to confer permission.

RIGHTCLICK therefore treats discovery and authority as separate boundaries.

The model might discover:

Delete resource
Enter fullscreen mode Exit fullscreen mode

That does not mean the model automatically receives permission to delete it.

Similarly, credentials do not need to become arguments passed through the model.

Where supported, authority can be resolved below the model-facing capability contract and bound to the execution origin.

Conceptually:

MODEL
  │
  │ "invoke capability X"
  ▼
RIGHTCLICK
  │
  ├── capability contract
  ├── local policy
  ├── confirmation
  ├── authority resolution
  └── execution
Enter fullscreen mode Exit fullscreen mode

The capability tells the agent what could be done.

The runtime determines whether it may be done.

Those need to remain different concepts.

The runtime is also beginning to learn — carefully

A capability runtime becomes more interesting if it can benefit from previous experience.

But this creates another dangerous shortcut:

“It worked last time, therefore skip the checks.”

RIGHTCLICK explicitly doesn't do that.

Its current experience mechanism can retain bounded observations associated with freshly discovered capability contracts.

Things like:

accepted but unverified
predicates verified
failed
unknown
Enter fullscreen mode Exit fullscreen mode

But that history is advisory.

It cannot:

invent a capability

resurrect a capability that disappeared

grant authority

skip confirmation

replace fresh verification

change execution routing
Enter fullscreen mode Exit fullscreen mode

And importantly, the experience store isn't designed to retain credentials or raw execution payloads.

I think this distinction will become increasingly important in agent infrastructure.

There is a huge difference between:

learning from experience

and:

allowing historical experience to become authority

The first is useful.

The second can become terrifying very quickly.

So what exactly is RIGHTCLICK trying to become?

Not a bigger collection of integrations.

That's the trap I'm specifically trying to avoid.

The north star is closer to a universal capability runtime.

An agent enters an environment.

It has a small stable interface.

Then:

application installed
        ↓
new capabilities appear

API becomes available
        ↓
new capabilities appear

GraphQL service appears
        ↓
new capabilities appear

gRPC service becomes discoverable
        ↓
new capabilities appear

another runtime becomes reachable
        ↓
capability graph expands
Enter fullscreen mode Exit fullscreen mode

The AI shouldn't need to be rebuilt every time.

It shouldn't need thousands of permanent provider-specific tools loaded into its context either.

Instead, it can ask:

What can this environment do right now?

That feels much closer to how operating systems work.

Applications don't need the kernel rebuilt whenever new hardware is attached.

Browsers don't need their core rewritten for every website.

Compilers don't need a different programming language for every CPU instruction.

Those systems create abstractions between layers.

AI agents need better abstractions too.

Where ARD fits

Agentic Resource Discovery is especially interesting in this context.

But I don't think discovery itself should become the runtime.

In RIGHTCLICK's architecture, ARD can be a source of capability artifacts:

ARD
  ↓
discover compatible capability contract
  ↓
RIGHTCLICK reflector
  ↓
normalised capability
  ↓
same authority / execution / verification runtime
Enter fullscreen mode Exit fullscreen mode

So ARD can dramatically widen what an agent can find without forcing the rest of the system to become ARD-specific.

That distinction matters.

Discovery is an input.

It doesn't have to define the execution architecture.

What exists today

This isn't just a whitepaper.

The current RIGHTCLICK release line includes work around:

  • OpenAPI capability reflection
  • GraphQL capability reflection
  • gRPC capability reflection
  • Bonjour discovery
  • universal capability artifact resolution
  • ARD registry acquisition
  • MCP federation
  • OAuth/OIDC authority support
  • origin-bound authority handling
  • independent outcome verification
  • capability experience
  • a provider-independent Capability ABI foundation

The current v0.2.2 release acceptance recorded:

411 tests
26 skipped
0 failures
Enter fullscreen mode Exit fullscreen mode

The project is open source under Apache-2.0.

And it can be installed through Homebrew:

brew install rossbuckley1990-hash/tap/rightclick
Enter fullscreen mode Exit fullscreen mode

Then:

rightclick version
rightclick doctor
rightclick providers
Enter fullscreen mode Exit fullscreen mode

Or expose the runtime to an MCP client:

rightclick mcp
Enter fullscreen mode Exit fullscreen mode

What does not exist yet

This part is important.

RIGHTCLICK is not currently a universal production runtime for every operating system and every software contract.

The released runtime currently targets:

Apple Silicon
macOS 14+
Enter fullscreen mode Exit fullscreen mode

Not every OpenAPI shape is supported.

Not every application exposes something RIGHTCLICK can reflect.

Unsupported or ambiguous contracts should abstain rather than being guessed into existence.

The project also contains architecture work toward stronger typed capability contracts, leases, policy and verification boundaries that should not be confused with finished security certification.

And a portable capability representation does not magically mean the complete runtime is already portable across Linux, Windows and macOS.

I'd rather preserve those boundaries than turn a promising architecture into a collection of unprovable claims.

The bigger question

The project has left me with a question that I think is much more interesting than RIGHTCLICK itself:

Should AI agents have integrations at all?

Or, more precisely:

Should every capability require somebody to build an AI-specific integration?

Perhaps software should expose machine-readable capability contracts.

Perhaps agents should discover them.

Perhaps a runtime should normalise them.

Perhaps authority should be granted independently.

Perhaps execution should happen through a common ABI.

Perhaps outcomes should be verified independently.

And perhaps the agent should never care whether the capability originated from:

GitHub

Photoshop

an internal API

GraphQL

gRPC

a desktop application

a local service

a cloud service

another agent runtime
Enter fullscreen mode Exit fullscreen mode

It should care about the capability contract.

Not the brand.

The design rule I'm using

I've ended up with a fairly brutal rule when considering new RIGHTCLICK functionality.

A new integration is interesting only if it teaches the runtime a class of capability.

Not one provider.

Good:

"RIGHTCLICK can now safely reflect this category of GraphQL operation."
Enter fullscreen mode Exit fullscreen mode

Good:

"RIGHTCLICK can now resolve this generic authentication scheme."
Enter fullscreen mode Exit fullscreen mode

Good:

"RIGHTCLICK can now discover this class of capability artifact."
Enter fullscreen mode Exit fullscreen mode

Much less interesting:

"RIGHTCLICK now has 47 custom GitHub tools."
Enter fullscreen mode Exit fullscreen mode

Every provider-specific special case makes the demo larger.

Every generic capability primitive makes the architecture larger.

I want the second.

Try to break it

RIGHTCLICK is open source:

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

I'm particularly interested in people working on:

  • MCP
  • ARD
  • agent runtimes
  • capability security
  • OpenAPI
  • GraphQL
  • gRPC
  • authorization
  • agent verification
  • tool discovery
  • operating-system abstractions
  • autonomous software

Don't just star it.

Try an environment I haven't tried.

Give it a capability substrate it doesn't understand.

Find an authority boundary that's wrong.

Find somewhere provider acceptance is being confused with actual success.

Or propose a way for an entirely new family of software to become discoverable without adding another provider-specific AI tool.

Because if the core thesis is right, the end state shouldn't be:

“We built every integration an AI could ever need.”

It should be:

“We stopped needing to.”

Top comments (0)