🗺️ From Problem to Design
You arrived here with two things in hand: a chosen problem (Module 3.2) and a clear intent (Module 3.1). Designing the architecture means translating this into a concrete path: who talks to the system, what it does with that, and what it returns. The diagram is the bridge between "I want to solve this" and "I built this" — and designing it first avoids having to redo it later.
🧭 Architecture is just a flowchart
Don’t be intimidated by the word "architecture." Here, it doesn’t mean code or an engineer’s diagram: it’s a simple outline of the path the intention follows. It enters somewhere, passes through a few hands, uses a few tools, follows a few rules, and comes out as a result. Drawing this path is the work of this module.
Understand the problem and intent
The starting point is always the pain point you chose and the result you want—not the latest trendy tool.
Maps the path
Where it comes in, where it goes, what it uses, what it returns—in boxes and arrows, on paper or on screen.
Becomes a blueprint
The finalized design guides the Module 3.4 prototype—building becomes execution, not improvisation.
🚪 Channels and routing
Every solution needs a entry point — the channel through which the intent arrives (WhatsApp, website, email, form). But the channel alone isn’t enough: the system needs routing — know where to send a message inside the system—to which service or agent. The right channel plus the right routing makes the solution feel seamless; the wrong one blocks everything at the door.
🔀 Channel × routing, side by side
- Channel: where the intent comes in and where the response goes out (the door visible to the user).
- Routing: the internal decision of "which part of the system is this message for?" — invisible to the user.
- Together: the user speaks in one place, and each request reaches the right person without them noticing the machinery.
✓ Well-designed routing
- ✓Each type of request has a clear destination.
- ✓There’s a path for “I didn’t understand” (fallback).
- ✓The user speaks through a single channel, and everything flows.
- ✓You can add a new destination without breaking anything.
✗ No thoughtful routing
- ✗Everything ends up in the same place and gets mixed together.
- ✗Unexpected requests fail without a response.
- ✗Each new channel becomes a separate hack.
- ✗No one knows where the message has been.
💡 Practical tip
Start with ONE channel—the one your audience already uses. WhatsApp for customer service, a website form for lead capture, email for internal use. One well-routed channel is worth more than five messy ones. Add the others after the first one works.
🧱 Solution services and agents
Inside the system, the work is done by two types of components you already learned about on Day 2: services (capability blocks — retrieve a piece of data, generate text, record something) and agents (workers with a mission who make decisions and use services and tools). Designing the architecture means deciding which pieces your solution needs and how they divide the work.
💡 Practical tip
Golden rule: each component does ONE thing well. If you’re describing an agent and use the word “and” many times (“it handles e charges e schedule e reports"), they’re probably several agents disguised as one. Separating them makes each piece easier to test and evolve.
🔧 Required Tools
To act in the real world, the solution needs tools: the spreadsheet where you look up a price, the CRM where you record a customer, the calendar where you schedule a meeting, the API that sends a message. The golden rule from Day 2 still applies: the tool serves the intent, never the other way around. List only what the workflow actually needs—and nothing else.
Spreadsheet / database
Where the solution reads and writes data.
CRM
Where the customers and history are stored.
Calendar
To schedule, remind, and organize time.
Messaging
To send and receive messages through the channels.
External APIs
Other systems the solution queries.
Files / docs
The knowledge base it consults.
🧰 The minimum necessary test
For each tool you’re thinking of including, ask: "without it, does the workflow still deliver the result?". If so, leave it out of the prototype—it can come later if needed. A lean solution is built, runs, and shows value faster. One more tool is extra weight you don’t need to carry.
🛡️ Flow rules and security
When AI starts acting in the real world—sending messages, changing data, scheduling things—the security becomes part of the architecture, not a detail to deal with later. The guardrails you saw in Module 2.6 are part of the design: what the solution can do on its own, what it needs to validate, and what always requires a human to approve before it happens.
Without limits, one wrong action can cause real and costly damage.
Without checking the input, the system acts on incorrect data.
Risky actions (deleting, charging, sending to a customer) require a human “OK.”
✅ The wall in the right place
Not everything needs a wall. The key is to put the barrier where the risk is high: reading data can be unrestricted; delete, charge, or message a customer asks for validation or approval. Mark each point in your blueprint with a lock where an action can only happen after it has been checked.
📐 The Solution Blueprint
Now bring everything together in a single diagram: intent, channels, routing, services, agents, tools, and rules. This is the blueprint — the blueprint for your solution. It brings together everything you saw on Day 1 (terrain and channels) and Day 2 (soul, services, agents, tools, security), applied to YOUR problem. With the blueprint in hand, building the prototype becomes execution, not improvisation.
The blueprint, in structured text
Fill in one row at a time. Once you've answered them all, you'll have the solution blueprint—ready for the Module 3.4 prototype.
Starts with the intention and the result
The two ends of the diagram: where it starts (the pain point) and where it ends (the measured gain).
Connects the intake channel
Where the intent comes in and how routing sends it to the right component.
Connect services, agents, and tools
Who does the work along the way and what each person uses to act.
Mark the walls
Where validation and human approval fit—the risk points in the workflow.
💡 Practical tip
A good blueprint fits on one page, and anyone at the company can follow the path with their finger. If your design is too complex to explain in two minutes, it’s probably trying to solve more than one problem. Go back and narrow it down — focusing on ONE problem is what brings the solution to life.
Self-check (optional): what is the solution blueprint in the JARVIS method?
🗺️ Module summary
Next module:
3.4 — Functional Prototype: move from the blueprint to building something that truly works.