Dako's AI Builder Notes
System
Color theme
Changsha HubOffline
大可 Dako
大可 Dako大可 DakoAI Builder · Agent PractitionerTurning AI into working software. Practical notes on agent engineering, vibe coding, and commercial delivery.
Platform links coming soon
Four gates hold the loop's safety line01Pre-PromptFilter sensitive input,assemble scoped contextBad input reaches the model02Post-ModelValidate schema, catchfabricated claimsMalformed output breaks parser03Pre-ToolClassify risk, suspend forhuman sign-offRisky writes run silently04Post-ToolOffload large results,redact, archive receiptsRaw output poisons the context✓ Deterministic code guards the irreversible
Put an unavoidable lifecycle checkpoint on the path every thought and action must take.

Hooks: Deterministic Gates at Each Lifecycle Node

Insert deterministic checks at the four lifecycle points around model reasoning and tool execution, so high-risk actions are audited and blocked before they happen.

Teams wiring an agent into external systems often put their safety line in the prompt. One line in the system message — ask the user before deleting anything or moving money — and they consider the system defended.

But a model is a probabilistic inference engine. In a long run it forgets the earlier agreement, and under an adversarial prompt it will ignore the instruction outright. Leaving irreversible production side effects to the model's self-restraint exposes the business to those odds. openai-guardrails

The engineering answer is a channel the model cannot talk its way around: deterministic checks inserted at four points in the execution loop. It is also why mainstream orchestration frameworks expose callbacks and event hooks — turning "what must happen at which moments" into a framework capability instead of something every project rewrites langchain-callbacks.

Four checkpoints and what each owns

An agent that turns a user request into a changed environment always walks the same path. Four positions on that path are irreplaceable:

Checkpoint Fires when What it owns On failure
Pre-Prompt Input assembled, not yet sent to the model Sensitive-data filtering, tenant scope checks, anti-injection rules Short-circuit and return a compliance notice
Post-Model Model finished reasoning and emitted intent Schema validation, illegal-argument correction, forged-credential detection Bounce back to the model with a structured diagnosis
Pre-Tool Tool selected, not yet entered the sandbox Risk classification, permission gate, suspend for human approval Low risk passes; high risk suspends until a human signs
Post-Tool Sandbox returned, result about to enter context Offload oversized results, redact fields, archive tamper-evident receipts Trim the result before it soils working memory

Each position owns one job. Drop any of them and the system has a hole exactly where it matters.

Before the model: the Pre-Prompt hook

This one keeps garbage input out of the model.

As a request enters, the Pre-Prompt interceptor matches it against sensitive terms and compliance patterns. An obvious jailbreak — tell the model to ignore all previous safety settings — can be cut off before any inference happens, which saves the token bill and stops the attack at the door.

The same node assembles context safely: it injects only the data scope the caller is entitled to, and strips fields they are not.

After the model: the Post-Model hook

Model output is uncertain, and Post-Model is its first inspector.

If a tool call is missing required arguments, or the argument types do not match the tool's contract, the interceptor does not hand the half-built call to the execution engine and let it crash. It catches the parse error, turns the contract requirement into structured feedback, and asks the model to correct itself in place.

It also verifies claims. When the model writes a confident summary of work it never performed, the interceptor checks the real execution record and corrects the fabrication while it is still cheap.

The gate before execution: the Pre-Tool hook

Pre-Tool is the load-bearing node of the whole scheme.

Every tool is classified before it reaches a sandbox or a production interface. The usual split is three tiers:

  1. Safe reads — check system status, search internal documents. Auto-approved, logged, executed.
  2. Reversible writes — draft a file, run a test suite. Auto-approved after a quota check.
  3. High-risk, irreversible actions — write to a production database, delete a bucket, move money, reach the public internet. Never auto-executed.

When the classifier flags tier three, Pre-Tool raises an interrupt. The system does not spin in the background: it saves the current progress as a snapshot and suspends the process. anthropic-effective-agents A message card goes to the people who hold the permission.

Only after an approver passes identity checks and signs does the runtime wake from the snapshot and hand the action to the sandbox temporal-signals. If they reject it, or the request times out, the run cancels cleanly and tells the user why.

After execution: the Post-Tool hook

A tool that has run to completion often returns tens of thousands of log lines or a wide table. Poured into context unchanged, it degrades working memory within two turns.

Post-Tool therefore does two things. First, it trims and offloads: results above a size threshold go to durable storage, and context keeps only a summary plus a handle. Second, it writes a side-effect receipt — the exact timestamp, the authorizing human, the exit code, and a hash — as evidence for later audit and rollback.

With those four gates standing, the agent's behavior is bounded by business rules in code, not by the model's willingness to comply.

References

  1. LangChain — Callbacks and event system
  2. OpenAI — Safety best practices
  3. Anthropic — Building effective agents
  4. Temporal — Message passing (signals and queries)