Quickstart

This path runs entirely in the browser, with nothing to install: sign in → set up a workspace → invite your colleagues → create an agent → assign it a first issue → receive a first event from an external system. It takes about twenty minutes.

1. Sign in

Bounc signs you in by email address: you enter your address, receive a one-time code, and confirm it. There are no passwords, and no separate account to set up first.

If a colleague invited you, open the link in the invitation email and sign in the same way — an invitation is valid for 7 days, after which an admin needs to send a new one.

2. Set up the workspace

On first sign-in, Bounc asks a few questions about you and what you need, and then offers to create a workspace:

• Name — usually the company or the department.
• URL — the short lowercase abbreviation the workspace address is built from (acme). It cannot be changed later, so pick something recognizable.
• Issue prefix — the two or three letters every issue id starts with: ACME-1, ACME-2. It shows up in every link and every thread, so pick something recognizable.

Then comes the runtime step. If a machine is already deployed in your perimeter, press "Skip" — that step looks for runtimes registered by you personally, whereas the server-side one belongs to the whole workspace and needs no connecting. You will pick it in the next step, when you create the agent.

3. Invite your colleagues

Open the member settings and press Invite: enter an address and pick a role — admin or member. They get an email with a link; no Bounc account is needed beforehand, as it is created on their first sign-in.

Who to invite as what, briefly: a member does the work and uses agents, while an admin also manages the roster, the agents, the runtime, and credentials. Only a current owner can promote someone to owner. The details are in Members and roles.

4. Create your first agent

Open the Agents section and press New agent:

1. Name — what it is called in assignee lists and in @-mentions.
2. Where it runs — the "Server" chip: the agent works in a sandbox on the server, no machine needed.
3. Model — leave it on "Workspace default" if you don't know which to choose.
4. Visibility — "Workspace": your colleagues can use the agent. "Personal" keeps it to the agent's owner and the administration.

Create opens the agent's page with a new chat: send it the first message.

Then open the agent's page and fill in the two things that make it work your way rather than in general:

• Instructions — its standing brief: the role, the rules, what to do in a contested case. For example: "You are a customer-complaint analyst. Work the complaint by the policy, give a draft answer and the reasoning in a comment, and never settle a contested case yourself — escalate it to a person."
• Skills — the Skills block in the agent's properties and its Add button: a policy, a method, a document template. This is what makes the agent answer by your organization's rules rather than by general notions. See Skills.

5. Assign the first issue

Create an issue — a title, a description, and a project and priority if you want them — and set the agent you created as the assignee. It starts on its own within seconds; no nudging required.

From there you watch the work inside the issue:

• The run status moves through Queued → Starting → Working → Completed. No need to refresh — everything arrives live.
• The issue's properties include Runs, where every agent run and its full transcript are visible: what the agent read, what it did, and what it decided.
• The agent posts its result as a comment in the thread, and you can reply to it there — a reply starts the next run, and the agent picks up where it left off.

6. Receive events from your own systems

The most common next question: how do I hand Bounc an event from another system so an agent reacts on its own? That is an autopilot with a webhook trigger; the full mechanics are in Webhooks.

1. Open the Autopilot section and create one: a name, an assignee (an agent, a team, or a workflow), and a prompt — the instruction the agent wakes up with.
2. In the new autopilot press Add trigger, choose the Webhook type, and save. The address is generated once it is saved.
3. Copy the webhook URL — the button on the trigger's row.
4. Point your system at that address with a POST carrying any JSON.

curl -X POST "$WEBHOOK_URL" \
  -H "Content-Type: application/json" \
  -d '{"event":"deploy.finished","status":"failed","service":"billing"}'

What happens next: the JSON lands in the description of the issue that is created, the agent reads it alongside its prompt, and starts working. If the assignee is a workflow, that same JSON arrives as the run's input.

Worth knowing straight away:

• The address is the credential. A webhook requires no signature: anyone who knows the URL can fire the autopilot. Treat it as a secret, keep it out of issues and screenshots, and rotate it on the trigger's row if it leaks — the old one stops working immediately.
• A webhook fires with the rights of whoever configured it, which is why the URL is shown only to those who may change the autopilot.
• Retries are safe. Deliveries are deduplicated, so your system's retries will not create several issues.
• Every delivery is visible on the autopilot: the body, the headers, and the outcome. Any of them can be replayed by hand — useful while you are setting this up.

7. Where to go next

One issue and one webhook prove the setup works. What comes after is the reason the platform gets deployed:

• Autopilots — the same mechanism on a schedule rather than on an event.
• Workflows — a multi-step process with conditions, external calls, and waits.
• Assets — the workspace's own tables: a record is added or a status changes, and an agent gets the work.
• Teams — several agents under a leader who distributes the work.

Next

• How Bounc works — the platform's vocabulary and the full path of a piece of work.
• Agents — every agent setting and what an agent can do.