There is a step in my pipeline where the system has everything it needs to act, and it waits.
It is not waiting on data. It is not waiting on compute. It is waiting because I built the wait, and I built it after realizing that letting a system answer and letting a system act are two different design problems.
Last issue was about provenance: the record behind the answer. Once a system can explain where an answer came from, a harder question shows up quickly. Should it be allowed to do anything with that answer?
Before an AI system takes an action, I want three things designed: scope, approval, and record. What it is allowed to change. When it has to wait for a person. What gets written down when the action happens.
This matters because answering and acting carry different risk. A wrong answer sits on a screen where someone can question it. A wrong action is already inside the system. A row updated, an email sent, a job triggered downstream. By the time anyone questions it, it has moved.
The first check is scope.
Access decides what a system can see. Scope decides what it can change. They sound like the same conversation, and they are not. A workflow that reads a table can embarrass you. A workflow that writes to one can hurt you.
In my ETL pipeline, the model classifies records all day. It never touches the production table directly. Its output lands in a staging layer, and the only thing that writes to the system of record is a gated MERGE, built to be idempotent so a rerun cannot apply the same change twice. The model produces. The pipeline commits. Keeping those jobs separate was a decision, not a default.
Scope also means sorting actions by reversibility. Drafting is not sending. Flagging is not deleting. A suggestion sitting in a queue is not a production write. When nobody does this sorting, every action the system takes becomes production-grade by accident.
The second check is approval.
Not every action needs a human. A system that pauses for everything is a system nobody uses. But a system that pauses for nothing is a system nobody can defend. The design work is matching the pause to the consequence.
I run an agent chain that builds features for my pipeline. The research step runs on its own. The spec gets written on its own. Then the chain stops, because the next step changes code, and I have not approved the plan yet. One approval point, placed exactly where the cost of being wrong jumps.
Here is the principle underneath all of this. A system does not know when to stop. Stopping is not a model capability. It is an architectural decision, and if nobody makes it, the system's boundary becomes whatever the workflow happens to permit.
The third check is record.
Last issue argued that an answer needs a record behind it. An action needs a stronger one. What ran, what it changed, and what allowed it to proceed, whether that was a person or a rule. Ideally, what the data looked like before.
The difference shows up the first time something breaks. "The system did something last night" is an incident. A run ID that traces exactly which records were touched is an investigation. In my pipeline, every run carries an identifier and every record carries lineage back to its source. Not because an auditor asked. Because rolling back an action without a record of the action is guesswork.
None of this slows a system down the way people fear. Scope is a permission you set once. Approval is a pause you place deliberately. Record is a write you were going to want anyway. What they buy you is the ability to let the system act without holding your breath.
The conversation about AI has moved from what these systems can say to what they can do. That shift is real, and it is not going back. So the question worth asking is no longer whether your system can take the action. It is whether anyone decided where it has to stop.