Imagine this. You send a quick message, maybe on Telegram, maybe Slack, and just seconds later, you get back a really detailed professional technical stock analysis. Yeah, like full breakdown, mass CD, support, resistance lines, even the actual chart image right there on your phone. Exactly. It sounds like something you'd need, I don't know, expensive financial software for. Right. But here's the kicker. This whole thing, this advanced agent system, it was built in just a
few hours. And get this completely no code. Wow. Yeah, it's not just some simple chatbot fetching a price. It's a proper AI agent. It's even running a pretty sophisticated dual model strategy. Welcome to the deep dive. So today we're going to open up the hood on that exact system, the personal AI stock analyst. Our mission really is to get our heads around the architecture. This two part. two AI models set up that makes it all tick.
Yeah, we'll map out what it can actually do, you know, memory comparisons, that kind of stuff. Then we'll really dig into that core idea, the brain versus the specialist separation. And crucially, you'll see why they picked two totally different AI models. You know, one that's great for reasoning, the thinking part, and another one completely separate that's amazing at visual stuff, like reading those charts. All right, let's dive in.
Let's do it. okay so let's unpack what this system actually does day to day it seems to handle three main things that make it feel like a proper agent not just you know a simple script right the first one's pretty straightforward single stock analysis you feed it a ticker symbol like uh NASDAQ .UXU or whatever. Exactly. And you get back a full professional style report. Trend health, key price levels, mass D analysis, volume. Yeah. The whole nine yards. That's kind of the baseline.
Yeah. Yeah. But the second function, comparative analysis, that's where this split architecture really starts to shine, I think. How so? Well, you can ask it to compare two stocks, say Alphabet versus Microsoft. Yeah. Like in the example, it doesn't just give you two separate reports. It runs the entire technical breakdown for both, generates the charts for each one, and then, this is the cool part, it performs this higher level reasoning to give you a final summary comparing
them side by side. Ah, so it synthesizes the information. It doesn't just fetch it. Precisely. And that leads to the third really key function, smart memory. Right. The conversational aspect. Yeah. So if you just ask for that alphabet analysis, you can immediately follow up with something simple like, OK, now compare that to Microsoft. And it knows what that. refers to. Exactly. It remembers the last, say, five messages in the conversation. So you don't have to repeat the
ticker. You don't waste time or API credits reanalyzing the first doc. It just picks up where you left off. That makes sense. And I guess that complexity needing memory, needing to synthesize comparisons, that's what drives this dual architecture idea. You got it. Separating the manager from the doer. So part one is the AI agent brain. Think of it like the CEO. This is the main workflow. probably
built in something like NADN. It handles the chat, keeps track of the conversation history, that memory decides when it needs help from a specialist, and then takes the specialist output and formats the nice final report for you. And part two is? Part two, the technical analysis tool. The specialist. This is a totally separate, smaller workflow. A sub -workflow. Okay, a sub
-workflow. Let's define that quickly. Sure. A sub workflow is basically like a dedicated mini program the main system can call up whenever it needs a specific task done. Like calling a consultant for a specific job. Exactly like that. This specialist one, it does one thing. Perfectly. Takes a stock ticker, calls an outside service and API to generate the chart image, and then does the raw technical analysis on that chart.
OK, but I have to ask, doesn't splitting it into a CEO and a specialist make things more complex, like harder to build and manage, especially in a no code setup? Why not just cram it all into one big workflow? That's a great question. It seems counterintuitive, right? But actually, it makes things way less complex in the long run. Really? By separating them. The main CEO system stays really clean and focused just on managing the conversation and logic. It's modular.
So let's say tomorrow you want to add a tool that analyzes, I don't know, options data. You just build a new separate specialist sub -workflow for options, tell the CEO about it, and plug it in. The core brain doesn't get cluttered. It makes the whole system much easier to manage and scale up with new tools later. Ah, I see. So that separation actually promotes clarity and makes it easier to add more capabilities down the road. Precisely. Scalable clarity. That's
the goal. Okay, so we've got the CEO of the brain. Now, which AI model do you actually pick for that role? It used to be, you know, you'd just go with the biggest name or whatever was hyped that week. Right, whatever was trending on Twitter. Exactly. Yeah. But for something like financial analysis, you need proof it actually performs under pressure. The source material mentions this platform, mouse1 .ai, that runs something called the Alpha Arena. The Alpha Arena. What
is that exactly? Sounds intense. It kind of is. It's basically this live high stakes competition for different AI models. They compete in this real time streaming environment designed to simulate, you know, dynamic market conditions. So it tests how well they reason and how reliable they are when things are constantly changing, like in actual trading. You got it. It's about battle -tested performance, not just benchmark scores
or, you know, how fast it spits out tokens. Okay, so based on that kind of testing, which model did they choose for the brain? The data apparently pointed towards using DeepSeq v3 .1 chat. That became the core reasoning engine, the CEO brain. DeepSeq. Okay. And how do you actually connect to it? They used OpenRouter. Right, OpenRouter. Let's quickly define that too. Yeah, simple one. OpenRouter is just an aggregator that lets you access lots of different AI models using just
one API key. Super flexible. Gives you options if you want to swap models later. Exactly. Now, critical for this brain, remember that smart memory we talked about? Yeah, remembering the last five messages. Right. The absolute crucial setup step there, and this is the bit people apparently mess up all the time, is you must tie that memory to the specific chat ID coming from the Telegram trigger. Ah, okay. So the memory is unique to each user conversation. What happens
if you forget that link? What's the failure mode? Oh, it's instant chaos. Utter chaos. Imagine you're asking about Apple, right? And someone else in a totally separate chat just asked about Tesla. Uh -oh. Yeah. Suddenly you might start getting the Tesla analysis popping up in your Apple chat. The conversation memory gets completely crossed. It just obliterates the user experience. You have to link it to that unique chat ID. Got it. Okay. So you've picked the model based on
performance. You've set up the memory correctly. Right. What's next? Defining what the agent should actually do. Exactly. You need to give it its job description, its personality, its rules, and that's done via the system prompt. The prompt. Okay. And the sources mention this needs to be really structured, not just a paragraph of text. Absolutely. That structure is like your defense against prompt drift, where the AI starts forgetting its instructions over time or gets sidetracked.
Makes sense. So what's the structure look like? It starts with an overview, basically telling the AI who it is, like you are an expert technical stock analyst. Then comes context listing the tools it has access to. like our chart specialist, and maybe what data sources it can use. After that, step -by -step instructions on how to handle requests. Okay, overview, context, instructions, what else? Then, importantly, detailed tool descriptions. So, explicitly naming the get chart tool and
maybe explaining what it does. And finally, SOPs as standard operating procedures. This is where you repeat the absolute most critical rules, like the big one. Do not give explicit financial advice. You hammer that home. That structured approach seems vital. Oh, it is, honestly. I still wrestle with prompt drift myself sometimes. Keeping things tightly structured like this, especially with those SOPs, is pretty essential for keeping the agent reliable and focused query
after query. So let's connect that back. If we're building this scalable no -code system, Why is going through the trouble of using something like the Alpha Arena to pick maybe a less common model like DeepSeek V3 .1 so important? Why not just default to, say, GPT -4 or Claude, which everyone knows? Yeah, good question. It comes back to that performance under pressure idea. The Alpha Arena helps select the model that's proven to be most reliable and accurate specifically
for this kind of dynamic reasoning task. In finance, you know, that reliability, that accuracy when things get volatile, that trumps familiarity every single time. You want the best cool for that specific brain function. OK, so the CEO brain running on DeepSeek decides it needs a chart and some analysis for, say, Apple. How does it actually hand off that specific task to the specialist tool, that sub workflow? Right. So the brain basically calls the specialist.
tool using its unique url that call triggers the sub workflow to start running like dialing its direct number kind of yeah and the absolute key detail here for setup is the naming the name you give the sub workflow in your no code tool Let's say you call it get chart. That name has to exactly match the tool name you defined back in the brain system prompt. Exactly match, like capitalization and everything. Everything. Case
sensitive, spaces, underscores, whatever. If it's off by even one character, the brain basically says, I don't know what tool you're talking about. And the whole process breaks down. Connection failed. Okay, meticulous naming is critical. So the specialist gets the call. Its first job is getting the actual chart image, right? It uses that free service chart IMG ATI. Yep, that's the one. And the sources pointed out a really neat efficiency trick here for setting up that
API call in NANN. Ah, yeah, they called it the pro gamer move using the CRL import method. Uh -huh, yeah, that's the one. And it's genuinely a massive time saver. So what does that trick actually do for the person? Building this. How does it simplify things? Well, instead of manually setting up every single parameter for the API call, you know, the headers, the request body, the authentication method, which can be super tedious and error prone. Right. Fiddling with
JSON and stuff. Exactly. You just find the example CRL command in the chart IMG API documentation. It's usually just a snippet of text. You copy it and you paste it into this specific import function in the NNN HTTP request node. And then? Bam. And it automatically configures the entire node for you. So that's all the headers, parameters, everything based on that URL command. It literally turns what could be hours of debugging into like 10 seconds of copy paste. Wow. Okay. That is
a huge shortcut. So when configuring that API request to chart IMG, what are the key settings? Two main things mentioned. First, using storage in the API's URL path. That tells Chart .img to generate the chart and give you back a public URL link to the image file, which is what we need. Okay, so you get a link to the picture. Yep. And second, you need to dynamically insert the stock ticker the user actually asked for. Use an N8N expression for that, something like
trainison .query. That pulls the ticker, say NASDAQ key geog, from the data the brain sent over and sticks it into the API call. Got it. So the chart gets generated. We get a URL back. What's step three? Step three is actually downloading that image. You need the image file, not just the link, to feed to the Vision AI later. So that requires a second HTTP request node. Another API call. Yeah, this one just takes the URL from
step two and fetches the actual image data. And the crucial setting here is you have to set the response format to binary. Binary. Okay, what exactly is binary data here? Think of binary data as the raw file format for the image itself, the actual pixels and colors that an AI vision model can understand. Not text. Right. If you forget to set it to binary, the node just downloads the image link as text, and when you pass that text to the vision AI, well, it can't see text.
It needs the picture. Analysis fails instantly. Okay, binary format is key for the image download. And that brings us to step four, the actual specialized analysis using AI vision. And this is where that dual AI strategy really comes into play, right? Exactly. Because even though our brain is deep seek, for this specific task, analyzing the visual chart, we switch models, we use GPT -4O. Ah, interesting. Why the switch? Because, well...
Currently, GPT -4 is generally considered the best model out there, specifically for visual analysis, for understanding images. So you're using the best tool for each distinct job, DeepSeq for reasoning and managing, GPT -4 for seeing.
Precisely. We're essentially paying a bit more maybe for that specific vision step, but we're outsourcing that really critical high -value task, interpreting the candlestick patterns, the Mali lines, the volume bars visually to the absolute best specialist model available for that job. That makes a lot of sense. Pick the expert for the specific task. It really demonstrates
the power of this modular approach. Whoa. Just imagine scaling this kind of architecture, like across a huge company, using the absolute best AI model for every single tiny step in a really complex business workflow. That feels like the future of building AI agents, doesn't it? It really does. So when you feed that downloaded chart image to GPT -40, what do you ask it to look for? The prompt must be pretty specific. Oh, yeah. Super specific. You don't just say
analyze this chart. You instruct it to perform distinct types of analysis. Yeah. Detailed candlestick pattern analysis, MCG analysis, like is it crossing over? Volume analysis, are there spikes? And crucially, to identify and map the key support and resistance levels directly onto what's understanding the chart. So you're forcing it to act like a real technical analyst, looking for those specific indicators, not just describing the picture. Exactly. You want a professional readout, actionable
insights derived from the visual data. So drilling down on that, what is the biggest advantage then of using an AI vision model to look at the chart image compared to just feeding a regular text -based AI model the raw price and volume data in tables? Great question. It's about pattern recognition, really. The vision model can instantly see complex visual patterns like a bullish engulfing candlestick pattern or the specific shape of a Mackie divergence or a sudden volume spike
coinciding with a price move. It can recognize these holistic visual signals. much faster and often more reliably than a text model trying to infer those same patterns just from raw numbers in a table. It literally sees the picture the way a human analyst would. So we put it all together. User sends a message on Telegram. The brain, deep -seek, figures out what's needed, maybe calls a specialist sub -workflow. The specialist, using chart IMG API, generates the chart image
URL, then downloads the binary image data. Right. Then that image is sent to the vision AI, GPT -4, with specific analysis instructions. GPT -4 sends back the detailed text analysis. Which goes back to the specialist, then back up to the brain. The brain takes that analysis, maybe combines it with conversation history or other analysis if it was a comparison request. And finally formats it all into a nice message and sends it back to the user on Telegram. Exactly.
And the amazing thing is that whole round trip. Apparently it takes only about 10 to 20 seconds. Wow, that's remarkably fast for that much processing and multiple AI calls. It really is. And that architecture really proves its worth with that multi -stock comparison feature we talked about earlier. Right, comparing Alphabet and Microsoft. Yeah. The brain is smart enough to recognize this needs two separate analyses. So it calls a socialist tool twice, once for each stock.
Gets back two sets of chart analysis texts from GPT -4. And then... The brain performs that high -level reasoning itself using DeepSeq to synthesize those two reports into that final comparative summary for the user. It's a real orchestration feat, managing that flow. Definitely sounds like it. Now, are there any limitations or things to watch out for with this specific build? Yeah, a couple of key ones mentioned. First, that free chart IMG API they used. It's limited. It only
works for NASDAQ -listed securities. Ah, okay. So if you ask for a stock on the London Stock Exchange or something. The sub -workflow will probably just fail, hopefully gracefully, but you won't get a chart or analysis back. That's a limitation of that specific free tool. Good to know. What about common mistakes people make when trying to build something like this? Two big ones were highlighted. And they're easy traps to fall into. First, we mentioned it, but it's
worth repeating. The tool name. The name you give your specialist workflow, like GetChart in your no -code platform, must perfectly, exactly match the tool name you wrote in the brain system prompt. Case -sensitive spaces, the whole deal. Got it. Get it wrong, and the brain can't call the specialist dead end. Nah. The second big one, and we also touched on this, is ensuring
the chat ID variable. From Telegram. Yes, making absolute sure it's correctly mapped not just to the memory node, but also to all the Telegram send nodes that reply back to the user. Why all the send nodes too? Because if you only link it to memory, but not the reply node, the agent might remember the right conversation, but it could still accidentally send the reply to the wrong user's chat window. You need that chat ID guiding both memory and replies to keep everything
strictly tied to the right conversation. Missing that is how you get those frustrating crossed messages. Okay, so map the chat ID everywhere it relates to a specific user interaction, memory, and sending messages back. Bingo. Nail those two things, exact tool names and consistent chat ID mapping, and you avoid probably... 80 % of the common frustrations. And all this efficiency, this complex orchestration, it really brings us back to the power of no -code advantage, doesn't
it? Absolutely. I mean, think about it. This system connects multiple different APIs, manages conversational state with memory, strategically swaps between different best -in -class AI models for different tasks. And delivers results in
seconds. Yeah. And it was all built. Visually, in maybe a few hours, on a platform like NAN, a traditional software developer trying to code this from scratch, setting up the servers, the API integrations, the state management, the model switching logic, that could easily be a multi -week, maybe even multi -month project. It really lowers the barrier to creating sophisticated AI tools. Fundamentally. It democratizes the ability to build these complex, specialized AI
agents. That's the real power here. Hashtag, hashtag, hashtag outro. So reflecting on this whole project, it feels like it demonstrates three really critical ideas for building advanced AI systems now. First, that separation of concerns. Using that brain specialist architecture, the CEO and the expert consultant model, it just makes systems cleaner, more modular and much easier to scale later on. Yeah, definitely. Second
big takeaway, AI vision is a game changer. The ability for AI to actually analyze images like these stock charts unlocks totally new possibilities. It lets the agent see the market in a way text alone can't capture. It moves beyond just processing numbers. And third, it highlights that tools make the agent. An AI agent isn't just defined by its conversational ability anymore. It's defined by the specialized tools it can connect to and use effectively to perform complex multi -step
actions out in the world. That's so true. And, you know, this specific brain plus specialist. tool architecture. It's not just for stocks. You can adapt this exact model for countless other specialized uses. Like what? Oh, I don't know. Maybe a financial advisor tool that pulls specific compliance documents or a trading education bot that can analyze user submitted practice trades or even hyper -focused content creation tools for any niche industry where you have specialized
data sources or analysis steps. The pattern is reusable. That's a really powerful idea. So maybe the final thought for everyone listening is this. If you can build an expert technical stock analyst with no code. What other specialized tools, unique data sources, or expert processes exist in your field? Yeah, what could you connect an AI agent
brain to? Because the future here seems to be less about just building a better chatbot and more about building better connections, orchestrating these specialized tools to achieve complex, valuable tasks. It's about connection and action, not just conversation.