01 / THE PRODUCT QUESTION
Good tools.
A missing shared workflow.
Each AI development tool can do useful work. Combining them introduces another job: carrying context between tools, deciding who goes next, and checking whether a result is ready to use. That coordination problem became the starting point for Smart Route.
My product management work was deciding which parts of that coordination the system should own and which decisions should stay with me. I built the workflow around explicit assignments, review, and visible recovery. The aim is simple: make it easier to understand the work and decide what happens next.
Different models. One coordinated team. Remarkably fast results.
What it means for the team to “know each other”
The principle I’m building toward is operational: specialized AI models should understand their teammates’ roles, share context, and collaborate toward a verified result. Speed and efficiency should come from good coordination, useful reuse, and less repeated work.
Six requirements for that team
- Know the roles. Give each model a clear account of every teammate’s responsibilities and relevant strengths.
- Carry the work forward. Include the context needed for the next decision and references to the exact artifacts in every handoff.
- Reuse what is already known. Make prior findings available, with their evidence and limits, so the next worker can build on them.
- Match the task to the teammate. Route work by relevant capability, availability, and constraints.
- Preserve progress through recovery. Keep partial results, verify what survived, and resume only when the next step is safe.
- Measure the outcome. Evaluate verified results, elapsed time, and cost, including review and recovery work.
This principle connects the UI and backend. The interface should show one shared objective, clear ownership, and how each contribution moves the work forward. Underneath, the system needs consistent assignments, context, artifact references, and recovery state to make that view trustworthy.
“Remarkably fast” is the ambition. Demonstrating it means comparing time and cost for equivalent, verified outcomes. A busy activity feed cannot establish that result.
02 / EXPLORE THE LAYERS
Clear responsibilities.
One connected experience.
The Mac app uses SwiftUI for the interface. A separate TypeScript service coordinates assignments, results, and review. Adapters connect individual AI tools, while shared records keep the work tied to its context and evidence.
Select a layer to see what it owns. Pull the assembly apart to see how those responsibilities fit together.
What is allowed to happen next?
The coordinator owns the working loop. Hermes supports diagnosis; Commander handles qualified recovery escalations. Those interventions remain distinct from ordinary building and review.
Design decisionGive probabilistic tools an explicit process, with state that can be inspected.
Why these boundaries matter
Keeping provider connections behind adapters limits how much of the product needs to change when a tool changes. Keeping coordination outside the interface gives the workflow its own place to be tested. Those boundaries also create a cost: state has to stay consistent across services, connections, and the screen. That synchronization is part of the engineering work.
The same separation applies to recovery. Hermes supports diagnosis and recovery around the workflow. Command Center presents the recovery state and open human actions in the native app. Investigating trouble and explaining it to a person are related, but distinct responsibilities.
03 / LOCAL AI & MIXED ORCHESTRATION
Frontier judgment.
Local capability.
Smart Route supports local AI alongside frontier models. A demanding planning or review step can use a more capable model, while a local coding model handles a clearly scoped implementation on your own machine. Shared roles, context, and review connect their contributions into one workflow.
Qwen’s open-weight coding family, for example, includes Qwen2.5-Coder at 7B, 14B, and 32B parameters. Whether a model is a good local teammate depends on the task, available memory, context length, and runtime—not its size alone.
Give the smaller model a better-defined job
In this workflow, the planner supplies a bounded task, the relevant code, constraints, and acceptance criteria. A local worker produces a patch. Tests and independent review evaluate it, with targeted feedback for another attempt or escalation when necessary. Guidance can make the task more tractable; the result still has to earn acceptance.
Spend capability where it changes the outcome
The potential value is using expensive reasoning selectively while keeping more implementation work local. I would compare this mixed team with a frontier-only workflow on equivalent tasks, counting review, retries, elapsed time, and total cost. Local inference also consumes hardware resources, and extra coordination can erase the savings.
Local execution gives a choice about where work happens. A hosted planner or reviewer still receives whatever context is sent to it, so the interface should make that boundary clear before a handoff.
Can a well-guided local model deliver the same accepted result with less frontier-model work?
Local and frontier models can participate in the same coordinated workflow. The quality, speed, and cost benefits of a particular model combination still need to be measured on comparable tasks.
04 / FROM INTAKE TO EXECUTION
The task shapes the team.
Coordination starts during intake. Smart Route uses the brief and expected deliverables to automatically propose a team: who plans, who builds, and who reviews. The proposal connects those responsibilities to the configured AI tools and models. I can inspect and adjust the team before approving the mission.
A software build, a research assignment, and a presentation can call for different specialist roles. Making team selection part of intake lets the user start with an outcome and review a clear account of who will do the work.
Scrum turns the plan into active work
After approval, the Scrum Master role coordinates assignments, dependencies, and review. As tasks become ready, Smart Route starts or resumes agent sessions with their role and task context. Independent tasks can run in parallel within the configured limits; dependent work waits for its prerequisites.
Scrum also coordinates staffing across implementation and review as the workload changes. Results move through checks and review, with feedback returning work for revision when needed. That gives the person a shared view of the mission while the system handles the task-by-task coordination.
One task, from intent to review.
Separate creation from evaluation
A builder’s confidence is not an acceptance criterion. The workflow supports independent review, revisions, and a separate integration step. That adds handoffs and waiting time, but creates a place to challenge a change before it becomes part of the product.
Keep the person at the right level
The interface needs to answer three questions: what changed, what is blocked, and what needs my decision? I use those questions to judge whether a status view is useful. Showing more activity does not automatically make the work easier to understand.
05 / HERMES & COMMAND CENTER
Know when to help.
Know when to stay quiet.
An interruption should not automatically summon another agent. The working team gets the first chance to recover. Hermes, Commander, and Command Center have different roles when more help is needed:
Understand why the work stopped.
When work stalls or a failure needs investigation, Hermes helps interpret the context and guide the next step. The recovery path allows only permitted actions and checks their outcome.
Steps in when an observed incident needs diagnosis or recovery support. It does not take over the team’s assignment or approval responsibilities.
Bring extra help only when it is justified.
The working team gets the first opportunity to recover. After Hermes validates an incident that qualifies for escalation, Commander can be brought in with a limited scope. Its response still needs verification.
Steps in when the normal recovery path is exhausted or cannot safely proceed. Healthy work and ordinary first failures do not launch Commander.
Make intervention understandable.
Command Center is the native interface for seeing the incident and recovery state, whether continuity is blocked, and any open human actions. It also shows when no human action is required. It is a view of the recovery process, not another agent.
Brings you in when there is a decision or action for a person. Commander coordinates the escalation; Command Center is where that situation becomes visible to you.
When the ordinary path needs help.
Intervention should earn its place. The person should understand why it happened.
An example of the intended flow
Imagine a builder stalls partway through a task. The team works through its normal recovery path, with Hermes helping diagnose the incident. If the issue qualifies for escalation, Commander can coordinate a bounded response. Command Center shows the resulting recovery or blocked state and any human action that remains.
An attempted repair is not verified recovery. If the system cannot establish a safe next step, the unresolved state needs to remain visible.
06 / THE GAUNTLET
Failure is part of the product.
A multi-tool workflow has to contend with interrupted work and uncertain state. The gauntlet is a controlled way to test the recovery path around Hermes and Commander. One implemented scenario interrupts a worker after partial work exists, so the test has something real to preserve and inspect.
The questions behind the test
- What happened? Establish which work was interrupted.
- What remains? Preserve enough context to inspect the partial result.
- What is safe next? Evaluate recovery against the observed state.
- What did we learn? Turn a failure into a more precise engineering question.
A restart alone cannot answer those questions. The test needs evidence that the work survived and that the next step is appropriate. Building this harness makes the recovery behavior testable; it does not, by itself, establish a recovery success rate.
07 / WHAT I LEARNED
Better systems ask
more precise questions.
Working on reliability led to specific changes in the implementation. Three examples from the codebase show how small assumptions can affect the whole workflow.
Recognize the failure before reacting.
A missing development tool and a tool that cannot be accessed need different responses. Tightening that distinction made recovery behavior more specific.
Design for a known failure condition, with a clear stopping point.
The right role depends on the stage.
Work in progress, requested changes, and work under review carry different responsibilities. Stronger checks tied task ownership to the stage of the workflow.
Make the process part of the data the system validates.
The interface needs a trustworthy view.
The interface and service need to agree on which version of a state they are discussing. A correction to that contract was paired with a regression test for the case that exposed the mismatch.
Treat the connection between system state and user understanding as product work.
08 / BUILDING WITH IT
Eventually, the tool
became part of the work.
Smart Route’s own codebase became a workspace for the AI team building it. Using the workflow on its own development made coordination and review part of the work itself, rather than something I could judge only through a demo.
That is what I mean by the tool helping build itself: AI tools contributed software changes inside a workflow I was directing and developing. Changes still needed review and verification. This was iteration on the software and process—not model training or a claim of fully autonomous development.
What I take from the experiment
The most useful product questions turned out to be concrete: who owns the next step, what evidence supports this status, and when should the system stop and ask? Building the system gave me a way to test those questions against actual behavior. That is the connection I want to keep exploring between product decisions and engineering.
A public overview of an ongoing personal experiment. The diagrams simplify responsibilities; implementation details are kept private.