Wirejac | Devpost

Agent graph architecture
Wirejac dashboard
Graph Orchestration made by Wirejac
Web app made by Wirejac framework

Inspiration

AI coding tools are useful, but they often hide what they are doing and have far too much access to a project. That becomes especially risky when the project includes cloud infrastructure and physical hardware. We built WireJac to explore a different model: represent the development workflow as an agent graph, give each agent a small workspace, and make every step visible. Our demo connects that idea to an ESP32 and MPU6050 accelerometer collecting motion data for a snatch-detection experiment.

What it does

A user submits a change request to the Coordinator agent. WireJac turns that request into a structured impact plan, selects only the affected workspaces, and sends a Jac walker through the relevant nodes. The graph contains six nodes: Coordinator, Client, Server, Device, Deployment, and Monitoring. For a dashboard-only request, the route is: Coordinator -> Client -> Deployment -> Monitoring

Server and Device are explicitly skipped, so they do not consume model calls or modify files.

Each workspace agent can only read and edit files inside its assigned directory. WireJac snapshots the workspace before changes, runs deterministic validation, records lifecycle events, and stops if an API contract changes unexpectedly. Device work is prepared as an artifact, but flashing an ESP32 requires separate approval.

The demo includes an accelerometer dashboard backed by cloud sample storage. The product UI is hosted through S3 and CloudFront, while accelerometer readings are stored in DynamoDB through the project’s cloud data path.

How we built it

The orchestration layer is written in Jac using Object-Spatial Programming. The project areas are Jac nodes, workflow relationships are typed edges, and each user request is a ChangeRequest walker. Routing happens through explicit graph traversal rather than a separate agent framework such as LangGraph.

Coordinator and workspace agents use DeepSeek through OpenRouter. They receive bounded role instructions, local API specifications, acceptance criteria, and restricted tools. File paths are normalized and checked before access, shell commands are allowlisted, and environment secrets never enter model context.

We separated agentic work from operations that need predictable behavior. Deployment, validation, monitoring, filesystem access, subprocesses, AWS operations, and serial communication sit behind narrow adapters. The hardware service can produce breadboard designs, assembly artifacts, constrained MicroPython firmware, and Wokwi evidence for an ESP32 DevKit V1 with a GY-521 MPU6050.

The system also records compact activation events so the WireJac dashboard can show which nodes ran, which were skipped, validation results, tool activity, and failures without exposing private model reasoning.

Challenges we ran into

The first challenge was making the graph part of the execution model rather than drawing a graph on top of an ordinary agent loop. Jac event ordering matters: node abilities perform the work, while walker abilities decide where to go next.

Jac client development also required careful work around compiler-supported JSX, browser APIs, module resolution, and build configuration. We had to rely on the installed Jac tooling and documentation instead of treating Jac like Python or JavaScript.

Security boundaries took just as much work as the agent behavior. A coding agent must not escape its workspace, read deployment credentials, choose arbitrary shell commands, or gain serial access simply because a prompt asks it to.

The hardware path added another constraint. Jac can generate Python, but ordinary generated Python is not automatically compatible with MicroPython. We needed a restricted device subset, compatibility checks, stable serial-port identification, ESP32 MAC verification, and an approval gate before any physical write.

Keeping the Client, Server, and Device API specifications synchronized was another hard problem. WireJac treats a contract change as a reason to stop and replan rather than deploying stale dependent code.

Another challenge was the Founder's Inc. internet not working on the device the agent graph was being made on

Accomplishments that we're proud of

We built a runnable six-node Jac agent graph with explicit traversal and selective workspace activation. A client-only request can pass through Coordinator, Client, Deployment, and Monitoring while recording clear reasons for skipping Server and Device.

The agents work inside contained directories with bounded tools, snapshots, validation commands, retry limits, and secret redaction. We also support a mock mode that exercises the complete route without calling a model or modifying source files.

We are especially proud that hardware safety is part of the architecture instead of an afterthought. The model cannot flash a board directly. WireJac prepares and validates an artifact, then pauses before the physical operation.

The project also joins the software and hardware sides of the demo: an accelerometer data pipeline, a hosted visualization app, cloud storage, and a Jac-native orchestration dashboard that can present the workflow as it happens.

What we learned

Graph structure is useful when it controls execution. Typed nodes and edges make routing, skipped work, replanning, and failure paths easier to inspect than a collection of loosely connected agent prompts. We also learned that agent autonomy needs narrow boundaries. Structured plans, local role files, API contracts, snapshots, and deterministic checks produce better evidence than an agent simply reporting that it is done. Hardware changes need a different trust model from web changes. Retrying a CSS build is harmless compared with repeatedly flashing the wrong serial device. Approval must identify the exact artifact, command, port, and board. Finally, compiler output and runtime evidence matter more than confident model responses. WireJac only considers a request successful after validation, deployment, and monitoring have produced concrete results.

What's next for Wirejac

Next, we want to finish the live event connection between the Jac service and the orchestration dashboard using SSE or WebSockets. That will allow reconnecting clients to recover graph state and follow activations in order. We also plan to replace monitoring placeholders with real browser assertions, console-error capture, HTTP health checks, process logs, and serial observations. Monitoring failures will feed back into the Coordinator for bounded replanning. For the device pipeline, the next milestones are changing the jac native compilation target to run on MCUs so we can skip the MicroPython intermediary.

Longer term, WireJac can support queued requests, stronger contract reconciliation, safer rollback policies, and more project topologies while keeping Jac OSP as the control plane.