LIFECYCLE HOOKS

PRE-EXECUTION AND POST-EXECUTION INTERCEPTORS An interceptor is a hook that sits between two things and can inspect, change, or stop what passes through. A pre-execution interceptor runs before an action happens. For a tool call, it receives the proposed call, with the tool name and arguments, before the tool actually runs. It can allow the call, change it, or block it. A post-execution interceptor runs after the action completes. For a tool call, it receives the result and can examine it, record it, alter it, or trigger follow-up actions. Why are both needed? The pre-execution interceptor is your preventive control. It stops harm before it happens. The post-execution interceptor is your detective and cleanup control. It observes what did happen, checks the quality of results, and keeps records. Consider a pre-execution hook that checks every outgoing tool call against a deny-list. A deny-list is a list of forbidden patterns. If an agent proposes a command that matches a forbidden pattern, such as one that would erase everything on the computer, the hook blocks the call and returns a message to the model explaining that the action was denied. The model can then choose a safer approach. A deny-list is simple and useful, but it has a limit: it can only block what you thought of in advance. A complementary approach is an allow-list, which permits only actions that are explicitly approved and blocks everything else. An allow-list is usually safer for high-stakes systems, though it can be stricter. Now consider a post-execution hook that logs the tool name, the duration, and the result status of every call. The agent does nothing extra. Yet at the end, you have a full record for analysis, which feeds the observability tools you will study in Part Seven. A post-execution hook can also sanitize results. For instance, it can remove secret keys from tool output before the output reaches the model or the logs. Another important property is hook ordering. When several hooks attach to the same point, the harness runs them in a defined order, and the order can matter. For example, a hook that redacts secrets should run before a hook that writes logs, or the secrets may be stored in plain sight.