The architecture in plain English

The one-to-one pairing sounds like a technical detail. It is actually a governance feature you should like. Each client-server connection is its own sealed line, with its own permissions and its own audit trail. A kitchen never learns what another kitchen is doing, and a compromised kitchen cannot reach across the floor.

• Isolation by design: the sales server cannot see the HR server. If one connection is misbehaving, you can cut that one line without touching the others.
• The host is where policy lives: the restaurant decides which kitchens open, which waiters are hired, and what a waiter is allowed to carry. That is your control point (a4 and a5 go deep here).
• Adding capability is additive: a new kitchen means a new waiter, not a renovation. This is the a1 promise - configuration, not a project - shown at the architecture level.

The vocabulary maps directly onto products you may already run, so you can locate the roles without a demo:

• Hosts are the AI apps people open: Claude Desktop, Claude Code, Microsoft Copilot, Cursor, and a growing list of others.
• Clients are invisible to users - they live inside the host, one per server connection. You will rarely say the word "client" in a meeting, but it is why isolation works.
• Servers are the capability. Some you buy from a vendor, some your own team builds over your own systems. Sessions a3 and a5 are about which is which.

When someone says "we connected Copilot to our warehouse," translate it: the host is Copilot, a client inside it opened a one-to-one line to a warehouse server. That is the whole sentence, in architecture terms.

Read the triangle as three answers to one question: who decides this happens? The answer is deliberately different for each type, and that difference is the whole safety story.

• Tools are model-controlled - the AI decides, in the moment, to call one. This is the powerful and the risky part: actions with side effects. It is exactly where you want approvals, scoped permissions, and read-only defaults.
• Resources are app-controlled - the host app decides what reference material to pull in. The AI reads, it does not reach out and grab. Lower risk, because reading is not acting.
• Prompts are user-controlled - a human deliberately picks a saved playbook. Nothing fires on its own. This is the safest of the three and the most under-used.

Leadership takeaway: when a vendor says "our server has 40 tools," hear "40 actions this AI could take against our data." That is not a reason to say no - it is the reason to ask which 40, and what each one can touch.

A capability list is just a menu. Read it in this order and you will catch the important things without any technical background:

• Count the tools first. Tools are actions. Ask what each one can do and whether any of them write, delete, or send. A server with only read tools is a very different risk than one that can modify records.
• Check what the resources expose. Resources are what the AI can read. Confirm the scope - "the public catalog" is fine; "the entire customer table" deserves a conversation.
• Note the prompts. Prompts are convenience playbooks and usually the lowest risk. Their presence is a sign of a mature, well-designed server.
• Then the two questions from a4: who maintains it, and how does it authenticate? Hold those for the security session - but know that a menu with no answer to "who owns this" is a red flag.

Servers come in two flavors, and the difference is mostly about where they run and how they connect. In plain risk terms:

• Local server (runs on the user's machine). It talks to the host over a direct on-device channel. No network hop, but it runs with that person's access and lives outside central visibility unless you manage it. Convenient, harder to govern at scale.
• Remote server (runs somewhere central, reached over the internet). It connects over a modern web channel with proper authentication. Easier to govern centrally, to audit, and to share across teams - which is why most enterprise deployments prefer it. The trade is that it is now an internet-facing service you must secure (a4).

Leadership rule of thumb: local is fine for one person experimenting; remote is what you standardize on when a capability matters to more than one team, because that is where central governance and auditing live. One older connection style has already been retired, so if a vendor mentions "HTTP+SSE," ask whether they are current.

Tools (actions, model-controlled): get_subscription_status, refund_order, list_open_tickets. All three do something on request.

Resources (reading, app-controlled): the returns-policy document and the brand voice guide. Reference material the AI reads, never changes.

Prompts (playbooks, user-controlled): the "handle-a-churn-risk-customer" workflow. A human picks it deliberately.

The one to gate: refund_order - it moves money. It should be scoped, capped, logged, and ideally require a human approval. Notice you reached that conclusion with zero technical knowledge, using only the control triangle.