The More Interesting Agent Loop Is Repair, Not Coding

TL;DR: Autonomous coding agents are good at writing code. They are bad at noticing when their work failed, figuring out why, and remembering what they learned. The interesting problem is not the coding agent — it is the runtime around it that turns failures into structured, scoped, verifiable repair work. Tandem is building that runtime. Source on GitHub.

---

Most people are still looking at autonomous coding from the wrong angle.

They ask:

Can an agent fix an issue?

That is useful, but it is only one piece of the loop. The bigger question is:

Can the system notice that autonomous work failed, preserve the evidence, triage the failure, create a scoped issue, hand it to a coding agent, verify the fix, and remember what it learned?

That is the loop I have been moving toward with Tandem (source on GitHub). Tandem is the runtime that wraps autonomous work — events, runs, artifacts, approvals, memory. ACA is the autonomous coder that picks up scoped issues. Bug Monitor is the failure intake that turns runtime errors into reviewable signals. The interesting work is not in any one of those pieces. It is in how they connect.

Coding agents are the easy part. The harder problem is building the operating system around them — something that decides what is real, what is safe, what is worth doing, and what should be remembered.

The Starting Point: Bug Monitor

Tandem already had a basic Bug Monitor. The original idea was straightforward:

read runtime logs
detect failures
turn them into issue reports
optionally publish them to GitHub

That alone is useful.

Autonomous workflows fail constantly. Sometimes the model made a bad assumption. Sometimes a tool was missing. Sometimes a permission was blocked. Sometimes the output did not match the expected contract.

A normal agent stack treats that as noise. Tandem should treat it as a signal.

The early Bug Monitor could already read failures and create reports, but it had gaps. It needed stronger gates. Better metadata. Evidence preservation. A way to avoid turning every weak signal into a GitHub issue.

Most importantly, it needed to know when a failure was actually actionable.

That led to the more important realization.

Bug Reporting Is One Version of a Larger Pattern

The useful architecture was not really “bug monitoring.” It was this:

signal
  ↓
evidence
  ↓
draft
  ↓
triage
  ↓
proposal
  ↓
approval
  ↓
action
  ↓
memory

That pattern is much more general than bug reports. It can apply to:

• workflow failures
• weak research findings
• repeated manual work
• docs gaps
• customer requests
• product opportunities
• generated workflow proposals
• work-pattern learning
• autonomous product improvement

The key idea is simple:

Raw signals should not directly become actions.

A failure should not instantly become a PR. A weak research claim should not become a report. A repeated user behavior should not silently change future behavior. A discovered workflow idea should not automatically become a recurring automation.

Everything important should pass through evidence, triage, proposal, approval, and memory.

What That Looks Like in Practice

Picture a real failure moving through the loop.

A scheduled workflow runs. Halfway through, an agent calls a tool that no longer exists in its scope — the tool was renamed in a recent release. The workflow fails. A naive system would either silently retry, log a stack trace nobody reads, or open a "tool not found" GitHub issue with no context.

Inside Tandem, that same failure produces a structured signal: which workflow, which run, which task, which agent role, the expected and actual output, the tool name, the artifacts the run had already produced. Bug Monitor takes that signal in, dedupes against the last 24 hours of intake, and decides it is novel. A draft incident appears. Triage runs against the draft and figures out the tool was renamed in commit abc123, identifies the two callers still using the old name, and proposes a one-line fix in each. The proposal passes the coder-ready gate because the scope is bounded and the verification is obvious: rerun the original failing flow.

ACA picks up the issue, opens a PR, the verification step reruns the failing workflow against the PR branch, the workflow passes, the PR merges. The pattern — "tool rename without deprecation alias" — gets stored in memory so the next rename gets caught at intake before it ever reaches the coding agent.

That is the difference. The coding agent did one small thing. The runtime did everything else.

The Autonomous Coding Loop We Actually Want

For autonomous coding, the repair loop looks like this:

flowchart TD
 A[Autonomous workflow runs] --> B{Failure or blocked state?}
 B -- No --> C[Complete and store outcome]
 B -- Yes --> D[Emit rich failure signal]
 D --> E[Bug Monitor intake]
 E --> F{Quality gate}
 F -- Blocked --> G[Store blocked observation]
 F -- Passed --> H[Create incident]
 H --> I[Create issue draft]
 I --> J[Run triage]
 J --> K[Write triage artifacts]
 K --> L{Coder-ready gate}
 L -- No --> M[Needs review]
 L -- Yes --> N[Publish or approve GitHub issue]
 N --> O[ACA autonomous coder picks up issue]
 O --> P[Create branch and PR]
 P --> Q[Run verification]
 Q --> R[Store failure pattern and fix memory]

That is a very different system from “agent writes code.”

The coding agent is only one part of it. The runtime is responsible for turning failures into structured work.

What a Useful Failure Signal Includes

If an autonomous workflow fails, “failed” is not enough. The runtime should report:

workflow_id
run_id
task_id
stage_id
agent_role
attempt
max_attempts
retry_exhausted
error_kind
reason
expected_output
actual_output
tool_name
artifact_refs
files_touched
validation_errors
suggested_next_action

That context makes the failure useful.

Without it, the coding agent is guessing. With it, the system can produce a real issue:

• what failed
• where it failed
• why it likely failed
• what evidence exists
• what files or components are likely involved
• what should be fixed
• how to verify the fix

Quality Gates Keep the System Useful

This is the part most agent systems skip.

If every failure becomes an issue, the system becomes a bug factory. If every issue becomes coder-ready, the coding agent gets buried in vague tasks.

So we added gates.

A signal should only advance if it has enough evidence. A draft should only become a proposal if triage produced artifacts. A proposal should only become coder-ready if the scope is clear.

For example, a coder-ready issue should have:

likely files or components
acceptance criteria
verification steps
low or medium risk
non-duplicate status
required tool scopes available

If those are missing, the system should not hand the issue to the coding agent. It should stay as an observation or require review.

flowchart LR
 A[Raw signal] --> B{Intake gate}
 B -- weak/noisy/duplicate --> C[Observation only]
 B -- enough evidence --> D[Draft]
 D --> E{Proposal gate}
 E -- missing research or validation --> F[Needs triage]
 E -- validated --> G[Proposal]
 G --> H{Coder-ready gate}
 H -- missing scope or unsafe --> I[Needs review]
 H -- bounded and verifiable --> J[Coder-ready issue]

This Starts to Become a Code-Healing Loop

Once the pieces are connected, the system becomes much more interesting.

Tandem runs autonomous workflows. Some fail. The Bug Monitor catches those failures. It creates incidents and drafts. Triage researches the likely root cause. The system creates a GitHub issue with evidence and acceptance criteria. ACA picks up the issue. ACA creates a PR. Tandem verifies the fix — by rerunning the original failing flow against the PR branch, then the smoke suite — and the failure pattern is stored in memory.

The next time something similar happens, Tandem can recognize it faster. It is structured runtime feedback, not anything more exotic than that.

sequenceDiagram
 participant W as Workflow Runtime
 participant B as Bug Monitor
 participant T as Triage Run
 participant G as GitHub
 participant C as ACA Coder
 participant V as Verification
 participant M as Memory

 W->>B: workflow.run.failed with evidence
 B->>B: quality gate and dedupe
 B->>T: create triage run
 T->>T: inspect, research, validate, propose
 T->>B: proposal and coder-ready report
 B->>G: publish approved issue
 G->>C: coder-ready issue
 C->>G: PR with fix
 V->>W: rerun failing flow or smoke test
 V->>M: store failure pattern and fix summary

That is the loop I care about.

Not “can an agent edit files?” Everyone is working on that.

The harder problem is:

Can autonomous work become observable, governable, repairable, and reusable?

That is where Tandem is going.

The Same Pattern Applies Beyond Bugs

Bug Monitor is only the first vertical slice. The same shape works for research.

A research report can fail too. It just fails differently. It may have:

• unsupported claims
• stale sources
• conflicting evidence
• missing citations
• overconfident conclusions
• weak recommendations

That should create a research quality signal.

flowchart TD
 A[Research workflow output] --> B{Evidence quality gate}
 B -- Strong --> C[Publish verified brief]
 B -- Weak --> D[Create research signal]
 D --> E[Research scope draft]
 E --> F[Evidence triage run]
 F --> G[Validate claims and sources]
 G --> H[Corrected brief]
 H --> I[Store validated finding in memory]

The same pattern works for discovering new workflows.

If Tandem sees the user repeatedly doing the same work, it should not silently change behavior. It should propose something.

repeated user behavior
  ↓
pattern signal
  ↓
workflow proposal draft
  ↓
user review
  ↓
approved workflow
  ↓
pilot run
  ↓
outcome memory

That keeps the system proactive without becoming creepy or chaotic.

Why AI Coding Agents Need a Runtime, Not Just a Prompt

This kind of loop does not belong in a loose prompt file. It belongs in the runtime.

The runtime owns:

• events
• runs
• tasks
• artifacts
• approvals
• permissions
• memory
• tool scopes
• published outputs

That is why Tandem is solving a different problem from most agent tools.

A coding agent can fix an issue. But the runtime has to decide:

Is this actually an issue?
Is it duplicate?
Is it safe to act on?
What evidence supports it?
Who approved it?
What tools are allowed?
What should be verified?
What should be remembered?

That is not just an agent problem. It is an operating system problem for autonomous work.

The Real Agent Loop

The pattern is not:

prompt -> action

The pattern is:

signal
  ↓
evidence
  ↓
proposal
  ↓
approval
  ↓
action
  ↓
memory

That is the difference.

Tandem is not trying to be another agent that runs around a repo with some markdown instructions. Tandem is becoming the governed runtime around autonomous work.

Bug Monitor is just the first proof point.

If we can make this loop work end to end, the implications are much larger than bug reporting. Tandem can start turning failures, research gaps, repeated work, docs gaps, and product opportunities into structured, reviewable, safe actions.

That is the system I want.

Not an agent that pretends everything worked. A runtime that notices when it did not, figures out why, proposes what to do next, and remembers what it learned.

Try Tandem or Read More

If you want to see how this is built, the runtime is open source. The code, the architecture decisions, and the issue tracker live in one place:

• GitHub: github.com/frumu-ai/tandem
• Agents: tandem.ac/agents — what ACA is and how it picks up scoped issues
• Docs: docs.tandem.ac — runtime concepts, events, workflows
• More writing: tandem.ac/blog — Bug Monitor, observability, governed autonomy

If you are building autonomous coding agents and bumping into the same wall — fixes that work in isolation but fail to compose into reliable systems — the runtime layer is what is missing. That is what Tandem is for.