BuyBye

DECISION LOG

1. The UI is a component set, not a generation

   Adaptive interface is assembled from premade components. The model selects; it does not invent.

   Bounding the vocabulary is what makes generated interface safe to ship. A model choosing from a known set produces controls that are already styled, already accessible and already tested; a model producing arbitrary interface produces none of those guarantees and fails in ways that are invisible until a user hits them.

2. Two agents, two contexts

   A content agent answers. A second agent then assesses whether the question can be served by a quick-answer component, adds it to the interface, and returns the user's answer back to the content agent.

   The alternative was one agent holding both the content tools and the interface tools. Splitting them keeps the dynamic-UI tooling out of the content agent's context entirely, and each agent is more effective for carrying a narrower set of concerns. The same instinct that produced the orchestrator split on AgenticWP — narrow the context, and the model gets better at what remains.

   The loop matters as much as the split. Because the UI agent's component feeds its result back to the content agent, an exchange that would have required the user to type a sentence becomes a tap, and the conversation continues without a break in context.

3. Gemini for its tools, not its model

   Gemini rather than OpenAI, which was the choice on both neighbouring projects.

   The decision was made on tooling, not on model quality: at the time, Gemini's built-in search and web-scraping tools were the best available for the thing this product actually does, which is find out what a product costs and what people say about it, right now. A time-bound decision, made on the state of the tooling as it stood.

4. No bank access

   The product gives financial guidance and never connects to a bank account.

   Aggregation would have produced far better signal. It was refused on complexity and liability: holding a pipe into someone's finances is a different product with a different risk profile, and this one did not need to be that. Financial context is supplied by the user at onboarding and deepened through the dashboard over time.

5. Accuracy was iteration, not architecture

   Extracting reliable pricing and product detail from a photo or an arbitrary retail link is the messiest problem in this project.

   The approach is Gemini's web search and image tools. The honest finding is that no architecture solved it — reliability came from many iterations of prompting and validation against real inputs. Worth stating plainly, because the interesting failure mode here was expecting a structural fix to a problem that only responded to grinding.