Skip to content

Labor · Open Source

BKS open-bridge: one place from which AI agents work by your rules

BKS open-bridge is a git repository of plain text that an AI agent reads at the start of every session: clients, repos, machines, tasks, rules and what happened yesterday. From there you set everything in motion, and every step passes through your rules. We work with it daily, develop it in the open and publish it under the MIT license.

Visit the websiteDemo in 90 secondsSet up your own BridgeSource code on GitHub

Practical setup 01Built · in our own operations

One bridge from which everything runs

Tasks live in the tracker, access details in notes, scheduled runs on several machines, agreements in mails. An agent that is meant to help sees only what you explain to it right now.

Test bench

Pick a station and give a command.

Ready. Pick a station.

Commands to Tasks

Reading runs at once. Changes get logged. Anything outward or irreversible waits for you. Some things a rule stops.

Commands

0

from one place

Approved by you

0

outward, irreversible

Stopped by rules

0

whoever asks

Log rows

0

every change

Example with invented names, numbers and results. The stations match folders BKS open-bridge sets up. Reading without asking, approval before outward or irreversible actions, and the push guard are part of the public rule set.

How the setup works Pick a station on the arc and give a command. The beam runs through the ring of rules in the middle. Its colour shows what the rules decide, and the main screen keeps a record.
Scope and limitations

Not part of this demo: The stations are examples. Each instance decides which it uses, most of them are optional.

The folders, the approval rule for outward steps and the push guard are part of BKS open-bridge and publicly documented.

Practical setup 02Built · in our own operations

Context that grows from session to session

An AI agent starts every session without memory. Paths, commands, contacts, and open tasks have to be explained again and again.

Test stand

Five work sessions with an AI agent, once without and once with shared context.

Without shared context

  1. Session 1Look into the checkout errorPath to the repositoryDeploy commandOpen task
  2. Session 2Inform the clientClient contactTone of client mailsOpen task
  3. Session 3Roll out the fixPath to the repositoryDeploy commandWho approves
  4. Session 4Write the weekly reportOpen taskClient contactTone of client mails
  5. Session 5Roll out the next fixPath to the repositoryDeploy commandWho approves

With BKS open-bridge

  1. Session 1Look into the checkout errorPath to the repositoryDeploy commandOpen task
  2. Session 2Inform the clientClient contactTone of client mailsOpen task
  3. Session 3Roll out the fixPath to the repositoryDeploy commandWho approves
  4. Session 4Write the weekly reportOpen taskClient contactTone of client mails
  5. Session 5Roll out the next fixPath to the repositoryDeploy commandWho approves

had to askalready knew

What the agent reads

Instance registry

Path to the repository: ~/projects/shop

  1. Log still empty

Questions without context

0

every session starts empty

Questions with BKS open-bridge

0

only what is not written down yet

Written back

0

entries in the log

Simplified example with made-up values. Reading at the start and writing back at the end are part of BKS open-bridge and publicly documented. The build makes no claim about how much time a given team saves.

How the setup works Play five sample sessions, without BKS open-bridge at the top and with it below. Count the questions and watch the log on the right grow, which the next session reads.
Scope and limitations

Not part of this demo: The model is simplified. It shows the principle, not how much time a given team saves.

Reading at the start and writing back at the end are part of BKS open-bridge and publicly documented.

Practical setup 03Built · in our own operations

Tasks that outlast the session

What was discussed in one session is gone in the next. Tasks scatter across chats, notes and trackers, and nobody notices when too much runs at once.

Test bench

Change a task's status. The board is regenerated and the log gains a row.

Task folders

  1. work/tasks/checkout-bug/STATUS.mdPayment bug in checkoutshop
    Payment bug in checkout
  2. work/tasks/portal-login/STATUS.mdCustomer portal loginportal
    Customer portal login
  3. work/tasks/api-v2/STATUS.mdMove the API to version 2shop
    Move the API to version 2
  4. work/tasks/data-export/STATUS.mdData export for accountingportal
    Data export for accounting
  5. work/tasks/weekly-report/STATUS.mdWeekly reportinternal
    Weekly report
  6. work/streams/operations/STATUS.mdOngoing operationsops
    Ongoing operations

    Stream, runs for good and does not count

work/board.md, generated

# Board · WIP 3/3## Doing (2)- checkout-bug · shop- api-v2 · shop## Review (1)- portal-login · portal## Backlog (2)- data-export · portal- weekly-report · internal## Streams (1)- operations · ops## Done (0)

work/log.md

  1. No changes today yet

Active at once

0

doing and review, streams excluded

Limit

3

warns, never blocks

Log rows

0

one per change

Example tasks with invented names. Task folders, the four status values, the generated board, the log and the warning limit are part of BKS open-bridge and publicly documented.

How the setup works Change a task's status. On the right the board is regenerated and the log grows. Move more than three tasks into progress and the limit warns without blocking anything. “Good morning” has the agent read both back.
Scope and limitations

Not part of this demo: The board is a view for the instance. Syncing with GitHub or Azure DevOps is possible but not shown.

Task folders, the four status values, the generated board and the warning limit are part of BKS open-bridge.

Practical setup 04Built · checked in the build

Read only what the work needs right now

The more an agent reads upfront, the less room is left for the actual work, and the easier it picks up the wrong client's files.

Test bench

Pick a request. The bright files are what the agent reads before it answers.

Request to the agent
Reading

Board and log are enough: what ran yesterday, what is due today, what is waiting.

Read by every session

  • AGENTS.mdoperating manual2.1 KB
  • work/board.mdtasks0.8 KB
  • work/log.mdlog of the last days3.6 KB
  • Registry, as a cardone line per client and repo0.6 KB
  • Rule indexname and trigger per rule0.4 KB

Opened only when the work names it

  • workflow/workspaces/north.yamlrepos and agreements, client North1.4 KB
  • workflow/workspaces/south.yamlrepos and agreements, client South1.3 KB
  • skills/e-invoice/SKILL.mdplaybook for booking errors2.2 KB
  • protocols/standing-orders/mail-tone.mdrule for the tone of mails0.9 KB
  • identity/personas/company.yamlsender and signature0.7 KB
  • identity/mandants/team-north.yamlrecipient group0.5 KB
  • infra/remotes/test-server.yamlaccess to the test server0.8 KB

In the session's context

Under the ceiling.

Read

7.5

KB before answering

Ceiling

12.0

KB, declared

Files open

5

of all 12

Simplified example with invented file sizes. The fixed set at session start, opening on demand and the checked ceiling (context-budget.yaml, scripts/measure-context.py) are part of BKS open-bridge.

How the setup works Pick a request. The files the agent reads before answering light up, and the bar shows the amount against the ceiling. Switch to “Everything upfront” and see what happens.
Scope and limitations

Not part of this demo: The file sizes are invented. Which files open on which keyword depends on the instance.

The fixed set, opening on demand and the ceiling (context-budget.yaml, scripts/measure-context.py) are part of BKS open-bridge.

Practical setup 05Built · active once set up

Protecting private working states from the wrong destination

The general framework and private working notes live in the same working directory. Before anything is published, it must be clear where the changes are going and whether private areas are included.

Test stand

Put a push together and send it.

Target
Branch at the target
Changed files in the push

No push yet.

Pushes tried

0

in this stand

Let through

0

framework anywhere, personal only to private

Stopped

0

before the transfer, not after

Modelled on the public rules of BKS open-bridge (rules/push-guard.md, scripts/hooks/pre-push). Names and files are examples. The guard checks location and target, not the content of individual permitted files.

How the setup works Put a push together: target, branch, and changed files. The barrier checks like the BKS open-bridge push guard. Framework files may go anywhere, personal content only to a target confirmed as private, and for an unknown target it stays down.
Scope and limitations

Not part of this demo: The safeguard checks storage location and destination, not the content of individual permitted files. It complements technical access controls but does not replace them.

The safeguard is built, is set up locally, and we use it in our own operations.

Practical setup 06Documented process · followed by the agent

Clarifying the working context before every session

An agent can open a project fresh, on the wrong working state, or with an incomplete configuration. Without orientation, it easily starts in the wrong place.

Test stand

Set the starting situation, the agent checks it before the first reply.

Starting situation

Current branch
user branch exists

(it is the current one)

bridge-config.yaml exists

Detected state

  • New hereNEW USER
  • Wrong branchWRONG BRANCH
  • Orphaned configurationORPHAN STATE
  • Configuration missingBROKEN CONFIG
  • NormalNORMAL
  • User branch without configurationBROKEN USER BRANCH
  • Working on the coreCORE DEV MODE

The agent's first reply

Welcome. Before I answer your question, here are four ways to get started, from a short tour to a private setup.

Checks before the first reply

3

branch, user branch, configuration

States seen

1

of seven

Work state loaded

0

only in the “Normal” state

Modelled on rules/session-start.md in BKS open-bridge. The replies are summarised. The process is documented and followed by the agent, not enforced from outside.

How the setup works Use the switchboard to set which branch the agent starts on and what exists. One of seven lamps lights up, and below it you see how the agent opens the session.
Scope and limitations

Not part of this demo: The process is documented but not enforced by an external session mechanism. Its reliability depends on the agent actually following it.

The startup logic is part of BKS open-bridge and publicly documented.

Practical setup 07Built · designed to work across tools

One knowledge base for several agent tools

Different agent tools look for working instructions in different places. Duplicate copies would quickly drift apart.

Test stand

Change the description and see what the tools read.

  • .claude/skills/Claude Codereads Writes one line to the work log, with time and context.old version
  • .agents/skills/Codex and othersreads Writes one line to the work log, with time and context.old version
  • .github/skills/GitHub Copilotreads Writes one line to the work log, with time and context.old version

skills/protokoll/SKILL.md

Scope in the skill

Where the skill is passed on

  • open-bridge (public)
  • company overlay
  • personal overlay
  • this instance only

Places holding this skill

1

one store or several copies

Tools reading an old version

0

do not see the latest change

Passed on to

3

levels for this scope

Modelled on the skill store of BKS open-bridge (skills/ and the links .claude/skills, .agents/skills, .github/skills). How well a tool reads the store has been tested to different degrees per tool and operating system.

How the setup works Change a skill's description once and see what the three tools read. Switch to copies and they go stale. The scope in the skill decides where it is passed on.
Scope and limitations

Not part of this demo: Compatibility has been tested to different degrees per tool and operating system, and needs to be checked in the specific environment.

The shared store is built and in daily use with Claude Code. Codex and Copilot CLI read the same store, Cursor and Gemini CLI we have not tested ourselves.

What else BKS open-bridge can do

The test benches above show the core. The BKS open-bridge website describes what builds on it. Most parts are optional and set up only when you need them.

  • Demo in 90 seconds

    A morning with the agent: session start, daily overview, an incident with log analysis and a test-driven fix, first-time setup.

    Watch the demo

  • Workspaces

    A client's repos as a named workspace. Commits are pinned, drift is visible at a glance.

    Workspaces

  • Scheduled runs

    Every report, poller and service is a file. The service file for the machine is rendered from it and regularly reconciled with the machine.

    Workloads

  • Outward agents

    An agent answers questions over A2A from public content and takes requests, always with a human in between.

    Bridge-Agents

  • Try it yourself

    Our public agent runs on this foundation. You can ask it questions right here in the Labor.

    To the public agent

  • Company overlay

    An instance subscribes to a company's shared configuration without forking it. With ours, a new colleague has a bridge on day one that knows our clients, boards and routines. Your own changes take precedence.

    Use cases

  • Meeting to tasks

    A meeting transcript becomes minutes and proposed tasks. What you confirm is taken over.

    Use cases

  • Two examples to try

    An agency with two clients and an open incident, and one person with several roles: consultancy, freelance work, household, a home server. Both run without any setup.

    Examples on GitHub

  • Everything on one map

    As of September 2026, BKS open-bridge ships 943 files, 27 are yours. The map shows how the parts connect.

    Open the map
Open source and publicly verifiable
BKS open-bridge is publicly documented, and we run BKS-Lab on it ourselves. A single instance has collected 4,072 work-log rows and 164 closed tasks since 4 July 2026. The safeguards support responsible working practices, but they replace neither a content review nor technical access controls.

Back to the Labor overview →

What rules does an agent need before its first working step?

We organize project knowledge, responsibilities, and safeguards so an agent starts with solid context and knows its limits.

Schedule a conversation