Just Looking, or Actually Touching? - The One Question MiNa Asks

TL;DR MiNa first needs to distinguish whether the user only wants to inspect something or actually change infrastructure. Separating read-only work from change actions is what makes AI operations fast and safe.

In the previous article, we explained how MiNa answers an operator's question by combining impact, ownership, and past cases. For a question like "What is affected if this domain goes down?", MiNa gathers DNS, proxy, service, server, and owning team together.

But operators do not always ask read-only questions. Some questions change things: "Delete this container," "Stop this GPU job," or "Lock this user account." If the same MiNa answers those questions in the same way, it becomes dangerous.

This article is about the one question MiNa asks: "Are you only looking, or are you going to change something?"

The Same Emergency Room, Two Modes

Emergency teams do two different kinds of work. They read patient charts, and they also prescribe medicine or decide on procedures. The same doctor may do both, but the process is completely different. Opening a chart does not change the patient. A prescription can affect the patient immediately if it is wrong.

When MiNa receives an operator's question, it first makes the same split. "Is this a read-only question, or is it a change request?" The same MiNa asks and answers, but the two paths are different.

The Fast Path - Read-Only Questions

Read-only questions can move quickly.

• "Show me the server list"
• "Who is using the GPU?"
• "Where does this DNS record point?"
• "Which team owns this domain?"

For these questions, MiNa does not need deep deliberation. It directly calls the required tool and returns the result. In emergency-room terms, it immediately opens the chart. Fast answers help operators make the next decision quickly.

The Careful Path - Questions That Change Things

Change requests cannot move at the same speed. MiNa goes through three steps.

1. Answer the impact first with a dry run

MiNa first shows, "If this is removed, these things will be affected." Even for deleting one container, it shows the site supported by that container, the connected proxy, and log-retention policy. Nothing has actually been changed yet.

2. Check the owning team

MiNa also answers who owns the area: "This belongs to the infrastructure team," or "This requires the data team's authority." This protects operators from casually making changes outside their responsibility.

3. Wait for explicit approval

MiNa does not execute until the operator explicitly confirms. It is similar to getting consent before a risky procedure in the emergency room.

Why the Two Paths Must Be Separate

If there is only a fast path, operations become dangerous. A change request could be executed before the operator understands its impact.

If there is only a careful path, operations become frustrating. If even simple read-only questions ask for confirmation every time, operators will stop asking MiNa and go back to clicking through menus manually.

Fast triage plus careful treatment - the same shape that helps an emergency room work well also applies to infrastructure operations. Both tracks need to exist together.

Closing

MiNa's ability to combine answers is important, but so is its ability to know when to stop and ask the operator again. The MiNa we use every day with internal infrastructure answers quickly when speed matters, and pauses when care matters.

In the next article, we will look at the operation chain MiNa follows: how it starts from one domain and traces all the way to backups and owning teams.