Reusable systems

From repeated work
to durable leverage.

These systems start inside real engagements. When the same problem keeps reappearing, we extract the working structure and make it easier to reuse.

Why these exist

Every engagement should leave something behind: a workflow, interface, validation method, or open-source tool. A reusable module is not a side project; it is proof the operating model was understood well enough to repeat.

Built from real operations Extracted after verification Small enough to adopt Reusable without starting from zero

Open Source

Tools we build in public so teams can inspect, adapt, and own the structure.

A
Open Source · Python

agents-stack

The harness layer for agentic AI. Skills, memory, evaluation, and workflows, shipped as a scaffold and framework for building agent-based projects in the open.

Extracted fromRepeated agent delivery structure
Operating layerAgent workflow contract
ProofPublic scaffold, repository, and implementation examples
github.com/labs21-dev ★ 24
T
Open Source · TypeScript

Terminal / BLMTRM

A hacker-style financial terminal with real-time data, charts, and an AI agent, all in the browser.

Extracted fromDecision-surface and data-flow design
Operating layerData and decision interface
ProofPublic repository and browser implementation
github.com/labs21-dev ★ 107
Product admission

Not every engagement
becomes a product.

A module enters the product queue only when the problem, operating structure, and evidence have repeated. This prevents us from building a beautiful surface nobody needs.

  1. 01
    Real problem. The same business friction appears more than once.
  2. 02
    Named structure. The workflow, ownership, and data boundaries can be described.
  3. 03
    Verified delivery. Someone ran the system through a real cycle.
  4. 04
    Reusable seam. The bespoke context can be removed without losing the value.
Product proof

Public code, reusable structure, honest status.

Each product states what it extracts, which operating layer it touches, and what evidence exists today. Metrics are published only when they can be verified.

How a tool becomes a product
  1. 01 Repeat The same problem shows up again.
  2. 02 Structure The useful path is named.
  3. 03 Publish The code is public and owned.
Module extraction map

From repeated operation
to reusable structure.

Each line shows the operating problem a product came from, the reusable layer it preserves, and the public proof available today.

Operating problem Repeated agent delivery structure
extracted agents-stack · Agent workflow contract Public scaffold, repository, and implementation examples Inspect
Operating problem Decision-surface and data-flow design
extracted Terminal / BLMTRM · Data and decision interface Public repository and browser implementation Inspect
The extraction loop

Engagement to module.

We do not treat products as a separate fantasy. They are hardened from the systems clients actually need to run.

  1. Diagnose a repeated problem. The same workflow or decision keeps costing time.
  2. Deliver it once. Prove the operating model under real constraints.
  3. Remove the bespoke part. Separate the durable structure from one-off context.
  4. Publish or productize. Open-source it, turn it into a tool, or make it a service.