You know that feeling? It's visceral. You've
just finished a sales call and it wasn't just
good, it was a killer call. The chemistry was
electric. You could actually see the prospect's
pupils dilate when you mentioned the ROI. You
hang up and you are buzzing with adrenaline and
then... Silence. The crash. The crash. You open
your laptop, you click on PowerPoint, and there
it is. That white rectangle. The blinking cursor.
Yeah. The blank page. And suddenly that adrenaline
turns into absolute dread because you realize
you have to spend the next three hours remembering
exactly what you said, organizing it, and making
it look pretty. It's the worst feeling in sales.
Honestly, it's a precise moment where the job
shifts from solving problems to moving pixels
around. Right. And that's where most deals die.
They just lose momentum because the follow -up
takes way too long. Well, today we are declaring
the death of the blank page. We're doing a deep
dive into a specific architecture detailed by
Max Ann that claims to build a 2026 AI system.
Yeah. And the promise here is bold. A system
that listens to your meeting and delivers a 90
% finished slide deck to your inbox three minutes
after you hang up. And just to be clear for everyone
listening, this isn't some vague, you know, use
chat GPT to summarize notes advice. We are getting
under the hood of a fully automated architecture
using NAN, Fireflies, and Gamma. It's about building
a machine that does the grunt work so you can
stay in that deal closing mindset. So let's map
this out. We're going to break this architecture.
down into the technical specifics. We'll look
at the ears of the operation, how to capture
data without losing nuance. Right. We'll talk
about the brain, specifically a very clever AI
persona designed to write persuasive copy, not
just summaries. The most important part. And
finally, the hands that actually build the slides.
But first, the philosophy. The source material
makes a really big point about splitting this
into two workflows. Why? Why not just one straight
line from audio to slides? This is the classic
newbie automation mistake. You try to build one
giant Rube Goldberg machine where one trigger
does everything. Right. The source argues for
a modular approach. You have Workflow 1, which
is the logger. Its only job is to listen, clean
the data, and store it. Then you have Workflow
2, the generator. which creates the outline.
It uses that analogy of Lego blocks versus carving
a sculpture. Exactly. If you carve a statue out
of marble and you make a mistake or you decide
later you want to change the arm, you have to
start over. You've ruined the whole stone. Yeah.
If you build with Legos, you just swap a block.
By separating the logging from the generating,
you create scalability. Today, you might want
a sales proposal, but tomorrow... Maybe you need
meeting minutes for an internal sync. Or a project
plan or something. Or a project plan for a kickoff.
If you have that foundational logger workflow
running separately, you can plug in different
outcomes without breaking the whole system. So
you're basically building a data reservoir first
before you even decide where the pipes are going
to go. Exactly. You're decoupling the input from
the output. It's a safety net for growing businesses.
So why is this separation specifically so critical
for a business that's scaling up? Because it
lets you add new deliverables like project plans
or summaries without risking the stability of
the core recording process. Let's get into the
weeds because that's where this gets really interesting.
Workflow number one, the ears. This starts with
Fireflies .ai. Now, most people know Fireflies
is that little bot that joins your Zoom calls,
but connecting it to an automation system like
NAN isn't exactly plug and play, is it? No, not
at all. And this is where people get stuck. You
set up a webhook in NAN, which is basically a
digital catcher's mitt, and you tell Fireflies,
hey, throw the ball here when the meeting is
done. You check the box for transcription complete.
Seems simple. It sounds simple. Yeah. But there's
a glitch. A significant one. It's the webhook
response problem. Fireflies is incredibly eager.
It pings your automation the second the audio
file is processed to say, hey, I'm done. But
at that exact second, it sends almost no data.
Just an ID. It's like a waiter running to your
table to tell you your food is ready, but his
hands are empty. So you have the notification,
but not the meal. Precisely. And the problem
is... The AI summaries, the action items, the
gist, the sentiment analysis, those take another
30 to 60 seconds to bake after the audio is processed.
If your automation grabs the data the moment
that webhook fires, you get blank fields. You
get broken automation. So how do we solve this?
The source describes something called a polling
loop. It's a very clever bit of engineering that
mimics human patience. First, you insert a wait
node. You force the system to just pause. Just
breathe for 30 seconds. Okay. Then you make the
request to Fireflies. But, and this is key, you
don't just assume it's ready even then. You use
an IF node. You ask the system, does the summary
actually exist yet? And if it doesn't? The system
loops back. It waits another 30 seconds and it
asks again. It keeps checking until the data
is actually there. So it's essentially just checking
the oven to see if the cake is ready. That's
it. It prevents the system from serving you raw,
unfinished data. It ensures reliability. Why
do we need to build a loop, though, instead of
just waiting, say, five minutes to be safe? Because
speed matters. Yeah. You want the data as soon
as it's ready, not five minutes later. But you
can't grab it before it exists. I love that.
It's a patience mechanism built right into code.
Now, once we have the data, the source mentions
data hygiene. We're not just dumping raw text
into a file. Right. But the source suggests using
Claude the AI model to actually write the code.
Yeah. This is a massive unlock for non -technical
people. The data coming out of Fireflies is in
JSON format. Okay. So. For those who aren't developers,
what exactly is JSON? Think of JSON as a very
specific, very rigid way of organizing data.
It's like a filing cabinet where every folder
has to be labeled exactly right. It can be messy
and really hard to read for humans. You might
need to extract just the list of attendees or
format the date so it doesn't look like computer
gibberish. And usually you'd need to know JavaScript
to clean all that up. Correct. But here... The
hack is that you take that raw, messy JSON, you
paste it into Claude or ChatGPT, and you say,
I am using NA10. Write me a code node in JavaScript
to extract the speaker names from this mess.
And it just does it. It writes the code for you.
You copy it, you paste it into NA10, and it works.
You don't need to learn to code. You just need
to know how to ask for the code. That just lowers
the barrier to entry so significantly. So we
clean the data, and then we log it. The destination
here is a Google Sheet. Why log it to Sheets
if we're just making a slide deck? Why not go
straight to the slide generator? Because you
want a master brain. By logging every single
meeting into a structured spreadsheet date, title,
attendees, gist, meeting ID, you're creating
a historical database. It creates a paper trail.
I see. But more importantly, that new row in
the spreadsheet acts as the trigger for the next
step. it ensures you never lose a meeting's history
even if the slide generation fails for some reason
so what's the primary strategic reason for logging
everything to a spreadsheet first it creates
a master database and acts as a reliable trigger
for any future automation so nothing is lost
okay so we have our logger running every meeting
is being recorded cleaned and neatly filed into
a spreadsheet row now we move to workflow number
two the generator this is where the magic happens
the trigger is that new row in the spreadsheet.
Correct. But here is a nuance. We don't want
to just blast out proposals for every single
meeting. Right. If I have a 15 -minute coffee
chat with a colleague, I don't need a 10 -slide
commercial deck sent to my email. That would
be a little aggressive and a waste of computing
credits. Very. So we introduce a Humean loop.
Yeah. The automation sends the message to Slack.
It says, meeting X just ended. Do you want to
generate a proposal? And it gives you two buttons,
yes or no. I find this so interesting because
usually automation is all about removing friction.
But here we are deliberately inserting friction.
A button you have to click. It's strategic friction.
You want the creation to be automated, but the
intent to be human. If you click no, the system
updates the spreadsheet to say generation declined,
and it stops. But if you click yes, that's when
we wake up the agent. The proposal generator
agent. Now, this isn't just a generic prompt
that says summarize this meeting. The source
material is very specific about the persona we're
assigning to the AI. This is critical. I mean,
prompt engineering is often the difference between
a mediocre output and a really great one. The
prompt here explicitly defines the AI's role.
Expert Senior AI Solutions Consultant for UpIt
AI. UpIt AI being the fictional company in this
example. Right. You'd swap that for your own
company. But the key is the title. Senior Consultant.
It tells the AI to be confident, authoritative,
and strategic. It changes the tone from a junior
note -taker to a senior partner. The constraints
listed in the prompt are interesting, too. It
says do not include internal notes, do not mention
this was AI -generated, and my favorite, make
confident assumptions. Ah, yeah. That confident
assumptions part is scary but necessary. Is it?
I mean, that feels risky. If the AI guesses wrong
on a number, couldn't that blow the deal? It's
a calculated risk. Look, if the client didn't
explicitly say we lose $50 ,000 a year on this
problem, but they hinted at it, you want the
AI to estimate it. Why? Because a proposal with
placeholders like insert number here looks unfinished.
It looks like a template. A proposal that says
estimated annual loss $50 ,000 looks proactive.
It gives the client something to react to. So
it's easier to correct a wrong number than to
fill in a blank one. Exactly. It shifts the conversation.
If the number is wrong. The client corrects you,
and now you have the real number. If you leave
it blank, the client just ignores it. The structure
demanded by the prompt is also very rigid. Nine
specific sections. Executive summary, problem
solution, ROI, roadmap. It forces the AI to speak
the language of business value. It's not just
transcribing, it's translating. It takes, we
hate doing this manual data entry, and turns
it into operational bottleneck, resulting in
15 wasted hours per week. So what is the main
psychological shift we're trying to force the
AI to make with this specific persona? We are
forcing it to be persuasive and client -facing,
moving away from passive description to active
sales. So we have this persuasive text generated.
Now we need to get it into a slide deck. And
we're using a tool called Gamma for this. Gamma
is fantastic because it's not just a text -to
-slide tool. It understands design. We use an
HTTP request node, an NAN, to talk to Gamma's
API. This sounds technical. Walk us through what
that actually means. It's a little bit technical,
but totally manageable. You're basically sending
a digital package to Gamma. Inside that package,
you tell it the theme, so it uses your company's
colors and fonts, not some random template. Okay.
You tell it the source for images. We're using
DAO E3 here for unique visuals. And you paste
in that structured text from the AI agent. There's
a specific replace function mentioned in the
source, a bit of code cleanup before sending
to Gamma, something about new lines. Yeah, this
is a classic gotcha in automation. AI models
love to output text with line breaks, tabs, quotation
marks. If you feed that raw text into a JSON
payload for an API, It breaks the code. It confuses
the system because it thinks the code has ended
when it hasn't. So the Cisco just crashes. It
crashes hard. So you use a simple dot replace
function in JavaScript to smooth out those characters.
It's like sanding down the rough edges of a puzzle
piece so it sits into the slot. It replaces actual
line breaks with the symbols for line breaks
so the machine can read it. And the result? The
result is a link. It arrives in your inbox. You
click it and there's a fully built presentation.
Title page with the client's name. An executive
summary. A slide calculating the ROI. A roadmap
slide. Is the output actually ready to send right
that second? It's 90 % there. And that's the
honest truth. You still need to review it. Maybe
the AI estimated the savings a bit too high.
Maybe the tone is slightly too formal. Right.
But you are editing, not creating. Yeah. And
that is a fundamentally different cognitive load.
So ultimately, does this output actually remove
the human from the process? No, it just changes
the human's role from writer to editor, which
is much, much faster. We're going to take a pause
right here. We've built the machine. But when
we come back, we're going to talk about a feature
that I think is the hidden gem of this entire
system, the on -demand trigger. Because what
happens when you accidentally click no, we are
back on the deep dive. We've built the logger.
We've built the generator. We have our Slack
button. But the source material brings up a very
real human problem. What if I click no in Slack?
But then a week later, I changed my mind. Right.
Actually, that guy was interested. I really should
send a proposal. If your system only works in
real time, you're out of luck. The moment has
passed. So we need an on -demand feature, a way
to go back in time. The solution is a manual
trigger, a form submission node in N8n. You go
to your Google Sheet, remember our master database,
dash copy the meeting ID, paste it into a simple
form, and hit go. But here's the engineering
challenge. You now have two different ways to
start the same process. Path A is the automatic
path from the spreadsheet. Path B is the manual
path from the form. How does the AI agent know
which one to listen to? This is where we get
into what the author calls technical magic. It's
all about standardizing inputs. Okay. Imagine
two different roads merging onto a highway. The
AI agent is driving on the highway. It doesn't
care which road the car came from. It just needs
the car. So we need a traffic controller. Exactly.
We use a set node as a middle layer. It sits
between the triggers and the AI. It looks at
path A and path B and says, okay, whoever sent
data, I'm going to map it to this one variable
called JSON .transcript. So whether the transcript
came from the live automation or the manual form,
the AI agent just looks for JSON .transcript.
Right. It decouples the source from the processor.
It's elegant. Because it means you don't have
to duplicate the entire AI workflow for every
different trigger. You just map the inputs to
the same variable names. So why is this specific
set node technique considered technical magic?
It allows you to use the same AI brain for multiple
different triggers without duplicating your work.
Let's zoom out. We've built this system. It works.
What's the actual impact? The source does some
ROI math here. Yeah, the math is compelling.
It assumes you write about two proposals a week.
Manually, that's maybe three hours each. That's
six hours a week. Which is nearly a full workday.
Right. Over a year, if you're doing volume, say,
100 proposals, that's 300 hours. That is seven
and a half work weeks. Wow. Almost two months
of working time. Just spent formatting slides.
Just spent staring at a screen, copy pasting,
adjusting font sizes, aligning boxes. And the
competitor who has this system. they're using
those 300 hours to meet more clients, to refine
their pitch, or just to rest so they're sharper
on the next call. And the finished product isn't
just text. It includes that ROI slide, the roadmap.
It looks professional. It looks like you spent
four hours on it. That perception of effort,
it matters to clients. If you turn around a high
-quality deck in 20 minutes, it signals competence.
It signals that you have your act together. It
strikes me that the real value here isn't just
time. It's cognitive bandwidth. Oh, absolutely.
The blade page syndrome is draining. It causes
procrastination. You put off writing the proposal
because you know it's going to be a slog. With
this system, the friction is almost zero. You
click yes and slack. That's it. It changes your
entire relationship with the work. You know,
we talk a lot about AI replacing jobs, but this
feels different. This feels like AI enabling
relationships. That's the big idea here. AI agents
don't replace the handshake. They don't replace
the strategy. They replace the busy work. They
eliminate the barrier between having a good meeting
and asking for the sale. If you are still formatting
slides for two hours, you are technically doing
the job, but you are falling behind. You're fighting
a war with a musket while the other side has
laser guided missiles. A vivid image. So here
is a final thought to mull over. We've talked
about using this for sales proposals, but what
happens when you turn this lens inward? What
if you use the same logger and generator architecture
for your own internal decision making? How do
you mean? Imagine an AI that listens to your
team's internal debates and automatically generates
a pros and cons document. or a decision memo,
completely free of the bias of whoever usually
takes the notes. That is fascinating. An objective
historian for the company. That could change
how meetings are run entirely. Something to explore.
Thank you for listening to this deep dive. Don't
just read about the Lego blocks. Go build them.
See you in the next deep dive.