AxoFlow

Inspiration We were inspired by how powerful coding agents have become, but also by how fragmented the workflow still feels. Developers often jump between tools, prompts, terminals, and context windows just to get one task done. We wanted to build a local-first control center that makes agent-assisted development feel structured, transparent, and safe instead of chaotic.

What it does AxoFlow is a terminal-native orchestration layer for coding agents. It scans a repository, understands the project’s languages and tooling, turns a goal into a structured execution plan, and routes that work to downstream agents like Cursor CLI, Claude Code, and OpenCode. It also keeps track of plans, runs, and events locally, with replay support and policy controls for safer execution.

How we built it We built AxoFlow primarily in Go, using Cobra for the CLI and Bubble Tea plus Lip Gloss for the TUI. Under the hood, we created a repo scanner that detects languages, frameworks, package managers, and likely build/test/lint commands, then feeds that context into a planning engine. The system supports both deterministic planning and LLM-assisted planning, uses SQLite for local persistence, and exposes a pluggable adapter architecture so different coding agents can be integrated behind a common interface. We also added a TypeScript adapter SDK with Zod to make the ecosystem easier to extend.

Challenges we ran into One big challenge was designing a clean abstraction over very different coding-agent tools, each with its own detection logic, capabilities, and execution model. Another was keeping the terminal UI responsive while coordinating longer-running planning and execution flows. We also had to balance flexibility with safety, which meant building approval gates, destructive-command blocking, and local-only policy behavior into the product instead of treating safety as an afterthought. Finally, making LLM-generated plans reliable enough for real workflows pushed us to include deterministic fallbacks and structured parsing.

Accomplishments that we're proud of We’re proud that AxoFlow already feels like a real product instead of just a demo. It has a polished terminal interface, a working multi-adapter architecture, local SQLite-backed run history, replay support, and a built-in policy layer for safer agent orchestration. We’re also proud that the project is extensible: the adapter interface and SDK make it possible to grow beyond the initial integrations without rewriting the whole system.

What we learned We learned that orchestration is just as much about trust as it is about automation. Developers need visibility into what an agent is about to do, why it chose that plan, and how risky the change might be. We also learned that repo-aware context matters a lot: scanning the workspace and understanding project structure makes plans much more useful than generic prompting alone. On the engineering side, we learned the value of strong interfaces, local-first persistence, and deterministic fallbacks when building AI-assisted tooling.

What's next for AxoFlow Next, we want to expand AxoFlow’s adapter ecosystem, improve planning quality and memory across runs, and make the repo understanding even smarter through better module and architecture awareness. We also want to strengthen the developer experience with more documentation, broader test coverage, and CI. Longer term, we see AxoFlow becoming a reliable control plane for agent-driven software development: structured, extensible, and safe by default.

If you want, I can also turn this into:

a more polished hackathon-demo tone, a shorter Devpost-style version, or a more ambitious startup-pitch version.