Operators

An operator is an AI worker you set up once and then leave to keep an eye on one environment: you give it a job in plain English, decide what data it can read, and give it a monthly budget. This page covers turning Operators on, creating and configuring one, what it can access, asking it questions in the portal and in Slack, and what happens when its budget runs out. To have operators run on their own, see Operator schedules.

What an operator is

Each operator lives in one environment and has:

• A job. A plain-English description of what it watches and what counts as a finding. This is the instruction it works from.
• Its own access. It reads through its own security group and its own Solidafy key, not through the account of the person who made it.
• A monthly budget in credits. When it is spent, the operator stops working until next month or until someone raises the budget.
• Optionally, a schedule and a Slack channel to copy its findings to.

An operator answers by calling the environment's curated views (the same curated tools the hosted MCP server offers), never by querying raw tables. Its answers come back as structured reports: text, tables, figures and charts, plus suggested follow-up questions.

Operators are not the same thing as Scout. Scout is the assistant you chat with as yourself. An operator is a standing worker with its own job, access, budget and schedule.

Turning Operators on

Operators are off by default for every organisation. To use them, ask Solidafy to switch Operators on for your organisation; your own admins cannot turn it on.

Once it is on, access follows the Operators permission, which is set per environment role:

An administrator can change this for a role in the permission editor (see Security and access). With the permission, you see Operators in the sidebar under Workspace. The same permission covers creating, configuring, asking and scheduling operators, in the portal and through the API.

Creating an operator

Open Operators and choose New operator. The form is split into cards; most of them can be changed later under Configure on the operator's card.

Start from a template

When you create an operator you first pick a starting point:

• Security Operator: watches for unusual access and risky permissions, and explains why each one matters.
• FinOps Operator: tracks what the business is spending, what changed, and what is driving it.
• New operator: start from nothing and write the job description yourself.

A template only fills in the name, the job and a starting budget. It grants no data, and you can change every word of it afterwards.

Name

What the operator is called. Names are unique within an environment.

The job

The job (sometimes called the charter) is the instruction the operator works from, up to 8,000 characters. A good job says who the operator works for, what it looks for, how to check each thing, and what makes something worth reporting. For example:

You watch cloud spend for the platform team.
Look for: any service whose daily cost rose more than 30% week on week.
Check it by comparing the last 7 days with the 7 days before.
It counts when the increase is over 50 EUR a day.
Out of scope: one-off credits and refunds.

If you would rather not start from a blank page, choose Describe the job instead above the text box. Say in a sentence or two what the operator should watch, for example "Watch our warehouse stock and warn me before a product runs out.", and choose Write the job. It drafts a job with a role, the things to look for (each with how to check it and the threshold that makes it count) and what is out of scope. Type into Ask for a change and choose Redraft as often as you need, then Use this job description. While you are creating an operator and have not chosen a name yet, it also suggests one. An organisation can draft 50 job descriptions a day; after that, write one yourself or try again the next day.

What it can read

When you create an operator, the What it can read card decides which security group it joins. By default a new, read-only security group is made for it, named after the operator, granting:

• Views: the curated views you choose.
• Data: the namespaces and tables those views read. Everything on offer starts selected, because a view only runs when the tables it reads are granted too.

If you do not manage security groups yourself, you can only hand an operator views, namespaces and tables you can read. If you have the Security Groups permission, you can instead choose Existing group and put the operator in a group that already exists; it then reads whatever that group grants, now and as the group changes.

After creation, the group is managed under Settings > Security Groups, not on the operator. See What an operator can access.

What it can do

On an existing operator, What it can do narrows which curated views it may call. Allow every tool in this environment is the default, and with it a curated view published later becomes available to the operator straight away. Untick it to choose a subset; you must keep at least one.

Every view in the environment is listed, but a view the operator's security group does not grant is shown as "not granted by its security groups" and cannot be ticked here. To give the operator that view, change its group under Settings > Security Groups.

When it runs

An operator can have one built-in schedule:

• Only when I dispatch it (the default): it runs only when someone asks it something.
• Daily, Weekly or Monthly, at a time of day you pick.
• Custom cron expression: five fields, in UTC.

Times are entered in your computer's timezone and stored as a fixed UTC time, so in a timezone with daylight saving the run moves by an hour for part of the year; the form warns you when that applies. A schedule can run at most once a day. For a schedule that follows your timezone's clock changes, asks several operators, or runs when pipelines finish, create a standalone schedule instead (see Operator schedules).

Where it reports

Optionally, a notification channel to copy the operator's findings to in Slack. The default is No Slack channel. Reports are always readable in the portal either way. Channels are set up under Settings > Notifications.

Budget

The hard monthly ceiling, in whole credits. Work stops when it is reached (see When the budget runs out). Each run's cost is shown in credits on the run, and the Operators page shows Spend this month. Credits are the same unit used for Code Review.

Status

A new operator is always created paused: nothing runs until you enable it. On an existing operator, the Status card switches it between Enabled and Paused. A paused operator answers no questions and its schedules skip it.

Deleting an operator

Choose Delete from the menu on the operator's card. Deleting revokes the operator's key and removes the operator together with its conversations, run history and memory.

What an operator can access

Its own security group

An operator reads exactly what its own security group grants, and nothing at all when it is in no group. It does not inherit the groups of the person who created it. Anything an operator creates is granted to its own group, not to its creator's.

An operator belongs to one security group at a time. Under Settings > Security Groups, each group has an Operators panel next to its members, with Add operator; adding an operator that is already in another group moves it. On the operator's own page, the Data access card shows its group and how many views it grants. With no group, it says the operator cannot read anything.

See Security and access for how security groups work.

When you ask it something

When you ask an operator a question in the portal, it reads as both itself and you: it can only use views that its group and your own group both grant, at the lower of the two access levels, with your row-level data policies applied. So asking an operator never shows you more than you could see yourself. A conversation like this is visible only to you.

Questions asked in Slack and plain scheduled runs read under the operator's own access only, because there is no single person they act for.

Its key

Creating an operator gives it its own Solidafy key, named Operator: <operator name>. It is listed under Settings > API Keys alongside personal access tokens, and it does not expire.

• Revoking the key stops the operator. Its configuration stays, but every run is refused with "This operator has no live identity." To restore it, create the operator again.
• The key is recorded as created by the person who made the operator, and it stops working if that person is no longer an active member of the environment.

These keys are not the same as the short-lived solidafy-operator (session) tokens Scout uses for each chat turn.

Asking an operator

Open an operator to ask it something. Each question starts a run, and the page follows it live: each step, the views it read, and what the run cost in credits. The answer is a structured report with suggested follow-up questions underneath.

Conversations

Conversations are listed newest first, and you can search them by what was said. A follow-up question carries the recent conversation with it, so you can ask "and last month?" without repeating yourself. You can edit your latest question, which replaces it and its answer.

An operator works on one question at a time in each conversation; asking again before it finishes gets "This conversation is already working on a question. Wait for it to finish." It can work on up to five conversations at once. Beyond that, you see "This operator is busy with 5 conversations at once. Try again when one of them finishes."

Asking colleagues

While it works, an operator may ask other enabled operators in the same environment for help, for example a security operator asking the FinOps operator about a cost spike. Each of those questions is a run of the colleague's own, paid from the colleague's budget, and is shown under the answer so you can see where part of it came from.

Memory

The Memory card lists the facts an operator keeps between conversations. Use Teach to add one by hand (up to 300 characters); facts you write are pinned and never dropped, and an operator holds up to 15 of them. During a conversation you can also tell an operator to remember something. It then offers the fact back to you to keep (reworded if you like) or dismiss.

Memory is for how to read your data, such as "spend is reported in EUR" or "the platform team owns every repository starting with infra-", not for figures or one-off findings.

Feedback

Rate an answer with thumbs up or thumbs down. You can change or remove your rating, and each person sees only their own.

In Slack

With a Slack workspace connected under Settings > Notifications, operators post as your workspace's bot and answer when they are mentioned in their channel. Replying in the thread continues the conversation. When several operators share a channel, the one named in the message answers.

When the budget runs out

The budget is checked before every run against what the operator has spent this calendar month. Once it is spent:

• A question in the portal or in Slack is refused with "This operator has spent its monthly budget (N credits). Raise the budget or wait for next month."
• Scheduled runs are skipped until the next month starts or the budget is raised.

Spend is recorded when a run finishes, so several runs started at the same moment can together go slightly past the ceiling.

Operators that apps install

When your organisation installs the Engineering Delivery, FinOps or SecOps app, the app installs its own operator, named Scout. It is created enabled, can use only that app's own tools, has no Slack channel, and has a monthly budget of its own. When you ask it something, it reads the app's data as you, so it only sees what you can see.

It is listed under Operators with the rest and can be configured, paused or deleted like any other. Uninstalling the app removes its operator and the schedules the app made; operators and schedules people made are never touched. For how Scout works in Engineering Delivery, see Goals, alerts and Scout.

Using the API

Everything on this page is also available through the REST API under /api/v1/operators, and schedules under /api/v1/operator-schedules. Every call needs the Operators permission. A question asked with your personal access token acts for you, just as it does in the portal:

curl -s -X POST https://api.solidafy.com/api/v1/operators/<operator-id>/ask \
  -H "Authorization: Bearer $SOLIDAFY_PAT" \
  -H "Content-Type: application/json" \
  -d '{"question": "Anything unusual in spend since yesterday?"}'

The call returns the run straight away, usually with status still running. Read it back with GET /api/v1/operators/<operator-id>/runs?session_id=<session-id> until its status is succeeded (the answer is filled in) or failed (the error says why). Pass the returned session_id with your next question to continue the same conversation.

When you create an operator through the API, leaving out access creates it in no security group, so it can read nothing until you add it to one under Settings > Security Groups.