Why the approval sits in the chat

An agent that can send email is only useful if it cannot send the wrong one. The usual response is a permission system somewhere else: a tray icon, a settings page, a log you will not open. T-FORCE puts the decision in the conversation you are already having, and it sorts actions by what they change, not by how impressive they look.

That sort is the whole design. Some work runs because you asked. Some work waits on a card until you approve or deny it. The card is not a second product. It is the request, made specific, sitting next to the reason.

Effect, not difficulty

The expensive mistake is rarely that the model thought hard about the wrong question. The expensive mistake is a side effect: a file overwritten, a command run, a message delivered, a schedule that will keep firing after you have forgotten the sentence that created it. Thinking can be undone by ignoring it. A sent email cannot.

So the split ignores how hard the task felt.

These run in the same turn, because asking was the consent:

• The time, the weather, a calculation.
• Web search, and opening a page.
• Reading a PDF or an image that is already in the project.
• Generating a still, a clip, speech, or a sound effect.
• Reading mail or Drive, once those apps are connected and you asked for the read.

These pause until you say yes:

• Writing a file on the machine.
• Running a shell command.
• Sending mail, posting a message, creating an issue.
• Changing a schedule.

A research question can be genuinely difficult and still run immediately. A one-line email can be obvious and still wait. If the gate tracked effort, or tracked how confident the draft sounded, it would open for the cases that feel finished and close for the cases that are merely slow. Finished is how bad sends happen.

Secrets are the same idea, drawn tighter. A .env file or a credential pauses before the agent opens or copies it. The risk there is not that the content is a side effect. The risk is that the content becomes part of a later side effect, or part of a model call, without a moment where you saw the boundary get crossed.

What the card has to show

A dialog that says "allow T-FORCE to modify files" is a license, not a decision. You cannot answer it well, so you answer it once and stop reading. The approval in the chat has to name the action. The file. The command. The recipient. Approve, or deny. Two choices, because a third choice labeled "always" is how a specific decision decays into a license.

The Manager's job around that card is to say who it hired and what is waiting. You should not have to reconstruct the plan from the card alone. The sentence that asked for the work is still on screen. The card is the concrete form of that sentence: not "send the update," but this update, to this address. If those two diverge, deny is the correct button, even when the sentence was yours.

This is also why the card does not live in a queue you visit later. A queue separates the decision from the context that makes it intelligible. By the time you return, you are approving a stranger's request, and the stranger is you, an hour ago. People click through strangers. They are slower with a card that still has the draft underneath it.

Schedules are where the gate earns its keep

A schedule is a side effect with a delay. "Send me a Monday brief" sounds like a preference. It is a job that will run when you are not in the conversation that created it. Changing a schedule waits for approval for that reason. The moment you confirm it is the last moment the request and the decision are in the same room.

After that, the app still owes you ordinary controls: pause, resume, run now, remove. Those are how you live with a job you already approved. They are not a substitute for the approval. A pause button you discover on a bad Monday is a recovery. The card is the chance not to need one.

A specialist can own the scheduled job. That does not move the approval onto the specialist. The specialist does the work. You still decide that the work is allowed to recur. Ownership and permission are different, and the product is worse if a hire silently includes a license to keep doing the thing.

The gate is not a conscience

Nothing in this design reviews the wisdom of the action. You can approve a rude email, a destructive command, a file written to the wrong folder. The card makes the action legible. It does not grade it. Anyone selling an approval button as a guarantee is selling the feeling of a review, not the review.

The matching limit is on the other side. Immediate actions are not harmless in some deep sense. A web search reveals a query. A generated image is a generation. Reading connected mail pulls mail. "Runs now" means you already asked for that class of thing, not that the class has no consequences. If a class is too broad for the way you work, the fix is to ask for less of it, or not to connect the account. The gate will not invent a narrower intent than the one you typed.

There is a last, dull limit. The approval is only as good as the person at the keyboard, and only on that machine. T-FORCE does not add a second approver, a company policy engine, or an audit trail in someone else's cloud. Enterprise rollouts that need those will need a process around the app, not a myth that the card is the process.

What the card does claim is smaller, and it holds. Lookups and drafts move. Anything that leaves the machine, or changes it, waits where you can still see why it was asked.