Docs / Implementing it
Setting up Mindset
Find what already exists, then get one thing live. Two phases, ending with a short sprint that puts one automation live with us alongside.
Phase one: find what already exists
The material is already there, in skill files, prompt documents, MCP servers on laptops and spreadsheets somebody maintains by hand every Friday. You are looking for what is already working, not for ideas nobody has tried.
- Ask the people who already build. Whoever your AI leads or power users are. They usually have a list already.
- Run one session per function. Finance, operations, HR, an hour each. The question is not what could be automated. It is what somebody has already automated and is quietly relying on.
- Read what your discovery tooling found. Tenant admin tooling and data loss prevention already have a list. Most of it is noise. The few entries touching a real system are the ones you want.
Write them down in one list with the person who built each one. That list is the asset, and it usually surprises people.
Then qualify the list
Three questions per item, twenty minutes for the whole list.
- Can the automation 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 the automation makes?
- Can you describe the work as stages, each with something it must have achieved?
Three yeses and the automation moves as it is. Start with the biggest, because you already know how it should behave, which makes it the cheapest thing to learn on. Anything driven by clicking through a screen, and anything that has to pick itself up after a failure, does not move.
Phase two: the first sprint
One automation, taken all the way through, with us alongside. Not for the automation. For the fact that your team has done every step once and does not need us for the second one.
| Phase | What happens | Who |
|---|---|---|
| Setup | Create the Mindset organisation, its environments and its governance settings. Region, retention, whether OpenTelemetry export is on, whether write approval stays on. | Your Mindset owner, with us |
| Connect the first system | Credentials, discover operations, enable the ones the automation needs, mark each read or write. The conversation with whoever owns that system. | System owner, with us |
| Build and test | The automation comes into Mindset, which reads what already exists in your Mindset organisation, proposes a plan and waits. Then the stages, then the behaviour criteria. Also where you settle which model the agent uses, by running the same criteria against a cheaper model and taking the cheapest that still passes everything. | The person who built it, with us |
| Live and watched | Make the same change in your Mindset Production environment and publish it. Then it runs, and you read the runs daily. Nothing else gets built until you can say what a normal run looks like. | Mindset owner and system owner |
What the first one costs you
The effort scales with what you are bringing across rather than with Mindset, so treat these as the shape rather than a quote.
| Roughly | What moves it | |
|---|---|---|
| Governance decisions | About an hour | Fixed. Same for everyone. |
| Each system you connect | One conversation with the owner, then setup | How many systems the automation touches, and how many operations it needs on each. An API with good documentation is quick. A database where nobody knows the schema is not. |
| The automation itself | Days, not weeks, if it already works | How many stages, whether the work is already written down, and whether it writes or only reads. |
| Your team's time across the sprint | A couple of days for the Mindset owner, plus the builder | Mostly whether the people who own the systems are available. |
The second automation costs a fraction of the first, because the connections and the operations already exist. That is the number worth planning around, not the first one.
Decisions to make before day one
- Region. Fixed when the Mindset organisation is created and not changeable afterwards.
- Mindset environments. At least Test and Production. Names cannot be changed later.
- Write approval. Leave it on for the first month. Revisit once you can describe what a normal run looks like.
- Retention and export. How long records are kept, and whether the full record goes to your own logging tooling over OpenTelemetry.
- Personal agents in Mindset. Off by default. Turning them on gives people somewhere in Mindset to experiment that holds no connections and reaches nothing. This is where personal productivity agents belong.
The thing to protect in the first month is the second automation, not the first. If your team needs us for it, the sprint did not work, however well the first one runs.