How I Built a Self-Healing Loop
My startup, Resyndeo, turns an idea or an existing codebase into a live product.
A user describes what they want, and Resyndeo builds the application, puts it online, verifies that it works, and returns a URL.
Every application is different. One might use an unusual address to report that it is healthy. Another might need a specific command to start. Some contain several services, background jobs, or databases.
When something fails, I need to know whether Resyndeo is broken or whether one application simply works differently from the others.
That is the problem I built my self-healing loop to solve.
Gathering the Whole Story
A production error rarely contains enough information to explain itself. The useful context is spread across several systems.
The original conversation tells me what the user wanted. My Postgres database connects that conversation to the project and deployment Resyndeo created. S3 stores the exact version of the source code that was built.
LangSmith records the decisions made by the AI while it reviewed the deployment. Loki collects written error messages from the application and its containers. Prometheus tracks numerical changes such as error rates, response times, restarts, and resource usage.
Kubernetes runs the application and reports whether it is healthy. ArgoCD checks that what is running matches the production configuration stored in Git.
I group all of that information around the same conversation and deployment. This gives the operations agent the user’s intent, the code, the AI’s decisions, and the final production result.
It can then investigate the complete story instead of guessing from one error message.
Fixing the Right Thing
Suppose a user’s application reports that it is healthy at /status, but Resyndeo checks /health.
A health check is simply a request used to confirm that an application is running correctly. In this case, the application works, but Resyndeo is checking the wrong address and concludes that the deployment failed.
The conversation shows what the user asked Resyndeo to build. The stored source code confirms that /status is the correct address. The AI trace shows why /health was selected, while the production logs show repeated requests to the wrong place.
Together, those clues explain the failure.
The operations agent can update that user’s deployment to use /status and put the application online again.
It can also decide whether Resyndeo itself should change. If the platform could have detected the correct address from the source code, the agent can improve that shared detection logic. If the chat instructions were unclear, it can improve those as well.
This distinction matters. Some problems belong only to one application. Others reveal a platform bug that could affect every future user.
The combined context lets the agent tell the difference.
Verifying the Repair
Platform changes still go through the same safeguards as my other work.
The agent makes the smallest change it can and adds a test for the failure it found. Automated code review and continuous integration check the change before it can reach production. I use Greptile as an additional reviewer, while GitHub Actions runs the tests and release checks.
The review also produces a Human Attention Map. It highlights the small parts of the change where a mistake could cause a serious problem, giving me a focused place to perform final quality assurance.
After the repair is deployed, the agent checks the application again. It confirms that the deployment is healthy, the original errors have stopped, and the broader production measurements remain normal.
It then records what failed, what changed, and whether the repair worked. That information becomes useful context the next time it sees a similar problem.
Closing the Loop
The process is straightforward:
Understand what the user wanted.
Observe what Resyndeo built.
Collect what happened in production.
Fix the individual application.
Improve Resyndeo when the cause is shared.
Verify that both now work.None of the individual tools makes the system self-healing.
The self-healing behavior comes from combining their information into one story, using that story to make the right repair, and checking the result afterward.
That is how I use production failures to handle the quirks in each person’s application while continuously improving Resyndeo itself.