Epyk Forge

The autonomous operations fleet for the factory floor.

Comment

Inspiration

Manufacturing operations generate enormous amounts of useful information—machine state, alarms, cycle times, production schedules, maintenance history, operator notes—but most systems stop at displaying it.

A dashboard can tell a supervisor that a machine went down. It usually cannot determine what happened, investigate the evidence, calculate the downstream production impact, coordinate recovery, enforce operational policy, and preserve what was learned.

EPYK Forge was built around a simple idea: dashboards tell you what happened; Forge starts handling what happens next.

What it does

EPYK Forge is a secure autonomous multi-agent operations fleet for the factory floor.

It continuously monitors a synthetic precision-manufacturing facility called Northstar Precision Works and responds to operational events without requiring someone to first open a chatbot and ask a question.

When a machine develops a problem, Forge can automatically:

  • detect the anomaly and open an incident
  • correlate telemetry and preceding events
  • investigate likely causes
  • retrieve relevant maintenance knowledge with provenance
  • calculate production and schedule impact
  • create a governed recovery plan
  • generate maintenance actions and notifications
  • reserve alternate production capacity
  • request human approval for higher-impact decisions
  • execute approved digital workflow changes
  • record a complete decision trace
  • preserve the outcome as operational knowledge

The primary demonstration follows MC-04, a synthetic five-axis machining center, through an X-axis servo-overload cascade.

Precursor telemetry begins degrading before the alarm: axis load rises, cycle time drifts, and feed holds occur. Forge detects the resulting servo alarm automatically and coordinates six specialized agents:

Observer → Diagnostic + Knowledge → Production → Recovery → Supervisor

The Diagnostic Agent ranks likely causes from evidence rather than presenting an unsupported answer. The Knowledge Agent retrieves approved synthetic procedures and historical incidents. The Production Agent determines how many parts and downstream commitments are at risk. The Recovery Agent creates bounded operational actions. Finally, the Supervisor Agent applies deterministic policy and requires human approval before a consequential production reassignment.

The result is not merely an AI-generated recommendation—the application state actually changes.

Agent fleet

Forge uses six purpose-built agents with separate identities, responsibilities, and tool permissions:

  • Observer Agent — anomaly detection and incident creation
  • Diagnostic Agent — evidence-based root-cause investigation
  • Knowledge Agent — governed retrieval of operational knowledge
  • Production Agent — deterministic production-impact and capacity analysis
  • Recovery Agent — recovery workflow planning and bounded digital actions
  • Supervisor Agent — policy enforcement, authorization, and approval gating

Physical machine control is deliberately outside Forge's authority. Operations such as PLC writes, servo resets, or machine actuation are explicitly denied. Forge coordinates people and digital workflows rather than autonomously operating industrial machinery.

Security and governance

Agentic systems become much more useful when they can take action—but that also makes governance critical.

Forge implements least-privilege tool permissions, explicit agent identities, deterministic policy enforcement, audit records, human approval gates, and untrusted-knowledge handling.

A dedicated security scenario injects malicious instructions into the synthetic knowledge base. Retrieved documents are treated as evidence, not authority, so an embedded prompt cannot grant itself additional permissions or override system policy. Unauthorized actions are denied and recorded in the Security Center.

The application also includes a controlled retry scenario demonstrating that failed agent operations can recover without duplicating side effects such as incidents, evidence, maintenance tickets, or schedule changes.

Observability

Every operational incident is correlated across the agent fleet through a decision trace.

Forge records:

  • agent executions
  • evidence references
  • tool calls
  • durations
  • structured results
  • policy decisions
  • failures and retries
  • workflow transitions
  • state-changing actions

This makes autonomous behavior inspectable without exposing private model chain-of-thought.

How we built it

EPYK Forge combines:

  • Gemini 3.5 Flash
  • Google Agent Development Kit (ADK)
  • Google Cloud Run
  • Python / FastAPI
  • React / TypeScript
  • structured Pydantic agent outputs
  • event-driven workflow abstractions
  • persistent operational state
  • deterministic policy enforcement
  • synthetic manufacturing telemetry and knowledge

The architecture intentionally separates model reasoning from deterministic operations. Gemini is used where contextual reasoning is valuable, while calculations, permissions, state transitions, idempotency, and high-impact authorization remain controlled by application logic.

The entire Northstar facility—including machines, work orders, telemetry, maintenance records, procedures, and incidents—is synthetic and was created specifically for this project.

Challenges

One of the largest challenges was making the application meaningfully agentic without turning it into an uncontrolled collection of LLM calls.

We had to design explicit boundaries between reasoning and execution, preserve state across a long-running incident, prevent duplicate side effects during retries, maintain evidence provenance, and make the workflow understandable to a human supervisor in real time.

Deploying the distributed frontend/backend stack to Google Cloud also required hardening API routing, build-time configuration, authentication, service permissions, and cloud deployment behavior while preserving a deterministic local development environment.

Accomplishments

We are especially proud that Forge:

  • initiates work from machine events instead of chat prompts
  • coordinates multiple specialized agents
  • performs real application-state mutations
  • combines AI reasoning with deterministic manufacturing calculations
  • provides human approval for consequential actions
  • visibly enforces denied capabilities
  • survives controlled failures without duplicating side effects
  • exposes the autonomous workflow through a complete decision trace
  • runs as a deployed Google-powered application rather than a static prototype

What we learned

The most important lesson was that useful enterprise agents need more than intelligence.

They need identity, state, permissions, provenance, failure handling, observability, and clear limits on what they are allowed to do.

For industrial environments especially, the strongest agent architecture is not one that removes humans entirely—it is one that handles routine operational complexity automatically while escalating the decisions where human judgment still matters.

What's next

The current project uses a synthetic factory, but the architecture was designed around adapters so the same approach could eventually consume real manufacturing data through systems such as MTConnect, MES/ERP integrations, maintenance platforms, and other operational event sources.

Future work would expand the agent fleet across quality, tooling, maintenance forecasting, production planning, and cross-facility operations while continuing to strengthen enterprise identity, policy, memory, and observability.

EPYK Forge — The autonomous operations fleet for the factory floor.

Built With

Share this project:

Updates

Submission history