S01E09: The Pattern Behind Every Jarvis Command

Ready to transform artificial intelligence from a buzzword into your personal revenue generator

HubSpot’s groundbreaking guide "200+ AI-Powered Income Ideas" is your gateway to financial innovation in the digital age.

Inside you'll discover:

Download your guide today and unlock a future where artificial intelligence powers your success. Your next income stream is waiting.

Get Your Guide

There are 42 tools inside Jarvis.

They handle email triage, MEDDPICC scoring, LinkedIn post generation, stock analysis, contact enrichment, deal coaching, and 36 other things.

Every single one follows the same pattern.

Once I understood that pattern, building new tools stopped being hard. Adding a capability became a 15-minute task instead of a multi-day project.

This issue breaks down that pattern.

Most people use AI as a chatbot. That’s not a criticism. Its facts.

You type a question. You get an answer. You copy the answer somewhere useful. Repeat.

That works fine for one-off tasks. It doesn’t work for a system.

Here’s the difference.

A chatbot gives you text. You decide what to do with it. Every time.

A system executes a defined action. The result goes somewhere specific. The next step is automatic.

When I ask Jarvis to triage my inbox, I don’t want a paragraph describing what I should do. I want my emails categorized, stored, and the top five sent to me with proposed actions. No copy-pasting. No deciding. Done.

That requires tools, not prompting.

A tool is not a piece of software. In this context, a tool is a definition.

It is a structured object with three pieces:

Name. A short identifier. "email_triage" or "score_deal" or "generate_hooks."

Description. A plain-English explanation of what it does. This is what Claude reads to decide whether to call this tool.

Input schema. The parameters it needs to do its job. For email triage: none, it just runs. For deal scoring: the deal name. For generating hooks: the topic and platform.

That is the entire definition of a tool.

You put all your tools in a list. You pass that list to Claude along with the user's message. Claude reads the message, reads the tool descriptions, and decides which tool to call. It also decides what inputs to pass.

Then your code executes the function and returns the result.

This sounds fragile. It is not.

Claude is very good at reading intent from natural language and matching it to a well-described tool. The descriptions do the work.

If someone types "what's my pipeline looking like," Claude matches that to the "get_pipeline_summary" tool. If someone types "score the Apex deal," Claude matches it to "score_deal" with the input set to "Apex."

The better the description, the more reliably Claude picks the right tool. Writing a clear description is the most important part of building a new tool.

And here is the thing about descriptions: if you can explain to a colleague what the function does in one sentence, you can write the description. No technical skill required.

This is the part that changes how you think about it.

In a traditional chatbot interaction, every new capability requires a new prompt. You build a library of prompts. Every prompt is a separate thing. None of them connect.

With the tool pattern, every new capability is additive.

You write the function.
You add the tool definition to the list.
You add one case to the routing switch.
Done.

The rest of the system stays the same. Claude still reads the same list. The Telegram bot still works the same way. The routing logic still works the same way.

Everything is backwards-compatible because the pattern never changes. Only the list grows.

That is how you go from 1 tool to 42 without rewriting anything. You just keep adding entries.

To implement this pattern, you need three pieces. Only three.

A tool registry. A list of tool definitions (name, description, input schema). This is where you declare every capability.

A Claude call. You send Claude the user's message plus the tool registry. Claude responds with either a tool call or a direct text reply. If it picks a tool, it tells you which one and what inputs to use.

A routing switch. A function that receives the tool name and inputs, and calls the right function. One case per tool.

That is the architecture. Three pieces.

Add a tool: write the function, add the definition to the registry, add the case to the switch. Same three steps every time.

A practical example without diving into code.

Say you want to add a tool that looks up who your last email from a specific person was and summarizes it.

Step 1: You write the function. It calls the Gmail API, finds the thread, and returns a summary.

Step 2: You add the tool definition. Name: "get_email_history." Description: "Retrieves and summarizes the most recent email thread with a specific contact." Input: the contact's name or email address.

Step 3: You add the case to the routing switch. When the tool name is "get_email_history," call your function with the input.

Now when you type "what was the last thing Sarah from Apex said to me," Claude identifies this as a get_email_history call, passes "Sarah from Apex" as the input, your function runs, and the summary comes back in your Telegram chat.

The existing 41 tools were completely untouched.

Not with 42 tools. Not with 10.

Start with one.

Pick the manual task that costs you the most time today. The one you do every day and hate doing. For me it was email triage. For someone else it might be deal status updates or prospect research.

Build that tool. Use it for two weeks. Then add the second one.

The pattern is simple once you have done it once. The first tool teaches you the architecture. The second one takes half the time. By the fifth, it is automatic.

The mistake I see people make: they try to plan the full system before building anything. They want to know how all 42 tools will fit together before writing the first one. That is backwards.

Write one function. Make one tool work. Then figure out what to build next.

Paid subscribers get the implementation below. The actual code structure with annotations, plus five starter tool templates you can copy and adapt.

Talk next week.

Quickstart for paid subscribers | sellingwithai.vip