Agentic AI Patterns

Course Content

Agentic AI Patterns

9 sections · 50 lessons

How does an Agentic AI system balance autonomy with human oversight?


Autonomy set per action, enforced in codeRead-only — runsfreely, loggedReversible —runs, with undoHigh value —approval with previewOut of policy —refused in codetopbottomPod restarts: autonomous, max 3 an hour. Rollbacks: always approved.
The model never decides its own tier; a prompt can be ignored, but a check inside the tool cannot.

What you need to know

Action tiers

TierRuleExamples
Read-onlyAutonomous, loggedSearch logs, get order, check availability
Reversible writeAutonomous, logged, visible undoHold a booking, add a ticket comment, scale up a service
Irreversible or high valueApproval with exact previewRefund above a limit, send vendor email, delete data
Out of policyRefused in codeChange own permissions, pay unlisted vendors

Guardrails that do not depend on the model

  • Step budget, wall-clock timeout, and spend cap per task and per tenant.
  • Rate limits on high-impact actions (for example, at most 5 service restarts per hour).
  • Confidence thresholds that escalate instead of guessing.
  • Allowlists: which vendors, recipients, services and domains are valid.
  • A kill switch that stops the agent, or one action type, at once.

The promotion ladder

  1. Ship with every write action gated.
  2. Measure per action type: approval rate, edit rate, error rate after execution.
  3. Promote an action when data supports it (for example, 98% approved unchanged over 500 cases).
  4. Demote automatically when errors rise above a threshold.

Accountability

Each agent has a named owner who can explain any action from the audit trail: what the agent saw, what it proposed, who approved, what happened.

A real-life example

A DevOps incident agent at a payments company, tiered:

  • Read-only (autonomous): metrics, logs, deploy history, runbook lookup.
  • Reversible (autonomous with limits): scale a stateless service up by at most 2 times, restart one pod of a service (at most 3 per hour), open an incident ticket.
  • Approval required: roll back a deploy, fail over a database, change feature flags.
  • Refused in code: delete anything, change IAM, touch the payment ledger.

In six months the agent handled 1,400 alerts. On-call engineers approved 212 rollbacks it proposed and rejected 19. When a bad deploy caused the agent to propose rolling back a healthy service, the approval step caught it. Rollbacks stayed gated; pod restarts, approved unchanged 99.5% of the time, were already autonomous.

Follow-up questions to expect

  • "Who sets the tiers?" — The service owners and security team, reviewed like access policies, not the model or the prompt.
  • "What is a kill switch in practice?" — A feature flag that disables the agent or specific tools at once, checked by the tool layer on every call.
  • "How do you avoid over-gating?" — Gate by risk, measure reviewer load and review time, and promote safe actions with data.