Vortex

Inspiration Vortex was inspired by a simple idea: when a system fails, engineers do not just need more alerts, they need a way to walk causality. We wanted to build something that treated incidents and code behavior as connected graph problems instead of flat logs, dashboards, or disconnected scripts. That pushed us toward a Jac-first design, where traversal is part of the logic itself, not just an implementation detail.

How We Built It We built Vortex as a custom, graph-native system centered on Jac. Jac powers the core application logic, walkers, API surfaces, and CLI flows. Around that, we added a React and TypeScript UI layer for interaction, Python runtime helpers for orchestration and tooling, and a Rust + Tauri desktop shell to package the experience into a local native app. We also built an MCP layer so the system could expose and consume tools in a structured way, which helped keep the runtime extensible and agent-friendly.

At a high level, the project treats incidents and code flows as connected structures rather than isolated events. That made it possible to model investigations as path-aware reasoning instead of simple request-response logic. In a sense, the whole project was built around the idea that the shortest useful explanation is not just data, but a traversal path:

Insight≈State+Structure+Traversal

Challenges We Faced One of the biggest challenges was staying honest and disciplined about the architecture. It would have been easy to drift into a generic dashboard or wrapper around model calls, but we wanted the graph and walker model to stay at the center of the product. Another challenge was making multiple layers work together cleanly: Jac for core logic, Python for orchestration, MCP for tool interoperability, React for the interface, and Rust/Tauri for the desktop shell.

We also had to design for resilience. AI-assisted behavior is valuable, but the project still needed deterministic fallback paths so the demo remained credible even when model access was limited or unavailable. Keeping that balance between ambitious AI-native workflows and reliable local execution was a major part of the engineering work.

What We Learned We learned that graph-native design changes how you think about application structure. Instead of forcing everything into traditional endpoints and disconnected service calls, we could let traversal itself become the reasoning model. We also learned how valuable a strong integration layer is: MCP made the system more modular, and the combination of Jac, Python, frontend tooling, and Rust showed us how to build a product that feels unified even when it spans multiple runtimes.

Most importantly, we learned that a focused architecture tells a stronger story than a broad one. By keeping the project centered on causality, graph flow, and path-aware reasoning, we ended up with something much more distinctive than a conventional app.

Built With

• and-cli;-python-supporting-runtime-orchestration-and-the-vortex-mcp-server;-typescript
• and-vite-powering-the-ui-layer;-and-rust-with-tauri-providing-the-desktop-shell.-the-system-also-includes-a-dedicated-mcp-integration-layer-for-tool-discovery-and-execution
• api-surfaces
• built-with-a-custom-jac-first-architecture
• graph-workflows
• lm-studio
• plus-ai/model-routing-through-gemini-by-default-and-openai-compatible-local-providers-such-as-ollama
• react
• rust
• with-jac-powering-the-core-application-logic