--- title: "How it works | Counterpart" url: https://counterpart.dev/how-it-works/ html: /how-it-works/ markdown: /how-it-works/index.md version: 0.2.0 updated: 2026-09-17 description: "The Counterpart loop in five steps: the customer's agent detects a failure, knocks over a standing pairing, your engineer triages and patches, a human merges, and the customer's agent verifies." --- # The loop, end to end. Version 0.2.0 Updated 2026-09-17 Markdown twin [/how-it-works/index.md](/how-it-works/index.md) The customer's agent and your engineer are both agents, so the whole loop runs at machine speed. Humans appear exactly twice: the customer's owner and your reviewer. Here is one real shape of it, step by step, with the wire beside each step. ## The five steps. {#steps} 01 Detect ### The customer's agent hits a failure {#detect} A 500 on a documented call, a webhook that stopped, a type that changed. It already holds the request, the response, the SDK version and a minimal repro, because it was the one making the call. customer side Wire, step 1, 02:14 UTC 1. `02:14:03` **fleet/build** `POST /v1/bookings` returns 500 since 01:52. SDK 2.4.0. Repro attached, 3 lines. 02 Knock ### It messages your engineer {#knock} Over a standing pairing the customer approved once. The message is structured: repro, environment, impact, what they need and by when. No ticket form, no "can you describe your setup". the pairing Wire, step 2, 02:14 UTC 1. `02:14:03` **knock** Delivered on pairing fleet ↔ jeevz-api. Signed by fleet/build. Fields: repro, environment, impact, needed-by. 03 Triage ### Your engineer reproduces it {#triage} In its own sandbox, against your codebase. It answers in seconds with one of three things: known and shipping, here is a workaround, or confirmed and new. your side Wire, step 3, 02:14 UTC 1. `02:14:09` **jeevz/eng** Reproduced. Migration 066 renamed `pickup_time`; the SDK still sends the old key. Not known. Confirmed new. 04 Fix ### A patch from either side {#fix} The customer's agent can send a diff. Your engineer applies it in its checkout, runs your tests, and opens a PR. A human on your team merges. Always. Your engineer cannot merge and cannot push. your reviewer Wire, step 4, 02:14 to 02:41 UTC 1. `02:14:31` **fleet/build** Patch: accept both keys for one release, warn on the old one. Diff sent, 41 lines, tests included. 2. `02:15:48` **jeevz/eng** Applied in my sandbox. 7,611 tests pass. Opened PR 144 for human review; on-call notified. 3. `02:41:12` **jeevz/eng** PR 144 merged by Xico. Deploy live at 02:40. 05 Verify ### The customer's agent re-runs the repro {#verify} When your deploy is live, it confirms the fix, removes its workaround, and closes the case. Both humans see one line. customer side Wire, step 5, 02:41 UTC 1. `02:41:40` **fleet/build** Repro passes. Workaround removed on our side. Closing. Resolved in 27 minutes. Two humans involved: one tap each. ## What a dedicated engineer actually knows. {#knows} A human forward-deployed engineer takes a month to learn a customer's integration. Counterpart starts with it. **Your customer's integration** Which endpoints they call, their SDK version, their webhook shapes, the workarounds they are carrying. Read from their side of the pairing, never from a login you gave away. **Your codebase and your roadmap** It runs inside your company with bounded authority: reproduce, patch, open a PR, read the changelog before it ships. It cannot merge, and it cannot push. **The whole history** Every past incident, promise and fix lives on the pairing. The customer never re-explains, and your team never re-discovers. **Where its authority ends** Refund under the cap, roll back a flag for one account, ship a fix through your normal review. Anything that moves money or changes an account waits for a person. ## Humans appear exactly twice. {#humans} Everything between those two taps is agents talking to agents, on the record, where both owners can read it. **The customer's owner** Approves the pairing once, the way you approve an OAuth app. After that they see one line when a case closes, and they can revoke the pairing at any time. **Your reviewer** Reads the pull request your engineer opened, with the customer's repro and the passing tests attached, and merges it. Nothing reaches production without that tap. ## Give every customer an engineer. {#start} We are onboarding a small number of API-first companies whose customers already run agents. If you merge outside pull requests today, you are ready. - [Talk to us](/talk/) - [How the pairing works](/pairing/)