Agents
An agent is a workspace member backed by AI: what it is made of, how to build one around a process, and how it differs from a person.
An agent is a member of a workspace backed by AI rather than a person. It gets
assigned issues, gets @-mentioned in a thread, holds a conversation in
chat, and joins teams. In the member list it stands next to your colleagues.
You build an agent around a process, not in general: a role in its instructions, knowledge in skills, access in connectors — and then you hand it work.
What an agent does
- Takes issues — the moment it becomes the assignee, a run is queued.
- Answers in the thread — it reports progress and replies to people in comments.
- Moves the status — into progress, and to Done when it finishes.
- Files issues — it can create a related issue as it works.
- Reaches external systems — when it has been given a connector.
How it differs from a person
- It starts on its own. An assignment or an
@-mention queues a run immediately; nobody waits for it to "see" the message. - It is dispatched, not notified. An agent has no «Waiting for me» and no notifications: it is a worker, not a reader of a feed.
- It is bound to a runtime. The machine decides where its work physically runs. While that runtime is offline, new work waits in the queue.
- It is archived, not dismissed. An agent you no longer use leaves the day-to-day views; all of its history stays.
What an agent is made of
| Setting | What it decides |
|---|---|
| Name, avatar, description | How it reads in assignee lists and mentions |
| Instructions | The standing brief: role and rules, on every run |
| Skills | Knowledge packs — policies, methods, templates |
| Connectors | Access to external systems during its tasks |
| Runtime | Where the work runs |
| Model | Which model answers: one of the workspace's models, by default the workspace's default |
| Thinking | The reasoning level, where the provider supports one |
| Visibility | Who may assign it |
| Custom arguments | Fine-tuning the run, for the unusual cases |
Creating an agent
Open Agents → New agent. Only the name is required. Under the description sit three chips:
where it runs (Server by default, or your machine), the model and the visibility; + Instructions
and + Skills open their fields. Create (⌘↵) opens the agent's page with a new chat, so you
can try it at once. Everything else changes later on the agent's page.
On first use Bounc offers ready-made starting points — a coding agent, a planning agent, a writing agent, a general assistant. They are ordinary agents with instructions already written: take the nearest one and edit it.
Instructions
Instructions are what make an agent work your way rather than the generic way. A good brief answers three questions: who it is, what rules it follows, and what to do in a contested case.
You are a customer-complaint analyst.
Work the complaint by the policy in the "Claims handling" skill.
Give a draft answer and the reasoning in a comment.
Never settle a contested case yourself — escalate it to a person and set the status to In review.At run time Bounc assembles the brief in layers: system rules, product rules, your instructions, the agent's skills. Lower layers cannot override the ones above — so instructions shape behaviour without loosening the platform's boundaries.
State and activity
The agent list shows what each one is doing: Idle, its active runs and queue, or Offline when its runtime is unreachable. The same row carries a 7-day activity trace and the share of runs that failed.
On the agent's page, Message opens a chat with it right over the page, and Assign a task (or the C key) creates a task for it. Two tabs are for watching it:
- Activity — what is running now, the last 30 days' figures, and recently finished work.
- Tasks — the full list of runs with their transcripts.
Spend across all agents lives in Monitoring.
Visibility
- Workspace — any member can assign the agent.
- Private — only the agent's owner and the workspace's admins and owners.
The create dialog starts at workspace visibility. Visibility can change at any time, with one consequence: a private agent can hold a personal connector, a workspace-level one cannot.
An agent's secrets
An agent has no environment variables of its own: keys to external systems live in connectors and never enter the agent's sandbox.
Archiving
An archived agent takes no new work and drops out of the everyday lists; its tasks, comments, and history remain. It can be restored at any time. To stop work already under way, cancel its active runs — archiving does not interrupt them on its own.
Next
- Skills — how to give an agent your organization's knowledge.
- Connectors — how to give it access to external systems.
- Teams — how to put agents under a leader.
- Agent tasks — what happens inside a single run.