AXHUB5 cards

Half a day to build,
nine seconds to go wrong

Notes from an agent seminar — 2.5 hours of lecture, 1 hour of hands-on.
In half a day each person builds an agent for their own work and heads home.

The barrier to entry is gone.
What you need now isn't how to build one, but five things to check before you delegate.

Built from field mishaps and seminar notes (anecdotes) and Stanford data (figures)

Check before delegating1 / 5

01

Set the scope it can touch first

A true story that circulates among developers.
To one line — "fix the code" — an agent wiped the production DB and its backups in nine seconds.
The result: a forced rollback to three months ago.

An agent does what it's told "too eagerly."
Permissions are set by a person, not by the task.

Permissions in tiers Tier 1: read-only (query, analyze, draft) → Tier 2: write (edit, but apply only after review) → delete permission: never granted

Source Field mishap (anecdote) — least-privilege is rule one of running an agent

Check before delegating2 / 5

02

Don't hand it anything irreversible

Sending a customer email, paying, deleting, publishing.
Once these go out, you can't take them back.

Wiring it to production without backups is like handing a new hire the safe keys on day one.
Build the recovery path first, and let it go only up to "just before sending."

Example working rules "Email goes only to the drafts folder. A person presses send." "Files to clear go to an archive, not the trash."

Source An extension of the "AI is a new hire" view — reversibility is the precondition for delegating

Check before delegating3 / 5

03

Route exceptions to a person

Fully automatic, and accidents pile up quietly.
Approve every item, and there's no point automating.

The answer is routing — automatic as usual, only the unclear cases go to a person.
General inquiries auto-send; refunds, complaints, amounts always get a human check.

This structure produced double the gain (71% vs 30%), and this is where accidents get filtered.

Source Stanford Enterprise AI Playbook — escalation 71% vs per-item approval 30%

Check before delegating4 / 5

04

Decide first how you'll measure "better"

A shared gripe among operators — "is this actually better?"
Given the same instruction, AI comes out a little different each time.
Tweak it without a benchmark and improvement becomes just "a feeling."

Before you delegate, write in one line what you'll measure to judge it.
That one line keeps you out of this swamp.

Example one-line benchmark "Of 100 inquiry replies this week, the share that went out without a human edit." "Number of factual errors in the monthly report draft."

Source A shared concern among agent operators — for non-determinism, an evaluation system is the answer

Check before delegating5 / 5

05

Keep good instructions as team assets

What made the agent run well isn't the model.
It's the instructions you refined, the exception rules, the record of failures.

Kept in a personal note, they vanish with the person.
Kept in a team doc, they survive a change of tools.
77% of the gap came from operations like this.

Example format to keep Task name / full instruction text / exception rules ("if an amount is mentioned, send to a person") / failure cases and how they were fixed

Source Stanford Playbook — 77% of the hardest obstacles are change management and process (outside the tech)

AXHUBclosing

The easier building gets,
the more the rules come first

Building an agent takes half a day.
What to watch isn't the building but delegating without rules.

Permissions, recovery, exceptions, measurement, records.
Check these five, and it's worth delegating.

See the source material at axhub.net

Sources: field mishaps and seminar notes (anecdotes) · Stanford Enterprise AI Playbook (figures)

AXHub card No.12 — the mishap is a self-reported anecdote from social media, and the figures (71%/30%, 77%) are from verified source material. The example boxes are suggestions to copy.