# Will your automation work here?

> Sort the automations your team already runs into moves now, needs rearranging, or leave it, and pick the one to build first.

Use this page to sort each automation your team already runs into one of three piles: moves now, needs rearranging, or leave it. It takes about twenty minutes for a typical list.

## The three questions

Ask these of each automation.

### 1. Can it reach what it needs through an API, a database, a spreadsheet, or an MCP server?

Mindset reaches outside systems only through [connections](https://docs4.mindset.ai/docs/ams/connection-types): a REST API, a Postgres database, a Google Sheet, a knowledge base, an MCP server, or a SaaS system through StackOne.

An **API** is how one system lets another fetch or change its data without a person clicking anything. Most business software has one, even when the vendor calls it "integrations". An **MCP server** exposes another product's tools to AI clients. If someone on your team already runs one on a laptop, you can connect it.

**Passes:** an invoice check that reads from your finance system's API and a Google Sheet of purchase orders.

**Doesn't pass:** a step that only works when a person logs into a website and clicks through its screens. Mindset has no browser automation.

### 2. Is it acceptable to approve each kind of change once?

Each operation is a read or a write. A write changes something in another system, such as sending a supplier query or updating an invoice record. Approval happens per operation, once, when the operation is added. After that, every call to it runs.

By default, new write operations are enabled with no person involved. An admin can turn that off in **Settings → Systems**, and then a person approves each new write operation once. Either way, no individual call waits for approval.

If every single change needs a person to look at it first, you build that into a [script](https://docs4.mindset.ai/docs/ams/write-a-script) as an ask phase. The run posts the decision to a person (for example, as a Slack message with buttons), waits for the answer, and then carries on.

**Passes:** an agent that reads invoices, works out the discrepancies, and sends a supplier query once the finance team has approved the "send supplier query" operation.

**Needs rearranging:** the finance lead wants to read every query before it goes. That's fine, but it needs an ask phase in a script. See [When the answer is no](#when-the-answer-is-no).

### 3. Can you say what a good result looks like?

Mindset can't check work nobody has defined. You write the agent's instructions, and you [test its behavior](https://docs4.mindset.ai/docs/ams/test-an-agents-behavior) against criteria you set. Both need a clear picture of what done means.

**Passes:** "For each exception, the agent drafts a query that names the invoice, the purchase order line, the difference, and the contract clause that applies."

**Needs rearranging:** "It looks at the invoices and sorts them out." You'd have no way to tell whether it worked.

Three yeses and the automation moves as it is. Start with the biggest one. You already know how it should behave, so it's the cheapest one to learn on.

## When the answer is no

Most of the time the problem is how the job is put together, not what it does.

### It logs into a website and clicks through the screens

**Example:** a script signs into a supplier portal, opens the statements page, and copies the balances into a spreadsheet.

**Instead:** find out whether the supplier has an API. Then create a connection to it, open its **Operations** tab, paste a link to the API documentation, and press **Set up operations**. The builder reads the documentation and checks whether the host publishes a description of its API. It registers the read operations and proves each one by calling the real endpoint, then tells you in plain words which writes it found. If it can't find what it needs, it asks you instead of guessing. For a Postgres database, it reads the tables and checks what your database login is allowed to do.

If there really is no API, keep that one step with a person and let the agent do the work on either side of it.

### Someone must look at every change before it goes out

**Example:** a script that sends every unmatched invoice back to the supplier at 2am.

**Instead:** let the run gather everything overnight. Then add an ask phase that puts every pending query to the finance lead in **one** message, and send the approved ones after. One message to read in the morning is a decision someone actually makes. Fifty separate requests get waved through.

### It runs over thousands of records

**Example:** a monthly job over 4,000 invoice lines.

**Instead:** pick one of two options.

- **Small work per record:** a [function](https://docs4.mindset.ai/docs/ams/build-a-function) step can repeat one call for each item in a list. It runs eight items at a time, up to 1,000 items. A failing item is recorded as failed and the rest carry on.
- **Large work per record:** make the unit smaller, such as one run per batch of invoices on a schedule. See [Limits and run behavior](https://docs4.mindset.ai/docs/ams/limits-and-run-behavior).

### It needs to start when something happens elsewhere

**Example:** run when a new invoice lands in the finance system.

**Instead:** use whichever of these the other system supports.

- **It sends webhooks:** add a webhook trigger to the agent and paste the address Mindset gives you into the vendor's console.
- **It's your own software:** have it call the agent with an org API key.
- **Neither:** run the agent on a schedule and have it work out what's new since the last run. The shortest interval is every 30 minutes.

### It produces a Word document, or reads a scanned PDF

**Example:** the monthly exceptions report as a formatted document.

**Instead:** connect a document service through its API or MCP server, so its tools become operations. Mindset doesn't pass documents to the model. It can fetch a file through one operation and hand it to another service, such as a text extraction service, and the agent reads what comes back.

## What to leave where it is

- **Its only route is a website's screens**, and the system has no API, database, sheet, or MCP server.
- **It's one person's tool.** Nobody else relies on it, it changes nothing in another system, and it touches no data you'd have to report on. Leave it alone.

## You're done when

- Every automation on your list is marked moves now, needs rearranging, or leave it.
- For each one that needs rearranging, you know what you'd change.
- You've picked the one you're building first.
