Tools and system integration, answered in full.

MCP is an open standard for connecting AI applications to external systems: data sources such as files and databases, tools such as search and calculation, and predefined workflows. Its own documentation compares it to USB-C, a standardised connector so that a tool built once can be used by any client that speaks the protocol. Practically, it means an integration with your CRM is built against the standard rather than separately for each assistant, which is a real saving once you have more than one. It is supported across a range of assistants and development tools, and it is a connection standard rather than a security model.

For one agent and three integrations, plain function calling is enough and adding a protocol buys you nothing. MCP starts paying when the same systems have to be reachable by several different agents or assistants, because the alternative is an adapter per pair and a maintenance burden that grows faster than the value. The decision is about how many consumers of an integration you expect, not about capability. Whichever you choose, the authorisation questions are identical. No protocol decides for you whether a call carries the user's authority or the agent's, and that is the more useful thing to notice.

That the call carries an authority nobody decided on. The specific anti-pattern the protocol specification forbids is token passthrough, where a server accepts a token that was not issued for it and forwards it downstream. Doing so breaks rate limiting and request validation, it makes the downstream logs name the wrong caller, and a stolen token turns your server into a proxy for exfiltration. The second risk is broad standing permissions granted at setup because it was simpler, so a prompt injection through retrieved content or a reasoning error acts with the whole permission set rather than the task's. Both are design decisions taken in week one, and both are expensive to reverse.

By classifying the tools rather than trusting the model. Tenhaw settles that classification in the operating model rather than in the codebase. Every tool is labelled by consequence and reversibility before it is exposed: read, reversible write, and irreversible or consequential action. The third class either requires a human confirmation that names what is about to happen, or is not exposed to the agent at all and is instead raised as a request for a person to execute. Write tools carry idempotency keys so a retry cannot double-post, and the boundary is written down per decision class with your second line as co-author rather than settled in a code review.

Fewer than you will be tempted to give it, and the constraint is not the model, it is your ability to state the blast radius. Broad permission sets granted up front expand what a stolen token reaches, make revocation disruptive enough that nobody does it, and turn consent screens into something users click through, which is the argument the protocol's own guidance on scope minimisation makes well. In practice we would rather run three narrow agents with defensible permission sets than one that can do everything, and the audit trail is legible either way.

By logging the tool calls rather than the conclusions. Tenhaw instruments that logging in the first week of a build, because reconstructing it later is a project. Each call records the agent identity, the human accountable for that agent, the arguments passed, the result returned, the latency and the token cost, against the version of the tool contract in force at the time. That record answers the three questions you will be asked after any incident, which are what it was asked, what it did, and under whose authority, and it does so without an archaeology exercise. It is also the input to trajectory scoring, so the same logging pays for itself twice.

Benchmark numbers would describe Tenhaw's workloads rather than yours, so none are published. Both are measurable from day one if you log them, and the drivers are known: the number of model turns, which rises with the number of tools and falls with a tighter tool set; the tokens in context on each turn, which retrieval design controls; the latency of your own systems, which is usually the dominant term and is not something a model choice fixes; and retries. Tenhaw logs cost and latency per tool call from the first week of a build. Give each stage an explicit budget in the design, measure against it in the build, and get an estimated run cost per candidate workflow before anything is committed to.

The connector is an afternoon in every one of those. The authorisation model is the quarter, and it differs per system in ways that decide the architecture. Salesforce uses OAuth 2.0 against an external client app, with the JWT bearer flow or the client credentials flow for an unattended agent, and even the client credentials flow requires you to nominate an execution user whose permission sets are the real permission model. ServiceNow resolves an inbound REST call to a platform user, and that user's roles plus table, field and record-level access control rules decide everything, so the agent sees what that user would see in the interface. SharePoint and Microsoft 365 run on Entra ID, where delegated permissions intersect with the signed-in user's own access and application permissions do not, and where a certificate rather than a secret is required for app-only access to the SharePoint APIs. Snowflake is role-based with inheritance, and is retiring single-factor password authentication for service users on a published schedule that completes in the August to October 2026 window. Databricks uses OAuth machine-to-machine for a service principal with one-hour tokens scoped either to the account or to a single workspace. Workday uses an OAuth 2.0 API client registered in the tenant with scopes selected at registration, and a tenant-side security configuration behind it that you should confirm with your own administrator. Tenhaw has not built a production agentic integration into any of these six, and the delivered integration work we can point at is a document pipeline calling third-party enrichment APIs on a live insurance engagement.

It is the single most consequential design decision in an enterprise retrieval build, and it is usually taken by accident in week one. With delegated permissions the app acts on behalf of a signed-in user and its access is intersected with that user's own, so it can never return a document that person could not already open. With application permissions there is no user in the picture and no intersection, so an app granted a tenant-wide read permission app-only can read every file in the organisation, which is exactly what a crawler is usually given because it is the fastest way to build an index. Between the two sit the Selected scopes, Sites.Selected and the newer Lists, ListItems and Files variants, which grant nothing when consent is given and require an explicit per-resource grant with a role of read, write, owner or fullcontrol, so all three steps have to be completed before the app has any access at all. The design that holds is Selected scopes for what may be indexed, delegated access at query time, and a test in the build pipeline where a named user who should not see a document asks the question that would surface it and the run fails if it comes back. Retrofitting this after indexing usually means rebuilding the index.

One is usually enough, and Tenhaw is openly sceptical of the crew for a sequencing reason. A multi-agent shape multiplies the number of trajectories you have to evaluate, and it almost always arrives before anyone has a ground-truth set for a single one. Most workflows sold as needing several agents are one agent with a well-designed tool list and a clear stopping rule, and the tool list is the part that repays the effort. Start with one, build the evaluation set, and add agents when a single trajectory demonstrably cannot carry the work. Tenhaw builds that first agent on an Agentic Proof of Concept, and has delivered no client system on a multi-agent framework, so that is a view rather than a finding.

Start with none of them. That is a position rather than a finding, because Tenhaw has delivered no client system on any of the five and builds instead on the native tool calling in the model APIs, including the document pipeline delivered on a live insurance engagement. For one agent and a handful of integrations that native tool calling is the whole answer, and a framework is a dependency you will still be carrying in year two. Where a framework earns its place, the property to buy is explicit, inspectable, resumable state, which a graph with checkpoints gives you and a chain of implicit calls does not, because a trajectory you cannot reconstruct is one you cannot score, debug or explain to an auditor. On an Azure estate, Semantic Kernel is the layer closest to the platform Tenhaw has actually delivered on and the one to evaluate first, against your own tool contracts rather than against a demonstration. Tenhaw is openly sceptical of multi-agent frameworks. A crew multiplies the trajectories you have to evaluate, usually before anyone has a ground-truth set for one. Whichever you pick, keep the model interface, the prompts, the tool contracts, the retrieval corpora and the evaluation sets as your assets, so they survive you replacing the thing that composes them.

Settle the authorisation model before you build the tool catalogue. Most of the architecture is decided by one question, whether a tool call carries the asking user's authority or the agent's own, and whether the answer changes between a read and a write. Expect about a fortnight of design with your platform and identity people in the room. It is worth doing whether or not you ever adopt MCP, because the same question turns up in any function-calling design, and it is what a security review will fail you on. Then build the first two integrations properly and write the contract every later one is held to. Tenhaw pair-programs that work with your own engineers, as it did throughout the London specialty insurance proof of concept.

Because the flow has no signed-in user of its own. Salesforce's client credentials flow still requires you to nominate an execution user, and every action the agent takes is attributed to that user, so three agents sharing one execution user leave an audit trail that cannot say which of them updated the record. Give each agent its own integration user, carrying the API Only User permission and holding its privileges through permission sets under the Salesforce API Integration permission set licence, and scope those permission sets to the workflow rather than to the system. Attribution is cheap to design in and expensive to reconstruct once actions have accumulated against the wrong principal.

No. Without a standard, every assistant needs its own adapter for every system, and MCP takes out that real and boring cost. But the wire is the easy half. It does not standardise your authorisation model, your data residency position or the semantics of your own systems, and those take the time. Tenhaw builds integrations against your authorisation model, not integration platforms, and the delivered example is a two-week Azure proof of concept for a London specialty insurance business. The protocol's own security guidance says plainly that per-client consent, token audience validation and scope minimisation are the implementer's job. Read it as a saving on plumbing, not an answer to the access question, and be sceptical of any supplier who sells it as the second.

Three things. First, which tokens the server will accept. The specification requires a server to refuse any token that was not explicitly issued for it and names token passthrough as forbidden, so a supplier who cannot answer that has not read the document they are selling against. Second, whether the tool catalogue separates reads from writes, and whether it contains a general-purpose tool that can run arbitrary queries or commands, because one of those makes every other permission decision decorative. Third, what you could change a year later without them, since the tool contracts, prompts, retrieval corpora and evaluation sets are your assets and should outlive whatever composes them.

Usually yes, and then usually not quite. Human-facing APIs assume a human pace and a human retry. An agent calls them in loops, in parallel, and immediately after a timeout, which finds every missing idempotency key, every multi-step write with no transaction boundary and every rate limit nobody had reached before. The failure is rarely dramatic, just a duplicate record, twice, in a system somebody reconciles monthly. The answer is rarely a new API estate. It is a thin layer of narrow, single-purpose write tools with typed arguments and an idempotency key so a retry cannot double-post, and explicit confirmation on anything irreversible.

You have made a breaking change to a system whose behaviour you have already evaluated, so it should fire the same regression run a model upgrade does. Tool names, argument schemas and descriptions are versioned artefacts under change control, reviewed like any other code, because changing a description changes model behaviour as surely as changing the implementation. A rename underneath a running agent belongs in the regression set next to timeouts, partial writes, rate limits, a downstream system in read-only mode and a tool that returns hostile content. Those are the paths nobody demonstrates, and how an agent responds to a failed call is behaviour you specify rather than discover.

Because roles inherit. Snowflake's access control is role-based with object ownership on top, where privileges attach to roles, roles attach to users, roles inherit through a hierarchy, and secondary roles can combine several in one session, so an agent assuming a broad role gets everything beneath it rather than only what was granted to it directly. Inheritance is the trap, and it is why the agent needs its own role. Read what that role inherits before you read what it was granted, and scope it to the workflow rather than to the warehouse. Check how it authenticates while you are there, because Snowflake is retiring single-factor password authentication for service users on a published schedule.