How I Built Jarvis: A Personal AI Assistant With Claude Code

I did not write the original code for my personal AI assistant. I described what I wanted, Claude Code built it, and I kept improving the system through conversation.

I call it Jarvis.

Jarvis plans my day around my calendar, tracks projects and tasks, processes my inbox, prepares me for meetings, remembers follow-ups, and runs a weekly review across the parts of my life I care about.

The first version was a handful of Markdown files and two commands. The current version is a proper personal operating system with structured data, generated dashboards, reusable workflows, and tightly controlled access to Gmail, Calendar, and Drive.

That evolution is the useful part of this story. You can start with one text file today. You do not need to predict the final architecture, choose a productivity framework, or learn how to build an app. You need one annoying workflow and a willingness to explain how you want it handled.

What Jarvis Does Today

Jarvis now handles four layers of my personal operating system.

Daily execution

Reads my calendar and existing commitments
Processes quick captures from an inbox file
Picks one to three Most Important Tasks
Builds a realistic plan around available time
Gives me one clear next action when I get stuck
Closes the day by recording progress, blockers, and loose threads

Projects and tasks

Tracks active, on-deck, someday, and completed projects
Forces every active project to have a next action
Flags projects that have gone stale
Links tasks to projects and life areas
Generates readable Markdown dashboards from structured JSON data

Communication and relationships

Triages Gmail into response, review, and archive buckets
Pulls conversation history before helping me reply
Tracks contacts, commitments, and follow-up dates
Prepares meeting briefs from calendar, email, contact, and project context
Shows every email draft before anything is sent

Personal review

Tracks goals across health, relationships, wealth, mind, and spirit
Creates daily plans and weekly review files
Checks whether my calendar matches my stated priorities
Surfaces neglected goals before they quietly disappear for three months

The early version also held client work, sales, content, and personal projects. That eventually became too much context in one place. I split business operations into a separate system called Refound OS and kept Jarvis focused on my personal life.

That split made both systems better. A personal assistant should understand the shape of my workday, but it does not need every client proposal loaded into context while helping me plan a workout or remember a birthday.

Why Claude Code Works for This

The name makes Claude Code sound like a tool for programmers. Underneath the branding, it is an AI agent that can work with files, run tools, follow persistent instructions, and take multi-step actions on your computer.

Claude in a normal chat starts with the conversation and whatever you attach. Claude Code can start inside a folder that contains the state of your life. It can read yesterday’s plan, update a task, run a calendar tool, create today’s file, and preserve the result for tomorrow.

That filesystem changes the relationship.

A chat gives you an answer. A system leaves your world in a better state.

Claude Code now has several primitives that are useful for building this kind of assistant:

CLAUDE.md provides persistent instructions and explains how the system works.
Skills package reusable knowledge and workflows that Claude loads when relevant.
MCP and local tools connect Claude to services such as calendars, email, databases, and browsers.
Hooks enforce deterministic checks before or after actions.
Auto memory stores useful project-specific learnings across sessions.
Remote Control lets you continue a local session from the web or mobile app while the work still runs on your machine.
Routines can run cloud sessions on a schedule when you need unattended automation.

You do not need all of them. Jarvis became useful before most of these features existed.

The smallest useful version needs a folder, a CLAUDE.md file, and one workflow.

The Core Idea: Your Work Has State

Most people use AI as if every conversation is the first day at a new job.

They explain the project again. They paste the same background. They correct the same preferences. They ask for a plan, copy it into another app, and return tomorrow to a model that has no idea what happened.

Jarvis stores state in ordinary files.

When I complete a task, the task record changes. When a project moves forward, its last_progress date changes. When I prepare for a meeting, the useful context gets saved in the project folder. When I make a commitment in email, it can become a follow-up instead of relying on my memory.

This is why a personal operating system built with files can feel more intelligent than a polished assistant app. The model is only one part of it. The durable state is what allows the system to compound.

The first version of Jarvis used Markdown for everything because Markdown is easy to read and edit. That worked until I had enough projects and tasks that the model occasionally duplicated an item, changed formatting, or updated the dashboard without updating the underlying record.

I eventually separated machine state from human views:

jarvis/
├── CLAUDE.md
├── inbox.md
├── system/
│   ├── goals.md
│   ├── areas.md
│   ├── projects.json       # Source of truth
│   ├── tasks.json          # Source of truth
│   ├── projects.md         # Generated dashboard
│   ├── tasks.md            # Generated dashboard
│   ├── contacts.json
│   ├── contacts.md
│   └── follow-ups.md
├── daily/
│   └── 2026-08-07.md
├── weekly/
│   └── 2026-W32.md
├── notes/
│   └── project-name/
│       ├── _context.md
│       └── research.md
├── .claude/
│   ├── commands/           # Older workflows, still supported
│   └── skills/             # New workflows belong here
└── tools/
    ├── projects.py
    ├── gmail/
    ├── calendar/
    └── drive/

The JSON files are boring by design. They give scripts a predictable format. The Markdown files give me and Claude a clean view. A small Python tool updates the JSON and regenerates both dashboards.

You should not start here.

Start with Markdown. Move to structured data when you can point to a real failure that structure would fix. I made the change after the system had earned the complexity.

How Jarvis Knows How to Behave

The most important file is CLAUDE.md. Claude Code reads it when a session starts, so it acts like the operating manual for the entire system.

Mine explains:

What Jarvis is responsible for
What belongs in the separate work system
Which files are sources of truth
How projects, tasks, notes, and daily plans connect
What each workflow should do
Which actions require my approval
How to find context before giving advice

Here is a shortened example:

# Jarvis

Jarvis is a personal operating system covering five areas:
health, relationships, wealth, mind, and spirit.

## Sources of truth

- `system/projects.json` stores projects.
- `system/tasks.json` stores tasks.
- Markdown dashboards are generated views. Never edit their tables directly.
- `inbox.md` stores unprocessed captures.
- `daily/YYYY-MM-DD.md` stores each daily plan and review.

## Operating rules

1. Keep no more than five focus projects active.
2. Every active project needs one concrete next action.
3. Flag a project after two weeks without progress.
4. Show email drafts for approval before sending.
5. When a task involves a project, read its context file first.

Claude’s documentation now recommends keeping persistent instructions concise. Long procedures fit better in Skills because Claude sees the descriptions at startup and loads the full instructions only when needed. My older slash commands still work, but I would put new workflows in .claude/skills/ today.

The distinction is simple:

Put it here	Use it for
`CLAUDE.md`	Facts and rules Claude should know in every session
Skill	A repeatable workflow or a body of knowledge needed for certain tasks
Tool or script	Deterministic data operations and external service access
Hook	A rule that must run every time, regardless of what Claude decides

If you write “always ask before sending email” in a prompt, you are giving the model an instruction. If you enforce that approval in the email tool, you have a control. Important boundaries deserve controls.

The Workflows That Made Jarvis Useful

Jarvis grew one workflow at a time. These are the ones that survived.

Plan my day

The morning workflow pulls together my calendar, inbox, active projects, open tasks, and personal habits. It then chooses one to three priorities and fits them into actual open time.

The useful part is the constraint. It cannot create a fantasy schedule with eight hours of deep work on a day containing five meetings.

A current version of the Skill could look like this:

---
name: plan-day
description: Build today's realistic plan from calendar events, open tasks, active projects, inbox items, and personal goals. Use when the user asks to plan the day or decide today's priorities.
---

# Plan the day

1. Read today's calendar before choosing priorities.
2. Process actionable items in `inbox.md`.
3. Read active projects and their open tasks.
4. Choose one to three MITs that fit the available time.
5. Reserve buffer between meetings.
6. Include relevant personal habits and commitments.
7. Create or update `daily/YYYY-MM-DD.md`.

End with:
- Today's focus in one sentence
- The first action to start now
- Anything that should be deliberately deferred

That final deferral list matters. A good plan tells me what I am choosing to ignore.

What now

/what-now exists for the moment after I finish something and start drifting toward email or YouTube.

It reads today’s plan, checks the time, considers the next unfinished priority, and returns one action with a reason and time estimate.

One action. No menu. No productivity essay.

Weekly review

The weekly review checks all five personal areas, reads the week’s daily files, processes the inbox, looks for stale projects, reviews goal progress, and asks what deserves attention next week.

This is where the system becomes a coach instead of a task database. A task manager can tell me I completed 17 tasks. Jarvis can notice that I completed 17 work-adjacent tasks while avoiding the two health commitments I claimed were priorities.

Meeting preparation

Before a meeting, Jarvis can assemble:

The event details and attendees
My relationship with each person
Recent email history
Relevant project status
Open commitments and follow-ups
Suggested questions or decisions

The workflow follows a context chain rather than dumping every available file into the model. It starts with the meeting, identifies the people and project, then loads only the relevant history.

This pattern is a practical form of context engineering. Better context usually beats a more elaborate prompt.

Email triage

Jarvis reads unread mail, groups messages into response, review, and archive buckets, and helps draft replies. It also checks whether an email creates a commitment that belongs in the follow-up tracker.

The system separates reading from acting. Reading the inbox can happen automatically. Archiving, sending, or changing a commitment has a higher bar.

For email, my rule is simple: draft first, approve second, send third.

How the Integrations Work

The first Jarvis integrations were small Python tools using Google’s OAuth flow. Claude Code walked me through creating credentials, wrote the scripts, and helped debug them.

The tools expose narrow operations such as:

# Read unread messages
python tools/gmail/inbox.py --unread --limit 20 --output json

# Search conversation history
python tools/gmail/search.py --query "from:person@example.com"

# Read today's calendar
python tools/calendar/events.py --today

# Find open time
python tools/calendar/availability.py --date 2026-08-07

Claude decides when it needs an operation, runs the appropriate tool, and reads the structured result.

Today you have more options. Claude Code can connect to external services through MCP, and many products provide hosted connectors. A local script is still useful when you want complete control over scopes, data shape, and approval logic.

I would choose based on the job:

Approach	Best when
Hosted connector	You want the fastest setup and the provider already exposes the actions you need
MCP server	You need a reusable connection that multiple agent workflows can call
Local script	You need precise behavior, local control, or a tiny operation that does not justify a server
Direct API inside a Skill	Avoid this for Claude API Skills, whose code container has no network access

The last row matters. A Skill teaches the agent how to perform a workflow. MCP or a tool gives it access to an external system. They solve different layers of the problem.

Building Your Own Jarvis

Here is the path I would use if I were starting again.

Step 1: Install Claude Code

Anthropic now recommends the native installer on macOS, Linux, and WSL:

curl -fsSL https://claude.ai/install.sh | bash

You can also install the desktop app if you prefer a graphical interface. Claude Code requires a Pro, Max, Team, Enterprise, or Console account. Run claude, sign in, and accept the workspace trust prompt for the folder you create.

Step 2: Create a dedicated folder

mkdir -p ~/Projects/jarvis
cd ~/Projects/jarvis
claude

Keeping Jarvis in its own folder gives the agent a clear boundary. It also makes backup and version history straightforward.

Step 3: Create the operating manual

Tell Claude:

This folder will be my personal operating system. Interview me about what I want it to manage, what it should never do without approval, and how I currently track tasks. Then create a concise CLAUDE.md file. Keep procedures out of that file. We will turn those into Skills later.

The interview is worth doing. Your first attempt will be better if Claude understands the problem before creating folders.

Step 4: Start with one Markdown workflow

Task capture is a good first workflow:

Create an inbox.md file. When I say “capture” followed by an item, append it with a timestamp. Do not organize or prioritize it during capture. When I ask to process my inbox, help me delete, do, defer, delegate, or file each item.

Use it for several days. Pay attention to where it fails.

Step 5: Turn repeated instructions into a Skill

Once you have repeated the same instructions enough to trust them, create .claude/skills/plan-day/SKILL.md.

Ask Claude:

We have planned my day together several times. Review the successful examples and the corrections I made. Create a plan-day Skill that captures the workflow. Keep the main file concise and include a clear description so Claude knows when to use it.

Skills follow an open folder format. The name and description tell the agent when the Skill applies. The full instructions load only when the Skill is activated, which keeps your everyday context cleaner.

Step 6: Add one read-only integration

Calendar is a sensible first integration because it makes daily planning dramatically more realistic and has a low-risk read-only use case.

Ask Claude to help you choose between an existing connector, an MCP server, or a local Google Calendar tool. Give it read-only access first.

Do not begin by connecting your entire digital life with broad write permissions. Earn each new permission with a workflow you already use.

Step 7: Add structured data after Markdown hurts

Markdown can take you surprisingly far. Move projects and tasks into JSON, SQLite, or another structured store when you need reliable queries, unique IDs, validation, or generated views.

My breaking point was maintaining linked projects and tasks across multiple human-readable tables. JSON became the source of truth, and a script began generating the Markdown views.

That arrangement gives me reliability without forcing me to stare at raw data.

Step 8: Put approval gates around side effects

Classify each operation:

Read: calendar events, email threads, project files
Prepare: draft an email, propose a schedule, stage a task update
Act: send email, create an event, delete a file, move money

Reading can often happen automatically. Preparing should produce something you can review. Acting should require explicit approval unless the consequence is genuinely trivial and reversible.

Claude Code permissions and sandboxing help limit access. Tool design should enforce the important boundaries too. Prompts are guidance. Code is enforcement.

Step 9: Add remote and scheduled execution carefully

Claude Code can now expose a local session through Remote Control, so you can continue from your phone while the agent still runs on your machine with your local tools.

For unattended work, Claude Code Routines can run cloud sessions on a schedule, API trigger, or GitHub event. They are useful for workflows such as weekly repository maintenance. They are a different trust model from a local Jarvis session because the cloud environment uses the repositories, network access, environment variables, and connectors you configure.

For personal data, start local. Move a workflow to unattended execution only after it is narrow, tested, and safe without a live approval prompt.

Starter Prompts

Build the first version

I want to build a personal operating system in this folder. Start by asking me about the areas of my life I want to manage, my current tools, the decisions I struggle with, and the actions that must always require approval. Propose the smallest useful folder structure. Do not build integrations yet.

Plan the day

Read my open tasks, active projects, and today’s calendar. Ask about my energy and any fixed commitments that are missing. Choose one to three priorities that fit the time available. Create today’s daily file with time blocks, buffer, and a short list of things I am deliberately deferring.

Create a weekly review

Review this week’s daily files, active projects, inbox, and goals. Summarize wins, missed commitments, and patterns. Flag projects with no progress for two weeks. Ask me to choose next week’s focus before updating any project status.

Design an approval-safe email workflow

Help me design an email triage workflow. It may read and categorize messages automatically. It must show every draft before sending and must never send, delete, or permanently modify email without explicit approval. Recommend the narrowest OAuth scopes and explain how credentials will be stored.

Improve a workflow from evidence

Review the last five times we used this workflow. Identify repeated corrections, missing context, and steps that did not add value. Propose changes to the Skill, then wait for approval before editing it.

Mistakes I Made

I put too much in one system

The original Jarvis mixed personal goals, client delivery, sales, content, and relationships. It looked comprehensive. It also made context retrieval noisy and created unclear boundaries.

Splitting work into Refound OS let Jarvis become opinionated about personal life. Each system can still reference the other at a high level for planning.

I treated Markdown as a database for too long

Markdown is perfect for getting started. It becomes fragile when multiple files represent the same entity. Once a project appeared in a project table, a task list, a daily plan, and a follow-up file, I needed stable IDs and one source of truth.

I wrote giant persistent instructions

Every rule felt important, so I kept adding to CLAUDE.md. Long instruction files consume context in every session and make individual rules easier to miss.

Persistent facts stayed in CLAUDE.md. Procedures moved into commands and Skills. Detailed project knowledge moved into _context.md files that Claude reads only when a task touches that project.

I thought automation meant removing myself

The best parts of Jarvis remove clerical work. They do not remove judgment.

I want the system to find the email thread, assemble the project context, and draft the reply. I still want to decide whether the reply should be sent. I want it to show that a project has been stale for 18 days. I still want to decide whether to revive or kill it.

The goal is leverage, not absence.

Common Questions

Do I need to know how to code?

No. You need enough comfort to describe a workflow, review what Claude proposes, and ask questions when you do not understand an action. Claude can create the scripts and explain them.

As the system gains access to sensitive data, technical understanding becomes more valuable. You should know where credentials live, what permissions you granted, and which operations can change external systems. Ask Claude to explain those parts in plain language before approving them.

Is it secure?

Security depends on the access you grant and the controls you configure. Claude Code runs the local tools on your machine, while requests to the model still send relevant context to Claude. Connected APIs may also process data under their own terms.

Use least-privilege OAuth scopes, keep secrets out of your repository, enable sandboxing, configure permission deny rules, and require approval for consequential actions. If you connect a company account, follow your employer’s AI and data policies.

Why use files instead of a database from day one?

Files are transparent. You can read them, edit them, back them up, and inspect exactly what the agent changed. They are also easy for an AI coding agent to use.

A database becomes useful when the state needs stronger validation or reliable querying. You can add one later without changing the underlying workflow.

Can I use ChatGPT, Codex, or another agent?

Yes. The architecture matters more than the logo. You need an agent that can work with a filesystem, persist instructions, call tools, and respect permission boundaries.

I built Jarvis with Claude Code because its local agent loop and customization system fit the job. Agent Skills are now an open format, which makes the reusable workflow layer easier to carry across compatible tools.

Does Jarvis run when my laptop is closed?

My core personal system is local. A local session stops when the machine is unavailable. Claude Code now offers cloud Routines for unattended jobs, and you can deploy your own scheduled service if you need a true 24/7 assistant.

I would keep most personal workflows local and use cloud execution for narrow jobs with carefully scoped access.

What I Would Build First

Pick the moment when your attention regularly breaks down.

For me, that was deciding what to work on while juggling too many projects. The first useful version of Jarvis gave me a short task list. The next version looked at my calendar. The next version connected tasks to projects. Each addition solved a failure I had already experienced.

That is the pattern:

Find one recurring decision or administrative chore.
Represent its state in a file.
Teach Claude the workflow.
Use it long enough to find the weak points.
Turn the stable procedure into a Skill.
Add access and automation only when the workflow earns it.

You do not need to build a digital clone of yourself this weekend.

Create a folder. Give Claude one job. Make tomorrow’s version slightly more useful than today’s.

That is how Jarvis was built.