LensLink: An AI Camera Compatibility Agent Powered by Structured Sanity Content

This is a submission for the Sanity Challenge, Path One: Ship an Agent That Queries Real Content.

What I Built

LensLink is an AI camera and lens compatibility agent that answers whether a lens can be used with a camera using structured Sanity content rather than relying only on generic model knowledge.

The content models relationships between cameras, mounts, lenses, adapters, compatibility rules, and sources.

Demo

Live demo: https://lenslink-civq.onrender.com

Try these:

Is the Canon RF50mm F1.8 STM compatible with the Canon EOS R5?

Can I use the Canon EF50mm f/1.8 STM on the Canon EOS R5?

Is the Canon EF-M 22mm f/2 STM compatible with the Canon EOS R5?

These demonstrate direct compatibility, adapter-required compatibility, and an unsupported/evidence-limited case.

Code

GitHub: https://github.com/egbutaify2-ui/sanity-lenslink-agent

How I Used Sanity

I modeled the camera compatibility knowledge as structured Sanity content, including:

Camera → Mount

Lens → Mount

Adapter → From Mount / To Mount

Compatibility Rule → Camera / Lens / Adapter

Source → supporting evidence

I pointed Sanity Context at the LensLink Knowledge Base built from this structured content.

The agent uses these Context MCP tools:

initial_context

knowledge_base_search

knowledge_base_read

For each compatibility question, LensLink retrieves the relevant structured records before Gemini generates the answer.

For example, for the EF50mm + EOS R5 case, the agent can reason across:

EOS R5 → Canon RF Mount

EF50mm → Canon EF Mount

Canon EF-EOS R Adapter → Canon EF → Canon RF

This lets LensLink determine the documented adapter-required path instead of simply guessing from the product names.

Sanity Project Details

Project ID: kv3pdv23

Dataset: production

Agent Session

Agent session evidence is optional, so I have not included a transcript in this submission.

sanitychallenge

Comments

[Launch Gate]

The structured adapter path is a useful contrast to guessing from model names. I'd make "documented incompatible" and "not enough evidence" separate result states, especially for the third example. A missing rule is different from a source ruling a combination out. One regression fixture could keep the camera, lens and adapter records but remove the supporting source: does the answer switch to unknown and say what evidence is missing, rather than retain a confident yes or no?

[Egbuta ifeanyi chukwu]

Absolutely agree. The distinction is important because a documented incompatibility and an evidence gap are not the same thing.

The current schema already supports an unknown / needs verification compatibility state, but the existing live scenarios mainly exercise direct, adapter-required, and documented unsupported cases.

I think a good regression fixture would remove the supporting source/evidence while keeping the relevant camera, lens, and adapter relationships. In that case, LensLink should avoid giving a confident compatible/incompatible conclusion, classify the result as unknown/evidence-limited, and explicitly say what evidence is missing.

That would give us a stronger guarantee that the agent doesn't turn incomplete evidence into false certainty.

[Egbuta ifeanyi chukwu]

Thanks a lot for the feedback. I really appreciate you pointing that out.

I’ve implemented the distinction between documented incompatible and insufficient evidence / unknown. I also added regression coverage to ensure that when the supporting compatibility evidence is missing, LensLink returns an evidence-limited result instead of making a confident yes/no conclusion.

The existing direct, adapter-required, and documented-incompatible cases still pass as expected.

Really appreciate the suggestion — it made the evidence handling much stronger.