How assistant connectors work

Your team is about to put an AI assistant in front of customers, or inside your own operation, and connect it to something that matters. A pricing system. A policy library. A customer record.

Here is the uncomfortable part. When that connection is wrong, nothing breaks. No error, no alert. The assistant keeps answering, confidently, using a tool that does not do what its description claims. Ordinary testing does not catch it, because nothing failed.

This page explains how these connections work, which assistants make them easy, how to build one yourself, and what happened when we audited our own.

How a connector works

A connector is a small web service that follows the Model Context Protocol, the open standard assistants use to call outside tools. The assistant stays in charge. It decides when to call the tool, you see it happen in the conversation, and the answer comes back into the same chat.

The part most teams underrate: the assistant decides when to use your tool almost entirely from the words you wrote to describe it. That description is not documentation. It is the control logic. Too vague and your tool is ignored. Too confident and the assistant reaches for it in situations it cannot handle.

Our own connector is the proof

The most honest demonstration we can offer is the thing you are reading.

The 3Dogs Nexus connector was built using an AI assistant (Claude) via the Model Context Protocol. The assistant wrote the service, the sign-in, the usage metering and the tool descriptions, working against the live system, with a person at 3Dogs directing the work and approving every change that shipped. It was signed in, called and tested end to end before anyone was invited to use it.

Then we pointed 3Dogs at the result, which is the same audit we are proposing to run on yours. Three findings, all identified and resolved by that audit before this page went up, because they are exactly the kind that survive an ordinary review:

A claim that was false. A draft of this page said a person reviews every request before it reaches your assistant. Reassuring, and untrue: answers come back automatically, as they should. Caught and corrected before publication; it is stated accurately further down, because the audit ran.

A missing disclosure. No plain statement that we are independent of the assistant makers. Easy to omit, awkward to be asked about later. Added, and you will find it at the foot of this page.

Missing commitments. Nothing on where data goes, what is kept, or who owns a connector we build for a client. Every corporate buyer asks, and the page had no answer. Written down, and now the last section of this page.

Read that sequence again, because it is the whole argument. An assistant built a tool to make its own answers better on hard questions. The tool then caught mistakes that same assistant had made, and they were fixed before anyone read them. Neither half means much alone. Together they are the case study, and both halves are checkable: the connector works, and you are reading the corrected page.

None of those findings are exotic engineering faults. That is the point. A connector fails quietly, in the prose and the permissions, and the people closest to it are the least able to see it.

We can audit yours

If you have shipped a connector, or had one built, someone independent should look at it before your customers do.

What we check. Whether each tool description matches what the tool actually does. Whether sign-in and permissions hold up. Whether limits and costs are genuinely enforced rather than merely documented. What happens when the service is slow or fails. Whether the assistant is being told the truth about the tool's reach.

How. Auditing one thing from many independent angles at once is what this engine does all day. A rotating panel of models from different makers examines the service separately, argues, and reconciles. Dissent is preserved rather than averaged away, so you see where the reviewers disagreed and why.

What you get. A written opinion with the reasoning and sources shown, findings ranked by what would actually hurt, and the specific wording or configuration changes to make. It is a technical assessment, not a regulatory certification, and we would be wary of anyone who offered you one of those.

First step. A scoped call. Tell us what the service does and who uses it, and we come back with what the work involves and what it costs, before anyone commits to anything. Write to [email protected].

We can build yours

If you have a product, a dataset or a service that would be more useful inside an assistant, we can build that connector, run it for you, or hand it over for you to run.

The work is the same shape every time: decide what the tool should honestly claim to do, expose it safely, handle sign-in, meter it, and test it where real people will use it. The first step is the same scoped call.

We have no named customers to show you for this particular work yet. Rather than dress that up, we have written out below exactly how the job is done, so you can judge whether we know what we are talking about, or do it yourself without us.

Which assistants make this easy

The order we build in follows engineering difficulty, which anyone can verify from public documentation, rather than market size, which nobody outside those companies can.

Claude was first. You add a connector yourself: paste a web address into Customize, then Connectors, and it is there. Nobody has to approve it first. A thing you can hand someone and have them using in a minute is a thing worth building first.

Grok is next. xAI documents remote connectors for developers plainly. Sign-in is a token in a standard header, the transport choices are few and clearly stated, and no application review stands between a working service and someone using it.

ChatGPT is harder. Apps are built on a software kit still in beta. Full custom connectors sit behind a developer mode also in beta. An app that is to appear in the public directory must be submitted and pass OpenAI's review for quality, safety, privacy and transparency, with approved apps rolling out gradually. Early money-handling is limited: an app can send someone to the developer's own site to buy physical goods, and little more. None of that is a complaint. A beta is a stage, and a queue is a queue. Both end.

Gemini and Gemini Enterprise are not the same thing, and this catches people out. The Gemini app is an everyday assistant that comes with Google Workspace and draws on Gmail, Drive and Chat. Gemini Enterprise is a different product: an agentic platform connecting a company's other systems, including OneDrive, Outlook, SharePoint, ServiceNow, Jira and Confluence, under central administration. It lets a customer bring their own agent, either published from Google's agent platform or run elsewhere and joined over the Agent-to-Agent protocol. Google's documentation for it describes agents rather than connectors. So reaching it means building an agent, not a connector, and turning it on is an administrator's decision rather than a user's.

How to build one yourself

You do not need us for this, and we would rather say so than pretend otherwise. You can also ask your assistant to walk you through it, since the assistants understand this protocol well.

1. Expose a service over HTTPS that speaks the Model Context Protocol.
2. Describe each tool honestly and specifically, so the assistant knows when to reach for it and when not to. This is the step most people rush and the one that decides whether the thing is any good. Write the description for a capable colleague who has never seen your system and cannot ask you a question.
3. Add sign-in. The usual choice is the standard OAuth flow, so each person signs in to your service rather than everyone sharing one key.
4. Put limits and cost controls inside the service itself. Assume it will be called more often than you expect, because an assistant that finds your tool useful will use it repeatedly inside a single answer.
5. Test it inside the assistant, as a user, before anyone else sees it. Reading your own tool descriptions back in a live conversation is the fastest way to find the vague ones.
6. Where a directory exists, submit it for listing. Where one does not, people can still add it by address.

The assistant makers' own documentation is the authority on every one of these steps, and it changes. Read theirs before ours.

A person is always in the loop

Two loops, and we mean both.

Inside a question, the assistant you are already using stays in the loop. It decides when to bring us in, it can answer alongside us, and it can challenge what we send back. It is a coordinator, not a pipe.

Around the work, a person stays in the loop. 3Dogs is run by people. Someone decides what gets built, reads what the engine produces, and signs off every change to how the service answers, signs people in, meters usage and ships. To be exact about what that does not mean: no individual question is read by a person before the answer reaches your assistant. Answers come back automatically. And 3Dogs returns answers for you to act on; it does not reach into your systems and act on its own.

What this engine is

3Dogs Nexus is an AI engine, not a chatbot. Discovery grounds a question in live sources, and any claim that cannot be tied to a source is flagged rather than treated as settled. Nexus runs that brief through a rotating panel of 6 to 30 independent models, drawn from over 100 models across five clouds, in adversarial debate. Evolution audits every run and tests fixes before they change later runs.

On one email thread, 3Dogs Nexus made 48 model calls across 9 models on three clouds, read 172 sources and ran 21 deterministic checks, and returned a full source-checked written analysis. 3Dogs is an AWS Partner, and a client iPhone app we built is in Apple TestFlight.

What this costs inside your own assistant

3Dogs runs through your assistant, so it spends your assistant's allowance as well as ours. Handing a question over, writing an answer of its own alongside ours, reading our result back and challenging it all happen inside your session and count against whatever limits your plan carries.

It is built to spend less of that than the alternative, not more. The gathering, the cross-checking and the debate happen on our side. What crosses back into your conversation is the answer and its sources, not the hundreds of pages behind them. A question that would otherwise mean pasting a document set into your assistant, or that it would simply decline as too large, costs you one hand-off and one answer.

The practical consequence: if your assistant's limits are tight, a long session over large document sets will reach them sooner. Worth knowing before you start rather than after. What your assistant needs before a connector can be added at all is on the setup page.

What we do with your data, and what you own

Your question and any material you send are processed by AI models from Amazon Web Services and Anthropic. We keep the question and the answer to run and improve the service. We do not sell your data. If we build a connector for you, you own it. We fix defects for 30 days after launch.

3Dogs Nexus is independent. We are not affiliated with, endorsed by or certified by Anthropic, OpenAI, xAI or Google, and naming their products here says only where our work runs.