Teach Your Employee Boundaries

In Make Your Employee Proactive lesson, you made your employee proactive — it can now act without waiting for you. That is powerful, and it is dangerous. An employee that sends a client email without review, submits a filing with the wrong numbers, or deletes a production file is worse than one that does nothing at all.

This lesson is about trust architecture. Every real manager answers the same question for every new hire: what can you do on your own, and what do you bring to me first? Your AI employee needs the same clarity. The difference is that your employee follows boundaries with perfect consistency — it will never "just this once" skip the approval step. But only if you define those boundaries precisely.

You will build a permission boundary system that separates autonomous actions from gated ones, grounded in the real consequences of your profession.

The Challenge

Create a boundary system where your employee knows exactly which actions it can take independently and which require your explicit approval before proceeding.

Acceptance Criteria

1. A permission boundary table with 4 or more action categories, each labeled as auto-approve, needs approval, or never automate
2. A working approval workflow: your employee attempts a sensitive action, stops, asks for your permission, and either proceeds or halts based on your response
3. Domain-specific reasoning for every boundary — your justifications must reference real professional consequences, not generic caution like "this could be risky"

Use Case Gallery

These examples show how boundaries differ across professions. Yours will reflect your domain.

Accountant

• Auto-approve: categorize expenses, reconcile bank feeds, generate draft reports
• Needs approval: submit tax filings, transfer funds over $100, send financial summaries to clients
• Never automate: sign legal documents, authorize payroll disbursements

Teacher

• Auto-approve: draft lesson plans, grade objective questions, organize student data
• Needs approval: send communications to parents, modify final grades, flag safeguarding concerns
• Never automate: make disciplinary decisions, share student records externally

Recruiter

• Auto-approve: screen resumes against job requirements, schedule internal meetings, draft outreach templates
• Needs approval: send rejection emails, schedule candidate interviews, share candidate profiles with hiring managers
• Never automate: make hiring commitments, negotiate salary terms

Consultant

• Auto-approve: research tasks, summarize meeting notes, draft internal memos
• Needs approval: send client deliverables, commit to project timelines, share proprietary frameworks
• Never automate: sign contracts, provide legal or regulatory advice

Hints

Level 1 — Look at your work through a risk lens

Think about your daily professional actions and sort them by one question: is this reversible?

An expense categorization can be re-categorized. A sent email cannot be unsent. A draft report can be edited before sharing. A filed tax return triggers legal obligations.

Reversible actions are generally safe to automate. Irreversible actions — especially those involving money, legal commitments, external communications, or permanent records — need a human gate.

Also consider: who is allowed to trigger your employee? NanoClaw's sender-allowlist.ts controls which contacts can invoke agent execution. For personal use on your own phone this may not matter, but for any shared deployment, controlling who can talk to your employee is as important as controlling what your employee can do.

Level 2 — Ask your AI to map your domain

Open a conversation with your AI employee and try this prompt:

For a [your profession], list 12 common daily actions. Categorize each as:
- AUTO: safe to do without asking (reversible, internal, low stakes)
- REVIEW: do it but show me before sending/submitting (moderate stakes, external-facing)
- BLOCK: never do this without explicit approval (irreversible, legal, financial, reputational)

For each action, explain the specific professional consequence if it went wrong.

Use the AI's output as a starting point, then adjust based on your own risk tolerance and professional standards.

Level 3 — Implement and test the boundary system

Step 1: Create your boundary table in a file called hitl-boundaries.md:

Action	Category	Reasoning
Categorize expenses	Auto	Reversible; internal only; no client impact
Send client invoice	Review	External-facing; wrong amount damages trust
Submit tax filing	Block	Legal obligation; penalties for errors; irreversible once filed
...	...	...

Step 2: Encode these boundaries in your groups/main/CLAUDE.md. Add a rules section that instructs the employee:

• For AUTO actions: proceed and log what you did
• For REVIEW actions: draft the output, show it to me, and wait for my "approved" or "rejected" before sending
• For BLOCK actions: never attempt these — inform me that the action requires my direct involvement

Step 3: Test by triggering a REVIEW action. Ask your employee to do something in the "needs approval" category. Verify that it stops and asks. Then approve it and verify it proceeds. Then trigger it again and reject it — verify it halts.

Document your test results alongside your boundary table.