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.