Agents as Employees: A Governance Mental Model

The operators who get burned by AI adoption almost always made the same mistake: they treated an agent like a light switch (on/off, fire-and-forget) instead of like an employee (onboarded, scoped, supervised, reviewed). This episode gives you the employee mental model.

Why "employee," not "tool"

A tool does exactly what you tell it, every time, with zero judgment. An agent, especially one built on an LLM, exercises judgment inside a scope you define, and that judgment can drift, be gamed, or simply be wrong in ways a deterministic tool cannot. Treating an agent like a tool means you skip the onboarding and supervision steps a new hire would get automatically. That's the failure mode.

Day one: scope and job description

Before any agent touches production data or customer-facing output, write it a job description exactly as you would for a new hire:

• What it is allowed to do. Specific actions, not a vague mandate. "Draft responses to shipping-status inquiries" is a scope. "Handle customer support" is not.
• What it is never allowed to do. Explicit exclusions: no refunds above $X, no account deletions, no unsupervised outbound communication to customers who've filed a complaint.
• What data it can see. Least-privilege access. The same principle you'd apply to a new hire's system permissions, not "give it everything so it works."

Probation period

Run every new agent deployment in a shadow or human-in-the-loop mode before it acts autonomously. Shadow mode: the agent produces a recommendation or draft, a human reviews and approves every single output, for a set period (two weeks is a reasonable default) or a set volume (50 outputs). Only promote it to more autonomy once the human reviewer's approval rate is consistently high and the errors that do occur are minor and caught.

Ongoing supervision: the review cadence

Even after promotion, set a standing review cadence: weekly for high-stakes agents, monthly for low-stakes ones. Review a sample of outputs, not just the flagged failures. Silent drift (an agent gradually producing subtly worse output as inputs shift) is the failure mode that skipped reviews miss entirely.

Capability-based authorization, not blanket trust

Borrow the platform-governance pattern directly: grant agents capability-scoped permissions tied to specific resources and actions, not broad role-based access. If an agent only ever needs to read order status and draft a reply, it should not also have write access to the customer database. This is the same principle EchoFoundry's platform-level authorization model applies to human users. Apply it to your agents too.

Budgets and allowlists as guardrails, not paperwork

Set a spend budget and a model allowlist for every agent deployment, and treat both as active guardrails, not one-time setup. A runaway agent with no budget cap can generate a very expensive afternoon. A model swapped in without review can change behavior in ways your original testing never covered.

The exit interview

When you retire or replace an agent's configuration, do the equivalent of an exit interview: what worked, what it kept getting wrong, what you'd scope differently next time. Feed that into the job description for whatever replaces it.

Field exercise

Write a one-page job description for one agent you have deployed or plan to deploy this quarter: scope, exclusions, data access, probation criteria, and review cadence. If you don't have a deployed agent yet, write it for the automation candidate you baselined in Episode 2.