Inspiration
A factory can lose thousands of rupees every hour when a critical machine goes down. In that situation, the obvious approach is to find a supplier with the lowest price—but the cheapest part is not necessarily the cheapest decision.
The real question is:
"What is the fastest feasible way to restart production?"
We wanted to build an AI agent that could operate in this messy, real-world environment.
The biggest problem we focused on was that many suppliers still do not expose reliable, real-time inventory through APIs. A factory may need 20 parts, one supplier may have only 8, another may have 12, and a third may have the full quantity but take too long to deliver.
That's where RestartAI came from.
Instead of simply searching a database, RestartAI can communicate with suppliers through phone calls using CALL-E, convert their responses into structured offers, detect shortages, contact additional suppliers, and dynamically construct a recovery plan.
Our goal was simple:
Don't find the cheapest supplier. Find the fastest feasible way to restart the factory.
What it does
RestartAI is an AI-powered emergency production recovery agent for factories.
When a machine fails, the factory provides:
- Failed machine
- Required part
- Quantity
- Maximum acceptable recovery time
- Downtime cost per hour
- Available technicians
RestartAI then coordinates the recovery process.
1. Calls suppliers
Using CALL-E, RestartAI can communicate with suppliers through natural phone conversations and convert the responses into structured offers containing information such as:
- Available quantity
- Price
- Delivery/fulfillment time
- Compatibility confidence
- Other relevant supplier constraints
2. Handles partial inventory
This is one of the most important parts of RestartAI.
If a factory needs 20 parts but Supplier C has only 8, the system does not simply reject that supplier.
It recognizes a 12-unit shortfall and triggers adaptive supplier discovery.
It can then contact another supplier for the remaining 12 units.
3. Builds multi-supplier recovery plans
RestartAI can combine supplier legs when doing so produces a better recovery plan.
For example:
- Supplier C → 8 units → 0.5h
- Supplier D → 12 units → 1.5h
Instead of waiting 2 hours for another supplier with all 20 units, RestartAI can construct the C+D plan.
4. Calculates the real economic impact
RestartAI does not rely on an LLM to perform critical calculations.
Python deterministically calculates:
- Material arrival time
- Installation time
- Total recovery time
- Purchase cost
- Downtime exposure
- Total economic exposure
- Feasibility against the recovery deadline
For example:
$$ Total\ Economic\ Exposure = Purchase\ Cost + Downtime\ Cost $$
In our demo:
C + D
- Purchase cost = ₹3,720
- Recovery time = 2 hours
- Downtime exposure = ₹10,000
- Total economic exposure = ₹13,720
This beats Supplier B's ₹14,400 total exposure despite Supplier B providing the complete quantity.
5. Keeps humans in control
RestartAI does not automatically purchase parts.
It presents the recommended recovery plan along with alternative plans and requires human approval before the workflow can mark a plan as approved.
This keeps the AI focused on decision support and coordination, rather than giving an autonomous system unrestricted purchasing authority.
6. Provides an audit trail
Every important action is recorded in an activity timeline, including:
- Recovery actions
- Supplier replanning
- Recommendations
- Approval events
A downloadable recovery report can also be generated for incident documentation and postmortems.
How we built it
We deliberately separated communication, intelligence, deterministic planning, and human control.
Our architecture is:
Factory User
|
v
RestartAI UI
|
v
Recovery Engine
/ | \
v v v
CALL-E Maintenance Optional LLM
Agent Knowledge Base |
| |
v v
Supplier Calls Explanation only
|
v
Structured Offers
|
v
Dynamic Replanning
|
v
Recovery Plan Engine
|
v
Human Approval
CALL-E
CALL-E is responsible for the part that traditional software struggles with: communicating with suppliers that may not have structured APIs.
In LIVE mode, RestartAI sends calls through the CALL-E API and polls the call until a structured result is available.
For development and judging, we also built a deterministic DEMO mode so the complete workflow can be demonstrated without requiring real phone calls.
Python Recovery Engine
The core decision-making logic is deterministic.
Python handles:
- Supplier comparison
- Quantity constraints
- Partial inventory
- Multi-supplier combinations
- Installation time
- Technician constraints
- Recovery deadlines
- Economic exposure
- Plan ranking
This was an intentional architectural decision.
We did not want an LLM hallucinating whether a recovery plan was mathematically feasible.
Maintenance Knowledge Base
We created a maintenance knowledge base containing illustrative maintenance tasks and requirements such as technician count and installation time.
The system can also accept factory/user overrides.
Optional LLM
An LLM can explain the already-selected recovery plan in plain English.
Importantly, the LLM does not calculate the final cost, recovery time, feasibility, or supplier ranking.
That separation makes the system more predictable and auditable.
Backend and testing
RestartAI is implemented as a FastAPI application with a structured recovery engine and test suite.
We added tests covering scenarios including:
- Full-stock suppliers
- Partial stock + second supplier
- No over-purchasing
- No feasible supplier
- Technician shortage
- Recovery time calculations
- Economic exposure
- Best-plan selection
- Recovery-time constraints
- Demo mode
- Human approval
- Idempotency
Challenges we ran into
1. Real-world supplier information is messy
A traditional application can query an API and receive:
quantity = 20
price = 200
delivery = 2h
Real conversations are not that clean.
A supplier might say:
"We have eight pieces available right now. The rest can come tomorrow."
RestartAI needed to turn that type of conversation into structured operational information.
2. Partial inventory creates a planning problem
The hardest part was not finding one supplier.
It was deciding what to do when no single supplier can satisfy the requirement.
We had to make the system understand:
Required = 20
Supplier C = 8
Shortfall = 12
Supplier D = 12
C + D = 20
Then it must determine whether the combined plan is actually better than the alternatives.
3. AI should not control everything
We initially had to think carefully about where AI should be used.
For critical industrial decisions, allowing an LLM to freely calculate costs or determine feasibility introduces unnecessary risk.
So we separated the responsibilities:
CALL-E → communication
LLM → language/explanation
Python → deterministic calculations and planning
Human → final approval
This architecture made the system much more reliable.
4. Balancing realism with hackathon scope
A complete industrial production-recovery platform could involve ERP systems, warehouse management, procurement systems, IoT sensors, maintenance databases, logistics APIs, and persistent incident management.
That would be far too large for a hackathon.
We therefore focused on the core workflow:
Machine failure → supplier calls → structured offers → adaptive replanning → recovery plan → human approval
Accomplishments that we're proud of
Adaptive supplier recovery
RestartAI does not stop when the first supplier has insufficient inventory.
It recognizes the shortage and searches for additional supply.
Multi-supplier planning
The system can combine multiple suppliers instead of assuming that one supplier must provide everything.
Downtime-aware decisions
The system considers the economic cost of waiting.
A supplier that is cheaper but arrives too late can be worse than a more expensive supplier that restores production faster.
Deterministic decision engine
Critical calculations are handled by Python rather than being delegated to an LLM.
Human-in-the-loop safety
The system recommends and explains decisions, but purchasing is never automatically executed.
Real CALL-E integration
RestartAI is designed to work with actual supplier phone conversations rather than requiring every supplier to expose an API.
Demo without external dependencies
The deterministic demo mode allows the entire recovery workflow to be demonstrated without API keys, internet access, or real phone calls.
What we learned
The biggest lesson was that AI agents become much more useful when they are connected to deterministic systems and real-world actions.
We learned that an industrial agent should not simply be a chatbot.
It needs to:
- Understand the situation.
- Gather information from the real world.
- Convert messy information into structured data.
- Reason over constraints.
- Generate multiple possible plans.
- Explain the trade-offs.
- Keep a human in control.
We also learned that optimization is often about time, not just price.
A ₹150 part that arrives tomorrow can be more expensive to the factory than a ₹190 part that arrives immediately.
That changed how we thought about procurement and recovery.
What's next for RestartAI
RestartAI is currently a hackathon MVP, but the architecture can grow into a much larger industrial recovery platform.
Next steps
1. Real supplier networks
Connect RestartAI to verified supplier databases, distributors, logistics providers, and ERP systems.
2. Live inventory integration
Combine phone-based supplier intelligence with APIs from suppliers that already expose inventory digitally.
3. Predictive maintenance
Connect machine sensors and maintenance systems so RestartAI can identify potential failures before they become production stoppages.
4. Logistics optimization
Consider transportation availability, distance, shipping cost, and estimated arrival time when selecting suppliers.
5. Persistent incident management
Move from in-memory hackathon state to persistent storage so recovery incidents, supplier history, and postmortems can be retained.
6. Supplier reliability scoring
Over time, RestartAI could learn which suppliers consistently provide accurate availability, delivery estimates, and compatible parts.
7. Enterprise integrations
Integrate with ERP, warehouse management, maintenance management, and procurement systems.
Our long-term vision is for RestartAI to become an industrial recovery agent that coordinates the entire response to production disruptions.
The ultimate goal remains the same:
When production stops, RestartAI finds the fastest feasible path to get it running again.
Log in or sign up for Devpost to join the conversation.