Why Solutioner Now Has Plans (And Why We Built It as an MCP First)
Solutioner.ai started as the place where AI solution ideas live. Briefs get drafted, scored, prioritized, approved. Once a brief moves into development, the question that always comes up next is the one Solutioner didn't have a great answer for until this week: where does the actual work live?
Most teams answer that with a separate project management tool. Jira, Asana, ClickUp, a shared spreadsheet, a Notion database. The brief stays in Solutioner, and the plan and the running status live somewhere else. Clients see the brief. They rarely see the plan against the brief, and that gap is where transparency goes to die.
This week we shipped Plans, Tasks, and Milestones inside Solutioner, and we built them in the UI and as an MCP at the same time. Here's what they do, why we made the decisions we did, and what we think it changes about how AI consultancies should manage client work.
What we shipped
Every solution brief now has a Plan tab. The plan is its own object, with a description, a target completion date, and a set of tasks and milestones underneath it. Tasks are individual work items. Milestones are phase-level achievements. Both can have due dates, descriptions, and a done state. The UI is clean, fast, and intentionally sparse, because the plan should make the brief feel more concrete, not noisier.
There's a tenant Roadmap view that rolls up every brief's plan into a single timeline. Clients see what's coming up across all the briefs we're running with them, and we see the same view they see. There's also an admin Roadmap that spans every tenant on the platform, which is how our internal team tracks the engagement portfolio at a glance.
Tasks and milestones flag themselves as overdue if their due date passes and they're not marked done. Plans flag themselves as overdue, at risk, or on track based on the next-due item. The visibility runs from the line item up to the engagement.
Why we made it an MCP at the same time
The same capabilities that exist in the UI are wired into the Solutioner MCP. A team member working with Claude can list plans, create tasks, mark items done, query overdue work, and pull next-due summaries through natural language. Twelve tools total, six read and six write.
This matters more than it sounds like it does. AI-native consulting teams spend most of their time in conversations with Claude or another assistant. The work happens in a chat interface. Status updates, synthesis, and decisions all run through chat now. If the project management surface lives only in a separate UI, every conversation has to context-switch out to update status, then back in to do the next thing. That friction is enough to keep plans stale.
By building the MCP at the same time as the UI, we made it possible for a team member to take a real conversation, the kind that synthesizes a meeting, a working session, and a bunch of Slack threads, and turn it into a structured plan in seconds. The conversation that produced the understanding produces the plan, and they don't drift apart.
A team member can also do things like "show me everything overdue across all clients," "mark today's PO matching tasks done and add line item validation as a task for tomorrow," or "what milestones are slipping that I should bring up at Friday's meeting." The plan stays warm because the team interacts with it the same way they think about it.
Where this came from
This came out of a real client need. A client we work with was managing a critical brief, and they wanted more transparency on what was happening day to day. They wanted to see the milestones we were running against, what was complete, what was in flight, and what was upcoming. The brief itself wasn't enough. The status updates we were posting weren't structured enough. The gap between "this is what we said we'd do" and "this is what's actually happening" needed a structure that lived inside Solutioner, where the brief itself already lived.
That ask is what pushed us to build this. The client made a fair request. The right answer wasn't another tool. The right answer was making Solutioner do the thing it should always have done.
What this changes
For us internally, the team-wide view of work-in-flight is now a roadmap rather than a Slack channel. Our recurring weekly meetings have a new source of truth that didn't exist a week ago. We expect this will compress prep time and produce better decks, because the plan is the deck.
For our clients, the Plan tab on every brief gives them the running status of the work they care about, in the place they were already going to look. The Roadmap gives them the cross-brief view they previously had to ask for.
For the way our team works with Claude, this is the bigger shift. Every time we synthesize a situation, the synthesis can become a plan in the same breath. The plan is editable from Claude or from the UI, and updates run both directions. The work and the tracking of the work now live in the same place.