Skip to content

6 · Q&A and wrap-up

15 minutes

Discussion

  • How well did it actually work?
  • What scared us?
  • Where was the agent better than you? Where was it clearly worse?

Taking this to production

Gradual adoption

flowchart LR
    A["1 · Read-only<br/>observation"] --> B["2 · Proposes<br/>pull requests"]
    B --> C["3 · Writes with<br/>approval"]
    C --> D["4 · Autonomous in<br/>a narrow scope"]

Don't skip steps. Each one should last long enough that you know the agent's failure patterns before you widen its reach.

Read-only vs. read-write

Read-only agent Read-write agent
Value Triage, correlation, explanation Actual remediation
Risk A wrong diagnosis A wrong change
Requires Good logs and metrics RBAC, approval, rollback, audit
Start here? Yes After months, not days

An underrated point: a read-only agent captures most of the MTTR win, because diagnosis is usually the slow part. The fix is often a one-liner you already know.

Production checklist

  • Dedicated service account with minimal RBAC, scoped per namespace
  • Every tool call logged with arguments and results
  • A deterministic health check the agent cannot modify
  • A rollback that doesn't depend on the agent
  • Rate limits and a hard iteration ceiling (against runaway loops)
  • An approval gate for anything destructive
  • Guardrails verified at the tool layer, not just asserted in a prompt — see CVE-2026-46519
  • Evals: known scenarios you run against the agent before every prompt change
  • Clear ownership — who answers when the agent is wrong?

Cleanup

make cluster-down

Take it home

The repo is yours. make cluster-up works just as well at your kitchen table, and the hardening lab is a good way to get acquainted with your own stack's weak spots.

Thanks

Questions afterwards: open an issue in the repo, or get in touch with Lars Effenberger or Lars Søraas.