intentic
Create your workspace
Agent Orchestration

Autonomous employees

A specialized agent is a purpose-built sandbox. Give one a workspace, tools, system access, and curated context; hand it real work; make it event-driven; then run a team of them, one per role.

On this page(9 sections)

The recipe

You'd never onboard a new hire with one paragraph of instructions and no laptop. A specialized agent is the same: it needs an environment, not just a prompt. Building one is five ingredients and two multipliers:

  • A workspace: its own sandbox.
  • Tools: the libraries and CLIs of its trade, really installed.
  • System access: the services it operates, wired in as capabilities.
  • Curated context: the skills, runbooks, and house style of the job.
  • Work + supervision: real tasks, reviewed as diffs.
  • then autonomy (events wake it) and scale (a team of them).

1 · Give it a workspace

Start a sandbox and name it for the work it owns: storefront, customer-support, database-migrations. That dedicated sandbox is the agent: everything you add below scopes to it. Run as many as you have distinct roles, so a team never shares an environment. See Quickstart to bring one up.

2 · Install its tools

Tell the agent what the job runs on and let it propose an environment layer: a database client, a headless browser, a language toolchain. You approve it, and it is installed in the image rather than described in a prompt. The mechanics are in Docker setup; the rule is that an agent can never change its own environment without your sign-off.

3 · Connect its systems

Add the services the role touches as capabilities: GitHub, a database, Sentry, Stripe, an SSH host, an MCP server or your own tools, a click each. The credential is stored inside the sandbox and never shown back or written into workspace files, and the agent operates the service from chat. A capability that ships a skill teaches the agent to use it the same turn.

4 · Curate its context

Specialization lives here. Load only what this one job needs, and load it every turn:

  • Skills: short procedures the agent loads on demand (.claude/skills).
  • House style + project rules: an AGENTS.md the agent is told each turn, whichever model runs it.
  • Repos, docs, and runbooks: the material the role actually works from, in the workspace.
  • Agent plugins: a packaged bundle of skills, subagents, and hooks for a whole discipline.

Curated context is what makes the output yours instead of the model's average, and the single biggest lever on quality.

5 · Give it work, keep the wheel

Hand it a real task. In interactive chat the agent starts in plan mode: it proposes, you approve, and every change is a diff you commit or discard. Loosen or tighten it per conversation, and environment rebuilds always wait for explicit approval. That is how you trust an agent with real access without losing the ability to say no.

6 · Make it autonomous

An employee doesn't wait to be told to start. Automations wake the agent on the events that matter:

  • Schedules: a nightly cleanup, a morning report, a weekly release.
  • Webhooks: a push, a Sentry alert, a Stripe payment.
  • Listeners: a new email or a Discord message.

Each wake is a fresh, specialized run that leaves a transcript, and you can gate it behind a guard command so it only proceeds when a condition holds. The agent keeps working between your check-ins.

7 · Grow a team

Once one role is specialized the next is cheap: give it its own sandbox and repeat. Roles hand work down the line too, because a run can fire the webhook that wakes another: triage to a fixer, fixer to a reviewer.

Another sandbox, or another persona?

Growing a team, you'll hit a fork: does this new thing need its own sandbox, or just its own persona in one you already have? Go by what's actually different.

  • A new sandbox is a new worker: its own tools, systems, budget and code. Reach for it when the job is different or needs to be kept apart: a migrations agent and a support triager have no business sharing an environment.
  • A new persona is the same worker with a different face for the outside world. A persona ties together the logins that are the same someone, so the agent posts as that account and no other. One sandbox can speak as your brand and your founder, or answer for two products. Keep a persona draft-only and it proposes rather than publishes.

The short of it: different work wants a new sandbox; a different face for the same work wants a new persona.

Two newer mechanisms add capacity without creating another role. A full child agent is a delegated workstream inside this sandbox, with its own conversation and branch but the same sandbox boundary. A runner is only another place to execute that work: it adds compute, not identity, tools or authority.

That's the whole arc: a sandbox becomes a specialized agent, a specialized agent becomes an autonomous employee, and a handful of them become a team, driven from any browser.

Type to search every page, in the docs and the API reference.