Docs / Start here
What Mindset is
Read this first. It takes five minutes and everything else assumes it.
The one idea
We turn the skills, MCPs and ideas your team has already built into reliable agents your company owns.
Right now that work is on laptops. Someone in finance wrote a skill that reconciles invoices. Someone in ops has an MCP server wired to the ticketing system. Someone else has a prompt they run every Monday that everybody now depends on.
Each one helps. Together they are a problem, because:
- 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 takes what you have already got and runs it 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.
The example we use throughout
Every article in this guide uses the same workflow, so you see one thing from every angle.
Invoice exceptions. Every month, finance gets invoices that do not match the purchase order. Someone works through the list by hand: pull the invoice, find the PO, work out what the difference is, check whether the contract allows it, and either let it through or query it with the supplier.
By the end of this guide, an agent does the first four steps and a person approves the fifth.
The pieces
| Piece | What it is |
|---|---|
| Agent | The thing you build and the thing that runs. It is what gets triggered, whether that is a person asking it something, a schedule, or another system calling it. It holds a system prompt (its standing instructions), a script, a set of resources it is allowed to reach, and a model, all visible and editable |
| Script | The stages your agent works through, in order. For the invoice agent: gather the invoice and the PO, work out the difference, check it against the contract, then prepare the query. Each stage says what it needs to have achieved before the agent can move to the next one |
| Function | A fixed list of steps that produces the same answer every time. The agent calls it like a tool. For the invoice agent, comparing an invoice to a purchase order line by line is a function, because there is only one right answer and you do not want a model doing arithmetic |
| Connection | A link to one outside system, with its login details held by us rather than by the agent. For the invoice agent: your finance system, and a knowledge base holding your supplier contracts. A connection holds operations |
| Operation | One specific thing the agent can do on a connection. Not "the finance system" but "get the purchase order matching this invoice number". You choose which operations exist, and the agent can only use those |
| Run | One execution, recorded. What started it, what it did, what it touched, how it ended |
How they fit together
Everything the agent touches outside Mindset goes through a connection operation. There is no other route.
That is the whole point. On a laptop, an agent with a credential can reach anything that credential reaches. Here, the complete list of what your agents can do to your finance system is the list of operations you enabled on that connection. You can read that list, and so can your auditor.
Login details never reach the model. They sit on our servers and get supplied for each individual call.
Anything that changes something waits for a person
Operations come in two kinds, and the difference matters.
A read fetches information. Get the invoice, get the purchase order, search the contract. When the agent calls one of these, it happens.
A write changes something. Post a query to the supplier, update the invoice record, send an email. When the agent calls one of these, it does not happen. The agent records exactly what it wants to send, the run carries on, and the change waits. A person opens a link, reads what is about to happen, and approves it. Only then does it go through.
An agent cannot approve a write. Not its own, not another agent's. The only thing that changes this is an org-level policy you set deliberately.
For the invoice agent, this is the shape of the whole workflow: the agent does the gathering and the comparison, and the finance lead approves each supplier query before it goes out.
Where you will be working
| Workspace | What you do there |
|---|---|
| Orca | Describe what you want built. It plans it and hands each piece to a specialist builder |
| Agents | Everything about one agent: chat, script, resources, prompt, testing, triggering |
| Connections | Links to outside systems, and the operations on them |
| Functions | Build and test functions |
| Observability | What actually ran |
| Costs | What it is costing you, broken down |
You're done when
- You can say, for the invoice example, what the agent does, what the function does, and which operations are reads and which are writes.
- You can explain why an agent cannot approve its own write.
- You know the difference between the system prompt (always) and the script (stage by stage).