--- title: Why We Keep Rewriting the Agent Before Launch (and What We Would Ship Again) description: "Why agent architecture keeps getting rewritten before public ship — what broke in internal tests, and how we sequence the next rewrite." canonical: https://nowah.xyz/blog/why-we-rewrote-agent-after-launch lastModified: "2026-08-07T08:24:31.205Z" --- # Why We Keep Rewriting the Agent Before Launch (and What We Would Ship Again) Why agent architecture keeps getting rewritten before public ship — what broke in internal tests, and how we sequence the next rewrite. Agent architecture earns rewrites when tool use, memory, or booking safety does not hold under real conversation\. We prefer to burn those rewrites \*before\* public ship\. This post is about the triggers that force a rewrite and how we keep the cycle to weeks, not quarters\. ## Why the multi-agent pipeline hit its limits ![Illustration for this section](https://pics.nowah.xyz/website-media/launch-053-img-1.webp) Our initial architecture split the agent's capabilities across multiple specialized agents arranged in a pipeline. An intake agent interpreted the traveler's request. A search agent called the appropriate tools. A ranking agent ordered the results. A booking agent handled the transaction. A response agent composed the final message. Each agent was good at its job. The pipeline as a whole was slow. The latency came from handoffs. Each agent-to-agent transition involved serializing the conversation context, passing it to the next agent, and waiting for that agent to initialize, process, and respond. Five agents in a pipeline meant four handoffs. Each handoff added seconds. The latency was additive and unavoidable within the pipeline architecture. Context loss was the second problem. Each agent received a serialized summary of the previous agent's work rather than the full conversation context. Information was lost at every handoff. The intake agent understood the traveler's nuanced preference for morning flights, but by the time that preference reached the ranking agent, it had been compressed into a parameter that lost the nuance. The ranking agent optimized for "departure before noon" when the traveler meant "I prefer to fly in the morning but would consider an afternoon flight if it is significantly cheaper." Error propagation was the third problem. When any agent in the pipeline failed, the failure cascaded through all downstream agents. An error in the intake agent's interpretation produced wrong results in every subsequent stage. Debugging required tracing through five agent logs to find which agent introduced the error, a process that took longer than fixing the error itself. ## The rewrite decision The question was not whether the architecture needed to change. The question was whether to fix it incrementally or rewrite it. Incremental fixes could address individual problems. We could optimize handoff serialization to reduce latency. We could pass more context between agents to reduce information loss. We could add [error handling](/blog/error-handling-conversational-systems) at each boundary to prevent cascading failures. Each fix would improve the system. But the fundamental structure, multiple agents with handoffs, imposed a performance floor that no amount of optimization could eliminate. Four handoffs would always add latency. Serialized context would always lose information. The pipeline architecture was the problem, and patching individual symptoms would not resolve it. The rewrite decision came down to a calculation: how much engineering time to reach acceptable performance through incremental fixes versus through a rewrite. The incremental path estimated months of optimization work to reach a level that the rewrite could achieve in weeks. The rewrite was the faster path to the better architecture. ## The single-agent architecture ![Supporting diagram](https://pics.nowah.xyz/website-media/launch-053-img-2.webp) The rewritten architecture uses a single reasoning loop with direct access to all tools. One agent. Seventy-plus tools. No handoffs. The traveler sends a message. The single agent receives the full conversation context, reasons about the request, selects the appropriate tools, calls them directly, processes the results, and generates a response. There is no intake agent because the single agent handles interpretation. There is no ranking agent because the single agent handles ranking. There is no pipeline because there is nothing to pipeline through. The single-agent file is large. Over eighty kilobytes of tool definitions, instructions, and configuration. In a different context, a file this large would be a code smell. In the context of agent design, it reflects a deliberate architectural choice: co-locating all capabilities within a single reasoning loop eliminates the handoff overhead that dominated the previous architecture. The domain knowledge that previously lived in separate agents was retained as modular context. The intake logic, ranking algorithms, booking procedures, and response formatting are organized within the single agent's instructions. The knowledge is structured. The execution is unified. ## Migration strategy Rewriting the agent was an engineering challenge. Migrating live traffic from the old agent to the new one without disrupting travelers was an operational challenge. We ran both agents simultaneously for one week. Incoming requests were routed to either the old pipeline or the new single agent based on a traffic split. Initially, the split was heavily weighted toward the old agent: 95 percent old, 5 percent new. We monitored error rates, latency, response quality, and traveler satisfaction for the new agent's traffic. As metrics confirmed that the new agent matched or exceeded the old agent on every dimension, we increased the new agent's traffic share. Five percent became twenty-five, then fifty, then seventy-five. At each step, we verified that the metrics held. The gradual migration meant that if the new agent showed problems at any traffic level, we could immediately route all traffic back to the old agent. The A/B testing during migration produced a clear signal. The new agent was faster on every query type. Simple queries that previously took ten to fifteen seconds through the pipeline completed in a fraction of that time. Complex multi-step queries showed even more dramatic improvement because they involved more tool calls, and each tool call that avoided a handoff saved time. After one week of parallel running and gradual migration, the old pipeline was sunset. All traffic moved to the single agent. The old code was archived, not deleted. We keep it as a reference and as insurance, though we have never needed to revert. ## What we cut, carried over, and rebuilt The three-week timeline required ruthless scope management. We categorized every capability into three groups. Carry over: capabilities that worked well and could be directly transplanted into the new architecture. Most tool definitions fell into this category. A flight search tool does the same thing regardless of whether it is called by a pipeline agent or a single agent. These tools were moved with minimal modification. Rebuild: capabilities that were deeply intertwined with the pipeline architecture and needed to be redesigned for the single-agent model. The ranking logic, which previously was its own agent with dedicated reasoning, needed to be reimplemented as tool-enhanced instructions within the single agent. The response formatting, which had its own agent, was integrated into the single agent's output instructions. Cut: capabilities that were not essential for launch and could be added later. Some specialized features that the pipeline supported through dedicated agents were deferred. The single agent launched with the core capabilities that cover the vast majority of traveler interactions. Edge-case capabilities were added incrementally in the weeks following the migration. ## Post-rewrite metrics The metrics told a clear story. Latency for common queries dropped dramatically. The forty-five-second query that triggered the rewrite now completed in a fraction of the time. Complex multi-step queries, which accumulated the most handoff latency in the pipeline, showed the largest absolute improvement. Accuracy improved because the single agent reasons with full conversation context rather than serialized summaries. The nuances that were lost in handoff serialization were preserved. The agent made better decisions because it had better information. Cost per conversation decreased because the pipeline required inference at every stage. Five agents in a pipeline meant five sets of inference costs. The single agent uses one inference loop with tool calls, which consumes fewer total tokens for the same query. Traveler satisfaction, measured through post-conversation ratings and retention metrics, improved. Faster responses and better accuracy translate directly to happier travelers. The rewrite was not visible to travelers except through its effects: the agent became faster, smarter, and more reliable. The rewrite was the best engineering decision we made [after public launch](/blog/handling-negative-reviews-after-launch). Three weeks of focused work produced a fundamentally better architecture that improved every metric we track. The lesson is not that rewrites are always the answer. It is that when the architecture itself is the bottleneck, no amount of optimization within that architecture will solve the problem. Sometimes you have to rebuild the foundation. --- Nowah is an AI travel agent that searches and books real flights and hotels through conversation — no filters, no thirty open tabs. [Plan your next trip](https://app.nowah.xyz).