Why I Built Nexboard
I build robotics software for work and tinker with hardware projects on the side. Flight controllers, field sensors, PCBs, embedded firmware. Every project touches at least two others. I was coordinating all of it with AI agents and a growing pile of markdown files.
The Problem with Markdown
The markdown system fell apart predictably. I reassigned pins on a PCB, forgot to update the firmware notes, and handed an agent a task to write a driver against hardware that no longer existed. The agent did exactly what I asked. The context I gave it was just wrong.
The more projects I ran in parallel, the worse it got. Each project had its own set of markdown files, its own conventions, its own version of the truth. When Project A's decision affected Project B's scope, I had to manually propagate that change across files. I'd forget. The agents would build on stale assumptions. I'd burn hours debugging work that was correct in isolation but wrong in context.
The Pattern I Kept Hitting
That was the pattern. The agents were ready to work. I was the bottleneck. I couldn't keep track of what to delegate, what I needed to do first to unblock that delegation, and which of my scattered notes were still accurate enough to hand off.
I wasn't managing projects. I was managing context, badly, across too many repos.
I tried Linear, Jira, Notion. They're built for human teams tracking human work. None of them understand that my workflow includes AI agents as first-class participants. None of them can answer "is this brief specified well enough for an agent to execute?" or "what are all the agents working on right now across all my projects?"
Why I Built Nexboard
So I built Nexboard. One place to capture a decision and link it to every project it touches. When I hand off work, the context flows with it. No more stale markdown. No more reconstructing the same state of the world from memory every session.
The core idea is the brief — a structured unit of work with scope, constraints, decisions, and cross-board dependencies. Briefs are designed to be both human-readable and agent-ready. An agent can read a brief via MCP, understand exactly what to build and what not to touch, and report progress back.
Over time, the tool grew features I didn't plan but desperately needed: an Intake Queue where agent-created work lands for human review before entering the workflow. A Pulse view showing all active agent work across every board. A readiness score that tells me whether a brief is specified well enough to dispatch. A command bar so I never have to reach for the mouse. Cross-board dependency tracking so I can see when server work blocks client work across projects.
Nexboard isn't trying to replace Linear or Jira. It's a different tool for a different workflow — the one where you're orchestrating AI agents across multiple codebases and need a shared brain that stays in sync.
I built it because I needed it. If you're juggling interconnected projects and handing work off to AI, you probably do too.