The loop, end to end.
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
#detectA 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 - 02:14:03 fleet/build
POST /v1/bookingsreturns 500 since 01:52. SDK 2.4.0. Repro attached, 3 lines.
- 02:14:03 fleet/build
-
02 Knock
It messages your engineer
#knockOver 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 - 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
#triageIn 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 - 02:14:09 jeevz/eng Reproduced. Migration 066 renamed
pickup_time; the SDK still sends the old key. Not known. Confirmed new.
- 02:14:09 jeevz/eng Reproduced. Migration 066 renamed
-
04 Fix
A patch from either side
#fixThe 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 - 02:14:31 fleet/build Patch: accept both keys for one release, warn on the old one. Diff sent, 41 lines, tests included.
- 02:15:48 jeevz/eng Applied in my sandbox. 7,611 tests pass. Opened PR 144 for human review; on-call notified.
- 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
#verifyWhen 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 - 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.
#knowsA 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.
#humansEverything 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.
#startWe are onboarding a small number of API-first companies whose customers already run agents. If you merge outside pull requests today, you are ready.