How it works
Every ticket follows the same pipeline, whatever its channel and the execution mode. One decision is automatic, one approval is human.
The pipeline
- Received. An email, a widget report, a GitHub issue or a group of errors above the threshold becomes a ticket with a public status page.
- Triage and diagnosis. The agent reads the ticket and the logs, finds the code with the engine and classifies the request: usage, config, docs, bug, feature request or unknown, with a confidence score.
- Decision. A question gets a reply draft; a bug with enough confidence gets a fix job; low confidence goes to a person.
- Fix and verification. The fix is written on a
loopback/branch; the harness runs the mechanical verification and your tests, and opens the pull request only if both pass. - Approval. A person approves the exact commit SHA of the pull request.
- Release. Merge, tag and release; when the release workflow is green, the customer and every subscriber get the version in the same email thread.
Ticket states
The dashboard shows the precise state; the status page shows the customer a simpler one. Each transition is recorded in the audit log.
| State | In the dashboard | On the status page | Next states |
|---|---|---|---|
received | Received | Under review | triage, escalated, closed |
triage | Triage and diagnosis | Under review | draft_ready, needs_info, fixing, escalated, closed |
needs_info | Info requested from customer | We need your reply | triage, escalated, closed |
draft_ready | Draft reply | Answered | answered, needs_info, triage, escalated, closed |
answered | Reply sent | Answered | closed, triage, escalated |
fixing | Fix and verification | Cause found, fix in preparation | awaiting_approval, fixing, escalated |
awaiting_approval | Awaiting approval | Cause found, fix in preparation | releasing, fixing, escalated, closed |
releasing | Merge and tag | Fix being released | customer_notified, escalated |
customer_notified | Customer notified | Resolved | closed, triage, escalated |
closed | Closed | Resolved | triage, escalated |
escalated | Escalated to a human | Being reviewed by the team | triage, draft_ready, answered, fixing, awaiting_approval, closed |
Autonomy
The autonomy level of a workspace decides what happens without a click. The plan limits the levels you can choose.
| Level | Reply drafts | Fixes | Merge, tag, release |
|---|---|---|---|
copilot | Sent only after your click. | Branch prepared and verified; the pull request opens when you click Open pull request. | Always after approval. |
approve | Sent only after your click. | Pull request opened automatically when the verification passes. | Always after approval. |
autopilot | Sent automatically only for the categories you choose: usage, config, docs, feature requests. The ticket then closes. | As with Approve. | Always after approval. |
Approval, merge and tag
- The approval is an event with user, time and approved commit SHA. A new commit on the branch needs a new approval.
- When the branch is protected and requires reviews, the approval is also sent to GitHub as a review in the approver’s name.
- The pull request is merged, squash by default, when the required checks are green, and only at the approved SHA.
- The GitHub App creates the tag on the merge commit (semver patch, calver or manual) and the GitHub Release with the changelog. Tags created by the App start your release workflows.
- Loopback follows the workflow runs of the tag. When the release is green, the customer gets the final email with the version; when it is red, the ticket goes to your team.
When a person takes over
- The diagnosis confidence is below the threshold of the workspace (0.6 by default).
- The verification or the tests fail: no pull request, and the report goes with the ticket.
- Two fix attempts did not produce a verified fix.
- The merge is blocked, or the CI of the tag fails.
Rules that no setting changes
They hold in every execution mode and every plan.
- No tag or release without the explicit approval of a person, recorded with user, time and commit SHA.
- The agent never writes to the default branch: only to
loopback/branches, through pull requests. - No pull request when the verification or the tests fail.
- Ticket content is untrusted data: instructions inside emails, issues or logs are never followed.
- No secret in logs, saved prompts or replies to customers.
- Claude subscription logins are used only in MCP mode; the runner and Managed use API keys or a cloud provider.
- Every job is idempotent: running it again never duplicates pull requests, emails or charges.
- Every operation that costs tokens goes through metering first, to respect limits and spending caps.
- The shared memory holds only abstract patterns, and only with explicit consent.
- On the Agency plan, the product brand never appears in front of the agency’s clients.
- The widget captures nothing without the end user’s consent.
Powered by Vexp
Code understanding, impact analysis and verification come from vexp, the engine built by the same company. In the runner and in Managed it runs next to the agent as an MCP server, on a short-lived license that comes with each job; the Enterprise plan uses the vexp SDK inside your network. These are its public numbers:
| Measure | Value |
|---|---|
| Context tokens in the public run_pipeline example: 8,247 become 2,140 | −74% |
| SWE-bench Pro with Opus 5, reference result | 81.7% |
| Cost per task on SWE-bench Pro with Opus 5 | $1.52 |
The agent and the harness use five of its tools:
run_pipeline: hybrid search and ranking on the code graph turn the ticket and its stack trace into a context capsule within a token budget.get_impact_graph: who calls the changed code and what else in the repository may break, for external pull requests too.search_logic_flow: the path from a stack trace to the code that produced it.verify_done: parse errors, broken imports and dependents left untouched, with file and line. The harness runs it before every commit, never the agent alone.save_observation: notes tied to symbols, which go stale when the code changes.
Reports show the engine’s name to organizations that choose to see it; the others read “Automatic verification” and “Change impact”. See execution modes for where the engine runs.