Blog / Agent Infrastructure

How to Build a Software Factory on GitHub Actions

A clay orca swims along a glowing current past three stone markers pressed with a dot, a ring and an arrow, on deep navy water.

Luciana LaraSoftware Engineer

As agent harnesses evolve, the idea emerges that useful software factories do not require custom harness alterations, complicated memory management, or a thousand-file repository. In fact, the most effective workflows are often the simplest, boiling down the development cycle to:

Issue -> coding harness -> PR

This article demonstrates how we made a software factory run on GitHub Actions via issue-triggered invocations.

Key takeaways:

  • GitHub issues can act as the task interface.[1]
  • GitHub Apps serve as a secure way to mint short-lived agent access tokens.[2][3]
  • While GitHub is one destination for your factory, similar principles can apply across clouds.
  • II Agent Runtime enforces your runtime configuration and will eventually abstract cross-cloud configurations.

What is a software factory?

A Software Factory is a system that automatically accepts software tasks, runs a coding harness against a repository, and returns reviewable code changes.

What does the software factory do?

The software factory contains the configuration for your Codex agent to run on GitHub Actions. It also supplies you with the GitHub App manifest required for secure model-to-GitHub API key provisioning.[2][3]

  1. Issue
  2. Coding harness
  3. PR

How does an issue become an agent run?

The Software Factory listens for GitHub issue events in the hub repository. Opening or approving an Agent task starts a GitHub Actions workflow.[1]

  1. Request

    1. Issue
    2. Workflow

  2. Checks

    1. Authorize
    2. Admit

  3. Run

    1. Prepare
    2. Isolate
    3. Execute

  4. Deliver

    1. Verify
    2. Pull request
A GitHub issue in the hub naming a repository, a base branch and a task, followed by two replies from GitHub Actions: one saying an agent is starting, one linking the pull request it opened.
The task as filed in the hub, and the two replies: the agent started, then the pull request it opened.
The GitHub Actions run summary: triggered via issue, status Success, total duration 2 minutes 16 seconds.
The workflow run that issue started.
The agent job on GitHub Actions, succeeded in 2 minutes 12 seconds, with its steps: set up job, read immutable runtime source, pull private worker image, use Node.js, use OpenTofu, build trusted runtime, verify reserve and execute, retain bounded run evidence.
The steps of that job. The agent itself runs inside "Verify, reserve and execute".
A pull request opened by the Agent Factory bot into main from a task branch, with one commit and no conflicts with the base branch.
The pull request the run delivered, ready for review.

What does II Agent Runtime provide?

The software factory imports ii-agent-runtime and uses its built-in methods for deployment, run evidence, and credential isolation.

Try the example

intelligent-iterations / ii-agent-runtimeSecure. Deploy. Measure. Open infrastructure for agent harnesses. View on GitHub

This example includes:

  • the hub onboarding flow
  • GitHub App setup
  • runtime policy
  • GitHub Actions workflow
  • authorization checks
  • budget controls
  • PR delivery path

FAQ

Who is allowed to invoke an agent?

The issue author must have at least write permission on the target repository.[4]

How does the agent turn its work into a PR request?

Codex pushes its changes to a dedicated branch, then II Agent Runtime confirms that the branch contains commits ahead of the intended base before opening the pull request with a separate scoped credential.

Can this work outside of GitHub?

This example is GitHub-specific, but II Agent Runtime provides an abstraction over providers and will support alternative clouds while maintaining the same model.

Sources