🤖 An operational entity, not a chatbot
Jarvis—Tony Stark’s assistant—isn’t a chat box: it’s a entity that operates with purpose. It understands the home, controls systems, anticipates needs, and takes action. We use this image throughout the course because it replaces a small question (“what message does the bot respond to?”) with a big one (“what entity do I need to build to operate this problem?”). Operating is different from responding: responding returns text; operating resolves the situation.
🎭 The system as a character
Thinking of the system as a character with a name, role, and way of acting isn't fluff: it's a design trick. When you can describe Jarvis as "someone"—the attendant who never sleeps, the salesperson who knows the whole catalog—it becomes obvious what it should know, be allowed to do, and never do. The metaphor becomes a checklist.
✓ An operational entity
- ✓Has a purpose and knows who it works for
- ✓Receives input through multiple channels and acts in the real world
- ✓Remembers context and follows rules
- ✓Deliver results, not just conversation
✗ A standalone chatbot
- ✗Waits for a message and returns text
- ✗One door, with no action in the world
- ✗Forgets everything with each conversation
- ✗Stopped responding? The "value" is gone
💜 The soul — who it is and who it works for
A soul is the core of Jarvis’s identity: who it is, why it exists, what problem it solves, who it works for, what it can do, and what it must never do. Without a soul, the system is a pile of disconnected tools that no one knows how to use properly. With a soul, every part has direction — each channel, agent, and tool serves the same identity.
The outline of its essence, one line each
Illustrative recreation of the “soul”—each line becomes a design decision. Expanded on Module 2.1.
💡 Practical tip
Write the soul before before choosing any tool. If you can’t say in one sentence what Jarvis exists for and who it works for, any tool you add will be a guess. The soul is the first thing to write and the last thing to change.
🧩 The layers — channels, services, agents, skills
Jarvis’s anatomy has layers, and each one has a unique responsibility. Channels are the entry and exit points (WhatsApp, website, email). Services are blocks of capability (support, sell, schedule). Agents are the workers that execute each block. Skills are what each agent knows how to do. Knowing the layers gives you the vocabulary to design any solution without making a mess.
The entry points: WhatsApp, website, email, internal dashboard. Where the problem comes in and the solution goes out.
Capability blocks: "customer service," "sales," "scheduling." Each block groups one part of the work.
The workers who carry out each service—each with a clear focus, without mixing everything into one.
What each agent can do: check inventory, draft a reply, calculate shipping, schedule a meeting.
🛡️ Limits and security — protective walls
Jarvis has guardrails: rules, permissions, action limits, and validations that prevent the system from doing the wrong things. When AI only talks, a mistake costs you a bad sentence. When AI executes real tasks — sends the customer a message, creates an order, moves money—mistakes are costly. That’s why security stops being a technical detail and becomes part of the architecture, designed from the start.
✓ With well-placed guardrails
- ✓Only does what it is authorized to do
- ✓Asks for confirmation for sensitive actions
- ✓Validates data before acting
- ✓Errors become warnings, not damage
✗ No limits
- ✗Does whatever seems right
- ✗Acts on its own when it should ask
- ✗Trusts incorrect data and spreads the error
- ✗One slip-up becomes a customer problem
💡 Practical tip
The "nao_pode_fazer" line in the soul is the first wall. Before giving Jarvis a powerful tool (sending email, placing an order), ask: "if it gets this wrong, what’s the damage?" If the damage would be serious, put human confirmation in the process. Safety is decided in the design, not patched in later.
🔧 Tools — Take Action in the World
Tools are the resources Jarvis uses to act: spreadsheets, CRM, databases, calendars, messaging, APIs, payments. They’re the system’s hands. But there’s a golden rule that separates the architect from the enthusiast: the tool never comes before the intent — it serves a result. Reversing that creates the classic “solution in search of a problem”: lots of impressive integrations, no results.
Spreadsheets / data
Consult and record structured information.
CRM
View the customer's history and update the record.
Calendar
Schedule, reschedule, and confirm appointments.
Messaging
Send and receive messages via WhatsApp, email, or chat.
APIs
Talk to any external system.
Payments
Generate a charge and confirm receipt.
🧭 The right order
First, the intent ("close more sales on WhatsApp"), then what needs to be done ("answer questions, check inventory, create an order"), and only then the tool that does it. If you start with the tool, you end up with a system full of capabilities nobody asked for—and without the one that would solve the problem.
🧠 Memory and evolution — remembering and improving
Jarvis remembers context and gets better over time: it stores the customer’s history, learns from feedback, and adjusts as it receives new data. Without memory, it asks the same question every time and never gets beyond being a beginner. Without evolution, the solution freezes on the day it was delivered. With both, Jarvis becomes an asset that improves on its own — the more you use it, the better it gets.
Remembers the context
Knows who the customer is, what's already been discussed, and where the task stopped—it doesn't start from scratch.
Learns from feedback
Adjusts responses and rules as the team points out successes and mistakes.
Evolves as an asset
Becomes a business asset: the more it runs, the more refined and valuable it gets over time.
💡 Practical tip
Decide from the start what’s worth remembering — the customer’s order history, preferences, frequently asked questions. Too much memory creates clutter; too little turns Jarvis into an amnesiac service rep. Treat improvement as a routine: revisit what it got wrong and make adjustments instead of waiting for the solution to “be finished.”
🎯 Intent at the core — the center of everything
Above all, Jarvis has an intent — the destination that guides every decision, channel, agent, and tool. It’s at the heart of the metaphor and the reason the course is called Arquitetura de Intenção. Without a destination, any automation seems good and any response seems sufficient. With intent at the center, every choice has a criterion: “does this bring us closer to the destination?” Intent is the compass that keeps the system coherent as it grows.
Everything flows from the intention
The destination: "reduce customer response time to minutes."
Channels, services, and agents are chosen to serve that destination—and nothing more.
Each tool is included because it helps reach the destination; each boundary exists to protect it.
In the end, measure against the intent: did response time go down? If not, adjust.
🧲 The compass that keeps everything consistent
When the system grows, intention is what prevents chaos. Whenever you’re tempted to add an agent, channel, or tool, there’s only one question: “does this serve the destination?” If yes, include it. If no, leave it out—no matter how cool it seems. That’s how the Jarvis metaphor becomes a method.
Self-check (optional): in the Jarvis metaphor, what stays at the core and guides everything else?
🎯 Module summary
Next module:
1.3 — Infrastructure: folders, terminal, and version control. Time to build the foundation where Jarvis will live.