August 5, 2026 · Temple Compute

We put our workflow engine in charge of our codebase

A few weeks ago we asked ourselves a question that usually ends badly: what happens if we let our own workflow engine write our own code?

So we built tc-agent-loop: an autonomous issue-to-PR agent that lives on our servers and does exactly that. You open an issue in tc-os, comment /missues, and the loop claims it, plans a fix, implements it, validates it, and opens a pull request, then keeps working the PR until it's merged.

The part we're proudest of: the agent is not a bespoke script. It's a horus-runtime workflow. The same engine that orchestrates molecular dynamics simulations and bioinformatics pipelines across HPC and cloud is orchestrating coding agents.

The loop

GitHub issue + /missues
        │
        ▼
tc-agent-loop daemon (asyncio)
  ├─ plan     → headless opencode, writes plan.json
  ├─ resolve  → horus workflow: one implement task per plan step
  │              · each task = a headless opencode sub-agent
  │              · apply task captures the diff
  │              · validate task runs lint + type-check
  ├─ PR       → "Closes #N"
  └─ follow-up→ review comments become fix prompts, new implement round

One issue at a time, SQLite state, bounded retries, and guardrails: it never pushes to main, never auto-merges, and ignores its own comments.

The workflow inside the agent

When an issue is claimed, the loop builds a horus workflow that mirrors the plan. For a three-step plan it looks like this:

The tc-agent-loop resolver as a horus workflow The issue resolver workflow: one implement task per plan step, then apply and validate.

Each implement_N task runs a headless opencode run in a shared git worktree, so the steps chain safely. apply captures the accumulated diff, and validate runs the repo's own lint and type-check commands before anything is pushed. If validation fails, the loop retries the implementation, up to a bounded number of attempts, before giving up and asking a human.

Why this matters

Dogfooding with teeth. tc-os already runs horus workflows for scientific pipelines; now it runs them for software engineering too. Same DAG semantics, same artifact model, same failure policies.
Agents as tasks. A coding agent is just another task implementation: a Python function that happens to spawn an LLM. Everything horus already gives you (chaining, retries, validation, artifact capture) applies to it for free.
Composable. Want review feedback to trigger a re-implementation? Add an edge. Want to gate the PR on a test job? Add a task. The agent is a graph, so it grows like one.

Try it

The loop runs on our own infrastructure, against our own repository, and is the fastest way we've found to turn "we should fix that" into a reviewable pull request.

Code: github.com/temple-compute/tc-agent-loop
Engine: github.com/temple-compute/horus-runtime

Want the managed experience? Temple Compute OS is in early access, including the workflow engine that just wrote this loop.