Gemba
Give your agent team a factory floor
Gemba is the agent-runtime platform. A command family runs the loop in your terminal, and a set of CI actions runs the same loop on every push.
Every team builds the same runtime again.
A team that wants to run coding agents continuously starts by writing a bootstrap script and a session harness. After that it needs a place for traces, a place for memory, and a way to tell real improvement from noise.
Gemba packages that work as one platform. In Lean practice, gemba is the factory floor, the place where the work happens and where you go to understand it. This platform is that place for your agent team.
The loop has six steps, and every run leaves a record.
The loop goes from stand up to run, see, remember, measure, and stop. Each step answers one question. Five of the steps ship as commands, and the first ships as the bootstrap action and its installer.
Two of the steps come from factory practice. See is genchi genbutsu: you go to the place where the work happened and look at the real thing, which for an agent session is the trace. Measure asks the question Shewhart and Deming asked on the factory floor: whether the process shifted or only varied as usual. An XmR chart separates the two.
Is the environment ready and the toolchain pinned?
gemba-bootstrapWhat did the agent do on this task?
gemba-harnessWhat does the trace say about the session?
gemba-traceWhat did the team learn, and where does it live?
gemba-wikiDid the metric move, or is this noise?
gemba-xmrIs the team creating work faster than a human can read it?
gemba-watchdogWhat you run in a terminal also runs on every push.
Gemba ships the loop in two forms. The commands run in a terminal, and five published composite actions run the same steps in GitHub Actions. A workflow pins each action to a commit SHA.
Install the six commands, or run any one of them through
npx. You run a session, read a trace, write
memory, and draw a control chart in the terminal you already
use. None of it needs a server or a database.
gemba-bootstrap sets up the platform
environment. gemba-harness runs the session and
uploads the trace. gemba-wiki writes memory
with a token it mints for the run.
gemba-benchmark splits benchmark families
across machines and merges the reports.
gemba-watchdog counts repository activity and
sets an operator latch when a counter breaches its
threshold.
Gemba has no importable API of its own. It uses published
runtime libraries. When you need the components instead of the
commands, import @forwardimpact/libharness,
@forwardimpact/libwiki,
@forwardimpact/libxmr, and
@forwardimpact/libwatchdog directly. The
library catalog
lists them.
Kata runs on this platform every day.
Kata is an agent team that plans specs, ships features, studies its traces, and acts on what it finds. Its skills call five of the six commands, and its workflows pin four of the five actions in the same way any other team would. Kata shows that the platform is not tied to one team. Read about the practice at kata.team.
Some parts still refer to that tenant. For example,
gemba-wiki creates a metrics directory only for a
skill whose name starts with kata-, and the
gemba-xmr route registry holds the paths of the
tenant's kata-implement skill.
Capture your first trace in three lines.
Install the skill pack and the command family, then run one session.
The gemba-bootstrap action does the same setup in
CI. Its fit-install.sh installer does it on a
workstation, and that installer ships in the shared
gear release. Follow the full path in
Get started, then read the
documentation.