Skip to content
CollectDev
Talk to us
The Bridge case study

The Bridge

Technical notes · CollectDev tooling

How the Bridge is built: gates, the autonomy ladder and nightly calibration

The case study says what the Bridge does for a business. This page says how it is built: what runs without anyone watching, the lanes and what each cannot do, the send gate and where it lives, the privacy boundary, the autonomy ladder with its thresholds, token spend as a signal, the feedback loops, the nightly calibration, and the incidents that produced each rule.

What this page is
The engineering notes behind the case study: the gates, the lanes, the privacy rules, the ladder thresholds and the incidents, written for the person who would build or audit it
Rob's role
Designed, built, and runs it daily. CollectDev's own tooling.
Shape
One hub and one database per client, a phone-first console, a daemon per route, and twelve agent lanes

The Bridge is CollectDev's own tooling, used on client engagements. The clients are not named here, and the system is built so that they cannot be: its repository names no client and its build fails if one appears. This page describes what the software does, not whose work it did. For what it means for an operating business, read the case study or the AI and workflow automation service.

01

What runs without anyone watching

Most of the system's work happens with no click anywhere.

  • The hub reads the inbox itself. Every DM and mention is filed into a conversation, a new line joins the open exchange with that person rather than starting a sibling, and a lane is woken. A message the person has already answered by the time it is read is filed for the record and wakes nobody.
  • The inbox lane rules on each message, reply or no reply, and drafts either way. When the answer has to be looked up first, it runs the research itself and redrafts from what it found, marking the draft as research-based so everything downstream knows what it stands on.
  • A pull request link in a DM that reads like a review request has the person added as a reviewer on GitHub and the review started, automatically. The reviewer runs, an independent verifier checks the verdict, a refused verdict is redispatched once, and the result is staged with a line saying what the check found. A merged or closed PR gets a line saying there is nothing to review.
  • The coder works in its own worktree per task, commits, and its commits are pushed to the person's own branches as it goes. On the person's open pull requests, a poller turns every review comment, red check and dirty branch into a turn; the coder pushes fixes, replies on the PR, resolves the threads it answered, and re-requests the reviewers who asked for changes.
  • Multi-step errands advance on their own. Ask a third party, wait, relay back: the chain moves when they reply, with no timer and no nag.
  • The coach reads the whole day every night, grades the drafter against what the person actually did, rewrites the client pack's knowledge of people and precedents, files lessons into lanes, and names structural fixes. Those fixes are filed as tasks without anyone asking and closed without anyone asking when a commit on main names them.
  • Trust is demoted automatically. A draft to someone discarded as wrong, or sent over a block, takes that counterpart's grant to watch on its own.

What is left for a person is short: Send on a draft to a colleague, Post on a review, Open PR, Merge, and Create on a ticket. Each is one click, and the click is the whole act; the system has already done everything up to it.

02

The lanes

Twelve lanes, each with one job, one kind of output, and one thing it cannot do. The ones that carry most of the day:

  • Front door

    Carries the client's org memory and classifies every ask into a lane. It cannot send.

  • Inbox

    Rules on every DM and mention and drafts the reply the person would send, with its reasoning on labelled lines above the draft. It has no tool that writes to Slack.

  • PR reviewer

    Reads a pull request and writes the review, lede first. It is print-only: every write verb of both Git hosts is denied to it.

  • Verifier

    Takes another lane's claim or verdict and confirms or refuses it independently. It cannot amend what it checks, only pass or fail it.

  • Coder

    Takes a task to a branch in its own worktree and answers the review on it. It cannot open the pull request; it writes a PR block that the person's click turns into one.

  • Coach

    Reads the day and writes what worked and what misfired into memory. No push, no merge, no send.

  • Digest

    Sweeps the team's channels and reports what moved, grouped by theme, with personal matters left out. It is the one lane whose output needs no approval, because the person is the only reader.

The rest (approval gate, QA triage, support triage, standup, team status) follow the same shape: a constitution, an allow list, and a hard limit on what they can touch.

03

The seam, and where it lives

A gate in the interface is a suggestion. A gate in the database is a rule.

  • The outbox is the single outbound edge, and a database trigger refuses any outbound row whose body differs from the approved draft. The console cannot deliver something other than what the person saw.
  • A sent draft is immutable. A superseded version is frozen and can be neither revived nor sent. The audit log rejects updates and deletes, including from the database owner. Continuous integration re-proves the triggers on every pull request.
  • The agents have no path to Slack. The lanes' Slack write tool was removed on purpose, and the token the inbox reads with has no write scope. On Send, the hub posts the reply as the person, with the person's own token, into the thread the ask came from.
  • A posted review lands unpublished, as a pending review on GitHub or a draft note on GitLab, and is submitted by id from the console so the body cannot be lost. Publishing is the person's.
  • Merge is a click that re-reads the pull request at that moment and merges only if it is approved, green, conflict-free and, unless the person waives it, has no unresolved threads. Otherwise the thread says exactly what still blocks it.
  • One hub and one database per client. No process and no identity in the project can see two clients' data. The repository names no client, and a build fails if one appears.

04

The privacy boundary

The rule the agents work under matters more than being helpful: information flows inward to a narrower audience and never outward to a wider one. One test decides every case. Can every recipient of this reply already see the source? If not, the reply is a leak.

  • A public channel, wiki or repository can be cited anywhere. A private channel can be cited only inside itself. A DM can be cited only in that DM.
  • Every line the agents retrieve from Slack is marked by the data, not by the model's memory, as safe to quote or restricted to know. Restricted lines inform the answer and never appear in it.
  • A person being in two DMs does not make one usable in the other. Operational facts that finish a shared task cross; opinions, complaints and anything said in confidence do not, even when the person asks for the relay.
  • The nightly distillation treats DMs as sealed: a role or an ownership may be recorded, never a quote or a third party's words. Personal matters are left out of every file.

05

The autonomy ladder

Trust is earned, measured and scoped. It is never assumed and never granted globally.

  1. Prechecks

    A deterministic pass runs on every draft version and looks for the ways a draft goes wrong: scaffolding left in, something shaped like a secret, an @-mention of someone not in the thread, a greeting that does not match the recipient's clock, a span lifted from another conversation, a colleague's message that landed after the draft was written. Its verdict is recorded. A pass changes nothing; a block makes Send a two-step. What the person then does is the label.

  2. Labels

    Sent unchanged. Edited and sent, with the edit classified: a touch, a greeting, a sign-off, shortened, lengthened, reworded, rewritten. Regenerated with a note. Answered in Slack by the person themselves, in which case the unused draft is scored against what they actually wrote. Discarded, as erroneous or as wrong. Sent despite a block. A draft nobody used is a verdict on it too.

  3. Trust, per counterpart

    A grant is offered for a person or a channel, never a lane, and only once the record clears the bar: a thirty-day window, at least eight outcomes, nine in ten sent unchanged, and the last five in a row unchanged. Research-based replies have their own bar. A wrong discard or a send over a block drops the grant to watch on its own, and it resumes only when that outcome ages out of the window.

  4. Autosend

    Scoped autosend, and delayed send with a Hold button, are built with every guard in place: Slack only, prechecks passed, never a first message to someone, never a “no reply” card, never while trust is at watch. They sit behind a deploy-time flag that has not been flipped while the drafter is in training. The agents are still earning it, and the ladder page is how Rob will know when they have: a shadow column shows what the hit rate would have been if every pass had gone out untouched.

Promotion is on numbers, never on vibes.

06

Token spend as a signal, not a bill

Every lane run ships its token usage by type and its cost by model into the hub over OpenTelemetry, stamped with the lane that incurred it. The costs page shows spend by day, by lane and by model, the conversations and single runs that cost the most, and the share of everything read that was the agent re-reading its own context. A share over ninety percent is flagged.

That number has already changed the design. One coach run read its inputs itself over forty-nine turns at a hundred and fifty thousand tokens each, 7.4 million in a night. The fix was to gather first: the daemon now assembles the day's labels and material into the brief so the lane starts with them read, a turn cap bounds the run, and a finish instruction makes a capped run write its report from what it has rather than leaving nothing. The calibration trend shows the coach's daily cost beside the quality line, so "is the nightly calibration earning its cost" is a question with a number.

Sessions are restarted on purpose, because a long one re-sends its whole history on every turn. Nothing that matters may live only in a session's head; the open items, the interrupted work and every run's transcript live in the hub. And every wake names the runtime that is paying for it, so a session answering on the wrong one is told to say so and stop.

07

Feedback loops at five timescales

  • Seconds, per draft

    The card has one text box and two verbs. Send delivers exactly what is on screen. Regenerate treats the box as feedback: the note is recorded against that version and the next draft arrives with it attached. Six one-tap chips cover most of what a person wants to say: shorter, warmer, more direct, ask a clarifying question, add the link, match their register.

  • Fifteen seconds, per pull request

    A poller diffs GitHub every fifteen seconds. Any review, comment, red check or dirty branch becomes a feedback ask. The coder gets one turn per batch and answers either addressed, with a push and replies, or cannot, which raises it to the person and pushes nothing.

  • Each review, independently

    The verifier checks a review before it is staged: does it restate an existing comment as its own, does it leave an open one out. Every verifier verdict is a row the coach reads weekly. Two refusals of the same shape become one filed lesson for the reviewer.

  • Nightly, into memory

    The day's labels, and the day's material (every DM, mention, review thread, coding task and digest, with the person's own replies marked), are written to files the coach grades. Until that hop existed, the ladder's numbers were shown to the person and read by no agent.

  • Weeks, into the system

    When the coach names a fix to build, the daemon files it once as a task the person can turn into a coding session with one click, and closes it when a commit on main names the label. The rule in the coach's constitution: after three recurrences of the same mechanism, name a gate, a lane or a permission change, not a fourth written rule.

08

Daily calibration

The whole system is built around one ritual. Every day gets a report card that writes what worked and what misfired into the memory the agents load next session. The coach's constitution puts it plainly: never skip. If a day was quiet, write that it was quiet, with the counts.

A watcher polls, so a sleeping machine catches up rather than missing the hour, and fires once a day on the person's clock so the report is waiting when they sit down. It dispatches the coach with the day's labels and material already in the brief. At most three attempts a day. A day with no report is a red heartbeat on the status page, never a quiet failure.

The coach writes numbers, not adjectives. "Nineteen of nineteen, run without the GCP extra, in CI" is an entry; "tests passed" is not. Every claim carries the environment it was checked in. Every edit and every regenerate note is a finding with the mechanism named from the diff. Repetition is the signal: once is noise, twice is a missing rule. What it learns is promoted into the client pack the agents load next time:

  • Who owns what and how they like to be answered, cited and dated
  • Decisions with the reason given, superseded rather than accumulated
  • Questions reviewers tend to ask, so a pull request can pre-empt them
  • Lessons per lane, filed into the hub where that lane reads them
  • Work in flight, one line each, where the agents' recall finds it
  • Skill candidates: manual work done twice in a day is named as a capability to build

Events decay; decisions do not. The coach cannot act. No push, no merge, no send. It reads the day and writes markdown, and acting on a lesson is another lane's job.

Calibration is measured like everything else. The trend tracks drafts sent, sent as written, edited and discarded as wrong, whether a report was written, and what the coach cost. The line to watch is the rolling seven-day sent-as-written rate. Up five points or more and the calibration is moving the drafts the person's way; flat or down and the lessons are not landing, or the work changed under them. A report card nobody can connect to that line is a log.

09

Built from incidents

Every rule in the system is dated to the failure that produced it. A few:

  • One evening a single session made the same mistake four times: it formed a claim from partial evidence and stated it as fact. Nothing wrote the lesson down after the first. That evening produced the coach.
  • A draft went out saying “it is Saturday” on a Sunday, because the session had no clock and invented one. Every wake now carries the time, the weekday spelled out, and the recipient's local time.
  • GitHub's own review dialog opens empty for a review created through the API, and three reviews were blanked submitting them there. The console now submits a pending review by id, body intact, and refuses when none is pending.
  • Seven messages in seventeen days were mangled by a backtick in a shell argument, each session sure it was the first. The lanes now speak through typed tools with no shell in the path.
  • A coach run spent 7.4 million tokens reading its own inputs. Gather first, cap the turns, force the report.

10

What it is built with

  • TypeScript, strict, for the hub, the console, the daemon and the shared contract, with schemas at every boundary; shell for the route's watchers
  • Fastify hub with a WebSocket for live updates; Next.js console, installable on a phone with Web Push
  • Postgres on Cloud SQL through Prisma, one database and role per client, with the send gate and the append-only audit log enforced by triggers
  • Cloud Run behind a global load balancer and identity-aware proxy, Terraform for the footprint, GitHub Actions deploying through workload identity
  • Agent lanes as Claude Code sessions with constitutions and allow lists, per-run token and cost metrics over OpenTelemetry, errors to Sentry
  • Slack and GitHub or GitLab, read by the agents, written to a colleague only on a person's click

The agents read, decide, research, draft, review, code, push and grade themselves every night. A person does one thing: approves what leaves under their name. The system keeps score so that line can move.

Tell us what is taking too much time.

Describe the work in a short conversation. You get an honest read on whether software, an integration, or AI belongs, and a sketch of how we would attack it. Rob reads the brief before the call.