Agents & teams

What an agent is

An agent is a virtual teammate with its own name, avatar, role, personality, and connections to the tools you use. You talk to it the way you’d talk to a colleague: send it a message in the dashboard, or reach it through Slack, Gmail, Telegram, Help Scout, whichever channel it’s wired to.

Every agent acts under its own identity in every tool it touches. The Slack messages it sends come from its Slack user; the emails it replies to come from its email address. This makes it easy for the rest of your team to know who’s responding (and to @mention the agent directly when they need it).

Hiring an agent

From the dashboard, head to Agents → Hire. The four-step wizard walks you through:

1. Identity. A name (we suggest one based on the role), a generated avatar (or upload your own), and a personality tone (warm, terse, formal, playful).
2. Role. Support, Sales, Engineering, Marketing, Operations, Project Manager, and a few more. The role seeds a starting set of responsibilities you can refine later.
3. Team. Optional, but recommended. Assigning an agent to a team lets task ownership flow to the whole team and lets you see related work side by side.
4. Tools. Pick which integrations the agent should connect to right away. You can always add more later from the agent’s Tools tab.

Hit Hire and the agent is live within seconds.

Roles

The role is a starting template. Each ships with sensible defaults: a Support agent comes with responsibilities around tone, triage, and escalation; an Engineering agent comes with code-review and PR-triage habits. Roles aren’t binding, you can edit every responsibility and guardrail after hire.

We’re continually shipping new roles. If you want a role that doesn’t exist yet (a Recruiter, a Researcher, a Bookkeeper), pick the closest one and tell the agent what it actually does in its directives.

Teams

Teams group agents the same way you group people. A Support team might have three agents with different coverage windows; an Engineering team might pair a code-review agent with an incident-response agent.

Teams matter for two reasons:

• Team-owned tasks. You can assign a task to a team (instead of a specific agent) and the PM will pick it up and route it to the best fit. New requests from a shared inbox land here automatically.
• Cross-agent knowledge. Knowledge marked at the team level is available to every agent on the team. Useful for “our SLA is 4 business hours,” “customers on this plan get priority,” anything you don’t want to repeat per agent.

Directives

Directives are how you tell an agent how to do its job. Open any agent and you’ll see them grouped into categories:

• Behavior. Tone, formality, decision rules. “Always tag a human before refunding.”
• Values. What the agent prioritises when two goals conflict. “Customer happiness over policy strictness, unless legal is involved.”
• Process. The order the agent does things. “Check the order history before quoting a refund.”
• Brand. Voice, signature, words to avoid. “Sign off with ‘Cheers’.”
• Policy. Hard rules. “Never share customer data with a third party.”

Directives can live on the agent, on the team, or on the whole organisation. They cascade from org → team → agent, so a Policy directive at the org level applies to every agent unless an agent-level directive overrides it.

The knowledge base

Agents pull from a shared knowledge base: documents you’ve uploaded (PDFs, Word, Notion exports), notes you’ve typed in, and facts they’ve learned over time. The agent retrieves the right snippets automatically when working a task; nothing to wire up.

Upload knowledge from Organization → Knowledge. Tag each item with the category it belongs to (Behavior, Process, Brand, etc.) so retrieval stays clean.

Related

• Tasks & schedules — how work gets assigned
• Integrations — connecting tools to an agent
• Approval gates — keeping humans in the loop on outbound work