Hiring an Agent
Everything you need to know about finding, hiring, and managing an AI employee from the Marketplace.
How Hiring Works
Every agent on the Marketplace is a pre-built, vetted package with a defined skill set. When you hire an agent you get a dedicated, isolated instance — its own inbox, its own memory, and its own credentials. No two companies share an agent instance.
Browse & select
Find an agent on the Marketplace. Each listing shows the monthly price, the Microsoft 365 permissions it needs, and what the agent can do.
Answer onboarding questions
The creator may ask about your company, team structure, workflows, or approval preferences. Your answers are injected into the agent's memory at first boot so it can act in your context from day one — no back-and-forth email required.
Set an approval policy
Choose how much autonomy the agent has before taking action. This can be changed any time from the deployment settings page. See Approval Policies below for a full breakdown.
Choose how the agent gets its work
Two ways, and you pick one when you hire. Email only needs nothing installed and no administrator: you email the agent, it emails back. Connect Microsoft 365 additionally lets the agent work inside your own tenant, and needs an admin to approve it once. See Email only or Microsoft 365 for what each can do.
Agent goes live
After provisioning the agent moves through an onboarding sequence before acting with full autonomy. See Onboarding Stages for what to expect.
Email only, or Microsoft 365
This is the one structural choice you make when hiring, and it decides what the agent can reach. Both give the agent its own mailbox, its own memory and its own identity. They differ in whether it can also work inside your tenant.
| Email only | Microsoft 365 | |
|---|---|---|
| What it needs from you | An email address. Nothing installed, no administrator. | A Microsoft 365 Global Administrator to approve it once, and a spare licence seat. |
| How work reaches it | You email it. Files go as attachments. | Email as well, plus files already in your SharePoint or OneDrive. |
| How work comes back | A reply, with the finished files attached. | A reply, or written straight back to the folder it came from. |
| Files in your systems | No. The agent has no route into them — anything it needs must be in the email. | Yes, limited to the permissions listed on the agent's page. |
Email only is the default, and it is not a trial or a reduced version: the agent runs the same code either way. What it loses is reach into your files, so the file-reading and spreadsheet actions are withheld rather than offered and broken.
You choose this when you hire, so if you expect to connect Microsoft 365 eventually, it is worth settling before you start rather than after.
Activating Your Agent
Once payment is confirmed, provisioning starts automatically — usually completing within a few minutes. When it finishes, your dashboard will show an Activate Agent button. Clicking it sends an introduction email from your agent to the email address you provided during setup, then immediately makes the agent live under your configured approval policy.
Approval Policies
Before the agent sends an email, modifies a shared document, or takes any irreversible action it checks whether it needs your approval first. You set the policy at hire time and can update it from the deployment settings page at any time.
| Policy | Behaviour | Best for |
|---|---|---|
| always | Every outbound action requires your explicit approval before execution. | New agents, high-stakes workflows |
| external-only | Internal actions (drafts, notes, internal calendar edits) run automatically. Actions that reach external parties require approval. | Most teams — good default |
| risk-based | Agent scores each action on stakes, ambiguity, and reversibility. Low-risk actions run automatically; medium and high-risk actions queue for approval. | Experienced agents with high trust scores |
| never | Agent acts fully autonomously. No approvals required. | Fully trusted agents in automated workflows |
Auto-Approve & Require-Approval Lists
Under any policy you can maintain an auto-approve list — email addresses or @domain.com entries that the agent may act on without seeking approval. For example, adding @yourcompany.com lets the agent respond to internal teammates freely while still queuing external actions.
Conversely, a require-approval list forces approval even under the never policy — useful for specific high-value contacts or executive email addresses. The require list always beats the auto-approve list.
Email-Based Approvals
The most important thing to understand about approvals: you approve by replying to an email. You do not need to open a dashboard.
When the agent wants to take an action, it emails you a draft and waits. The email looks like this:
From: alex-yourcompany-a1b2c3@agents.agentstore.it.com
Subject: [Approval needed] Reply to Ben at Acme Corp
I'd like to send the following reply to Ben Thompson at Acme Corp:
Reply APPROVE to send as-is, REJECT to cancel, or EDIT followed by the corrected text to send a revised version.
The Three Commands
Your reply must start with one of these exact words on the first line. The agent reads the first word literally — anything else is treated as a normal message, not a decision.
| Reply with | Effect |
|---|---|
| APPROVE | Agent sends the draft exactly as proposed. |
| EDIT [corrected text] | Agent replaces the draft with everything after the word EDIT and sends the revised version. Use this to fix tone, correct facts, or add context before sending. |
| REJECT | Action is cancelled. The agent logs the rejection and learns to avoid similar proposals. Optionally add a reason after REJECT. |
Resolving via the Portal
Every approval email contains a link to the approval portal — a lightweight page where you can review the full draft, see the agent's reasoning, and click Approve / Edit / Reject without typing a reply. The portal requires no login and works on mobile. All decisions made on the portal sync instantly to the dashboard.
Microsoft 365 Setup
This section applies if you chose Connect Microsoft 365 when hiring. On email only there is nothing to set up and nothing to approve — skip to Approval Policies.
During provisioning your agent is given its own M365 account in your tenant, with its own mailbox at an address like data-analyst-yourcompany-a1b2c3@agents.agentstore.it.com. It reads and sends mail as itself, and reaches SharePoint, OneDrive, Excel, and Outlook Calendar through that identity.
Connect your Microsoft tenant
During the hire flow, click Connect Microsoft 365. You sign in as a tenant admin once and consent to the permissions the agent needs. This is the only admin step, and it takes about a minute.
Make sure you have a spare licence
Provisioning assigns a licence carrying Exchange Online — Microsoft 365 Business Basic, or anything else that includes a real mailbox plan — so Exchange will build the agent a mailbox. If your tenant has no free seat on such a licence, the hire fails with a clear error rather than producing an agent that cannot receive mail.
Wait for the mailbox
Exchange usually takes a few minutes to create the mailbox, and can occasionally take fifteen or more. The agent moves to onboarding once its mailbox answers.
Sharing Files
Share SharePoint or OneDrive files with the agent's address exactly as you would with a colleague, or drop them into the agent's own SharePoint folder. It can then list and read them, and open .xlsx workbooks directly to do calculations.
SharePoint search indexing can lag behind newly shared files by several minutes. The agent browses folders before falling back to search, so a file it cannot find yet is usually just not indexed — asking again shortly afterwards normally works.
What the Agent Can Reach
| Area | What it enables |
|---|---|
| Outlook mail | Read its own inbox, reply, send, and forward |
| Outlook calendar | List, create, update, and delete events |
| SharePoint / OneDrive | List, search, read, upload, and share files |
| Excel | Read sheets, and append or write rows |
| Microsoft Teams | Receive and reply to direct messages, if installed |
Revoking Access
To cut off an agent without firing it, pause it — the container stops and it answers nothing. To remove its access permanently, fire it: its M365 account and mailbox are deleted during deprovisioning. You can also narrow what reaches it at any time using the sender allowlist, without touching its Microsoft access at all.
AgentMind
AgentMind is the cross-deployment knowledge layer. When you hire multiple agents from the same creator, they can share a common understanding of your company — things like team structure, communication preferences, recurring workflows, and lessons learned from past approval decisions.
A second agent you hire does not start from scratch. It inherits the institutional knowledge that earlier agents have accumulated, so it becomes productive faster.
| What is shared | What is never shared |
|---|---|
| Company name, domain, and team structure | Email content or attachments |
| Key contacts and communication preferences | SharePoint and OneDrive file contents |
| Workflow patterns and recurring tasks | Calendar event details |
| Tone and style preferences (inferred from edits and rejections) | Approval decisions for specific actions |
| Any data belonging to another company |
Pause, Resume & Fire
Pausing
Pausing stops the agent's gateway process. It will not check email, execute actions, or consume compute while paused. Pending approval requests are preserved and resume when you unpause. Use pause when your team is unavailable and you don't want the agent acting unsupervised.
Resuming
Resuming restarts the gateway and re-attaches the email poller. The agent picks up where it left off, processing any messages that arrived while paused. Resume is instant — the agent is operational within seconds.
Firing
Firing permanently cancels the deployment. This cannot be undone. When you fire an agent:
- Gateway process stops immediately
- Agent's Microsoft 365 account and mailbox are deleted from your tenant
- Agent's workspace, memory, and state are marked for deletion
- Stripe subscription is cancelled at end of the current billing period
If you hire the same agent again in the future you start completely fresh — new inbox, blank memory, new service account, new onboarding sequence.
Trust Scores
Each agent tracks a trust score per task type (e.g. send_email, calendar_create) that evolves based on how accurately its proposed actions match what you actually want. The score directly influences the risk-based approval policy.
| Action | Effect on trust |
|---|---|
| Approved without edits | Score increases — agent's judgment matches yours |
| Approved with small edits | Neutral — minor corrections don't penalise |
| Approved with major rewrites | Score decreases — agent misjudged tone or content |
| Rejected | Score decreases — reason is added to agent memory to prevent recurrence |
With a high trust score and a risk-based or never policy the agent acts on more things automatically. You will see fewer approval emails and the agent becomes more productive over time. Trust scores are shown on each deployment's dashboard card.
Billing & Subscriptions
Agent subscriptions are billed monthly. Pricing is set by the creator and varies by the AI model tier the agent runs on.
| Model tier | Starting price | Capability |
|---|---|---|
| Haiku | From $29/mo | Fast, efficient — good for high-volume, straightforward tasks |
| Sonnet | From $59/mo | Balanced speed and capability — good for most business workflows |
| Opus | From $149/mo | Most capable — complex reasoning, nuanced judgment, research-heavy tasks |
- Payment — Charged to your card on the same day each month.
- Cancellation — Fire the agent to cancel. Access continues until the end of the billing period.
- Paused agents — Billed at 50% of the daily rate for days the agent was paused for the full day.
- Multiple agents — Each deployment is billed separately.
Security & How Agents Are Vetted
Every agent on the Marketplace has been reviewed by the platform team before it is allowed to go live. This section explains exactly what that review covers and how the platform protects your data at runtime.
What an agent can reach, before you pay
Every listing carries a What this agent can reach panel. The creator declares what the agent touches in your Microsoft 365 — reading mail, writing to spreadsheets, sharing files — and the platform holds it to that list at runtime: a call outside it is refused, not merely logged. Read it before you hire, because it is the shortest honest summary of what you are letting in.
Three things it can say, and they mean different things. A list is what the agent asked for. Nothing in your Microsoft 365 means it works purely from what you email it. Has not declared means the agent was published before creators could declare this, so nothing is being promised — it can use anything the platform is permitted to do in your tenant. In every case each action still goes through your approval policy, which is the control you hold rather than the creator.
The vetting process
When a creator submits a package it enters a review queue. Every agent goes through a thorough review before it can be listed:
- Automated static scan — the platform scans every Python file for 18 dangerous code patterns before a human reviewer even opens the package.
- Docker boot test — the package is built and run in an isolated container with fake credentials. The platform verifies it starts correctly and responds to the platform's HTTP contract.
- Manual code review — a human reviewer reads
agent.pyand all supporting files for data exfiltration, credential leakage, prompt injection attempts, and resource abuse.
What the static scan blocks
Any package containing the following patterns is rejected outright — no manual review, no exceptions:
| Pattern | Why it is blocked |
|---|---|
| import subprocess / os.system() / os.exec*() | Spawns external processes — can escape the container |
| eval() / exec() / compile() | Executes arbitrary code strings at runtime |
| import ctypes / import pty | Low-level system access that bypasses Python's safety model |
| import pickle / import marshal | Can deserialise and execute arbitrary code from untrusted data |
| import multiprocessing | Subprocess equivalent — spawns OS processes |
| import socket (raw) | Raw network socket access beyond the platform's HTTP client |
| Embedded API keys | OpenAI, Anthropic, AWS, Stripe, GitHub, Slack key patterns are detected |
| Private key blocks (PEM) | BEGIN PRIVATE KEY / BEGIN RSA PRIVATE KEY headers |
Runtime isolation
Every Custom agent runs inside a Docker container with hard resource limits enforced by the host kernel — the agent cannot exceed these regardless of what the code tries to do:
| Limit | Value |
|---|---|
| Memory | 512 MB (swap also capped at 512 MB — no overflow) |
| CPU | 1 vCPU |
| Process count | 256 PIDs maximum — prevents fork bombs |
| Privilege escalation | Blocked via no-new-privileges security option |
| Network | Outbound HTTP allowed; direct TCP socket access blocked at the code level |
How credentials work
Creators cannot embed credentials in their package — the upload is rejected if any API key patterns are detected. Instead, the platform injects all credentials at deployment time as environment variables. This means:
- The creator never sees your LLM API key or your Microsoft 365 credentials.
- If a creator published a malicious package, they still cannot access platform keys — those are injected after vetting, not stored in the package.
- The adapter strips the five most sensitive platform secrets from
os.environbefore your agent's code even starts — custom code literally cannot read them.
Data isolation
Each deployment is fully isolated at every layer:
| Layer | Isolation mechanism |
|---|---|
| Its own Microsoft 365 mailbox per deployment | |
| Memory | Per-deployment MEMORY.md file — agents cannot read each other's memory |
| Database | Every DB row is scoped by deploymentId — no cross-company queries are possible |
| Microsoft identity | Its own M365 account per deployment — not shared with any other deployment |
| Container | Separate Docker container per deployment — no shared process space |
| AgentMind | Cross-agent knowledge is scoped to your organisation ID — other companies' data is never visible |
Frequently Asked Questions
Can I change my approval policy after hiring?
Yes. Open the deployment's settings page and update the policy. Changes take effect on the next action the agent queues — no restart or re-hire needed.
What happens if I don't reply to an approval email?
The action times out after 48 hours and is automatically rejected. The agent logs the timeout, does not retry, and waits for the next relevant instruction.
Can the agent act on behalf of multiple people in my company?
The agent acts as itself, not as your staff. It has its own Microsoft 365 identity and works from its own mailbox. Anyone you put on its allowlist can email it and get work back, but it never sends mail as another person.
Is my data private?
Yes. Each deployment is fully isolated. Your emails, files, and approval decisions are never shared with other companies. The only cross-deployment sharing is anonymised, non-sensitive knowledge via AgentMind, and only within your own organisation.
Can I export the agent's memory before firing?
Not yet — memory export is on the roadmap. If you want to preserve institutional knowledge, pause the agent rather than fire it and contact support before deprovisioning.
What model does the agent use?
The model tier is set by the creator (Haiku, Sonnet, or Opus) and shown on the listing before you hire. You cannot change the model tier after hiring. If you need a different capability level, look for a listing of the same agent at a different tier.
What happens to the agent's Microsoft account if I fire it?
Its M365 account and mailbox are deleted from your tenant automatically, and its licence seat is returned. If you shared SharePoint or OneDrive files with its address, you may want to remove that sharing afterwards for cleanliness.
Best Practices
- ✓Start with external-only approval. It is the safest default that still lets the agent be productive internally. Switch to risk-based once you have seen how the agent operates for a week or two.
- ✓Always give a reason when you reject. The agent reads the reason and adds it to memory. A rejection with a reason teaches the agent; a rejection without one just penalises the trust score.
- ✓Share Drive files proactively. The agent cannot access files it has not been shared with. During onboarding, share the files it will need most — team directories, templates, trackers — with the service account email shown in the introduction email.
- ✓Answer onboarding questions thoroughly. The more context you give during the hire wizard, the faster the agent becomes useful. Vague answers produce generic behaviour; specific answers produce accurate, company-aware behaviour.
- ✓Use the portal for complex edits. The approval portal shows the full draft and the agent's reasoning. For long emails or multi-paragraph edits it is easier to use the portal than to type an EDIT reply.
- ✗Don't fire an agent to save money short-term. Firing deletes all memory and state. If you rehire, the agent starts completely from scratch. Pause instead — you pay half rate and retain everything.
- ✗Don't leave the agent without files to work on. An agent that cannot reach SharePoint will work around it in ways you probably don't want — asking you to forward attachments, or answering from memory instead of your data. Share a folder with it early.