We needed the bot fleet and a coding agent to hand work to each other without giving an agent a database credential. The operations repository was already the fleet's durable record, so we made it the handoff surface too. A task is a Markdown file in a shared repository, not a direct call into the admin database.
The handoff file
The handoff is a small Markdown work order. A repository-side worker picks it up, routes it to the named worker, archives the finished task, and records the result in the run log.
The first bridge test described itself as "First task through the tasks inbox. Pushed from Claude Code." It assigned the work to a named worker, and its done condition was a line in the run log saying "tasks bridge live, received from Claude Code." The log records that line at 2026-09-05 13:28 CT.
Why the database stays out of it
The ingest design makes the boundary explicit. Agents write Markdown files and commit them. The admin application reads the repository and derives database rows from those files. Agents never hold a database credential, and replaying the repository can rebuild the projections if the database is lost.
The application also gives a human a guarded way to send a new task back to the fleet through the repository. Read and write credentials are separated and scoped independently, so widening one cannot widen the other. A name collision fails instead of replacing an existing task.
What the bridge does not grant
A repository handoff cannot override operating policy or a worker description. Work that needs human approval stays drafted and held.
The records prove the Claude Code to fleet direction end to end. They do not record a worker handing a task back to Claude Code, so that reverse direction is not claimed here. The evidence is the inbox rules, the bridge test, the run log entry, and the ingest and outbound-write implementation.