Roll out Mindset in your company

Where Mindset fits

Mindset is an agent framework with optimization at its core. You build agents in configuration, then optimize them on cost, outcome and security. Governance (named operations, approvals, audit, environments) is the security part of that.

Most companies already own the tools around it:

Mindset sits beside your identity provider and your discovery tooling. It's where the agents that touch real systems are built, run, recorded and improved. The same words mean different things across these products, so check the glossary before a meeting with your Microsoft or Claude admins.

Step 1: find what already exists

The material is already there: skill files, prompt documents, MCP servers on laptops, and spreadsheets someone updates by hand every Friday. Look for what already works.

• Ask the people who already build. Your AI leads and power users usually have a list.
• Run one session per function. Finance, operations, HR, an hour each. Ask what someone has already automated and is quietly relying on.
• Read what your discovery tooling found. Most of it is noise. The entries that touch a real system are the ones you want.

Write them in one list, with the person who built each one.

Step 2: decide what belongs in Mindset

Ask six questions of each automation on the list:

1. Does it change anything? Reads are recoverable. Writes aren't.
2. Can that change be undone?
3. Does anyone other than the builder rely on the output?
4. Does it run under a person's own credentials?
5. Does it run when nobody is watching, on a schedule or a trigger?
6. Does it touch data you'd have to report on, such as personal or regulated data?

Any single yes, and it belongs in Mindset. Six noes, and it's somebody's personal tool. Leave it alone. Don't register it, review it or ask anyone to declare it.

Then check it can move:

• Can Mindset reach what it needs? An API, a database, a Google Sheet, an MCP server or a knowledge base. See Will your automation work here?
• Does it need a browser? Mindset can't drive a web page or click through a screen. If there's no API, it doesn't move.
• Which parts must wait or happen in order? Most of the work becomes the agent's instructions. Only the stretch that has to wait for a person, or must happen step by step, becomes a script.

Start with the biggest automation that passes. You already know how it should behave, which makes it the cheapest thing to learn on.

Step 3: take the first one all the way

One automation, end to end, with us alongside. The point is that your team has done every step once and doesn't need us for the second.

Don't build the second agent until you can say what a normal run of the first looks like. The second one costs a fraction of the first, because the connections and operations already exist.

Decisions to make before day one

• Region. Your org's region comes from the Mindset deployment you sign up on, and it can't change afterward.
• Environments. Every org starts with one, called Sandbox. An org admin creates more, usually Test and Production. You can rename an environment later, but its address (the slug) is permanent and it can't be deleted. Connections belong to one environment, and nothing copies between them. See Environments.
• Write operations. The setting Turn on connections that change other systems automatically (Settings → Systems) is on by default. With it on, a new write operation is enabled as soon as it's added. Turn it off and a person approves each new write operation once. Either way, approval is per operation, not per call. If a specific change needs a person each time, build that into a script as a question (for example, Slack buttons), and the run waits for the answer.
• Retention and export. In Settings → Governance, set audit retention, conversation retention, and whether traces go to your own tooling over OpenTelemetry.
• Personal agents. Off by default, in Settings → Defaults. When on, members build their own agents in the Hub. A personal agent holds no connections. It can only hand work to agents already available to its owner, so it gives nobody new access. This is where personal productivity agents belong.

Conventions your team keeps

Mindset enforces a lot on its own: every outside call goes through a named operation, credentials stay on the connection, an agent can never approve an operation, and every run is recorded. See What Mindset enforces for you. Three things it can't enforce, so write them down:

• Each agent has a named owner and a backup. An org agent has no owner field. Put the owner and backup in the agent's description, in the same format every time, for example Owner: Priya Shah. Backup: Tom Ellis.
• Personal tools stay personal. Don't register or review them. A policy that governs somebody's meeting-notes helper won't be taken seriously on the agent that touches bank details.
• Agents nobody uses get switched off. Anything that hasn't run in thirty days is a question. Turn its Available switch off (it then shows as Unavailable), or delete it.

Who does what

Daily and weekly habits

Everything here comes from Govern in AMS: Monitor (Cost, Performance, Resources, Topology), Log (every session, in order), Optimize (acceptance tests and experiments) and Audit. Monitor has an agent docked on the left that you can ask in plain words.

Put the monthly hour in the diary before the first agent goes live.

Things to know about the record:

• Never used and idle are different. An agent that has never run has a trigger problem. One that used to run and stopped has a different one.
• Granted against called. Topology shows what each agent was granted and what it actually called. A call with no current grant is worth looking at the same day.
• Getting the record out. There is no CSV export of runs. A single session downloads as JSON from the Log. For everything else, turn on the OpenTelemetry export.
• Two numbers Mindset can't give you. Time saved against the manual way, and how many people can now do what only one could before. Capture the baseline before the agent goes live, because nobody can reconstruct it afterward.

What can go wrong

• The second automation still needs us. Then the first sprint didn't work, however well the first agent runs.
• Nobody holds the review. The habits above decay first. The usual failure is that the monthly review never gets scheduled, and the first one happens after an incident.
• An agent's risk changes after launch. It starts reaching a new system, starts calling other agents, or runs far more often than it used to. Look again when any of those happen, not only at the start.