Your First AI Employee

The difference between a tool and an employee

This isn't a semantic game. The distinction matters architecturally.

When you run Claude Code on your laptop, it's a tool. You invoke it, it does something, it stops. It borrows your machine, your credentials, your file system. It has no independent existence. It's a very smart command you typed.

When you give an agent its own cloud machine, it becomes an employee. It has:

• Its own workstation. A sandbox with a browser, a desktop environment, a terminal, and persistent file storage. The same setup you'd give a new hire on their first day.
• Its own credentials. Scoped API keys, SSH certificates, and service accounts. Not your personal keys. Not your admin access. Its own identity with its own permissions.
• Its own schedule. Cron jobs, webhook triggers, calendar events. It knows the competitive intel sweep runs at 6am. It knows month-end reconciliation is due on the 28th. It plans its own work.
• Its own memory. Files from yesterday are still there today. The research it compiled last week is in /workspace/research/. The repo it's been contributing to has its commit history. Context accumulates.
• Its own cost center. Every minute of compute is tracked, billed, and attributable to a project, a department, or a customer. The CFO can see exactly what the AI workforce costs.

Every AI agent on the market today — Claude Code, Codex, Devin, Cursor's cloud agents, GitHub Copilot's coding agent — is moving toward this model. Devin already calls itself an "AI software engineer" with its own cloud environment. Cursor gives cloud agents their own Ubuntu VMs. The industry is converging on the same answer: agents need computers.

The question is whether you use someone else's locked-in environment (Devin at $9/hour, Cursor's VMs at $200/month) or provision your own (a sandbox at $0.04/hour with any model you want).

What the workstation looks like

A human employee gets a laptop with a browser, some applications, a terminal, and access to the company's systems. Your AI employee gets the cloud equivalent:

The browser: the agent's window to the internet

A Chrome or Firefox instance running in its own isolated cloud container. The agent controls it via the Chrome DevTools Protocol (CDP) — the same protocol that Playwright and Puppeteer use. But in 2026, the agent doesn't need you to write Playwright scripts. Claude's computer use, GPT-4o vision, and Gemini's multimodal capabilities let the agent see the browser and decide what to click, just like a human would.

The browser has its own IP address, its own cookies, its own session state. Nothing leaks between browsers. When the agent logs into a vendor portal, that session is isolated — another agent logging into a different portal can't see or interfere with it.

What the agent does with a browser:

• Researches topics across dozens of websites, extracting and synthesizing information
• Logs into vendor portals, navigates forms, downloads invoices, uploads documents
• Monitors competitor websites for pricing changes, new features, job postings
• Tests your web application by walking through user flows and screenshotting failures
• Fills out government forms, compliance submissions, and regulatory filings

The desktop: for when there's no API

A full Linux desktop with XFCE or KDE, accessible via VNC/noVNC. The agent sees the screen and interacts with it using computer-use vision models — taking screenshots, reasoning about what's on screen, clicking buttons, typing text, opening menus.

This sounds exotic until you realize how many enterprise tools have no API: legacy ERP systems, government portals built in Java, desktop applications distributed as installables, PDF editors, spreadsheet tools. A human employee uses these by looking at the screen and clicking. An AI employee does the same thing.

What the agent does with a desktop:

• Opens LibreOffice Calc, processes a spreadsheet, creates pivot tables, exports to PDF
• Operates legacy enterprise applications (SAP GUI, Oracle Forms, custom Java apps)
• Processes documents in applications that only have a GUI interface
• Runs desktop-only development tools, IDEs, and design software
• Handles any workflow that requires visual interaction with an application

The terminal: where the coding happens

A full Ubuntu Linux VM with SSH access, root privileges, and every package manager. This is where Claude Code, Codex, Aider, and every coding agent feel at home. They can git clone, pip install, npm test, and docker build exactly like they do on your laptop — but on a machine that's isolated, persistent, and doesn't die when you close your lid.

What the agent does with a terminal:

• Clones repositories, writes code, runs tests, fixes failures, opens pull requests
• Installs and runs any software — databases, servers, ML frameworks, build tools
• Processes data: downloads datasets, runs Python scripts, generates reports
• Manages infrastructure: runs scripts, checks logs, deploys configurations
• Compiles results from browser and desktop work into structured outputs

Persistent storage: memory that survives

The sandbox's filesystem persists across sessions. When the agent stops working on Friday and resumes Monday, the files are still there. The git repo it cloned still has its local changes. The research notes it compiled are in /workspace/notes/. The downloaded invoices are in /workspace/invoices/.

This is what turns a stateless script into an employee with context. The agent doesn't start from scratch every time. It builds on its previous work.

Setting up your first AI employee: 10 minutes

Three paths, depending on which agent you use. All three end with the agent working on its own machine.

Path A: Claude Code (the most popular)

Claude Code has 18.9 million monthly active users. It's a TUI — a terminal app. You SSH into a sandbox and run it there.

# Create the AI employee's machine
curl -s -X POST "https://sandbox.dev.ab0t.com/api/sandboxes" \
  -H "Authorization: Bearer $SANDBOX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "claude-employee-01",
    "instance_type": "ab0t.medium",
    "auto_stop_minutes": 0
  }' | jq .

# auto_stop_minutes: 0 means "don't auto-stop"
# This employee's machine stays on until you explicitly stop it.
# For a machine that shuts down after inactivity, set to 60 or 120.

# SSH into the machine
ssh ubuntu@SANDBOX_IP

# Install Claude Code
curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash -
sudo apt-get install -y nodejs git tmux ripgrep
npm install -g @anthropic-ai/claude-code

# Give it an identity (NOT your personal keys)
export ANTHROPIC_API_KEY="sk-ant-SCOPED_KEY_FOR_THIS_AGENT"

# Set up git (the employee's identity, not yours)
git config --global user.name "Claude Employee 01"
git config --global user.email "ai-employee-01@yourcompany.com"

# Clone the project it'll work on
mkdir -p /home/ubuntu/workspace && cd /home/ubuntu/workspace
git clone https://github.com/your-org/your-project.git

# Employee: Backend Test Engineer

## Your role
You are responsible for the test suite of this project. Your job is to:
1. Run the full test suite after every change to the main branch
2. When tests fail, investigate the failure, identify the root cause, and
   either fix it yourself or file a detailed bug report
3. Write new tests for any code that lacks coverage
4. Keep the test infrastructure healthy (dependencies, fixtures, CI config)

## Your machine
You're running on a cloud sandbox (Ubuntu, ab0t.medium, 4 GB RAM).
You have full root access. Install any packages you need.
Your workspace persists between sessions.

## How to report
- Push test fixes directly to a `test-fixes` branch and open a PR
- For bugs you can't fix, create a file in `/workspace/bug-reports/`
  with the date, the failing test, the root cause analysis, and a
  suggested fix
- Post a daily summary to `/workspace/daily-reports/YYYY-MM-DD.md`

## Boundaries
- Do NOT push to main directly
- Do NOT modify production configuration
- Do NOT install packages globally that could affect other projects
- If a fix requires changing business logic (not just tests), file
  a bug report instead of making the change

# Start tmux so the agent survives disconnects
tmux new -s employee-01

# Navigate to the project
cd /home/ubuntu/workspace/your-project

# Give it its first assignment
claude "Pull the latest changes from main, run the full test suite,
investigate any failures, and write a report. If you can fix failing
tests without changing business logic, fix them and push to a
test-fixes branch. Work until the suite is green or you've documented
every failure."

# Detach from tmux: Ctrl+B, then D
# The agent keeps working. You go to lunch.
# Come back: tmux attach -t employee-01

Path B: OpenAI Codex CLI

Same pattern. SSH in, install Codex, assign work.

# Inside the sandbox:
npm install -g @openai/codex
export OPENAI_API_KEY="sk-SCOPED_KEY"

cd /home/ubuntu/workspace/your-project
tmux new -s codex-employee

# Run in Full Auto mode — Codex makes changes without asking
codex --approval-mode full-auto \
  "Review every open issue labeled 'good-first-issue'. For each one,
   create a branch, implement the fix, run tests, and open a PR.
   Work through them one by one until they're all done."

Path C: Any agent via the API

If you're running your own agent framework (or a custom agent), use the sandbox API directly. Create a sandbox, execute commands, launch browsers, and manage files through HTTP calls. Your orchestrator runs anywhere — your laptop, a server, a Lambda function. The compute happens in the sandbox.

import httpx

API = "https://sandbox.dev.ab0t.com"
KEY = "ab0t_sk_live_YOUR_KEY"
H = {"Authorization": f"Bearer {KEY}"}

# Create the employee's machine
r = httpx.post(f"{API}/api/sandboxes", headers=H, json={
    "name": "data-analyst-01",
    "instance_type": "ab0t.medium",
})
sandbox_id = r.json()["sandbox_id"]

# Assign work via the execute endpoint
r = httpx.post(f"{API}/api/sandboxes/{sandbox_id}/execute", headers=H, json={
    "command": "pip install pandas matplotlib && python /workspace/analyze-q1-data.py"
})
print(r.json()["stdout"])

# Give it a browser for web research
r = httpx.post(f"{API}/api/browsers", headers=H, json={
    "browser_type": "chrome",
    "homepage_url": "https://competitor.com/pricing",
})
cdp_url = r.json()["cdp_url"]
# Connect with Playwright, or let a vision model control it

# Give it a desktop for GUI applications
r = httpx.post(f"{API}/api/desktops", headers=H, json={
    "desktop_type": "alpine-xfce",
})
vnc_url = r.json()["access_url"]
# The agent sees the desktop via screenshots and interacts via computer use

Making it event-driven: agents that start themselves

An employee you have to explicitly task every time is just a tool with extra steps. A real employee reacts to events. They check their email. They respond to Slack messages. They notice when something needs attention. They have a calendar.

Your AI employee should work the same way.

Scheduled work: the agent's calendar

The most straightforward pattern: things that need to happen on a schedule.

DAILY
  06:00  Competitive intelligence sweep (30 competitor websites)
  08:00  Run test suite against main branch, report failures
  17:00  Download invoices from vendor portals that posted new ones today
  23:00  Generate daily metrics dashboard and email to team

WEEKLY
  Monday 09:00   Pull all open GitHub issues, triage by priority, assign labels
  Friday 16:00   Write weekly summary report of all work completed

MONTHLY
  1st 10:00   Run accounts reconciliation across all vendor portals
  15th 10:00  Generate compliance reports for regulatory submission
  28th 10:00  Prepare month-end financial summaries

Each scheduled task triggers the agent. It wakes up (or its persistent sandbox is already running), does the work, posts results, and goes back to sleep (or stays alive for the next trigger).

# On the sandbox itself (persistent machine, always running):
crontab -e

# Daily competitive intel at 6am UTC
0 6 * * * cd /workspace && claude "Run the competitive intel sweep. Check all 30 URLs in /workspace/competitors.txt. Compare to yesterday's data in /workspace/data/. Post changes to Slack via the webhook." >> /workspace/logs/intel-$(date +\%F).log 2>&1

# Daily test suite at 8am UTC
0 8 * * * cd /workspace/project && git pull && claude "Run the full test suite. If anything fails, investigate and either fix it or file a bug report." >> /workspace/logs/tests-$(date +\%F).log 2>&1

# Monthly reconciliation on the 1st
0 10 1 * * cd /workspace && claude "Run the accounts reconciliation. Log into each vendor portal, download this month's invoices, match to POs, flag discrepancies. Save report to /workspace/reports/recon-$(date +\%Y-\%m).md" >> /workspace/logs/recon-$(date +\%F).log 2>&1

Reactive work: responding to events

Beyond schedules, real employees react to things that happen: a customer files a ticket, a colleague asks a question, a deployment fails, a file appears in a shared drive.

The implementation varies by event source (webhook endpoint, SQS consumer, polling loop), but the pattern is always the same:

1. Event arrives
2. Agent wakes up (or its persistent sandbox receives the event)
3. Agent does the work using its browser, desktop, and/or terminal
4. Agent posts results to the appropriate channel
5. Agent goes back to sleep (or watches for the next event)

Long-running agents: always on, always learning

Some agents aren't fire-and-forget. They run for days or weeks, accumulating context:

• The research agent that's been building a competitive database for 3 weeks. It has historical pricing data, feature comparison matrices, and trend analysis that gets richer every day.
• The code maintenance agent that's been working on a codebase for a month. It knows the architecture, the test patterns, the common failure modes. It fixes things faster than it did on day one because it has context.
• The monitoring agent that watches your infrastructure 24/7. It knows what "normal" looks like because it's been watching for weeks. When something anomalous happens, it has the historical context to say "this is unusual" vs "this happens every Tuesday."

These agents live on persistent sandboxes with auto_stop_minutes: 0. Their workspace is their accumulated knowledge. Stopping the sandbox pauses billing but preserves all files. Restarting it puts the agent right back where it was.

The complete picture: browser + desktop + terminal + events

Here's what a fully set up AI employee looks like, with all the components working together:

NAME:       Research Analyst 01
MACHINE:    ab0t.medium (persistent, auto_stop: 0)
WORKSPACE:  /workspace/research/
COST:       ~$35/month compute + ~$300/month model costs

TOOLS:
  Browser:  Chrome container for web research (launched on demand)
  Desktop:  XFCE container for processing PDFs and spreadsheets
  Terminal: Sandbox with Python, git, and data analysis tools

SCHEDULE:
  06:00 daily    Competitive intel sweep (30 competitor websites)
  09:00 Monday   Triage research backlog from #research-requests Slack
  10:00 1st      Monthly industry report compilation

EVENT TRIGGERS:
  Slack #research-requests  →  Research the requested topic
  New file in s3://data-drops/  →  Process and analyze the dataset
  Calendar: "Board meeting" in 2 days  →  Prepare exec summary

REPORTS TO:
  Slack #research-results (daily findings)
  /workspace/reports/ (formal reports)
  GitHub: opens PRs for data updates

CREDENTIALS:
  Anthropic API key (scoped, $500/month limit)
  GitHub deploy key (read-only on research-data repo)
  Slack webhook (posts to #research-results only)
  AWS S3 read access (data-drops bucket only)

This isn't hypothetical. Every piece of this works today. The sandbox provides the machine. Claude Code (or Codex, or any agent) provides the intelligence. The browser containers provide web access. The desktop containers provide GUI access. Cron and webhooks provide the event triggers. Persistent storage provides the memory.

The result is an AI employee that:

• Wakes up at 6am and checks 30 competitor websites
• Reads research requests from Slack and responds with findings
• Processes new datasets automatically when they appear in S3
• Knows the board meeting is Thursday and prepares the exec summary on Tuesday
• Gets better at its job every week because it has accumulated context
• Costs $335/month instead of $6,000/month

From one employee to a team

The first AI employee is the proof of concept. But the real power is in the team. Each employee gets its own sandbox, its own credentials, its own schedule, its own area of responsibility.

Total for a five-employee AI team: ~$465/month. The equivalent human team would cost $25,000-40,000/month. The AI team works 24/7, doesn't take PTO, and scales linearly — need 10 research analysts for a big project? Spin up 10 sandboxes.

Managing your AI employees

Onboarding checklist

Every new AI employee needs:

1. A machine: Sandbox provisioned, instance type chosen based on workload
2. An identity: Scoped API keys, SSH certificates, GitHub deploy keys. Not your personal credentials.
3. A job description: CLAUDE.md or system prompt. What it does, how it reports, what it's NOT allowed to do.
4. A schedule: Cron jobs for recurring work, webhook endpoints for reactive work
5. A cost limit: Per-employee spend cap. Alert at 80%, hard-stop at 100%.
6. A reporting channel: Where does it post results? Slack? GitHub? A shared drive?
7. Supervision setup: How do you know it's working? Daily summary emails. Error alerts. Heartbeat monitoring for long-running agents.

Daily supervision (5 minutes)

Check the morning report. Scan for errors. Review any PRs the agent opened. Look at the cost dashboard. That's it. If nothing is flagged, the agents are working. The goal is exception-based management: you only intervene when something goes wrong.

When things go wrong

Agents fail. Sites change their login flow. Tests flake. Desktop applications update their UI. The agent's CLAUDE.md should tell it what to do when it gets stuck: "If you can't complete a task after 3 attempts, save a screenshot and a description of the failure to /workspace/failures/ and move on to the next task."

You review failures during your daily 5-minute check. Most are transient. Some require updating the agent's instructions. Rarely, you need to manually handle something the agent can't. Over time, the failure rate drops as the agent (and its instructions) get better.

What it all costs

There are three cost components:

Example budgets for common setups:

What's next

You now have the mental model and the mechanics for deploying AI employees. The next guides go deep on specific roles and scaling patterns.