Talon Started as a Chatbot. The Product Became an Operating Problem.

Talon started as a support chatbot.

That was the honest first version. New subscribers needed a faster way to understand Skylit, the platform vocabulary, and the options-market concepts behind the product. Skylit had its own product language. Options markets have their own language. The SkylitAI Academy had a body of educational material that could answer a lot of early questions, but only if a user knew where to look and what to ask.

Most new users do not start that way. They arrive with intent, confusion, urgency, and partial vocabulary. They want to get to value quickly.

So the first job for Talon was simple: retrieve the right knowledge, explain it in the user's context, and reduce the repeated onboarding questions that landed with the trader success team.

That is a good use case for RAG.

Retrieval gave Talon a bounded source of truth. It kept answers close to approved Academy and knowledge-base material. It turned scattered documentation into a conversational entry point. A subscriber could ask what a term meant, how a platform concept worked, or where to start, and Talon could help without requiring them to already know the map.

But the moment users start trusting an agent inside a live trading platform, the shape of the problem changes.

They do not only ask, "What does this term mean?"

They ask, "What does this mean right now?"

That question moved Talon from documentation retrieval into operating context.

The next expectation was that Talon should read Gamma and Vanna maps for a trade. That is a different class of problem. The agent is no longer just retrieving a paragraph from a knowledge base. It has to interpret current market structure, connect that structure to the question, and avoid inventing certainty where the evidence is incomplete.

The solution was not better prompting.

It was tools.

We built scripts and tool paths around market context, with caching where latency and repeated access mattered. Redis became part of the practical architecture because the same snapshots can be requested repeatedly, and the agent needs fresh context without turning every answer into a slow, fragile fetch.

This is where domain knowledge became the linchpin.

A general-purpose model can explain what gamma is. That is not the same as knowing how a trader uses a gamma map inside Skylit. The useful agent needs to know which data matters, which interpretation is too strong, what language is safe, and when the right answer is not a prediction but a bounded read of the evidence.

Then options flow entered the loop.

This made the advantage of using AI more obvious. Flow data can be massive and noisy. The point is not to summarize every print. The point is to filter, cluster, and surface the pieces that may change a trader's attention.

An AI layer can process more context than a human wants to manually scan, but it still needs rules, constraints, and provenance. Otherwise it becomes a confident narrator over noise.

Then came news and earnings.

External data added more context, but also more responsibility. News can be stale. Earnings can be scheduled, revised, interpreted badly, or over-weighted. The agent has to bring those signals into the answer without pretending they are the whole answer.

The process kept expanding because the product expectation kept moving from "answer questions" toward "help me operate."

That is the real lesson from Talon.

A chatbot is an interface. An agent is an operating layer.

The interface is what the user sees: a text box, a response, maybe suggested prompts. The operating layer is everything behind it: retrieval, tools, cache, market data, source boundaries, stale-data handling, user experience, and the discipline to say when evidence is missing.

The first version of Talon helped users understand the product.

The later versions had to help users understand the moment.

Those are not the same job.

Pre-launch, the work becomes deciding what Talon is allowed to do, what it is only allowed to explain, and where the human remains responsible. Post-launch, the work becomes watching real users ask questions that do not match the neat categories from the build plan.

User feedback will matter, but not because every request should become a feature. Users will ask for predictions, shortcuts, alerts, certainty, and magic. Their requests are signal, but the product team has to translate those requests into needs: clarity, context, confidence, speed, and trust.

That distinction matters.

A user may request a stronger answer. What they need may be a clearer boundary.

A user may request more data. What they need may be better filtering.

A user may request a trade call. What they need may be a grounded read of the conditions that matter.

Talon became interesting when it stopped being a chatbot bolted onto a knowledge base and started becoming a trading agent with operating context. The product challenge is making that power useful without letting the interface overpromise.

The next serious AI products will not be judged by whether they can answer questions. They will be judged by whether they can carry context, use tools, expose their evidence, and know when not to act.

That is the work Talon forced into the open.

Read the rest of the Talon series.