Docs / Start here
Overview
We turn the skills, MCP servers and ideas your team has already built into reliable agents your company owns.
Right now that work sits on laptops. Somebody in finance wrote a skill that reconciles invoices. Somebody in operations has an MCP server wired to the ticketing system. Somebody runs a prompt every Monday that everyone now depends on.
Each one helps. Together they are a problem.
- It is not centralised. It lives with whoever built it.
- Only one person can fix it, or you pull an engineer off real work.
- You cannot prove what it did, or what it cost.
Mindset runs that same work somewhere the company owns. One place to build agents, one place to see what they did, one set of connections they are allowed to touch, and no dependency on a single model vendor.
What this guide is. What Mindset sees working across the companies it runs in: how they decide which automations to govern, what policy they write, how they bring them in without stopping anyone building, and what running that looks like week to week. Where Mindset does a part of it for you, the guide says which part.
Eight sections, about twelve minutes for this page. The articles in the sidebar go deeper. Read them when you need them, not now.
Section 01 — Where we fit
Four jobs have to be done before an agent can safely touch a real system. You already own three of them.
Access. Who may use which model. Your identity provider, and the admin consoles for Claude Enterprise, ChatGPT Enterprise and Microsoft Copilot.
Discovery. What exists that nobody sanctioned. Your tenant admin tooling, your data loss prevention, your threat detection platform.
Execution. What a sanctioned agent may do once it exists. This is Mindset, and it is the only one of the four standing in the way at the moment something gets written.
Surface. Where people work. Agents reach people through the Mindset Hub, a browser app for colleagues, through your own product as an embedded element, or back inside Claude over MCP. Nobody changes tool.
Discovery and execution do different jobs. Your tenant admin tooling tells you an agent exists. Mindset is the record of what was allowed. An agent that tooling finds, and that Mindset has no record of, reached its system by some other route.
Section 02 — The gaps that sit across a mixed stack
Most companies now run more than one. Copilot for the Microsoft estate, Claude and ChatGPT alongside it, each with its own admin console and its own idea of what a control is. Each product governs its own patch well. None of them governs the others, and five things fall between them.
- Nowhere to build that is not live. Copilot Studio has Power Platform environments. Claude and ChatGPT have one organisation or one workspace, so there is no non-production place for anyone to work.
- No identity for the agent. In Claude and ChatGPT an agent acts as the person who ran it, so every log attributes its actions to that person. Copilot Studio can issue an Entra identity.
- Limits are all or nothing. A connector is on for everyone or nobody. Copilot Studio can go down to individual actions, but an MCP server is still on or off as a whole. Nowhere can you say this agent may look up a purchase order and may not raise one.
- The record is at the wrong level. All three record conversations. An investigation needs actions: which agent, which operation, on which system, with what result, in which run.
- Nothing waits for a person. If an agent can call a tool that changes something, the change happens. Approval exists only if whoever built that agent added it.
Mindset answers all five the same way in every product, so the answer does not change depending on where a team happened to build.
Section 03 — Deciding what to govern
The policy question underneath agent, MCP and skill sprawl. Which of the things your people built are worth governing, and which to leave alone.
Six times no and it is a personal tool. Do not register it, review it or ask anyone to declare it. A policy that governs the agent tidying somebody's meeting notes will not be taken seriously on the agent touching bank details.
A Cloud Security Alliance survey of 228 security and IT professionals in early 2026 found 31 per cent of organisations let agents run under human user credentials, and only 36 per cent assign a dedicated identity per agent.
Section 04 — How this fits the way your teams already build
Nobody moves tool. People keep building where they build today, and the working result comes into Mindset. The word that causes most confusion here is environment, because it means something different in each product.
Where Claude Enterprise and ChatGPT Enterprise have nothing equivalent to a test environment, Mindset environments fill that gap. Copilot Studio already has Power Platform environments, which are a separate object with different rules and no relationship to Mindset environments.
Mindset gives you environments. Named partitions inside your Mindset organisation, normally Test and Production, each with its own connections pointed at its own systems. An agent built in Test cannot reach a real system, because the credentials for the real system are not in that environment.
- Nothing is copied for you. Promoting means making the same change again in Production once it holds up in Test.
- You cannot invite somebody into Test only. Membership of a Mindset organisation gives a person every environment in it.
Section 05 — How something gets added
Four steps to bring an automation in, done once. After that the agent runs, and every run is recorded.
| Term | What it means in Mindset |
|---|---|
| Connection | A link to one outside system, holding its login details. Those details never reach the agent or the model. |
| Operation | One named thing an agent may do on a connection. Not the finance system, but get the purchase order matching this invoice number. |
| Run | One execution, recorded from whatever started it to however it ended. |
A Claude skill becomes a Mindset agent. An MCP server becomes a Mindset connection, with each of its tools as a named Mindset operation.
Section 06 — The rules we enforce
Ten rules. Mindset makes seven of them true on its own, whether or not anybody has read the policy. Three are conventions your team has to hold, and those are the three worth writing down.
The rule to decide deliberately is rule three. Every Mindset operation is marked read or write.
- A read fetches information. The agent calls it and the call happens.
- A write changes something. The agent calls it and nothing happens yet. It records exactly what it wants to send, the run carries on and finishes, and the change waits behind a link a person opens.
Write approval is on by default. It can be turned off, but only for the whole Mindset organisation, never per agent and never per operation. When that setting stands in for a person, the record names the setting rather than inventing an approver. Leave it on for the first month.
Section 07 — Getting started
Two phases. Find what your people already built, then get one thing live with us alongside.
Finding them. Three routes, and most companies need all three.
- Ask your AI leads and power users. They tend to have a list already.
- Run one session per function. The question is not what could be automated, but what somebody has already automated and is quietly relying on.
- Read what your tenant admin tooling and data loss prevention already found. Most is noise. The entries touching a real system are the ones you want.
Qualifying them. Three questions per item, twenty minutes for the whole list.
- Can it reach what it needs through an API, a database, a spreadsheet or an MCP server?
- Is it acceptable for a person to approve the changes it makes?
- Can you describe the work as stages, each with something it must have achieved?
Three yeses and it moves as it is. Start with the biggest, because you already know how it should behave.
The first sprint runs about three weeks with us, then a month of watching.
Section 08 — Running it week to week
Most of the watching is done for you. Mindset holds every write until a person approves it, blocks any version that fails a single test criterion, marks every agent and connection as working, failing, idle or never used, and compares what each agent was granted against what it actually called.
A person does the rest: ten minutes each morning reading what failed, what is waiting on an approver, and what ran but changed nothing; thirty minutes each week reading the new agents and operations, and the granted-against-called comparison. One named person, and a backup — that is the whole standing commitment.
The guide to the record is itself an agent, published to your team over MCP, so the question gets asked from Teams, Copilot, Claude or ChatGPT and answered there — "did the invoice agent run this morning?", "what failed yesterday, and at which step?", "what is waiting on an approver?", "which agents can write to finance?", "what did we spend, and on which agent?" — as a sentence, a number, a table, or over OpenTelemetry into your own tooling.
Name one owner. In the same Cloud Security Alliance survey, responsibility for agent security was split across security, engineering and IT, IAM teams were rarely the primary owner, and some organisations reported no identifiable owner at all. On who is accountable when an agent causes an incident: 28 per cent said security or IT, 25 per cent engineering, 18 per cent the business owner, and 15 per cent did not know.