MCP, tool calling and integrating agents with your systems
The moment an agent can call your systems, integration stops being plumbing and becomes an access decision.
Tool calling is how an agent stops being a chat window: the model is given a set of typed functions it can invoke, and it decides which to call and with what arguments. The Model Context Protocol, or MCP, is an open standard for connecting AI applications to those tools and data sources, so an integration is built once rather than once per assistant. In an enterprise the standard solves the easy half. The hard half is deciding which tools may act rather than only read, giving the agent its own scoped credentials instead of a person's, validating that every token was actually issued for the service receiving it, and accepting that a tool description and a tool result are both untrusted text the model will act on.
This is our approach, not a programme we have already run.
We build with tool-calling agents daily and we have not run an MCP server estate inside a regulated enterprise. Our own operations run research agents that call external services for competitor monitoring and opportunity-gap analysis, and our development pipeline is AI-engineering-first. On client work, the document pipeline delivered on a live insurance engagement calls third-party APIs to enrich extracted fields, so the integration and provenance parts of this are written from delivery. What we have not done is stand up an internal catalogue of MCP servers with an authorisation model behind it, and the flagship agentic build is a regulated-estate proof of concept now being productionised. Where deep integration or identity engineering is required we would expect to work alongside your platform and IAM functions rather than around them.
On this page
The demand signal
The standard's own documentation is the demand signal worth reading. The Model Context Protocol describes itself as a standardised way to connect AI applications to external systems, the way USB-C standardised connecting devices, and it ships a security best practices document alongside the specification. That document names confused deputy attacks through OAuth proxies, token passthrough, server-side request forgery during metadata discovery, session hijacking, local server compromise and scope inflation, in specification language: an MCP server must not accept any token that was not explicitly issued for it. A standard that publishes its own attack surface in that much detail is telling you where the work is, and it is not in the wire format.
Why it stalls
5 failure modes we keep meeting
The integration takes an afternoon and the authorisation takes a quarter
Connecting an agent to an API is genuinely easy now, which is the problem: the first version works, so nobody asks whose authority the call carries. The protocol specification is blunt about the anti-pattern, calling token passthrough explicitly forbidden and requiring that a server refuse tokens not issued to it, because the alternative breaks rate limiting, breaks the audit trail, and lets a stolen token use your server as a proxy for exfiltration. Programmes that skip this arrive at the security review with an integration nobody can explain and no cheap way to fix it.
Every useful tool gets added to one agent until nobody can reason about it
Tool sprawl is the quiet failure. Each addition is individually sensible, the combined permission set is nobody's decision, and the specification's own guidance on scope minimisation describes exactly where it ends: broad scopes granted up front, a blast radius nobody has calculated, revocation that would disrupt every workflow at once, and users who stop reading consent screens because the list is too long to read. This is also the mechanism that stops an agent portfolio scaling past three or four.
Nobody separated the tools that read from the tools that act
A retrieval call and a payment call are the same shape to a model and entirely different to your business. Where that distinction is not explicit in the design, the human approval boundary ends up wherever someone happened to put a confirmation dialogue, rather than being drawn by consequence and reversibility. It is the same boundary question as any other consequential decision and it belongs in the operating model, not in whichever pull request first needed it.
The API being wrapped was designed for a person with a form in front of them
Human-facing APIs assume a human pace and a human retry. Agents call them in loops, in parallel, and immediately after a timeout, which surfaces 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. It is a duplicate record, twice, in a system somebody reconciles monthly.
A tool description and a tool result are both prompt
Everything the model reads can steer it, including the text describing what a tool does and the payload a tool returns. Indirect prompt injection was demonstrated against deployed applications by planting instructions in content the application would later fetch, and prompt injection is the first entry in the OWASP risk list for language model applications. Once tools can act, an injection stops being an embarrassing answer and becomes an action taken under your agent's credentials, which is a different conversation with your auditors.
How we approach it
7 moves, in order
- 01
Start from the decision, not from the API catalogue
The design starts with the decisions in the workflow and what each one genuinely needs to see or change, and the tool list falls out of that. Starting from what the systems happen to expose produces an agent with thirty tools, twenty-six of which exist because they were easy, and a permission set nobody can defend.
- 02
Split read from write, and make the write tools boring
Read tools and write tools are designed and reviewed as different classes. Write tools are single-purpose with narrow typed arguments, carry an idempotency key so a retry cannot double-post, and require explicit confirmation for anything irreversible. There is no general-purpose escape hatch tool, because a tool that can run arbitrary queries or arbitrary commands makes every other permission decision on the page decorative.
- 03
Give the agent its own credentials, scoped to the task and time-boxed
Each agent gets a distinct identity, never a human's and never a shared service account, with permissions scoped at the granularity of the workflow rather than the agent, and credentials that expire. This is cheap at design time and expensive once actions have accumulated against the wrong principal, and it is the thing that makes the blast radius calculable.
- 04
Validate the audience of every token, and never pass one through
A server accepts only tokens issued for itself, and exchanges rather than forwards when it needs to call something downstream. The protocol specification states this as a requirement rather than a recommendation, and the reasoning is the part worth carrying to your architecture review: without it the downstream system's logs show the wrong caller, the security controls that depend on token audience are bypassed, and one compromised service becomes access to everything that trusted the same token.
- 05
Version the tool contract, and review descriptions as code
Tool names, argument schemas and descriptions are versioned artefacts under change control, reviewed like any other code, because a change to a description changes model behaviour as surely as a change to the implementation does. Renaming a tool is a breaking change to a system whose behaviour you have evaluated, and it should fire the same regression run that a model upgrade does.
- 06
Log the call, not just the outcome
Every tool call records which agent identity made it, which human is accountable for that agent, the arguments, the result, the latency and the token cost. This is where the answer to what it costs per run and how slow it is comes from, it is the raw material for trajectory scoring, and it is the same record a regulator asks for when they want to know what the system actually did. Collect it from the first week, because reconstructing it later is a project.
- 07
Test the paths nobody demonstrates
Timeouts, partial writes, rate limits, a tool that has been renamed under you, a downstream system in read-only mode, and a tool that returns hostile content. Those belong in the regression set alongside the happy path, because they are what week three looks like, and because an agent's response to a failed tool call is behaviour you have to specify rather than discover.
Read tools and write tools are designed and reviewed as different classes.
The orchestration layer, named, with what we have and have not built on
1 delivered, 4 our approach
The frameworks a technical buyer asks about by name, each with the same label the guide carries. Delivered means we have shipped on it. Our approach means a position with no delivery behind it.
Native tool calling in the model APIs
DeliveredTyped functions declared to the model, which decides which to call and with what arguments. No framework involved.
This is what we actually build with, daily and on client work. The document pipeline delivered on a live insurance engagement calls third-party APIs to enrich extracted fields, and our own operations run research agents that call external services. For one agent and a handful of integrations this is the whole answer, and reaching for a framework first is how a fortnight of work acquires a dependency it will still be carrying in year two.
Model Context Protocol (MCP)
Our approachAn open standard for connecting AI applications to tools and data sources, so an integration is built once rather than once per assistant.
We have not run an MCP server estate inside a regulated enterprise; the interesting part of that work is the authorisation model rather than the wire format. It starts paying when several assistants need the same systems, because the alternative is an adapter per pair. Read the protocol's own security guidance before the design review: it is the document that names token passthrough as forbidden, and that requirement is the one an enterprise architecture actually turns on.
LangChain and LangGraph
Our approachOpen-source frameworks for composing model calls into applications. LangGraph models the composition as a graph with explicit state.
No client delivery on either, and the position is about the shape rather than the brand. Agentic work needs explicit, inspectable, resumable state, because a trajectory you cannot reconstruct is one you cannot score, cannot debug and cannot explain to an auditor, and a graph with checkpoints gives you that where a chain of implicit calls does not. What we would resist on any framework is letting the abstraction become the architecture: the model interface, the prompts, the retrieval corpora, the tool contracts and the evaluation sets are your assets and they should survive you replacing whatever composes them. Ask any supplier proposing one what you would be able to change a year later without them.
Microsoft Semantic Kernel
Our approachMicrosoft's SDK for composing models, plugins and planning inside an application.
It is the orchestration layer closest to the estate we have actually delivered on, and we have still not built a client system with it. On an Azure estate it is the first thing we would evaluate, and evaluate is the word: against your own tool contracts and your own evaluation set, not against a demonstration.
CrewAI and AutoGen
Our approachFrameworks for orchestrating several agents that hand work between each other in defined roles.
No delivery on either, and our position is openly sceptical for a sequencing reason. A multi-agent shape multiplies the number of trajectories you have to evaluate, and it usually arrives before anyone has a ground-truth set for one. Most workflows sold as needing a crew are one agent with a well-designed tool list and a clear stopping rule. Start with one, build the evaluation set, and add agents when a single trajectory demonstrably cannot carry the work. That is a view rather than a finding.
The systems agents actually get pointed at, and what each access model implies
A guide about integrating agents with your systems that names no systems is a guide about nothing. Each row below was read from the vendor's own current documentation rather than recalled, and the column that matters is not the connector, it is what decides the blast radius when the agent is manipulated.
| System | What an agent wants | How a machine authenticates | What decides permissions | What bites |
|---|---|---|---|---|
| Salesforce | Accounts, contacts, opportunities and cases: the record an agent summarises, triages or updates. | OAuth 2.0 against an external client app. Salesforce restricted the creation of new connected apps from Spring '26 in favour of external client apps, and existing connected apps continue to work. For an unattended agent, either the JWT bearer flow, which signs a request with a private key and needs no browser, or the client credentials flow, which exchanges a consumer key and secret for a token. | The scopes on the app, intersected with a nominated execution user. The client credentials flow has no signed-in user, so Salesforce still requires you to name one, and its guidance is that this user carries the API Only User permission and holds its privileges through permission sets under the Salesforce API Integration permission set licence. | Every action in that flow is attributed to the execution user. Share one execution user across three agents and your audit trail cannot tell you which agent updated the record. One integration user per agent, and scope its permission sets to the workflow rather than to the system. |
| ServiceNow | Incidents, requests, changes and the CMDB: the workflow an agent triages, enriches or routes. | OAuth 2.0 or basic authentication on inbound REST, and either way the request resolves to a platform user. Authorization code is the flow to prefer where a user context exists, because it supports single sign-on and an external identity provider. | That user's roles, then access control rules evaluated per table, per field and per record. There is no separate API permission model to reason about, which is a real advantage: the agent sees what that user would see in the interface, and nothing else. | Which is exactly why the shortcut is to give the integration user the admin role, and that is the entire permission design gone in one grant. Build the role set from the workflow, then test it by logging in as that user and trying to reach something the workflow has no business reading. |
| SharePoint and Microsoft 365 | Policies, procedures and the document estate: the corpus almost every enterprise retrieval build starts from. | Microsoft Entra ID, in one of two modes. Delegated, where the app acts on behalf of a signed-in user, or app-only, where it acts as itself. For app-only access to the SharePoint CSOM and REST APIs, Microsoft's own guidance is that a certificate is required and every other option is blocked. | This is the most consequential row in the table. Delegated permissions intersect with the user's own access, so the app can never exceed what that person could already open. Application permissions do not intersect with anything: an app granted Files.Read.All app-only can read every file in the organisation. Between the two sit the Selected scopes, Sites.Selected and the newer Lists, ListItems and Files variants, which grant nothing on consent and require an explicit per-resource grant carrying a role of read, write, owner or fullcontrol. All three steps have to be completed or the app has no access, which is the point of them. | This row is where enterprise retrieval builds go wrong, and it is nearly always found after indexing. An app-only crawler with a tenant-wide read permission indexes everything it can see, and every user then gets answers drawn from documents they cannot open. Selected scopes for what the agent may index, delegated access at query time, and a test in the pipeline where a user who should not see a document asks the question that would return it. Retrofitting that usually means rebuilding the index. |
| Snowflake | The warehouse an agent queries for a number, and the semantic layer it should be querying instead. | Key-pair authentication, OAuth or programmatic access tokens. Snowflake is retiring single-factor password authentication on a published schedule: in its stated phase three, August to October 2026, legacy service users are converted to the SERVICE user type and blocked from authenticating with a password. An agent built against a password today has a dated problem. | Role-based, with ownership on top. Privileges attach to roles, roles attach to users, and roles inherit through a hierarchy, with secondary roles able to combine several in one session. | Inheritance is the trap. An agent assuming a broad role gets everything beneath it in the hierarchy, not only what was granted to it directly. Give the agent its own role, then read what that role inherits before you read what it was granted. |
| Databricks | The lakehouse behind the analytical question, and the pipeline that produced the table the agent is about to trust. | OAuth machine-to-machine for a service principal: a client ID and secret exchanged for an access token valid for one hour, refreshed automatically by the supported SDKs. Tokens are scoped either at account level, reaching every workspace the principal can access, or at workspace level. | Whatever that service principal has been granted. Account-scoped and workspace-scoped tokens are a genuine architectural choice rather than a configuration detail, and the account-scoped one is the convenient default. | Scope the token to the workspace the workflow lives in, and audit what the service principal was actually granted rather than what the person who created it intended to grant. We have not built an agentic workload on Databricks and this row is read from its documentation, not from delivery. |
| Workday | Worker, organisation and absence data: the system of record behind most HR and finance workflows. | OAuth 2.0 through an API client registered in the tenant, which issues a client ID and secret, and at registration you select one or more scopes matching the functionality the client needs. That much is from Workday's own developer documentation. | The scopes on the API client, and then the tenant-side security configuration behind the integration account. Workday's customer documentation for that second half sits behind a login we could not open, so this row stops at what the public documentation supports. | Confirm the tenant-side half with your own Workday administrator before anyone designs against it, and get the scope list agreed in writing at the same time. It is also the system where the data is most likely to be special-category or to carry an employment-law consequence, so the human-in-the-loop boundary here is a legal question before it is an engineering one. |
Salesforce
- What an agent wants
- Accounts, contacts, opportunities and cases: the record an agent summarises, triages or updates.
- How a machine authenticates
- OAuth 2.0 against an external client app. Salesforce restricted the creation of new connected apps from Spring '26 in favour of external client apps, and existing connected apps continue to work. For an unattended agent, either the JWT bearer flow, which signs a request with a private key and needs no browser, or the client credentials flow, which exchanges a consumer key and secret for a token.
- What decides permissions
- The scopes on the app, intersected with a nominated execution user. The client credentials flow has no signed-in user, so Salesforce still requires you to name one, and its guidance is that this user carries the API Only User permission and holds its privileges through permission sets under the Salesforce API Integration permission set licence.
- What bites
- Every action in that flow is attributed to the execution user. Share one execution user across three agents and your audit trail cannot tell you which agent updated the record. One integration user per agent, and scope its permission sets to the workflow rather than to the system.
ServiceNow
- What an agent wants
- Incidents, requests, changes and the CMDB: the workflow an agent triages, enriches or routes.
- How a machine authenticates
- OAuth 2.0 or basic authentication on inbound REST, and either way the request resolves to a platform user. Authorization code is the flow to prefer where a user context exists, because it supports single sign-on and an external identity provider.
- What decides permissions
- That user's roles, then access control rules evaluated per table, per field and per record. There is no separate API permission model to reason about, which is a real advantage: the agent sees what that user would see in the interface, and nothing else.
- What bites
- Which is exactly why the shortcut is to give the integration user the admin role, and that is the entire permission design gone in one grant. Build the role set from the workflow, then test it by logging in as that user and trying to reach something the workflow has no business reading.
SharePoint and Microsoft 365
- What an agent wants
- Policies, procedures and the document estate: the corpus almost every enterprise retrieval build starts from.
- How a machine authenticates
- Microsoft Entra ID, in one of two modes. Delegated, where the app acts on behalf of a signed-in user, or app-only, where it acts as itself. For app-only access to the SharePoint CSOM and REST APIs, Microsoft's own guidance is that a certificate is required and every other option is blocked.
- What decides permissions
- This is the most consequential row in the table. Delegated permissions intersect with the user's own access, so the app can never exceed what that person could already open. Application permissions do not intersect with anything: an app granted Files.Read.All app-only can read every file in the organisation. Between the two sit the Selected scopes, Sites.Selected and the newer Lists, ListItems and Files variants, which grant nothing on consent and require an explicit per-resource grant carrying a role of read, write, owner or fullcontrol. All three steps have to be completed or the app has no access, which is the point of them.
- What bites
- This row is where enterprise retrieval builds go wrong, and it is nearly always found after indexing. An app-only crawler with a tenant-wide read permission indexes everything it can see, and every user then gets answers drawn from documents they cannot open. Selected scopes for what the agent may index, delegated access at query time, and a test in the pipeline where a user who should not see a document asks the question that would return it. Retrofitting that usually means rebuilding the index.
Snowflake
- What an agent wants
- The warehouse an agent queries for a number, and the semantic layer it should be querying instead.
- How a machine authenticates
- Key-pair authentication, OAuth or programmatic access tokens. Snowflake is retiring single-factor password authentication on a published schedule: in its stated phase three, August to October 2026, legacy service users are converted to the SERVICE user type and blocked from authenticating with a password. An agent built against a password today has a dated problem.
- What decides permissions
- Role-based, with ownership on top. Privileges attach to roles, roles attach to users, and roles inherit through a hierarchy, with secondary roles able to combine several in one session.
- What bites
- Inheritance is the trap. An agent assuming a broad role gets everything beneath it in the hierarchy, not only what was granted to it directly. Give the agent its own role, then read what that role inherits before you read what it was granted.
Databricks
- What an agent wants
- The lakehouse behind the analytical question, and the pipeline that produced the table the agent is about to trust.
- How a machine authenticates
- OAuth machine-to-machine for a service principal: a client ID and secret exchanged for an access token valid for one hour, refreshed automatically by the supported SDKs. Tokens are scoped either at account level, reaching every workspace the principal can access, or at workspace level.
- What decides permissions
- Whatever that service principal has been granted. Account-scoped and workspace-scoped tokens are a genuine architectural choice rather than a configuration detail, and the account-scoped one is the convenient default.
- What bites
- Scope the token to the workspace the workflow lives in, and audit what the service principal was actually granted rather than what the person who created it intended to grant. We have not built an agentic workload on Databricks and this row is read from its documentation, not from delivery.
Workday
- What an agent wants
- Worker, organisation and absence data: the system of record behind most HR and finance workflows.
- How a machine authenticates
- OAuth 2.0 through an API client registered in the tenant, which issues a client ID and secret, and at registration you select one or more scopes matching the functionality the client needs. That much is from Workday's own developer documentation.
- What decides permissions
- The scopes on the API client, and then the tenant-side security configuration behind the integration account. Workday's customer documentation for that second half sits behind a login we could not open, so this row stops at what the public documentation supports.
- What bites
- Confirm the tenant-side half with your own Workday administrator before anyone designs against it, and get the scope list agreed in writing at the same time. It is also the system where the data is most likely to be special-category or to carry an employment-law consequence, so the human-in-the-loop boundary here is a legal question before it is an engineering one.
Every authentication and permission statement above was read from the vendor's own current documentation on 26 July 2026 and is linked in the sources at the foot of this page. Vendors change these, sometimes at short notice, so check the source before you design against a row rather than after. Tenhaw has not built a production agentic integration into any of these six systems. What we have delivered is a document pipeline calling third-party enrichment APIs on a live insurance engagement, and the reason we can be specific about the rest is that the access model is published and worth reading properly.
Where a standard helps, and where it does not
MCP standardises the wire between an application and a tool, which removes a real and boring cost: without it, every assistant needs its own adapter for every system, and the count multiplies. What it does not standardise is your authorisation model, your residency position or the semantics of your own systems, and those are the parts that take the time. The protocol's own security guidance is explicit that per-client consent, token audience validation and scope minimisation are the implementer's job. Treat the standard as a saving on plumbing rather than as an answer to the access question, and be sceptical of any supplier who presents it as the second thing.
Settle the authorisation model before the catalogue. One question decides most of the architecture: does a tool call carry the asking user's authority or the agent's own, and does the answer differ between a read and a write. That is 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 appears in any function-calling design, and it is the thing a security review will fail you on. Use us to build the first two integrations properly and to write the contract every later one is held to. If what you actually need is an enterprise integration platform stood up, that is a real piece of work, it is not the piece we have done, and we will tell you so.
Prefer to talk it through? Ask us on a discovery call →
Sources
Every source below was opened and read before it was attached. Where nothing survived that check, the claim on this page was softened rather than given a plausible-looking link.
Model Context Protocol, introductionThe standard's own description: an open standard for connecting AI applications to external systems, with the USB-C comparison quoted above.Model Context Protocol, security best practicesSource of the token passthrough prohibition, the confused deputy and session hijacking attack descriptions, and the scope minimisation guidance. Worth reading in full before any MCP design review.Greshake et al., Not what you've signed up for: compromising real-world LLM-integrated applications with indirect prompt injection (2023)Why a tool result is treated as untrusted input: instructions planted in retrieved content were used against real deployed applications, including to trigger API calls.OWASP Top 10 for Large Language Model Applications (2025)LLM01 Prompt Injection and LLM06 Excessive Agency are the entries that bear directly on tool design.Salesforce, OAuth 2.0 client credentials flow for server-to-server integrationSource of the nominated execution user, the API Only User recommendation and the Salesforce API Integration permission set licence. The note that connected app creation is restricted from Spring '26 in favour of external client apps is from the same documentation set.ServiceNow, inbound REST API documentationSource of the position that inbound REST authenticates by basic authentication or OAuth and that the caller's roles and access control rules then decide what is returned. Read alongside ServiceNow's own platform security documentation on access control rules.Microsoft, overview of Selected permissions in OneDrive and SharePointSource of the Selected scopes, the read, write, owner and fullcontrol roles, the three steps required before an app has any access, and the statement that in the delegated scenario the application can never exceed the user's permissions.Microsoft, overview of Microsoft Graph permissionsThe delegated versus application permission distinction in Microsoft's own words, including the worked example that an app granted Files.Read.All as an application permission can read any file in the organisation.Microsoft, granting access to SharePoint via Entra ID app-onlySource of the certificate requirement: for app-only access to the SharePoint CSOM and REST APIs, the documentation states every other option is blocked and returns access denied.Snowflake, multi-factor authentication rollout and deprecation timelineSource of the phase three window, August to October 2026, in which legacy service users are converted to the SERVICE user type and blocked from password authentication. Read with Snowflake's access control overview for the role hierarchy and secondary roles.Snowflake, overview of access controlSource of the role-based model with object ownership on top, the role hierarchy that makes inheritance the thing to check, and secondary roles.Databricks, OAuth machine-to-machine authenticationSource of the service principal client ID and secret exchange, the one-hour token lifetime, and the distinction between account-scoped and workspace-scoped tokens.Workday, create your API clientSource of the client ID and secret issued on registration and of selecting one or more scopes for the client's functionality. Workday's customer documentation for the tenant-side security configuration sits behind a login we could not open, which is why the row above stops where it does.Questions this guide answers
What is the Model Context Protocol?
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.
Do we need MCP, or is plain function calling enough?
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, which is the more useful thing to notice: no protocol decides for you whether a call carries the user's authority or the agent's.
What is the biggest security risk when an agent can call our systems?
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: it 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 scope: 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.
How do you stop an agent taking an action it cannot undo?
By classifying the tools rather than trusting the model. 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.
How many tools should one agent have?
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. The protocol's own guidance on scope minimisation makes the argument well: 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. 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.
How do you know what an agent actually did?
By logging the tool calls rather than the conclusions. 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.
What does a tool-calling agent cost per run, and how slow is it?
Benchmark numbers would describe our workloads rather than yours, so we publish none. 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. Give each stage an explicit budget in the design, measure against it in the build, and our audits produce an estimated run cost per candidate workflow before anything is committed to.
How do you connect an agent to Salesforce, ServiceNow, SharePoint, Snowflake, Databricks or Workday?
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.
What is the difference between delegated and application permissions when an agent reads SharePoint?
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: 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.
Do we need multi-agent AI, or is one agent enough?
One is usually enough, and we are 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. We have delivered no client system on a multi-agent framework, so that is a view rather than a finding.
Should we use LangChain, LangGraph, CrewAI, AutoGen or Semantic Kernel?
Start with none of them. That is a position rather than a finding: we have not delivered a client system on any of the five. For one agent and a handful of integrations, the native tool calling in the model API 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 is what a graph with checkpoints gives you and what 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 we have actually delivered on and is what we would evaluate first, against your own tool contracts rather than against a demonstration. On multi-agent frameworks we are openly sceptical: a crew multiplies the trajectories you have to evaluate, usually before anyone has a ground-truth set for one, and most workflows sold as needing several agents are one agent with a well-designed tool list and a clear stopping rule. 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.
The closest guides to this one
Nearest first, then the rest. Each one carries the same label: written from delivery, or the method we would bring. All 13 are on the hub.
Retrieval, RAG and permission-aware knowledge access
Answering from your own knowledge, without answering from documents the person asking is not allowed to see.
Our approachGuardrails, hallucination and accuracy control
You will not stop a language model being wrong. You can decide in advance what happens when it is.
Our approachRAG, fine-tuning or prompting: how to choose
Sorting the requirement into knowledge, behaviour and cost, so the decision survives a finance review.
DeliveredDocument intelligence to business intelligence
Getting information out of PDFs and into something the business can decide with.
Our approachAgent evaluation and assurance
Why AI pilots never reach production, and what it takes to get one through the gate.
Our approachAI governance and regulatory evidence
Building the evidence as a by-product of the work, rather than assembling it under deadline.
Talk to us about MCP, tool calling and integrating agents with your systems.
A 30-minute call with James Rooney. We'll tell you honestly which parts of this we have done before and which we would be doing for the first time, and you'll leave with a rough scope either way.
most start with a fixed-price AI Readiness Audit · £30k–£90k · 6–8 weeks
Calendar not loading? Open it on cal.com or email hello@tenhaw.com.