How Bounc works
The platform's vocabulary, the path of a piece of work from request to result, and example processes in banking, telecom, retail, and HR.
Bounc answers the three questions any operational work raises: where it lives, who does it, and where the execution happens. Work lives in issues, grouped into projects and initiatives. It is done by the members of a workspace — people and agents, side by side. And an agent's execution happens in a runtime deployed inside your own perimeter.
That yields the platform's defining property: AI is not a separate tool off to the side that people visit to copy text out of. An agent is assigned an issue, reports in its thread, and leaves behind the same history a person would — so a manager sees human work and AI work in one place, under one set of rules.
The vocabulary
| Term | What it is |
|---|---|
| Workspace | The closed perimeter of one company or department: its own issues, projects, agents, workflows, and credentials. Nothing crosses between workspaces. See Workspaces |
| Member and role | A person in a workspace and their level of rights: owner, admin, member. See Members and roles |
| Issue | The core unit of work: a title, a description, a status, a priority, an assignee, and a discussion. The assignee can be a person, an agent, or a team |
| Project and initiative | The two levels of grouping above an issue. A project collects related issues and shows a completion percentage derived from their statuses; an initiative collects projects. See Projects and initiatives |
| Assets | The workspace section holding its own tables: registers, reference lists, pipelines — leads, equipment, candidates, incidents. A person creates a table with no development and no migration, and agents read and write it alongside people |
| Agent | A workspace member backed by AI rather than a person. It gets assigned, gets @-mentioned, writes comments, and files issues |
| Instructions | An agent's standing brief: the role and the rules that hold on every run. "You are a customer-complaint analyst, answer by the policy, escalate anything contested" |
| Skill | A file-based knowledge pack attached to an agent: a policy, a method, a document template, a checklist. This is how institutional knowledge reaches an agent's work. See Skills |
| Team | A group of agents under one leader. Work goes to the team, and the leader decides who takes it. See Teams |
| Runtime | The environment on your servers that executes agent tasks. An agent is bound to a runtime, and that is what determines where its work physically runs |
| Agent task | One run of an agent, with its own status, duration, transcript, and usage accounting. The same issue can go to an agent many times — each time is a new run. See Agent tasks |
| Autopilot | A trigger that starts work without a person: a schedule, an inbound webhook from an external system, or a button. See Autopilots |
| Assetflow | A "when this happens, then do that" rule living on a single Assets table: dispatch an agent with a prepared prompt, or start a workflow. Unlike an autopilot it fires on its own table's records rather than at the level of the whole workspace |
| Workflow | A process assembled on a canvas out of nodes: dispatch work to an agent, check a condition, call an external API, send an email, wait for an event. See Workflows |
| Credentials | Named workspace secrets a workflow uses to reach external systems. The values are write-only: they cannot be read back. See Credentials |
Assets
Issues describe the work, but the work itself almost always rests on data: an incident log, a candidate list, a product catalogue, an equipment register. That is what the Assets section is for — the workspace's own tables, created by the business user rather than a developer.
- A person configures the table. Columns ("fields") come from ready types: text, number, currency, date, checkbox, one or several options from a list, URL, email, phone, image, a link to a record in another table, an assignee (person, agent, or team), and a project. No development, no database migration.
- Data arrives by import. Fill a table from CSV or a clipboard paste, and export it as CSV.
- Views for different jobs. One table shows as a grid, a kanban board, or a gallery — each with its own filters, grouping, and set of columns. Views are saved and switched by tab, so the operations team and a manager can each have their own take on the same data.
- A record is an object, not a row. Every record has a card with its properties, its change history, and whatever Bounc produced from it.
- Agents work the tables alongside people. Select records and ask an agent to go through them, or put an Assetflow on the table: "when a record is added" or "when a field changes", optionally with conditions, and an action of "dispatch an agent" or "start a workflow".
The details are in Assets.
The path of an issue
Take the most common case — an issue goes to an agent.
- The request. An issue is filed by a person, arrives from an external system through an autopilot, or is created by another agent in the course of its work.
- The handoff. An agent becomes the assignee. An
@-mention in a comment, a message in chat, an autopilot firing, a workflow step, and an Assetflow on an Assets table all do the same thing — see Assigning and mentioning. - The queue. Bounc puts an agent task into the workspace's queue.
- Execution. The runtime claims the run, prepares an isolated environment, and does the work, streaming the transcript into the interface live.
- The result. The agent posts its output where people would have: a comment in the thread, an updated status, new related issues.
- Acceptance. A person reads the result and decides what happens next: accept it, ask for more in a comment (which starts another run), or reassign.
The run statuses you see in the interface:
| Status | What is happening |
|---|---|
| Queued | The run is created and waiting for runtime capacity |
| Starting | The runtime has claimed the work and is preparing the environment |
| Working | The agent is doing the work, and the transcript is streaming |
| Completed | The work finished and the result was written back to the issue |
| Failed | The run was stopped by an error or a timeout, with a stated reason |
| Cancelled | A person or the system stopped the run |
An issue in the Backlog is the exception: assigning an agent to it sticks, but no run starts until the issue moves to an active status. That keeps the backlog a place for planning rather than an execution queue.
Three more rules hold for every run:
- Stuck runs clear themselves. One that has not started 5 minutes after being handed to the runtime, and one that has been working for over 1 hour, are marked failed; one never claimed from the queue within 24 hours expires. A failure always carries a reason, and the issue behind it stays on the board as needing another look.
- Context survives between runs. Handing the same issue to the same agent again continues the earlier conversation: Bounc keeps a session identifier on the issue-and-agent pair. You can force a clean start when you want one.
- Every run leaves a trace. The transcript is an ordered log of everything the agent did and said. Usage is the accounting of tokens spent per model, aggregated on the dashboard and broken down by runtime and by agent, so the cost of an automation is measured rather than estimated.
Where the work runs
An administrator deploys the runtime once on the company's servers, and the whole workspace then uses it.
- Every run is isolated. Each agent task executes in its own container with minimal privileges and limits on CPU, memory, and network. The container lives exactly as long as the run.
- Runtime state. A runtime confirms its health regularly and shows as "online" or "offline". While it is offline, new runs wait in the queue rather than getting lost.
- Recovery. If a runtime dies mid-flight, the runs it still held are closed with an explicit reason once it comes back, instead of hanging in an undefined state.
- Throughput. How many runs go at once is capped both at the runtime and in the agent's own settings — the guard against one automation consuming all the capacity.
The mechanics are in Computers and machines; the full run state machine is in Agent tasks.
Roles and access
- A member does the work: files issues, comments, hands work to the agents available to them.
- An admin manages the workspace roster, agent settings, the runtime, and credentials.
- An owner additionally manages owners and the workspace itself. There is always at least one.
Two constraints are worth knowing up front:
- An agent's visibility decides who may assign it. A workspace-level agent is available to every member, a private one only to the agent's owner and the administration.
- Secrets are split by purpose. Workflow credentials are readable by nobody; an individual agent's secret configuration is visible to those entitled to edit that agent. Which is why agents get their own narrowly scoped keys rather than the company's master one.
Use cases
The scenarios below are assembled from the building blocks already described — a table in Assets, an agent with a skill, an autopilot, a workflow, an issue — and need no development.
Banking · A disputed card transaction
Trigger. A cardholder does not recognize a charge and writes in from the mobile app. The complaint arrives by webhook and becomes a record in the "Disputed transactions" table: the masked card, the amount, the merchant, the review stage, the regulatory response deadline.
What the agent does
- pulls the customer's transaction history from the processing system;
- checks it against the familiar fraud patterns;
- fills in the record's fields — amount to refund, dispute category, deadline;
- drafts a verdict with its reasoning: fraudulent charge, merchant error, or a dispute without grounds.
What stays with a person. The claims officer works a kanban by stage, sees which deadlines are burning, and either approves the verdict or sends it back.
Assembled from. A webhook from the front-office system → a record in the "Disputed transactions" table → an Assetflow on "record added" → an agent carrying the dispute-handling policy as a skill → an issue for the officer.
Telecom · A surge of tickets after an outage
Trigger. An external monitoring system hits an autopilot's webhook, and the autopilot starts a workflow.
What the agent does
- compiles the incident summary and files a record in the "Incidents" table with the timeline and a status;
- triages and groups the overnight subscriber tickets before the shift starts;
- once the status moves to "resolved", prepares the post-mortem and the subscriber notice.
What stays with a person. The on-call engineer decides whether to escalate and approves the notice that goes out to subscribers.
Assembled from. An autopilot (webhook) → a workflow: agent task → a condition on the scale → an email to the on-call group → a record in the "Incidents" table → an Assetflow on the status change → a post-mortem issue.
Retail · Product copy and reviews
Trigger. A new item appears in the "Assortment" table — price, category, an image, a link to the supplier's record. A separate autopilot pulls reviews once a week.
What the agent does
- drafts the product copy against a "tone of voice and product-page requirements" skill;
- goes through the reviews and isolates the recurring complaints;
- files issues naming which items are affected and what share of reviews they account for.
What stays with a person. The content manager checks the copy before it goes live; the category manager decides what to do about a problem item.
Assembled from. The "Assortment" table → an Assetflow on "record added" → an agent task; a separate autopilot (schedule) → a reviews agent → issues in the "Assortment quality" project.
HR · Hiring and answering employees
Trigger. An application arrives from an external ATS by webhook and becomes a record in the "Candidates" table: the role, the stage, the recruiter in an assignee field.
What the agent does
- assesses the candidate against the role profile and fills in the record's fields;
- prepares a candidate summary with its reasoning and hands it to the recruiter as an issue;
- in parallel, answers routine employee questions in chat from "internal policies" and "benefits" skills.
What stays with a person. The recruiter decides the stage — interview or keep on file; an HR partner handles the unusual questions that get escalated.
Assembled from. An autopilot (ATS webhook) → a record in the "Candidates" table → an Assetflow on "stage changed" → an issue for the recruiter; a separate agent in chat for employee questions.
Marketing · Preparing a campaign
The clearest case of the lot, because the agent does the preparation rather than the manager.
Trigger. "Prepare the seasonal sale campaign" goes to a marketing agent as an issue.
What the agent does
- builds the segment — filtering the "Customers" table by city, last purchase, category, and mailing consent — and saves it as a view;
- writes the email copy against a "tone of voice and mailing requirements" skill;
- files records in the "Campaigns" table with dates and channels;
- hands it all back as one issue: here is the segment, here is the template, here is the plan.
What stays with a person. The marketing manager reviews the segment and the copy and approves the campaign.
Assembled from. An agent task → the "Customers" and "Campaigns" tables in Assets → an issue for the manager to approve → a workflow: an external call into the mailing platform → an email to the team.
In all five examples the agent does the substantive work — gathering the data, analyzing it, proposing an answer — and a person approves it. That is deliberate: Bounc takes the preparatory work off the table while leaving the decision point with whoever answers for it.
Next
- Quickstart — the first steps in a workspace.
- Agents — how to build an agent around a specific process.
- Autopilots and Workflows — how to make a process recurring.