DEV Community

Afrid Thenebanda
Afrid Thenebanda

Posted on

EdgeAI Forge: Building a Local-First Physical AI Architecture for Autonomous Industrial Pipelines

#opensource

EdgeAI Forge: Building a Local-First Physical AI Architecture for Autonomous Industrial Pipelines

AI is moving beyond chat. In industrial automation, the useful question is not only whether a model can answer an engineering question, but whether an AI system can help plan, generate, test, benchmark, review, deploy, and improve software that operates close to machines.

That is the idea behind EdgeAI Forge, an early-stage local-first agentic AI platform for Physical AI, machine vision, robotics, ROS 2, PLC integration, and edge deployment.

The target workflow is:

Requirement -> Plan -> Generate -> Test -> Benchmark
            -> Optimize -> Review -> Deploy -> Monitor -> Learn
Enter fullscreen mode Exit fullscreen mode

Why local first?

Industrial workloads have constraints that general cloud-first assistants do not always address well:

  • private image, telemetry, and engineering data;
  • low-latency or offline operation;
  • hardware-aware development and testing;
  • integration with cameras, robots, PLCs, Jetson devices, and ROS 2;
  • traceable artifacts and repeatable deployments; and
  • human approval for safety-critical actions.

Agentic workflows are also token-intensive. A single engineering request may require planning, code generation, validation, retrying, documentation, and testing. Sending every intermediate step to a cloud model can become expensive and can expose data that should remain on premises.

EdgeAI Forge therefore follows a simple principle:

Run frequent and private workflows locally. Use cloud models selectively for complex reasoning or large-context tasks.

A specialized multi-agent architecture

Instead of asking one model to do everything, the target design assigns focused responsibilities to specialized agents:

  • Planner Agent — converts a goal into requirements, tasks, risks, and expected outputs.
  • Vision Agent — designs preprocessing, training, inference, and optimization pipelines.
  • ROS Agent — proposes ROS 2 packages, nodes, topics, launch files, tests, and deployment steps.
  • Robotics Agent — supports simulation-first integration and reviewed motion workflows.
  • PLC/Automation Agent — prepares guarded Modbus and OPC UA integration templates.
  • Testing Agent — generates unit, integration, smoke, and performance tests.
  • Deployment Agent — prepares reviewed Jetson and edge-device delivery workflows.
  • Documentation Agent — records architecture decisions, usage, operations, and results.

The current proof of concept implements Planner, Vision, and ROS agents through an asynchronous Ollama client. The broader repository includes a FastAPI gateway, a Next.js command-center prototype, Docker infrastructure, observability configuration, benchmark utilities, and design scaffolds for the remaining modules.

Two logical planes

The target architecture separates coordination from model execution:

  1. A control plane manages APIs, orchestration, task state, memory, artifacts, approval gates, the dashboard, and observability.
  2. A compute plane serves local LLMs/VLMs, vision and robotics models, TensorRT workloads, and future GPU-accelerated inference.

Those layers can connect to Jetson devices, cameras, sensors, robots, PLCs, and HMI/SCADA systems. Cloud endpoints remain optional extensions rather than the default path.

Example: a ROS 2 vision pipeline

Consider this request:

Build a ROS 2 pipeline that reads USB-camera frames, detects objects, publishes detections, measures FPS, and prepares deployment to Jetson Orin.

The long-term goal is for the platform to turn that requirement into reviewed engineering artifacts such as:

  • package and node structure;
  • topics, services, actions, and launch files;
  • image preprocessing and inference code;
  • Docker and configuration files;
  • unit and integration tests;
  • latency, FPS, and GPU benchmarks;
  • TensorRT optimization guidance;
  • deployment and rollback instructions; and
  • generated operating documentation.

Safety is part of the architecture

Physical AI must be human-governed. EdgeAI Forge is not intended to bypass engineering review, machine interlocks, or functional-safety systems.

Real robot motion, PLC logic, production deployment, and machine-control changes should require explicit approval. Simulation, dry runs, tests, logs, and rollback plans should be first-class workflow stages.

Current status

This is an early prototype, not a production platform. Some components are runnable, while others are interfaces, placeholders, or roadmap items. I am sharing it now because architecture feedback is most valuable before the design hardens.

The project is developed in public under the BSD 3-Clause License.

GitHub: https://github.com/afridali123/EdgeAI_Forge

Long-form background: https://www.linkedin.com/pulse/edgeai-forge-my-journey-toward-local-agentic-ai-afrid-thenebanda-lpdhc/

I would especially value feedback on local model routing, ROS 2 artifact generation, simulation-first safety gates, Jetson deployment, observability, and meaningful evaluation of engineering agents.

Top comments (0)