Roll out Mindset

Step 1: find what already exists

The material is already there: skill files, prompt documents, MCP servers, 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 HTTP API, a database, a Google Sheet, a remote MCP server or a knowledge base. An MCP server that only runs on someone's laptop can't be connected. 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: make the decisions before day one

An org admin makes these once, mostly in Settings:

• 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 in Settings → Environments, usually Test and Production. You can rename an environment later, but its slug is permanent and it can't be deleted. Connections belong to one environment, and nothing copies between them. See Environments.
• Model keys. On the shared deployment, your own agents need a model key before they can run. Orca and the builders run without one, so you can start building first. Decide whose provider account pays, and whether the built-in agents also run on your key (Run the built-in agents on our own key, in Settings → Governance). See Use your own model provider keys.
• Embedding keys. Knowledge search uses a separate OpenAI embedding key, in Settings → Embedding keys. Without one, the deployment's own key is used.
• Write operations. The org setting that turns on new write operations automatically is on by default, in Settings → Systems. Decide whether to leave it on, or turn it off so a person approves each new write operation once. See Approve what an agent can do.
• Personal data. In Settings → Governance, decide whether the personal data policy is on. It's off by default. See Personal data.
• Retention and export. In Settings → Governance, set audit retention, conversation retention, and whether traces go to your own tooling over OpenTelemetry.
• API keys. If outside systems will start agents, an admin creates keys in Settings → API keys. Each works in one environment only.
• 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 published to its owner, so it gives nobody new access.
• AI clients. If people will call agents from Claude, Cursor or Copilot, send them the invite from Settings → Systems → Connect an AI client → For users. See Use your agents from Claude and other AI clients.

Step 4: 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.

Activating a version that puts new script text live is refused while any operation it calls is untested in that environment. See Test before it goes live.

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.

What can go wrong

• The second automation still needs us. Then the first sprint didn't work, however well the first agent runs.
• The first agent won't activate in Production. Its operations haven't succeeded there yet. Run the test parameters in Production, or an admin goes live untested.
• Agents say the org needs a model key. Nobody set one. An admin adds it in Settings → Model keys.

You're done when

• You have one list of automations, each marked in or out of Mindset.
• The day-one decisions are made and written down.
• The first agent runs in Production, and your team could build the second without help.