Miraxa Ask and Auto Modes

How Miraxa works on your live systems turn by turn, when it pauses for your approval, and what changes when you switch from Ask to Auto.

Overview

Most of what Miraxa does is build things you then run: it designs a workflow on the canvas, you review it, and Spojit executes it on a trigger. Ask and Auto modes are different. In these modes Miraxa works on your live systems now, one turn at a time, the way a colleague with terminal access would. That covers the one-off jobs that never justified building a workflow: investigating a connected database, reshaping a CSV, reconciling two systems that have drifted apart, or running a data fix you would otherwise do by hand.

Both modes reach exactly the same tools. The only difference is when Miraxa stops and waits for you. Ask pauses before every change. Auto removes that pause, but your workspace governance policy is still the ceiling: anything your policy marks for approval still pauses, anything destructive still pauses, and anything your policy denies stays denied. If you want Miraxa to think through an approach with no possibility of it running anything, use Plan mode instead.

Before You Start

The systems you want Miraxa to work on need connections in Spojit already. It calls the same connectors your workflows use.
Ask is the default and needs no special permission.
Auto is available to Editors, Admins and Owners by default. If you do not see it in the mode selector, your workspace administrator can grant it under the Miraxa permissions.
Understand that this is production. An approved write against live data is as real as one you typed yourself.

Choosing a Mode

Open Miraxa from the navigation bar and pick the mode in the selector in the composer, alongside Plan:

Plan: Miraxa reasons about the work and tells you what it would do. Nothing runs.
Ask: Miraxa reads freely and pauses before anything that changes state. This is the default.
Auto: Miraxa works without the mode-level pause, stopping only where your policy requires it or before something destructive.

The choice is remembered per conversation, so a session stays in the mode you set until you change it, and a new conversation starts in the mode you chose last. Switching mode while Miraxa is paused takes effect when it resumes.

What Miraxa Can Reach

A Linux workspace: a real environment with bash, python3, psql, mysql, curl and git available.
Your connections: the same connectors your workflows use, so it can read and write in the systems you have already connected.
Your files: it lists, reads, writes, moves and deletes in your workspace file store, so results land somewhere you can get at them.
Your knowledge base: it searches your collections when it needs context from your own documents.

Files and installed packages persist across calls within a task, so Miraxa can build up state step by step: fetch data, install what it needs, transform it, check the result, then write the output to your files.

How Approvals Work

In Ask mode, reads run freely and writes, installs and deletes stop and wait for you. In Auto mode, Miraxa pauses only where your workspace policy requires an approval, or before a destructive action such as a delete.

When Miraxa pauses, an approval card appears inline in the conversation showing the action it intends to take and how it classifies that action. Nothing runs until you approve. Rejecting it returns control to the conversation, so you can redirect it rather than starting over.

Workspace governance applies on top of this in both modes. A tool your policy denies stays denied, and actions that require a named approver still route to that person. This is configured with your approval policies, not in the chat.

The Sandbox

Commands run in an isolated sandbox, separate both from the services that run Spojit and from your own systems. Each session gets its own environment with its own kernel boundary, so one session cannot see or touch another, and the workspace is discarded when the session ends.

The sandbox can reach the public internet, which is what makes it useful for fetching a package or calling an API. It holds no credentials of its own: when Miraxa calls one of your connections, the credential is applied at the connector boundary, outside the sandbox, so a command running inside it never sees your keys.

Tips

Ask for small, verifiable steps. "Show me the schema first" beats "fix the data", because you can check the reasoning before approving anything that writes.
Read the approval card rather than skimming past it. It tells you exactly what is about to happen, which is the whole point of the pause.
Start read-only. Have Miraxa investigate and report, then decide whether to let it act.
Point it at your files. Asking it to write results into your file store gives you something durable to check instead of output that scrolls away.
Use Auto for work you have already reviewed. Run a task through Plan or Ask first, then let Auto finish something you understand end to end.

Common Pitfalls

Treating Auto as unsupervised: Auto removes the mode-level pause, not your governance policy. It is for work you have already reviewed, not for walking away.
Approving in bulk: clicking through approval cards without reading them turns a safety feature into a formality. Each card describes a real action against live data.
Using the chat for repeated work: live-system work is for one-off jobs. If you find yourself asking for the same thing every week, ask Miraxa to build it as a workflow instead.
Expecting the workspace to persist: the sandbox is temporary and is discarded when the session ends. Anything you want to keep has to be written to your file store.
Forgetting credits apply: a long session on your live systems with a capable model uses more credits than a short chat.

Learn More

Ready to build this?

Start on the free plan: 500 AI credits a month, no card needed.

Start free