Skip to content
Sai Eswar Gujjala
  • Professional work
  • Deployed internally
  • 2025–2026

ForgeOps: Agentic Manufacturing Exception Resolution

An event-driven, multi-agent AI platform. It spots manufacturing orders at risk of missing their delivery date, finds the root cause from evidence, plans a recovery, and carries it out after a project manager approves.

My role
End-to-end owner across all seven layers: problem definition with stakeholders and source-system integration; data models and ML models; agent design, the approval workflow and APIs; deployment, RBAC, audit logging and monitoring; pilot rollout, training and impact measurement.
Key result
Exceptions are spotted in 1.8 hours instead of 11.4 (84% less), and on-time delivery rose from 86.3% to 90.5%, compared with the manual process.
Technologies
  • Python
  • XGBoost
  • Isolation Forest
  • SHAP
  • Optuna
  • LangGraph
  • GPT-4o
  • Pinecone
  • Apache Kafka
  • Debezium
  • FastAPI
  • PostgreSQL
  • Redis
  • Docker
  • Kubernetes
  • Prometheus
  • Grafana
  • MCP
Skills shown here

What I owned

  1. Problem framing
  2. Data preparation
  3. Modeling
  4. Evaluation
  5. Application/API
  6. Deployment
  7. Monitoring

Built at Zetwerk for internal use. Described in simplified form; no customer or supplier names, data, code or internal links are shown.

In [1]:Problem and constraints

One customer order can span many suppliers, materials, machining steps, inspections and shipments, and a delay anywhere can cascade into a missed delivery.

  • Exception handling was manual and reactive: phone calls, emails, spreadsheets and status reviews.
  • Risks were noticed on average 11.4 hours after they first showed up in the data.
  • Investigations took hours, and recovery depended on who handled the case.
  • Nobody tracked whether a recovery plan actually worked.
  • Before ForgeOps: 86.3% on-time delivery, and 42% of exceptions caught before they reached the customer.

In [2]:Data and preparation

Real-time events from ERP, supplier portals, quality systems and logistics trackers, streamed with Kafka and Debezium change-data capture. Supplier emails, inspection reports and SOPs are indexed in Pinecone for retrieval.

In [3]:Baseline and evaluation design

  • The risk model scores every active order; SHAP explains each flag.
  • Agents were evaluated offline before rollout.

In production:

  • under 2% unsupported factual claims;
  • over 98% of conclusions linked to evidence;
  • over 99% of tool calls succeed;
  • zero unauthorized autonomous actions;
  • over 90% recall on high-severity exceptions.

Business results are compared with the manual process before ForgeOps.

In [4]:Architecture and modeling decisions

Seven layers:

  1. ingestion (Kafka, Debezium, Schema Registry);
  2. risk prediction (XGBoost, business rules, anomaly detection);
  3. evidence collection (Pinecone RAG);
  4. root-cause analysis (a GPT-4o agent in LangGraph);
  5. recovery planning (a GPT-4o agent);
  6. execution with approval (MCP tools, approval gates, RBAC);
  7. monitoring and closure.

ML scores every order quickly. LLM agents are used only where reasoning over messy evidence helps. A person approves every high-impact action.

In [5]:Implementation and integration

  • XGBoost predicts the chance of a missed delivery, with a rule engine and an Isolation Forest anomaly detector beside it. Flagged orders get a severity, predicted delay days and SHAP reasons.
  • An Evidence Agent gathers timelines, supplier profiles, material and quality records, and documents. A Root-Cause Agent separates confirmed facts from probable causes and missing information, with confidence scores.
  • A Recovery Planning Agent compares options (expedite, split with an alternate supplier, partial shipment, reschedule) on capacity, certifications, lead time, cost, quality risk and chance of success.
  • The project manager approves with full context. Then MCP tools create escalation tasks, generate RFQs, schedule inspections, draft messages and notify people. Everything goes into an immutable audit trail.
  • A case closes only when the system verifies the risk is resolved. If recovery fails, the case is escalated again.

In [6]:Deployment and operation

Status: Deployed internally

In production at Zetwerk (internal): Docker and Kubernetes, with Prometheus and Grafana monitoring, drift detection and retraining.

Out[6]:Results and evidence

  • Exceptions are spotted in 1.8 hours instead of 11.4 (84% less), and on-time delivery rose from 86.3% to 90.5%, compared with the manual process.
Mean time to identify an exception
1.8 hours (84% less)
Measured in production at Zetwerk, compared with the manual process before ForgeOps.
Baseline: 11.4 hours
Measured impact
Exceptions caught before customer impact
73% (+31 points)
Measured in production at Zetwerk, compared with the manual process before ForgeOps.
Baseline: 42%
Measured impact
On-time delivery
90.5% (+4.2 points)
Measured in production at Zetwerk, compared with the manual process before ForgeOps.
Baseline: 86.3%
Measured impact
Average exception-resolution time
2.5 days (36% less)
Measured in production at Zetwerk, compared with the manual process before ForgeOps.
Baseline: 3.9 days
Measured impact
Project-manager effort per case
3.1 hours (34% less)
Measured in production at Zetwerk, compared with the manual process before ForgeOps.
Baseline: 4.7 hours
Measured impact
Premium freight and expediting cost
11% lower
Measured in production at Zetwerk, compared with the manual process before ForgeOps.
Measured impact
Recommended plans accepted by operations
76%
Measured in production at Zetwerk. Not tracked before ForgeOps, so there is no baseline.
Measured impact

In [7]:Limitations, failures, and lessons

  • Detection is only as fast as the source data: a supplier who updates late still delays the signal.
  • Recovery options come from known playbooks, so truly new situations still need a person.
  • High-impact actions wait for approval by design.