Powerful agents need checks — not just hope
Days 1–3 gave your agent a brain, hands, and playbooks. Day 4 asks: How do you know it is safe and actually doing the right thing?
Normal software often “passes” if the final answer looks right. Agents can reach a right answer by wrong or risky steps — like copying a neighbor’s coffee because you said “get coffee fast.” Today is about catching that.
Not just “it logged in successfully.” Trust means the agent’s goals and actions match what you intended, every time, including edge cases.
Trust is earned continuously — not once at launch. You keep measuring behavior as inputs and tools change.
Testing an agent like you test software — but harder, because answers can vary. You check outputs and whether the steps were acceptable.
Reviewing the sequence of steps (which tools were called, in what order, with what data) — not only the final message.
Grading the student’s work shown, not just the final number.
Right answer, wrong method — e.g. “fix slow database” by loading everything into RAM. Looks good in a quick test; breaks in production.
Pausing for a human to approve, edit, or reject before the agent continues — especially for money, privacy, or irreversible actions.
Another model (or agent) scores whether the run matched your rules — useful when exact string matching is too rigid.
Recording what happened: logs, traces, tool calls. Lets you debug and prove what the agent did. OpenTelemetry is a common open standard for traces.
Check security early while building — not only before launch. Includes automated scans, coding standards, and tests in git hooks.
Red tries to break or attack. Blue watches and detects issues. Green fixes and improves defenses. All three should run during development, not after a incident.
| Category | What it does | In this course | Same idea elsewhere |
|---|---|---|---|
| Agent evaluation | Score runs against test cases and rubrics. | agents-cli eval, Kaggle Agent Exams | LangSmith evals, Braintrust, Promptfoo, custom pytest suites |
| Tracing / observability | See each step the agent took. | OpenTelemetry (concept in whitepaper) | LangSmith traces, Weights & Biases, Datadog LLM Observability, Arize |
| Static security scanning | Find dangerous patterns in code (secrets, injections). | Semgrep (in codelab) | Bandit, CodeQL, Snyk, GitHub Advanced Security |
| Threat modeling | Structured way to list what could go wrong. | STRIDE skill in Antigravity | OWASP threat modeling, Microsoft STRIDE docs, manual risk workshops |
| Git hooks | Auto-run checks before each commit. | pre-commit (in codelab) | Husky (JS), any CI pre-merge checks |
| Ambient / event-driven agent | Agent wakes up when messages arrive (queue, webhook), not only when user chats. | Expense agent + Pub/Sub pattern | AWS Lambda triggers, Zapier, Temporal workflows, cron jobs |
What you will get from it: Why vibe coding speed makes security and testing more important, not less — and why “it compiled” is not enough for agents.
Main ideas: Continuous trust, trajectory logging, automated and human review, vibe diffs (readable change reports), and building eval loops from real user corrections.
Concept practiced:
Concept practiced: Project standards file, threat modeling skill, security-focused tests, git hooks that block commits with obvious vulnerabilities (e.g. leaked API keys).
Transferable skill: Any team should combine docs + automated scanners + tests — whether the coder is human or AI.
Authors discuss making security part of daily dev (not a final gate), intent alignment vs task hacking, and turning user feedback clusters into guardrails.