## Tangent work and live control\: next steps The useful endpoint is not merely “the tan stopped\.” It is a report that identifies the target\, distinguishes job and agent state\, locates the available output\, and accounts for already\-written files or separately supervised processes\. Likewise\, “the message was delivered” does not establish that the requested correction was followed\. Completion\, delivery\, returned output\, and effects are different facts\. The next question is why a particular operation was permitted at all\. A tangent can inherit a per\-tool policy record while its initial settings helper defaults the approval mode to yolo\. Its narrow assignment is not an OS boundary\, and its initial headless construction is not Main’s interactive approval experience copied intact\. Continue to [Tool permissions and approvals]()\. Follow the exact call through tier classification\, effective policy\, device dispatch\, one\-call answers\, and host UI availability before treating a refusal as something to repair or a missing prompt as proof of safety\. Extensions can then make these distinctions easier to operate\: explicit tools can expose identity and revisions\, lifecycle handlers can retire stale authority\, and owner\-addressed delivery can keep a result with its originating conversation\. They do not remove the underlying boundaries or automatically install themselves in every child runtime\. After permissions\, continue to [Extensions inside those boundaries]()\. The design question remains how to make a capability’s actual scope visible to both a human and an agent\.