The easiest mistake when open-sourcing an internal AI workflow is to copy the scripts, prompts, labels, and directory structure from the private production repository.

That feels fast. It is usually the wrong kind of open source.

A private production workflow mixes two things: reusable methodology and local context that belongs only to one organization, product, or infrastructure. Open source should extract the former without leaking the latter.

Open-source the contract before the daemon

The first version of an issue-driven agent workbench should not start with a production daemon.

A better first version contains:

  • issue templates;
  • label state machine;
  • branch claim rules;
  • worker prompt skeletons;
  • evidence manifest;
  • PR checklist;
  • release boundary documentation;
  • toy examples.

That is enough for another team to rehearse the method manually.

If the first release is a daemon, users must immediately understand your scheduling assumptions, permission model, GitHub access model, concurrency strategy, failure recovery, deployment environment, and local workspace structure.

That is too much. It also risks turning one private implementation into a fake universal standard.

Replace private material with synthetic examples

The public repository should not contain:

  • private issue bodies;
  • internal screenshots or logs;
  • real user data;
  • service topology;
  • production environment names;
  • business-specific risk rules;
  • organization-specific labels;
  • release scripts or access assumptions.

Even if these details do not look sensitive, they reveal how a team operates production systems.

The safer pattern is to use synthetic examples.

Do not use real payment, trading, permissions, customer, or incident workflows as examples. Use a toy case such as “the greeting does not refresh after a profile name update” to demonstrate the issue contract, branch claim, and evidence gate.

The purpose of the example is not business realism. It is structural proof.

The open-source repository is an output node

If you have a central knowledge base, private production repositories, a personal site, and open-source repositories, the data flow should be explicit.

The central knowledge base forms concepts and publication sources.

The private production repository provides experience, but it is not exposed directly.

The personal site explains and distributes the public argument.

The open-source repository carries public-safe templates, specs, and examples.

In other words, the open-source repository is not the source of truth for the private workflow. It is also not a replacement for the central knowledge base. It is a public output node.

This boundary prevents two problems: the open-source repository does not get polluted by private production context, and the central knowledge base does not become constrained by public template decisions.

When to add a runner

A runner should come after the contract, state machine, and evidence gate have been used manually.

The first runner should be conservative:

  • dry-run by default;
  • manual trigger first;
  • no automatic release;
  • no automatic issue closure;
  • replaceable adapters;
  • all state written back to GitHub;
  • all risk escalated to humans.

At that point, the runner amplifies a stable process instead of automating confusion.

A good open-source target

A sustainable Issue-Driven Agent Workbench should not promise that AI will automatically fix every issue.

It should promise something more modest and more valuable:

  • turn issues into executable contracts;
  • give AI workers clear boundaries;
  • keep task state auditable;
  • make PR evidence reviewable;
  • preserve the release boundary;
  • extract private production lessons into public methodology safely.

The value of this kind of open-source project is not showing how aggressive automation can be.

The value is giving AI coding a control plane that humans can trust.