## Slide 2 — A second way into the same Amber (2 minutes)

Let me start with what MCP is, because the name tells you nothing.

MCP, the Model Context Protocol, is an open standard published in late 2024 and now supported by every major AI vendor. Microsoft, Google, Anthropic, OpenAI. It defines one common way for an AI tool to ask another system for information.

Think of USB. Before USB, every device had its own connector and its own cable. USB agreed one shape, and after that any device worked with any computer. MCP did the same thing for AI tools and the systems they need to reach. Build one connector and every compliant AI tool can use it.

What that means here. Today a member gets an answer by going to amber.bluetooth.com and typing a question. That works, but it means stopping what they were doing, going to a website, and carrying the answer back by hand. With MCP, their own AI tool asks Amber directly and the answer appears in the work. Nobody opens a browser.

Two things to be clear about. It is not a data dump. The AI tool asks a question and gets an answer back, one call at a time, logged and metered. It is not handed a copy of our library. And it is not one vendor’s technology. We publish a connector once, and whichever AI tool a member has standardized on can connect, subject to us approving that tool first.

Two audiences for us. Members, connecting their own AI agents through a connector we publish. And our own staff, through Microsoft Copilot and Claude Enterprise.

One thing that may surprise you: the connector is already built. It runs on our development environment today. What I am here for is the wrapper around it. Governance, commercial terms, and release.

## Slide 3 — A new door, not a new building

This is the slide for anyone whose first thought is data exposure. Mine was too.

Only two things change. Where the person is working, and how the question gets to Amber. Every row below those two says exactly the same.

Amber searches the same spec content, the same qualification data, the same SIG process material. It applies the same guardrails and the same disclaimers to every answer.

And on permissions, this is the important one. Amber MCP exposes only the APIs Amber Web already uses. Not a new set, not a wider set. The same ones, reached a different way.

Every call carries a signed in account’s own token and returns only what that account may already see.

We support service level accounts, and this matters for adoption. A member does not have to provision a login for every engineer. They can connect one account they own and control, something like amber@apple.com, and point their whole team at it. To us that is an ordinary user account, no different from an individual one, and it sees no more than any other non-owner at that company. It is also why billing is keyed to the member company rather than per seat.

The two tools that reach draft level qualification data are not in Amber today and are not in the pilot.

A member using MCP sees exactly what they would see signing in to Amber directly. No more, no less.

## Slide 4 — Why we are offering it

The demand is already here. It is just here in a form we do not control.

One Associate member ran about 1,450 scripted queries in a single day. That was roughly 70 percent of our production traffic that day. They were pulling spec content into a local knowledge base to use with their own AI tools.

The strategic point is this. Members are going to use AI on Bluetooth content either way. The only question is whether that happens through a path we control, meter, and audit, or a path we do not.

A sanctioned connector replaces uncontrolled copying with something metered, permission aware, and fully logged. And it keeps the SIG inside the workflow as member engineering moves to AI assisted tools.

## Slide 5 — What a member gets

From the member’s side, six things.

Bluetooth knowledge inside their own AI workflow, with nothing to copy, scrape, or maintain locally.

Answers grounded in adopted SIG content, with citations, rather than a general model guessing at spec detail.

Live qualification data, under their own account’s permissions.

Their AI does the reasoning. We supply the trusted source material.

Usage stays visible to both sides.

And they can connect however suits them, individual logins or one service level account they own and control, with no per user provisioning on their side.

The last two are the ones that matter commercially. ChatGPT and Copilot cannot see adopted SIG content, and they certainly cannot see a member’s own qualification records. That is what we are selling, and nobody else is in a position to sell it.

## Slide 6 — Pricing approach

Here is the shape of the commercial model.

It is open to every member, under separate terms and conditions, with one connection per URL.

One flat rate per member subscriber. That includes a set number of credits, which the member can spend in any mix of the two call types. I will explain those on the next slide.

Billed a quarter in advance, net 30. Unused credits lapse at quarter end. Any true up lands on the next invoice rather than forcing a mid term change.

On how we set the price. It comes from real Azure AI Foundry spend, anchored to the uncached cost of the most expensive call type, plus a 20 percent margin floor.

I want to be precise about that word floor. It is not a target. We calculate it against the worst case, which is a member spending every credit on the most expensive call with no caching benefit at all. Real margin will run above it.

Billing runs through Chargebee, keyed to Member ID, not per user. A member can point a whole team at one service level account and the price does not move.

## Slide 7 — Credits, not tokens

Two call types, and the ratio between them is the heart of the model.

A retrieval call costs the member 1 credit. Amber hands back source material and the member’s own AI does the reasoning. That is close to free for us.

An answer call costs 10 credits. Amber runs the full model end to end and returns a written answer. We carry the whole cost.

So the ten to one ratio is not arbitrary. It tracks what each call actually costs us.

Pricing in credits rather than raw tokens does two things. It shields the member from model price changes, so they are not renegotiating every time a vendor moves. And it holds our margin whatever mix of calls they choose.

## Slide 8 — Open questions

I would rather show you these than have you find them.

Seven items are open. The credit price itself, both included and overage, and how overage is trued up at quarter end. What discount, if any, we give for an annual commitment. Finance review of reporting rules as applied to prepaid credits. Legal review of all member facing terms, acceptable use, and data handling. Reinstatement terms after a suspension. Final rate limit figures. And a Qualification Workspace API clean-up covering two member specific tools.

None of these changes the shape of the model. They are the details we close before a price goes in front of a member.

The last one is not commercial and it is already handled.

Pricing proposal and board approval are targeted for December.

## Slide 9 — Member pilot

Before any of this goes broad, we run a pilot. Three to five companies, October through December.

We pick companies that differ from each other. Different sizes, different AI environments, different engineering use cases. It is free to them during the pilot.

On scope, the pilot ships the qualification tools Amber Web uses today, less two that are waiting on the Qual Workspace clean-up I mentioned. Neither is in Amber now, so no member loses anything they currently have, and both can be added part way through the pilot once the clean-up lands.

Each connects an approved AI host, and the first thing we confirm is permissions and audit logging. Then they run real scenarios, spec work, qualification work, member support, using defined test prompts alongside their actual workflows. Then we sit down with them. Usage data, ratings, interviews, defects, integration findings.

We are measuring three things.

Accuracy. Is Amber returning the right source material, do citations trace to adopted content, are permissions applied correctly.

Usefulness. Does this actually improve their work, does it cut search and copying and manual synthesis, would they keep using it.

Ease of integration. Can a company connect and run it reliably, is authentication stable, how much support friction did we see.

The gate to broad release is on the bottom. Trusted answers, clear member value, repeatable integration, and no unresolved security, permission, or operational issues. If those hold, we proceed in January.

## Slide 10 — Roadmap

Quickly down the table.

Connector built on dev, with non protected tools live and smoke tested. Done. PRD approved this month.

An externally connectable connector in October, gated on identity setup. Staff release through Copilot, October to December. Member pilot over the same window. General member release targeted for January, dependent on the pilot and on your pricing approval in December.

One row has no date, deliberately. Protected qualification tools. Two dependencies gate that track. The company boundary is enforced already, and the owner and non-owner split is confirmed. What is left is the API clean-up on two tools, which the Qual Workspace team is targeting for October.

## Slide 11 — Next steps

To close.

This month we finish pilot preparation and select the three to five member companies.

October, staff go live through Copilot and Claude Enterprise.

October through December, we run the pilot.

December, I come back to you with final pricing and terms for approval.

January, broad member availability.

So today is direction. December is the decision. Nothing goes to a member in between.

Happy to take questions.

—

# Likely questions

## On MCP itself

**Who controls this standard?**
It started at Anthropic and was handed to an open governance body. It is not owned by a single vendor, and there is no license or fee to us for using it. Microsoft, Google, and OpenAI all support it in their products.

**Is this a passing fad? Will we have built for a standard that dies?**
Reasonable question. Two reassurances. First, the expensive part of this work is not MCP, it is the identity and permissions plumbing, and that is reusable whatever protocol sits on top. Second, when the three largest AI vendors all adopt the same standard inside a year, the risk of it disappearing is low. If something replaces it, we swap the outer layer and keep the rest.

**Why would a member want this rather than just using Amber?**
Because their engineers do not work in a browser tab. They work in code editors and AI assistants. Anything that makes them stop, switch context, and copy an answer back gets used less. This puts Bluetooth knowledge where the work already is.

**Is this us building an AI product?**
No. We are not building a model or an agent. Members bring their own AI. We supply the trusted Bluetooth source material it reasons over, under their own permissions. We stay the authority on the content, which is the role we want.

**How is this different from a member just using our API?**
We do not publish a general purpose API into Amber, and an API would still need each member to build their own integration. MCP means they build nothing. Their AI tool already speaks it.

## On pricing and risk

**What does it actually cost a member?**
The working number is a flat rate per member per quarter with a large included credit pool, but I am not putting a figure in front of you today because Finance has not closed ASC 606 and Legal has not cleared the terms. The method is settled: uncached Azure Foundry cost plus a 20 percent margin floor. The number comes back in December.

**Why no free tier?**
Because the underlying cost is real and per call, not fixed. A free tier on a metered AI service is an open ended liability. Every member already gets Amber through the web app at no extra charge. This is a different thing, a programmatic path into their own tooling, and it carries real marginal cost.

**Could a member get data they should not see?**
No. The Qualification Workspace enforces this, not us, and Amber MCP exposes only the APIs Amber Web already uses. There is no new surface. Every call carries the signed in account’s own token and returns only what that account may already see.

**Could one division inside a member company see another division’s work?**
Not through us. The Workspace separates the owner of a qualification from other users at the same company, and a non-owner sees published products plus only what the owner has flagged for internal visibility. The two tools that reach draft level qualification data are not in Amber and are not in the pilot.

Worth adding: of the seven qualification tools, four return the same data to everyone. The three that vary by permission all require a specific qualification ID. None of them lets you search or list by company, so you would need that ID in hand already.

**What about shared accounts, where a whole team logs in as one user?**
That is fine and we expect it. An account like amber@apple.com is an ordinary user account to us. It gets non-owner visibility for that company, which is published products plus anything the company has chosen to flag internally. It cannot see more than any other non-owner at that company.

**Does member data go to OpenAI?**
No. Amber runs GPT models hosted privately inside our own Azure tenant. Inputs do not leave the SIG environment and are not used for training.

**What stops another bulk extraction?**
Rate limiting, keyed to the member organization, built in from day one rather than bolted on. The exact figures are still being finalized, which is why they are on the open list. The point is the limit is universal and applies to everyone, not a penalty aimed at anyone.

**Why not just let members scrape it, they already are?**
Because then we have no visibility, no audit trail, no rate control, and no revenue, and the content still ends up in a model we did not sanction. This gives us all four.

**What if the Qualification Workspace team says no to token exchange?**
Then the protected tools do not ship until we find another path, and I would come back to you on that. It does not stop the rest. Spec search, products, and general qualification information are all in the non protected set and ship independently.

**Is this a Claude product or a Microsoft product?**
Neither. MCP is an open standard. We publish one connector and any compliant AI host can connect to it, subject to our approving that host first. Staff happen to use Copilot and Claude Enterprise because that is what we run internally.

**Who signs off before anything goes to a member?**
Legal on all member facing terms and data handling. Finance on revenue recognition. And this board on price.

—

# Notes to self

– Do not name Bestechnic in the room.
– Do not characterize the bulk extraction as a terms violation. Demand signal only.
– Do not give a date for protected qualification tools.
– Do not say “our own models.” Say GPT models hosted privately in our tenant.
– Keep the division visibility answer scoped to Amber and MCP. Do not extend it into a general claim about the Workspace. Covered separately with Denise and Jay before the meeting.
– Do not say non-owners see published data only. The internal visibility flag is the exception and it is the member’s own setting.
– Do not say there is no service account. Shared member-owned accounts are supported and expected.
– Do not name the two held-back tools unless asked what is excluded.
– If anyone pushes for an October decision, the honest answer is the commercial track could hold October, but Legal and Finance reviews are not done and I would rather bring you a finished proposal in December than a provisional one in October.