You can now design a small agent: bounded goal, narrow tools, durable state, a loop that stops. Before this class closes, set the mental model you will carry through the rest of the part — because the next stop after "small loop" is usually "could this do real work in my business?"

The honest answer: an agent can act like a digital employee — with a job description, tools, a workspace, a manager, a schedule, and a review process. It can research, draft, categorize, watch for changes, update a CRM, prepare marketing assets, and handle routine support groundwork. It cannot replace judgement, ownership, or accountability.

The employee frame

Treat each agent as a new hire with a narrow role:

• Job description. Mission, allowed tools, decision rights, escalation rules, success measures.
• Workspace. The folders, inboxes, CRMs, and dashboards it may read or write — and the ones it may not enter.
• Manager. One named human owner who reviews output, handles exceptions, and can revoke access.
• Schedule. When it works: on a cron timetable, when a queue delivers a job, when a webhook rings.
• Review process. How its work is checked: spot checks, approval gates, audit logs, success metrics.

This frame makes two questions unavoidable — who is responsible when it errs, and what exactly is it allowed to decide alone? Every section below answers those questions for one kind of work.

Inbox work: useful before send, careful at send

The inbox is the most requested agent job and the most instructive boundary. A support or sales agent can do genuine work on incoming messages:

new message → classify intent + urgency → retrieve account, order,
  or help-center context → draft a reply → create or update a ticket
  → route exceptions to the right human

It can also sit inside a larger automation: form submission → CRM lead → enrichment → draft reply → human approval → send. The agent supplies classification, context retrieval, and drafting; the workflow supplies the routing, the record-keeping, and the gate.

Start with triage and drafted replies. An inbox contains private information, edge cases, impersonation attempts, and emotionally sensitive conversations — exactly the inputs where a confident-sounding mistake does the most harm. Allow automatic sending only for narrowly defined, low-risk message types (a password-reset pointer, an order-status reply built strictly from retrieved records), each with clear escalation rules, full logging, and a named owner. Everything else waits for a human to press send.

What agents can concretely reach

Make the reach specific so neither hype nor fear fills the gap:

• Content and social. An agent can prepare text, image, and video drafts — and post to an authenticated social account only when that permission is intentionally granted, within a defined calendar and scope.
• Operations. An agent can prepare accounting reconciliations, match records, and flag unusual entries for review. It proposes; a human records.
• Trading and research. An agent can gather facts, run a defined screen or model, and propose a decision with evidence attached. It does not substitute for judgement or required oversight.

Every one of these crosses the action ladder below. Read the ladder before granting anything above "draft."

The action ladder

Not all actions need the same control. Use this ladder for every agent you design:

The higher the rung, the slower the improvement cycle and the stronger the evidence required. A support-FAQ draft may update often after review; trading or accounting logic needs validation, explicit governance, and usually a human decision-maker.

And risk is not only financial. Climb the ladder faster when the work touches public reputation, customer harm, private data, irreversible changes, legal or contractual consequences, or powerful accounts. A wrongly sent email to one customer and a wrongly published claim to ten thousand followers are different failures with different controls.

Two worked examples

Marketing. A content agent proposes five posts, attaches drafts, checks each against short brand rules (claims require sources, no invented prices or dates), and queues them for approval. A mature setup may schedule pre-approved content within a narrow calendar and budget. What it never does freely: invent claims or spend on ads without boundaries.

Finance. An agent assembles a research packet: pulls two filings, compares named figures, runs one defined screen (stated formula, stated inputs), and flags transactions over a threshold for review. The output is a packet with sources, calculations, and open questions — not a decision. Anything involving money movement, trade placement, payment, or accounting entries is high-consequence work with much stronger controls. The agent shortens the manager's reading list; it does not sign the form.

Check your understanding

1. Name the five parts of the employee frame (job description through review process) for your own agent. 2. Why should inbox agents start with triage and drafts rather than automatic sending? 3. Place these on the action ladder: tag a ticket, publish a claim, draft a reply, place a trade, queue a CRM update. 4. Name two non-financial risks that push an action up the ladder.

Exercise: write AGENT-JOB-DESCRIPTION.md

Give your agent its employment papers. Create AGENT-JOB-DESCRIPTION.md:

# AGENT-JOB-DESCRIPTION: <agent name>

Mission: <one paragraph — the job it exists to do>
Allowed tools: <named tools + scope, from your Lesson 28.2 inventory>
Decision rights: <which ladder rungs it may act on alone>
Escalation rules: <what goes to a human, how fast, through which channel>
Success measures: <2–3 observable metrics, e.g. packet on time, zero unlogged actions>
Maximum spend/impact: <e.g. "$0 autonomous spend; may queue 5 drafts/week; no publishing">
Owner: <one named human manager>

Worked example (shortened):

# AGENT-JOB-DESCRIPTION: Inbox Triage v1

Mission: Classify incoming support mail and draft replies so the
on-call human clears the queue faster.
Allowed tools: read mailbox (support@ only), retrieve help-center
articles + order records, write drafts to ticket queue. No sending.
Decision rights: Explain, Draft, Prepare only. No autonomous sends.
Escalation rules: Angry / VIP / refund / legal language → route to
Darin within 1 hour with draft + context attached. Tool errors twice
in a row → stop and page owner.
Success measures: (1) 95% of messages classified by 9am; (2) every
draft links its sources; (3) zero sends without human approval.
Maximum spend/impact: $0 spend; no sends, refunds, or record changes.
Owner: Darin.

Finish line: one AGENT-JOB-DESCRIPTION.md with all seven fields — mission, tools, rights, escalation, measures, max spend/impact, owner.

Verify: read the rights and escalation sections aloud. Could a new team member tell exactly what the agent may do alone and what must come to a human? If not, narrow the rights or sharpen the escalation.

Common failure: writing "use good judgement" as an escalation rule. Name the trigger ("refund request," "claim without a source," "second tool failure"), the person, and the channel. Judgement belongs to the manager; the document assigns it.

Class 28 closes here. You can identify an agent's five components, grant its first tools, design its state, scope its loop, and hire it with a written job description. Class 29 puts that knowledge to work: telling chat, connectors, workflows, and true agents apart — so you build the simplest system that does the job.