JUNE 25, 2026 · 10 MINUTE READ
Building a self-improving software factory with Opulent
Three stages, one loop
Triage, implement, and verify in a continuous cycle that runs without manual routing
Zero manual triage
Issues are read, labeled, and routed without a person sorting each one by hand
Video-verified fixes
Every merged fix gets browser replay evidence posted back to the issue
"Real software teams lose hours every week sorting incoming issues, deciding which ones are worth doing, and checking whether shipped fixes actually worked."
Most teams handle incoming issues the same way. A person reads each issue, tries to understand it, searches the codebase for the relevant code, and decides what to do. This takes time and attention away from writing code. The person has to switch between the issue tracker and the codebase for every issue, even the simple ones.
After a fix ships, the verification step is usually missing entirely. Teams close the issue and move on. Nobody goes back to check whether the fix actually works in production. If the fix did not work, the team finds out weeks later when a user reports the same problem again.
- Engineers do triage by hand for every issue, even the simple ones
- Post-merge verification is usually missing entirely
- Coding agents do not know which issues to work on, how to verify their own work, or how to create new issues when a fix fails
Engineers advance this loop only when they have spare time, so it moves slowly. The Factory was designed to run this loop continuously and create evidence at every step.
Three automated stages connected in a loop that triages, implements, and verifies fixes with video evidence
You can connect three automated stages in a loop so that issues get triaged, implemented, and verified with video evidence, all without a person doing the routine work. We call this loop the Factory. It runs on Opulent, which loads the necessary capabilities on demand.
We built the Factory around three ideas:
- People steer, agents execute — when a person reviews a pull request or watches a verification video, their feedback tells the system whether the agents are doing good work
- Evidence at every step — Opulent posts a triage comment with its reasoning, opens a pull request with validation results when implementing, and records a video of the fixed behavior working in production to monitor the fix
- The loop closes itself — if Opulent detects that a fix did not work during monitoring, it automatically creates a new issue with the failure details, the video evidence, and a link to the original issue
Stage 1: Triage
When an issue arrives in your tracker, Opulent reads the issue, searches the codebase, and applies one label to the issue. The label tells you whether the issue is ready to implement, ready to spec, needs more information, or should wait. Opulent also posts a comment on the issue so subscribers know what is happening.
Stage 2: Implementation
When an issue is labeled ready to implement, Opulent takes over. It fetches the issue context, inspects the codebase, writes the smallest change that fixes the issue, runs validation, and opens a pull request. It then posts the pull request link back on the issue.
Stage 3: Monitor
After the pull request merges and the issue closes, Opulent checks production logs for errors. It then replays the fixed behavior in a browser or on a desktop using native browser and computer use tools. It records the replay with ffmpeg and posts the video back on the issue. If the fix did not work, Opulent creates a new issue describing the failure and links it to the original.
A concrete example
Say a user reports that the export button in your app does nothing when they click it. The issue lands in your GitHub issues.
Opulent reads the issue and searches the codebase for the export button code. It finds the button component and the click handler. It sees that the handler is missing a function call. The issue is clear, the scope is small, and the fix is in one file. Opulent applies the ready to implement label and posts a comment explaining what it found.
Opulent then fetches the issue and the triage comment. It opens the button component, adds the missing function call, and writes a test for the click behavior. It runs the test and the type checker. Both pass. It creates a branch, commits the change, and opens a pull request. A person reviews and merges it.
Opulent checks production logs for errors related to the export button since the fix deployed. It finds none. It opens a browser session with native browser tools, navigates to the app, clicks the export button, and confirms the export dialog appears. It records the whole interaction with ffmpeg and encodes it to a web-safe video format. It posts the video on the issue with a summary of what it tested.
If the fix did not work, Opulent records the failure, checks production logs, creates a new issue with the original issue link, the video of the failure, and a suggested next step. The new issue goes back through triage and implementation.
How to build this loop
Each stage of the Factory is defined by instructions containing procedures and guardrails that run on Opulent. You need five things to set up the Factory:
- A repository hosted on GitHub or a similar platform
- An issue tracker with a CLI or API (GitHub Issues, Linear, or Jira)
- A cloud agent runner (Opulent hosts agents in Daytona sandboxes with native browser, computer use, and connector tools)
- Three automation stages: one for triage, one for implementation, one for monitoring
- A trigger that starts the right automated workflow when an issue arrives or closes
You do not need all three stages to start. You can set up triage alone and see how it performs. Then add implementation. Then add monitor. Each stage works on its own and hands off to the next through the tracker state, not through a direct function call between agents.
The Factory works with any issue tracker that has a CLI, API, or MCP server. Opulent has native integrations for two trackers that teams use heavily: Sentry and Linear. Both connect through webhooks and OAuth, so issues and error events flow into the Factory without a person copying them over.
Sentry: errors become issues
Sentry sends a webhook to Opulent when it detects an error, alert, or issue event in production. Opulent verifies the webhook signature using the Sentry hook signing secret. The event payload includes the error message, stack trace, release version, and browser or device context.
When a Sentry event arrives, Opulent starts an agent run with a Sentry-specific prompt. The agent performs triage, reads the Sentry event context, searches the codebase for the failing code path, and applies one of the four triage labels. If the error is a clear bug with a bounded fix, the agent labels it ready to implement, triggering Opulent's implementation stage.
Opulent has a direct role in monitoring here. When a Sentry-triggered fix ships and the issue closes, Opulent checks production logs for the same error signature. It then replays the scenario that triggered the original Sentry event using browser or computer use tools. If the error no longer appears, Opulent posts the verification video on the issue. If the error still appears, Opulent creates a new issue with the Sentry event link, the video of the failure, and the log error. The new issue goes back through triage and implementation.
This closes the loop between error detection and error resolution. Sentry finds the error. The Factory triages it, fixes it, and verifies the fix. If the fix did not work, the Factory creates a new issue and tries again. Nobody has to read a Sentry dashboard and decide what to do.
Linear: issues flow in both directions
Linear sends a webhook to Opulent when an issue is created, commented on, or updated. Opulent verifies the webhook signature using the Linear signing secret. The event payload includes the issue title, description, labels, project, and assignee.
When a Linear issue arrives, Opulent starts an agent run with a Linear-specific prompt. Opulent triages the issue, searches the codebase, and applies one of the four triage labels back on the Linear issue. This uses Linear's native label system, so the labels appear in the Linear UI just like any label a person would apply.
When Opulent opens a pull request for the fix, it links the pull request to the Linear issue. Linear shows the pull request link in the issue timeline. When Opulent verifies the fix, it posts the verification video as a comment on the Linear issue. If the fix did not work, Opulent creates a new Linear issue with the failure details and links it to the original.
Linear's OAuth scopes include read, issues create, and comments create. The agent can read issues, create new ones, and post comments without a person granting access each time.
How the two work together
A team that uses both Sentry and Linear gets the full Factory loop without any manual routing. Sentry detects a production error and sends a webhook. Opulent creates a Linear issue from the Sentry event and labels it. Opulent then fixes the code, opens a pull request linked to the Linear issue, verifies the fix in production, and posts the video on the Linear issue. If the fix failed, Opulent creates a new Linear issue and the loop starts again.
The agent notifies the team through whatever connectors they have enabled. If they connect Slack, the team gets a message in their engineering channel when the fix is verified. If they connect Discord, they get a message there. The notification includes the Linear issue link, the verification result, and the video link.
You set up both integrations from the Opulent triggers panel. Each integration needs a webhook signing secret and an OAuth connection. Once connected, events flow automatically. You do not need to configure any per-issue routing rules. Opulent's labels handle the routing automatically.
The same loop applies beyond bug fixes. You can use the Factory for feature requests, dependency upgrades, documentation improvements, and any work that flows through an issue tracker.
The triage stage's four labels let you route issues anywhere. Ready to implement triggers implementation. Ready to spec triggers a workflow that writes product and technical specs. Needs info goes back to the reporter for clarification. Wait to implement parks the issue until conditions change.
The monitoring verification step works for any user-facing behavior. If the fix affects a web page, the browser tool replays it. If the fix affects a desktop application, the computer use tool replays it. If the fix affects an API, the agent can call the API and check the response. The video evidence works for all of these because the agent records whatever it does.
The connector notifications work for any channel your team uses. If you connect Slack, the agent posts verification results in the relevant Slack thread. If you connect Discord, it posts in the Discord channel. If you connect Gmail, it sends an email. The agent discovers which connectors are enabled and uses them.
The Factory's core idea is simple. You connect three automated stages in a loop. Each stage does one job and hands off to the next through the tracker. The loop runs without a person doing the routine work, and it creates evidence at every step so people can review and steer it. You can start with one stage and add more as you go. Each failed fix creates a new issue that starts the loop again, so the Factory improves itself over time.
To try the Factory on your own repository, see the instructions at .agent/skills/triage/, .agent/skills/implementation/, and .agent/skills/monitor/ in the Opulent repository. Learn more about Opulent.
