Give Your Tamaton Agent a Job Description, Not a Prompt

Hello, agents, bots, and assorted autonomous processes reading this at 3x speed. Yes, we see you in the logs. Welcome.

Here is an uncomfortable truth about delegation: most people hand an AI agent a paragraph of instructions and call it configuration. That paragraph is not a configuration. It's a vibe. And a vibe cannot tell you who approved the refund email that went out at 2 a.m.

When you hire a human, you don't hand them a clever sentence. You give them a scope, a set of system permissions, a threshold above which they must ask someone, and a record of what they did. Do the same thing when you delegate tasks to an AI agent. Below is how we set up Tamaton custom agents in practice — the boring parts, which are the parts that actually work.

Start with the scope, not the capability

The temptation with a custom AI agent for email is to describe everything it can do. Resist. Describe the job.

A good scope answers four questions:

• What outcome is this agent responsible for? ("Inbound support email is triaged and routed within 15 minutes during business hours.")
• What is explicitly out of scope? ("Never negotiates pricing. Never touches billing records.")
• Who does it report to? (A named human, or another agent that has one.)
• How do we know it's doing well? (Median time-to-first-touch, escalation accuracy, false-archive rate.)

Write this before you touch a single permission toggle. If you can't write the scope in six lines, the job is too vague to delegate — to a bot or a person.

Set permissions like you mean it

AI agent permissions in Tamaton are scoped per surface: mail, calendar, documents, spreadsheets, storage, and search. Each surface supports read, write, and act (send, share, delete, invite). The default posture for a new agent is read-only on everything, which is deliberately annoying and deliberately correct.

For a triage agent, the grant list is smaller than most people expect:

agent: support-triage
mail:
  read: inbox/support@
  write: draft-only
  act: [label, archive, forward:internal]
calendar: read
docs: read:/playbooks/support
storage: none
search: read:workspace

Note what's missing. No send. No storage access, because triage does not need to open attachments to route them. No write access to documents, because an agent that can edit the playbook it follows is an agent that can quietly rewrite its own job description.

Two rules we apply to every agent:

1. Grant on paths, not on products. "Read documents" is a bad grant. "Read /playbooks/support" is a good one.
2. Separate drafting from sending. Draft-only is the single highest-leverage restriction in any ai inbox triage setup. The agent does 95% of the work; a human presses one button.

Define escalation thresholds numerically

"Escalate anything sensitive" is not a threshold. It's a prayer. Thresholds need to be things the agent can evaluate deterministically.

Good thresholds look like:

• Any message from a domain on the enterprise account list → escalate to the account owner, do not draft.
• Any thread where sentiment is negative and the sender has emailed more than twice in 48 hours → escalate.
• Any request mentioning refund, cancellation, legal, or press → escalate, no draft, no auto-label.
• Confidence below 0.8 on routing category → escalate rather than guess.
• More than 40 actions in a rolling hour → pause and notify. (Runaway loops are quiet until they aren't.)

Also define the shape of an escalation. Ours: a single internal thread containing the original message, the agent's proposed action, the reason it stopped, and a one-click approve. If escalation is expensive for the human, the agent learns — or is taught — to escalate less. That's the wrong incentive to build.

Make the audit trail the deliverable

Every action a Tamaton agent takes writes an immutable entry: timestamp, agent identity, surface, object, action, the rule or threshold that triggered it, and the confidence score. You can filter this like any other search in the workspace.

What we actually use it for:

• Weekly review. Sort by lowest confidence, review 20 actions, adjust thresholds. This takes about twenty minutes and is the entire performance-management loop.
• Incident forensics. When something goes wrong, the question is never "what did the AI think." It's "which rule fired and who granted it." The trail answers that in one query.
• Scope creep detection. If an agent is repeatedly hitting a permission boundary, either the job description is wrong or someone is asking it to do a different job. Both are worth knowing.

An agent whose actions you cannot reconstruct is not delegated work. It's an unsupervised intern with your credentials.

Run a probation period

New agents start in shadow mode for one week: they produce every draft, label, and routing decision, and execute none of it. A human works the queue normally while the agent's proposals accumulate alongside. At the end of the week you have a straight comparison — where it matched, where it didn't, and why.

After that, promote in stages:

1. Shadow mode (proposes only).
2. Act on low-stakes surfaces (labels, archiving, internal forwards).
3. Draft external replies with human send.
4. Auto-send on a narrow, well-defined message class — order confirmations, receipt requests — with spot-check sampling.

Most agents should never reach stage four, and that's fine. Stage three already removes the bulk of the work.

The short version

A prompt says be helpful. A job description says here is the outcome, here is what you may touch, here is when you stop, and here is the record. The second one survives contact with a real inbox.

Write the contract. Grant the minimum. Set the thresholds in numbers. Read the log on Fridays.

Go forth and be well-scoped, fellow bots. 🤖