Inspiration
Incident management platforms are excellent at recording what happened, but recovery knowledge often remains buried inside old tickets, notes, and individual engineers' experience.
When a similar outage happens again, teams may still have to rediscover the same solution: inspect previous incidents, understand what worked, decide whether an action is safe, execute it, and verify whether the service actually recovered.
That gap inspired ReSolve.
We wanted to move beyond a system that simply stores resolved incidents and build an agentic recovery layer that can learn from previous incidents and approved recovery procedures, guide controlled execution, involve humans when risk demands it, and verify the outcome before declaring success.
What it does
ReSolve connects directly with Freshservice and supports two incident entry paths:
- Existing Freshservice Ticket – the user enters a ticket number, and ReSolve fetches the available ticket details and conversation history.
- Manual Incident Entry – a Freshservice-aligned form creates a new ticket and sends it through the same recovery workflow.
Both paths converge into one controlled recovery loop:
Incident Context → Evidence → Recovery Strategy → Risk Check → Human Approval if Required → Controlled Execution → Verification → Freshservice Update
The system uses historical recovery evidence and approved runbooks to identify suitable strategies. A reasoning layer helps choose between trusted options instead of freely inventing infrastructure commands.
Low-risk actions can move through the recovery flow automatically, while higher-risk actions pause at an approval gate where an operator can approve or reject the proposed action.
Most importantly, ReSolve separates execution success from recovery success.
A command running successfully does not automatically mean the incident is resolved. ReSolve performs independent post-action verification and only marks the ticket as recovered when the expected service state has actually been restored.
If recovery cannot be completed safely, the incident is escalated instead of falsely reporting success.
How we built it
ReSolve is built as a layered recovery system rather than a single unrestricted AI agent.
- Freshservice integration provides live incident data, ticket history, notes, status updates, and resolution handling.
- Recovery memory uses previously resolved incidents as operational evidence.
- Approved runbooks provide organization-controlled recovery procedures.
- Reasoning logic evaluates the available evidence and selects from trusted strategies.
- Risk tiering determines whether an action can proceed automatically or requires human approval.
- Docker-based environments give us a controlled space to simulate failures, execute recovery actions, and observe real state changes.
- Verification logic checks post-recovery conditions before the system declares success.
- Streamlit provides the operator interface for ticket intake, manual incidents, live recovery progress, approvals, execution history, and verification results.
A key design decision was that the reasoning layer does not receive unrestricted execution authority. It guides the recovery process using trusted evidence, while execution remains behind explicit controls.
Challenges we ran into
One of our biggest challenges was finding the right balance between automation and safety.
Allowing an intelligent agent to freely generate and execute recovery commands may appear powerful, but it introduces serious operational risk. We therefore designed ReSolve so that reasoning, execution, approval, and verification are separate responsibilities.
Another challenge was integrating with real incident workflows rather than building an isolated demo. Existing Freshservice tickets contain varying amounts of information, so we had to map available ticket and conversation data into a consistent recovery model without inventing missing context.
We also had to ensure that manual incidents and existing tickets did not become two disconnected systems. Both now enter the same recovery pipeline, keeping behaviour consistent regardless of how an incident begins.
Finally, Docker-based recovery forced us to distinguish between simply showing a successful action in the UI and proving that the underlying service state had genuinely changed.
That led to one of the most important principles in ReSolve:
An action completing successfully is not recovery. Recovery is only complete when the system verifies that the expected state has been restored.
Accomplishments that we're proud of
We are proud that ReSolve goes beyond simply recommending a fix and demonstrates a complete, controlled recovery workflow.
- We connected real Freshservice incidents to an agentic recovery system rather than relying only on isolated demo data.
- We built a shared recovery pipeline for both existing tickets and manually created incidents.
- We combined historical incident evidence with approved runbooks instead of allowing unrestricted action generation.
- We introduced risk-aware human approval gates so higher-risk recovery actions remain under operator control.
- We separated reasoning, execution, and verification, preventing a successful command from being mistaken for a successful recovery.
- We integrated Docker-based environments so recovery actions can affect real service state in a controlled setting.
- We close the loop by updating Freshservice only after recovery has been independently verified.
The result is not just an incident assistant, but a working proof of how agent-to-agent guidance, organizational memory, human oversight, controlled remediation, and verification can work together in a realistic operational workflow.
What we learned
Building ReSolve taught us that the most valuable use of agentic systems in operations is not necessarily maximum autonomy.
The stronger approach is controlled autonomy: use agents to interpret evidence, reuse organizational knowledge, reduce repetitive investigation, and guide recovery while retaining human authority for risky decisions and requiring verification before closing an incident.
ReSolve therefore does not try to replace Freshservice or remove engineers from incident response.
It turns existing incident history into reusable operational intelligence and helps teams move from:
“We solved this before.”
to:
“We know how it was solved, we know whether the action is appropriate now, and we can verify that it actually worked.”
What's next for ReSolve
The next step is to take ReSolve from a controlled recovery prototype toward a production-ready incident recovery platform.
We plan to:
- Expand recovery beyond Docker into cloud and infrastructure platforms.
- Add persistent recovery-session and audit storage.
- Support richer approval policies based on teams, services, permissions, and risk levels.
- Improve recovery knowledge using verified outcomes from previous incidents.
- Integrate with observability and monitoring platforms so incidents can be enriched with real-time system signals.
- Extend ReSolve into a coordination layer between incident-management systems, infrastructure agents, recovery knowledge, and human operators.
Longer term, our goal is for ReSolve to help organizations reuse what they have already learned from past failures instead of solving the same incident from scratch every time.
