OpsRelay

• 

  Opsrelay

Inspiration

I wanted to build something where an AI agent actually does useful work inside a real application, not just answer questions or chat.

I started thinking about manufacturing and operations because one small problem can turn into a much bigger one very quickly. A supplier being late can affect stock, production, customer orders and money all at the same time.

That is where the idea for OpsRelay came from.

What it does

OpsRelay is a manufacturing incident recovery dashboard.

For the demo I created a scenario where a supplier is 48 hours late delivering Aluminium 6061 Sheet. That delay causes a material shortage, affects production, puts three customer orders at risk and exposes R423,000 in revenue.

The user can give the AI agent one request and the agent can use the WebMCP tools in OpsRelay to work through the problem.

It can:

• check the current incident
• find the orders that are at risk
• check available inventory
• search for other suppliers
• compare the supplier options
• create a recovery plan
• send that plan for approval
• execute it once a human has approved it
• check the final recovery status

The main idea is that the user does not have to manually jump between every part of the system just to investigate one incident.

Why WebMCP

WebMCP is basically the part that makes the whole idea work.

Instead of the agent trying to understand the website by looking at buttons and text on the screen, OpsRelay gives it proper tools using document.modelContext.registerTool.

Those tools connect to the same data and state that the user sees in the dashboard.

So the agent is not just telling the user what it thinks should happen. It can actually use the application to investigate the incident and work through the recovery process.

Humans + agents

I did not want the agent to have full control over everything.

The agent can investigate the problem, compare options and create a recovery plan, but it cannot approve its own plan.

The approval has to be done by a human in the dashboard.

Only after that approval can the agent execute the recovery plan.

I liked this setup because the AI can do a lot of the repetitive work, but the important decision still stays with the person using the system.

How I built it

OpsRelay is built with Next.js, React, TypeScript and Tailwind CSS and is deployed on Vercel.

I registered nine WebMCP tools:

• get_current_incident
• get_inventory
• get_at_risk_orders
• search_supplier_options
• compare_supplier_options
• simulate_recovery_plan
• request_recovery_approval
• execute_recovery_plan
• get_recovery_status

The demo uses browser-local data and a fixed incident scenario so it can be reset and tested again without needing an external database or real supplier system.

Challenges I ran into

The hardest part was deciding what the AI should be allowed to do by itself and what should still require a person.

I also had to make sure that when the agent used a WebMCP tool, the result matched what was happening in the dashboard.

Another challenge was getting the full workflow working from beginning to end instead of just making a few separate tools that worked on their own.

Accomplishments that I'm proud of

The biggest thing for me is that the full workflow actually works.

The agent can start with a supplier incident, investigate what is affected, compare recovery options, create a plan, send it for human approval and then execute the approved plan.

I am also happy with the human approval part because the agent cannot simply approve and execute its own actions.

What I learned

Before building this I did not really understand how useful WebMCP could be.

I originally thought of AI inside websites mostly as chatbots or assistants.

Building OpsRelay showed me that the website itself can expose tools to an outside agent, while still keeping the normal interface for the person using it.

That opened up a completely different way of thinking about how people and AI agents can use the same application together.

What's next for OpsRelay

The current project is a simulated manufacturing incident, but the same idea could work with real operational systems.

The next step would be connecting it to live inventory, supplier, order and production data instead of the demo state.

I would also like to add more incident types, such as machine breakdowns, sudden demand changes and other supply chain problems.

Built With

• next.js
• react
• tailwind
• typescript
• vercel
• webmcp