The Bull and the Missing Hay

The bull has a good pasture. The water is clean, the fence is sturdy, and the farmer delivers several excellent kinds of hay. But the one bale it needs today is sitting just outside its tether. The bull can see the hay. It simply cannot reach it.

This is one way to think about AI tool integration catalogs. Different AI assistants offer different collections of partner connections and built-in capabilities. The availability of a tool may depend on which assistant you happen to be using, rather than on whether you own an account with that service.

The question hiding inside the joke

What if the connection belonged to the user rather than the assistant? A person might authorize access to a repository, a calendar, or a local device once, then give multiple compatible AI harnesses narrowly scoped access to that capability.

That is the proposed role of Peasant Bridge: an independent layer that describes available tools, maps their interfaces across supported harnesses, checks who may invoke them, and records the result. Peasant Passport would hold the user's configuration and access grants. A separate Vault would handle secrets without pasting credentials into model prompts.

The promise is not that every tool suddenly works everywhere. Authentication flows, platform sandboxes, protocol differences, provider policies, and rate limits remain very real fences.

The gate needs a lock

An agent that can call a tool is not automatically authorized to use every resource exposed by that tool. A connector might be permitted to list public repositories while being denied write access to private ones. Another agent may be allowed to draft an email but not send it.

An interoperability layer therefore needs capability discovery, resource-scoped permissions, trusted execution, and auditable outcomes. Simply forwarding credentials or offering an unrestricted HTTP proxy would extend the chain while removing the gate. That is not the goal.

An experiment worth running

A useful pilot would give two distinct harnesses access to the same connector definition, then test whether both can complete a deliberately small task. The evaluation should record:

• Did each harness discover the same supported capability?
• Could the user deny a specific operation or resource in both environments?
• Did the execution receipt prove success or failure, instead of trusting the assistant's claim?
• When the connector was disabled, did access really stop everywhere?

The result should include a compatibility matrix and documented failures. A demonstration is evidence for those two harnesses and that tool, not evidence for universal interoperability.

The field note

Provider integrations are useful. The problem begins when the list of supported partners becomes the boundary of a user's digital world. We would rather see a pasture where the gate is chosen by the person holding the key.

Research status: product hypothesis and interoperability test plan, not a validated cross-provider compatibility claim.