Where the business meets engineering
The expensive part of software was never the build. It was the distance between the person who needed something and the person who could make it. Here is how a request crosses it now.
Ask an engineering lead where the week went and the answer is rarely "writing code." It went to the meeting where a request got explained a second time, the ticket that sat because nobody knew what done meant, the estimate argued over and then quietly wrong, the Slack thread asking whether it shipped. The build was a few hours. Everything around it was days.
That gap, between the person who needs something and the person who can make it, is what sleds is for. We think of it as a seam, and every feature we have shipped sits on one side of it or the other, or carries something across.
A request starts as a sentence
Samantha runs product at a company that sells to enterprises. A customer's admins cannot sign in from a new tenant, the renewal call is on the 24th, and she has a spec and a prototype. A year ago that became a ticket with a title, two attachments and a hope.
Now she says it to Claude, in the same tab she was already using, and the sleds connector does the work a good engineering manager used to do by hand. It reads the product map and says what the request touches (auth/sso and api › sessions). It notices the spec answers the why and the deadline, so it asks only what is still open: what does done look like, in your words? Her answer, "an Acme admin signs in once and lands on the dashboard," becomes the acceptance line on the row.
What the org wants the seats to say at that moment is written by the org, in AI Guidance: the voice, the questions that always get asked, the ones that never do. Support teams tune it toward bugs. Product teams tune it toward worth. The filer never learns a verb.
It is sized before anyone commits
The row is sized from the team's own history, as a band, never a point: M · $4–11 · 20–55 min · 81%. The band is what the business sees before saying yes. It is also what engineering is held to afterwards, which is the part most tools skip.
When the work lands, the actual is written against the band: 31 min · $5.20 · in band. Over weeks the bands tighten, because every actual teaches the next estimate. Calibration is a number the board shows per area, and we will publish ours once there is a quarter of it to stand behind, rather than a good month.
It goes to the seat that fits
A seat is a place work can run: an engineer's Claude Code, a Codex or Cursor session, a coworker's sled with headroom this week, a managed agent in the cloud. Routing picks the one that fits the request, its size, who owns that part of the product, and what the seat has left on its bar this week. Jake gets it in his terminal with the brief, the band, and the fit already there. Sonnet at a fifth of the cost; Fable fits too.
Nothing starts without a yes if the sled is set to approve. With auto on, armed items start as they become ready and the engine on Jake's Mac runs them.
It comes back with a receipt
The pull request carries the SLEDS-* lines: source, estimate, seat, actual, a signature. The GitHub App reads them on merge, writes the actual to the row, and the row tells Samantha, in the thread where she asked. She never opened a tracker. Jake never wrote a status update.
What changed
Every step above existed before. People did them, slowly, with meetings. The difference is that the request now carries its own context, its own size, and its own receipt from the first sentence to the merge, and the handoffs happen because the record moved, not because someone remembered to.
That is the whole product: the seam, and the things that cross it.