Most engineering tasks require more than one person thinking
A lot of engineering work follows a recognizable pattern: you have a goal, you need someone to research it, someone to write the solution, and someone to review the output before it goes anywhere. On a real team, those roles exist naturally. Working alone or with a small team, you end up doing all three yourself, which is slow and error-prone.
What I wanted was a framework that could simulate that division of labor for the kinds of engineering tasks I run into regularly: PLC code review, HMI design, safety documentation, vision system configuration, and ops planning. Not a general-purpose assistant, but a system with domain knowledge and structured roles baked in.
I also wanted it to run completely offline. Using a cloud API for every agent call was a non-starter for anything that might involve proprietary process data or control system configuration.
Four crews, twenty agents, one interface
The backend is a Python service built on CrewAI. There are four crews covering different engineering domains: Code (Python, PLC, HMI), Vision (model configuration, inspection setup), Safety (hazard analysis, documentation), and Ops (runbooks, planning, handoff notes). Each crew has agents with specific roles and toolsets, and crews can be composed together for more complex tasks.
The template library has 18 pre-built task templates across those categories. You pick a template, fill in the context fields, and the appropriate crew handles the execution. There's also a free-form mode where you describe the task directly and the system figures out which crew should own it.
The React UI connects to the FastAPI backend over WebSocket and streams agent output as it happens. You can watch each agent's reasoning live, see handoffs between roles, and monitor crew status in the dashboard. Completed runs are stored and accessible from the run history page.
The MCP server is a separate component that exposes crew runs as tools. It lets you trigger any template directly from Claude Code or Claude Desktop using the Model Context Protocol. The CLI provides the same access from the terminal.
Where the real design work lives
The hardest part of multi-agent design is preventing agents from contradicting each other or getting stuck in loops. CrewAI provides the scaffolding, but you still have to think carefully about task sequencing, what context each agent receives, and how to handle cases where one agent's output doesn't match what the next agent needs. The system prompts for each role are where most of the real design work lives. A reviewer agent that returns freeform prose instead of a structured list breaks every downstream agent that expects structured input, so output format constraints had to be enforced through the prompt, not code.
Streaming was a specific engineering challenge. CrewAI runs synchronously by default. To get live output to the frontend, I run each crew in a thread and capture stdout, then push it over a WebSocket connection. This works well in practice but requires some care around thread safety when multiple runs are in flight simultaneously.
The offline demo mode deserves a mention. The UI has a demo state where all runs are simulated using pre-recorded agent output. This made it possible to showcase the system on the portfolio without requiring a live backend. The demo and live modes share the same component tree, which keeps the codebase clean.
The YAML-based configuration for agents and crews was a deliberate choice. It makes the system extensible without touching Python code. Adding a new agent is a matter of writing a few lines in a config file. The same config file drives the template library, the UI's task picker, and the MCP tool definitions.