Pick a role
Start from a template like Marketing Outreach or Technical Support.
Agent employees
Hire a small AI employee for the jobs that keep slipping.
An agent employee is a named helper with a role, tools, and limits. You stay the boss. The employee watches the right inboxes, does the research, drafts the work, reports back, and asks before crossing the lines you set.
Named roles
Easy setup
Boss approval
Visible activity
Connect the inbox
Give the employee the mailbox, chat, or support channel it should watch.
Choose tools
Allow only the tools the job needs, like search, GitHub MCP, calendar, or email draft.
Set the boss rules
Decide what can happen alone and what must come back to you for approval.
Two real employees
The point is not more chat. The point is work getting prepared.
These are the two employee roles we are shaping now: one grows awareness, the other answers product questions from real source material.
Marketing Outreach Employee
Finds good places to talk about SwarmMarshal and keeps the follow-up from dying in your head.
Search podcasts and YouTube channels that cover AI assistants, productivity, small business operations, developer tools, or agentic AI.
Build a prospect list with host name, audience fit, past episode angle, contact path, and why SwarmMarshal would be interesting to them.
Draft first-touch outreach, follow-ups, and short product pitches focused on concrete demos.
Track who replied, who needs a nudge, and which conversations are close to booking.
Tech note, translated: The employee uses role instructions plus approved search/browser tools. The structured output is a pipeline: prospect, fit, draft, status, next follow-up, and approval request.
Boss rule: You set the policy for claims, sends, bookings, public commitments, and anything that could sound like a promise.
Technical Support Employee
Answers software questions by checking how the product actually works instead of guessing from stale notes.
Watch a support mailbox such as support@swarmmarshal.com.
Read the customer's question and identify the real job they are trying to do.
Use the codebase and approved GitHub MCP tools as source-of-truth context.
Formulate a plain-English answer, include useful steps, and avoid exposing source code, secrets, or internal implementation details.
Tech note, translated: Code-grounded support means the employee searches the live repo, retrieves relevant files or docs, and writes the answer from current behavior. MCP is the tool bridge that lets it inspect approved systems.
Boss rule: You can run it draft-only, or allow direct replies after the answer is grounded, safe, and within policy.
Boss / employee model
You give the employee a job, not a blank check.
That is the important difference. The employee has a role, allowed tools, budget limits, and reporting rules. It can work in the background, but boss policy still controls public commitments, sending, deleting, spending, and policy changes.
Boss
sets role, tools, approvals
Employee
watches, researches, drafts
Report
draft, proposal, or result
What the boss controls
The safety rails are part of the employee's job description.
The job description: what this employee is for and what it should ignore.
The approved systems it may use, such as mail, search, calendar, or GitHub MCP.
Model and spend limits so a background job cannot quietly run up cost.
The line between 'prepare it' and 'go do it.'
Progress notes and proposals that show up for the boss to review.
If credentials, tools, or network access break, the employee explains the fix.
Employees stay visible.
You can see the roster, status, role, and where each employee is blocked or waiting.
The work becomes trackable.
Research, follow-ups, support replies, and approvals can turn into tasks instead of disappearing back into the inbox.
Start with one employee and a narrow job.
Give it one inbox, one role, and clear approval rules. Once you trust the loop, add more responsibility.