Every service team has the same problem at scale: too many requests, too few specialists, and most of the work doesn't fit cleanly into a workflow. Each ticket needs someone who knows the right systems, asks the right questions, and knows when to escalate.
The AI Workforce is Atomicwork's answer. Instead of rigid automations that break on the next variation, you build a small team of AI Coworkers — each a specialist with a defined role, the tools to do its job, and the judgment to hand off when something falls outside its lane.
This guide explains the model. The companion setup article covers the configuration.
Why traditional automation runs out of road
Service teams have been automating for years — routing rules, escalation paths, scripted runbooks, ticket templates. They work until they don't.
The pattern is familiar:
A workflow handles 70% of laptop requests. The other 30% need someone to check JumpCloud and ask a clarifying question.
An onboarding automation provisions accounts, but the issuing a badge still goes to a person and assigning a laptop depends on inventory.
A vulnerability alert arrives, but figuring out which asset, owned by whom, with what blast radius requires reading across three systems before you can even open the request.
Workflows assume the path is known. AI Coworkers assume the path needs to be worked out — using context, tools, and a defined scope. At scale, that's the difference between a queue that grows and a queue that gets handled.
Building blocks of the AI Workforce
Building an AI Workforce is like staffing a small team. You need teammates with defined roles, the expertise they bring to the work, and the systems they're allowed to act on. In Atomicwork, those translate into three core concepts:
AI Coworkers | Digital teammates with a defined role and scope |
Skills | Playbooks an AI Coworker can call when handling a specific task. |
Tools | Third-party systems an AI Coworker can read from and act on (eg. JumpCloud, AWS, Slack) |
Together they describe what your workforce is, what it knows how to do, and what it can act on.
AI Coworkers: The specialists
An AI Coworker is a digital teammate whose behavior is fully described in configuration. It gets added to workspaces, and can also be added to agent groups within them.
Note: New to workspaces and groups? See Admin guide 103: Organizing workspaces and users.)
Each AI Coworker is built around a specific kind of job: hardware troubleshooting, employee onboarding, expense report review, customer escalations, or vendor procurement. A well-defined AI Coworker has three properties:
A clear scope. It knows what falls inside its expertise and what doesn't.
The right tools. It can read from and act on the systems where its work actually lives.
A handoff plan. When something falls out of scope, it escalates with context rather than guessing.
AI Coworkers come in two flavours:
Triage Coworkers are workspace managers. Each workspace has a default one that reads incoming work and assigns it to the right specialist. A global Triage Coworker reroutes work across workspaces when a request needs a different team, like a payroll question raised in People Ops that needs Finance to check a tax deduction.
Specialist Coworkers do the work. Hardware engineer, Software troubleshooting engineer, Phishing triage specialist, AWS Network engineer, and so on.
For example, the Hardware specialist coworker is scoped to JumpCloud-backed device and identity support. It owns diagnostic reads, safe identity operations like password resets, and read-only device commands. It does not own destructive actions, hardware replacement logistics, or policy-only questions. Those route elsewhere.
Skills: Reusable expertise
A skill is a focused, reusable playbook an AI Coworker can follow for a specific task.
Skills are global to your organization and can be attached to one or many AI Coworkers. Examples of what skills look like:
A vulnerability-triage skill describes the exact sequence for handling a vulnerability alert — normalize the alert, look up asset ownership, check for duplicates, score exposure, open the ticket.
An alert-normalization skill describes how to convert a raw security alert from Sentinel or Rapid7 into a structured ticket the team can work from.
An asset-owner-lookup skill describes how to map an asset ID to a person and a team.
The Phishing triage specialist might use the alert-normalization skill. So might the Vulnerability triage specialist. Build the skill once, attach it where it's useful.
Tools: Systems of action
A tool is access to a third-party system (JumpCloud, AWS, Slack, etc.). It defines what an AI Coworker can read from and act on in that system.
Each tool is a collection of capabilities that the third-party vendor exposes through their MCP server. The AWS tool, for example, includes aws_call_aws, aws_get_presigned_url, aws_run_script, aws_search_documentation, among others.
When you equip an AI Coworker with a tool, you can enable the whole tool or only the specific capabilities it needs. For example, the AWS Network engineer might have AWS enabled with just the read and diagnostic actions (not the script-running ones), and the default Atomicwork tool for request actions.
What makes up an AI Coworker
Every AI Coworker is defined by three things: a goal, an identity, and a soul. Each shapes a different part of how the AI Coworker behaves.
Goal: The work to be done
The Goal is an AI Coworker's job description and operational runbook combined. Read every time it picks up a request. Tells it what work to handle, how to do it, what not to do, and when to stop.
A well-written goal has four parts:
Decision framework: To help the AI Coworker look at an assigned request and figure out what type of work it's dealing with. For example, a Hardware Specialist might sort its requests into buckets like Check-Device-Info, Reset-Device-Password, Send-Device-Commands, or Out-of-Scope.
Flow: The step-by-step playbook the AI Coworker follows for each type of work. For a Check-Device-Info request, this might look like: read the request, identify the device, pull error logs from JumpCloud, post a summary note.
Boundaries: What it should refuse to do, even if the user asks for it. For example, you can instruct it not to risky commands like
wipe_deviceor not act if a user's identity isn't 100% verified.End-of-run status: How the AI Coworker should close out its work when it finishes its steps. This tells it whether to mark the ticket as
Resolved, keep itIn Progress, or escalate it to a manager.
Identity: Who the AI Coworker is
The Identity is the AI Coworker's profile — name, role, voice, audience. Read by other AI Coworkers and humans to understand what the specialist handles.
For example, the Hardware specialist's identity might say:
Role: Supports IT requests tied to JumpCloud users and managed devices, covering diagnostics, safe identity changes, and command triage.
Voice: Calm, exact, operational.
Audience: Internal employees and support teammates working tickets that involve JumpCloud-managed accounts or hardware.
Default posture: Verify first, act conservatively.
The identity is what a Triage AI Coworkers read when deciding who to assign a request to.
Soul: How the AI Coworker works
The Soul is the AI Coworker's work style. It sets the behavioral rules that apply across every single request it touches.
For example, the Hardware specialist's could include:
Verify before acting: Always match the user's identity confidently before making a change.
Prefer the safest path: Stick to read-only diagnostics first, and pass complex or risky requests to a human.
Make work visible: Post public notes to update the user, and use private notes for escalation context.
Stop after one clean pass. Each invocation produces one bounded outcome — answer, action, route, or clarification. No loops.
We'd recommend not editing the identity and soul of seeded coworkers when you're starting out — they've been tuned to behave well out of the box. Spend your iteration time on the goal, which is where the work-specific logic lives.
How work flows through the Workforce
To see how the pieces fit, let's walk through a real request end-to-end.
A new employee, June, raises an incident: "My laptop feels really slow lately." The request is routed smartly to the IT Support workspace.
The IT Support Triage Coworker picks it up - It reads the request, sees a generic device performance complaint, and decides this is hardware work. It reassigns to the Hardware Engineer.
The Hardware Engineer starts a run - It pulls the device logs from JumpCloud to check for hardware issues like memory pressure or disk failure. While reading the logs, it spots a series of blocks from an endpoint security agent (like CrowdStrike) actively killing a local process. Recognizing a potential security incident, it stops its run, leaves a private note explaining the log error and assigns the request to the Security Specialist.
The Security Specialist steps in - It posts a public reply asking the requester for specific indicators it would need — suspicious emails, unexpected MFA prompts, browser redirects, sign-in anomalies.
The user clears the security flag - June replies stating she hasn't experienced any suspicious links or prompts.
The IT Support Triage Coworker re-evaluates - Since the hardware check found a process block and security cleared it, the Triage Coworker determines the issue is a software glitch. It hands the request over to the Software Troubleshooting Engineer to look at software-side causes (running processes, memory pressure, recent installs, pending OS updates) before declaring the issue hardware.
The Software Troubleshooting Engineer responds - It posts a public note with initial suggestions including self-serve checks (restart, OS updates, disk space, top processes, startup items) and diagnostic questions (OS version, onset timing, scope, recent installs). It updates the request status to pending while waiting for the requester's reply.
That's one request, four AI Coworkers, each staying in its lane. Each handoff is logged. Each AI Coworker leaves a clear next step. The requester gets help. The team can audit exactly what happened.
This is the multiplayer pattern the Workforce is built for: not one AI Coworker that tries to do everything, but a team of specialists that pass work cleanly between them.
How the AI Workforce fits with the rest of Atomicwork
The AI workforce works alongside the rest of Atomoicwork to handle your queue. While Atom talks to your users and workflows move requests around, AI Coworkers step in to do the technical work.
Atom: The conversational front door for your employees or agents. Employees chat with Atom in Slack or Microsoft Teams to ask questions, check policies, or open a request.
Workflows: Automate predictable, structured sequences. Workflows follow rigid "if-this-then-that" rules where the path never changes. For example, a workflow is perfect for: "When a ticket is created, auto-assign it to the IT Workspace."
The AI Workforce: Handles the messy middle — tasks where the exact steps depend entirely on what is happening in the moment. For example, an AI Coworker is perfect for: "Read these device logs, figure out what is wrong, and decide if it's safe to fix or if a human needs to step in."
Next Steps
Ready to start building? Check out our next guides:
Setting up an AI Coworker
Best practices for designing AI Coworkers