Building a Reliable, Agent-Driven Switching System for YourNavi
Wippy
agent runtime
stateful
flow engine
tribal
knowledge encoding
Solutions
Industries
Technologies
About THE Project
YourNavi operates SaveOnWireless, a telecom comparison platform that earns consumer trust before the decision but loses the user the moment that decision is made. Once a visitor clicks “Get deal,” they fall into a carrier-owned flow – one that is inconsistent, confusing, and instrumented by no one on Navi’s side. Post-decision conversion was at or near zero.
Spiral Scout shipped a carrier-specific switching assistant built on the Wippy runtime. The system guides users through the Verizon-to-Xfinity switching path – explaining what information is required at each step, handling the edge cases that cause abandonment, and keeping Navi’s brand and data layer present through to completion. The agent is stateful, meaning users can pause and resume without losing progress. All configuration and knowledge base data remains on Navi’s infrastructure. Spiral Scout does not hold the keys.
OBJECTIVES
- Own the post-decision moment instead of handing users off to carrier flows with no visibility
- Build a switching copilot that explains each step rather than issuing opaque instructions
- Encode Navi’s carrier domain knowledge into a configurable agent system that the internal team can maintain and extend
- Create a stateful user experience that preserves progress when users pause mid-flow
- Instrument the entire switching journey so Navi can see, for the first time, exactly where users abandon and why
- Establish a baseline architecture that lets future carriers be added as configuration variants – not rebuilds
Challenges
Solutions
The Invisible Drop-Off Point
Navi had strong top-of-funnel performance. Users were reaching the “Get deal” click. But the moment they hit that button, Navi lost them. The handoff went straight into carrier-owned activation flows that varied by carrier, were rarely mobile-optimized, and had no mechanism for users to recover when something went wrong. The client had no instrumentation on the other side of that click. They knew conversion was near zero but couldn’t see why. No internal team had the bandwidth or the architecture to address it.
A Post-Decision Switching Copilot, Scoped to One Carrier Path
Rather than attempting to solve every carrier and every flow at once, Spiral Scout constrained the scope deliberately. The first build targeted one path: the system handles pre-switch preparation, eligibility checks, step-by-step guidance, and error recovery – all through a conversational agent layer. Every interaction is instrumented. Navi can now see exactly where users hesitate and where they fail.
Consumer Trust vs. Opaque AI Recommendations
The client raised this concern directly: consumers already distrust telcos, and an AI that issues recommendations without explanation would backfire. A “magic chatbot” that tells users to switch without showing its reasoning is a trust liability, not an asset. Pure LLM approaches and generic RAG setups were ruled out explicitly because they produce outputs that cannot be audited or explained.
Rules-Driven Logic with an Explicit Decision Tree
The agent runs on codified rules, not on generative guessing. Each recommendation is traceable to a defined condition: carrier eligibility rules, device compatibility, porting requirements, promo pricing terms. When a user hits a blocker, the system explains what the blocker is and what to do about it. The rules are auditable. Navi can review them, approve them, and adjust them without touching the underlying agent architecture. The system can also tell users when switching is not the right move – which is the only position that holds up under scrutiny from consumers and carriers alike.
Scaling Without Rebuilding
Every carrier pair has different eligibility rules, required fields, activation steps, known failure modes, and promo conditions. Building a separate system for each carrier would mean starting from zero every time. That was not viable given Navi’s internal bandwidth constraints and the pace at which they needed to expand.
Variant-Pack Architecture for Multi-Carrier Expansion
Spiral Scout built a baseline flow engine designed from the start to accept carrier-specific configuration packs rather than hard-coded logic. The underlying framework – step sequencing, session persistence, instrumentation, error recovery – stays constant. What changes per carrier is the variant: required fields, eligibility checks, device-specific edge cases, promo disclaimers. Adding a new carrier path means adding a new variant pack and testing it. It does not mean rebuilding the product.
Strategy
Spiral Scout’s approach on this project was to push back on scope before writing a line of code. The temptation on an AI project like this is to start broad – multiple carriers, full automation, a generalized advisor. We said no to that, and we had to say it more than once. The thing that keeps AI projects from shipping is the gap between what gets demo’d and what holds up under real user behavior. The way to close that gap is to do one thing well before doing many things at scale.
Start Where the Leverage Is Highest
We used the client’s domain knowledge as the foundation. Building on known ground meant we could design the agent logic from real carrier rules, not from assumptions, and validate it against real edge cases before any other carrier was introduced.
Encode the Knowledge, Not Just the UI
The switching assistant is not primarily a UI project. The UI is the delivery mechanism. What matters is the knowledge layer underneath – the carrier rules, the edge case handling, the eligibility logic, the known failure modes. Spiral Scout worked with Navi’s subject matter experts to extract and encode that tribal knowledge into the Wippy knowledge base. That foundation means every future agent Navi builds can draw from the same underlying intelligence rather than starting from scratch.
Build for Client Independence from Day One
Wippy is open-source. Navi owns their data, their agent configurations, and their knowledge bases. Spiral Scout runs the training sessions, handles the onboarding, and is available for support – but the architecture was designed so that Navi’s internal team, including a non-technical operator, can build and extend agents without returning to Spiral Scout for every change. The goal was always to make Spiral Scout unnecessary for routine operations. That’s not a risk – that’s the point.
Project Results & Impact
What exists now is a working switching assistant deployed on Navi’s infrastructure, handling the app with a stateful, rules-driven agent that keeps users in a guided experience through the moment of commitment. Before this system, Navi handed users off at the decision point and had no visibility into what happened next. Now they have instrumented data on where users pause, where they fail, how long each step takes, and which edge cases cause abandonment. That data is a new asset.
The long-term architecture bet here is that this instrumentation compounds. Each assisted switch generates structured behavioral data that no carrier, no comparison site, and no generic AI product has access to at this resolution. As Navi encodes more carrier paths into the system, that data advantage grows. The client described the goal accurately: to become the conversion intelligence layer that sits between consumer intent and carrier activation – not a comparison site that sends traffic away.
Tangible outputs:
– A production-ready switching assistant covering one constrained carrier path
– A Wippy-based agent runtime deployed on Navi’s infrastructure with full client ownership of configurations and knowledge bases
– A variant-pack architecture enabling additional carrier paths to be added without rebuilding the flow engine
– A stateful session system allowing users to pause and resume the switching flow without losing progress
– Instrumentation capturing drop-off points, step completion times, and abandonment events across the switching journey
– A knowledge base encoding Navi’s carrier domain expertise, structured for ongoing extension by the internal team
– Training documentation and recorded sessions enabling Navi’s team to build and configure future agents without external engineering dependency
Key Takeaways
- The scope constraint was the design decision. Trying to handle every carrier at launch would have produced something too fragile to deploy. Starting with one well-understood path let us build something real before scaling it.
- Rules-driven agents are not a compromise – they are the right tool here. When the domain is complex, auditable, and high-stakes for consumer trust, you need logic you can explain and defend. Generative AI without a rules layer is a liability in this context.
- Tribal knowledge is infrastructure. Navi’s competitive edge is not their technology stack – it is the carrier domain knowledge their team has accumulated over years. Encoding that into a structured knowledge base turns a retention risk into a durable system asset.
- Client Independence was built in from the architecture, not retrofitted. Because Wippy is open-source and Navi owns all configurations, they are not locked into Spiral Scout’s roadmap, pricing, or availability. Any competent engineering team can extend what was built.
- The instrumentation layer is the real long-term asset. Conversion lift on one path matters today. The behavioral dataset Navi is building – on how users actually switch, where they fail, and what each carrier’s friction profile looks like – is what matters in two years.
- Client independence is an architectural outcome. It’s not a closing-phase handoff or a nice-to-have documentation package. It shapes every decision from day one. If your team can’t own it, it shouldn’t ship.
Worth thinking about if you’re building a consumer platform where your users make a high-intent decision and then fall into a third-party flow you can’t control.
Related projects
-
Agent-Driven Conversion Infrastructure for a Telecom Intelligence Platform
LinkSpiral Scout built a post-decision switching assistant that keeps Navi present at the moment users most often abandon.
-
Agent-Driven AI Data Hub with Grounded Executive Reporting
LinkGrounded AI retrieval, generative reporting, and conversational search for an executive data hub. Trusted answers. Stack owned by their team.
-
Temporal Workflow Architecture Consulting for Enterprise Data Services
LinkArchitecture consulting for a visual workflow editor built on Temporal, enabling cross-department automation at enterprise scale.
-
Market Discovery & System Framing for an AI-Driven Investor Relations Platform
LinkEstablished the architectural and market foundation for an AI-native earnings call product.
-
Conversational CRM Agent Orchestration for Salesforce-Native SaaS
LinkShipped a resilient multi-agent architecture that turns complex Salesforce CRM data into a conversational interface for sales teams.
-
Agentic Workflow Orchestration for Autonomous Banking Infrastructure
LinkArchitected a Temporal-backed agentic runtime for a fintech platform shipping autonomous financial workflows to regulated markets.
AI You Can Trust With Real Decisions
Meet the founders
Tell us your goals
Receive a proposal
Project kickoff
John Griffin
Co-Founder, CEO
Anton “JD” Titov
Co-Founder, CTO
“Anton is an exceptional technologist. I would feel comfortable having him work on any technical challenge.” – Ryland Goldstein, Head of Product, Temporal