Build an AI Assistant in Claude Code (Weekend)

The evening version of an assistant lives in one project and you paste it what it needs. It works, and that guide is where anyone should start.

This is the other one, and Claude Code is where I build it. It reads your calendar, your email, and your project tools on its own, it runs before you wake up, and it can act on your behalf inside limits you set. (Claude Code runs inside the Claude app now, so this is configuration, not a terminal weekend.)

It takes a weekend. Here's the honest version of what that weekend involves.

First, decide whether you need this

You need the built version when you're pasting the same context daily and resenting it, when you want output waiting for you rather than requested by you, or when you want it to do things rather than recommend them.

You don't need it because it sounds more impressive. A well-instructed project file beats a badly-scoped automated one every time.

Step 1: Connect before you build

Decide what it reaches before you design anything, because the connections determine what it's capable of and a rebuild is annoying.

Most assistants want some combination of: your calendar, your email, wherever your work actually lives, and your files.

The mechanism is MCP servers, the standard plugs that connect an AI to your other apps. Setting up your first one is the part that feels hardest and takes about twenty minutes; the MCP starter guide walks through it from zero.

One rule. Connect only the tools you genuinely use. An assistant wired to the project manager you abandoned in March is an assistant reading fiction and reporting it as fact.

For a first build, three connections cover almost everything:

Calendar first. It's the lowest-risk connection (read-only is fine to start) and it immediately makes every answer about your day smarter.
Email second. This is the one people hesitate on, reasonably. Start read-only, and scope it: your inbox, never shared or team accounts.
Your work tool third, wherever tasks actually live. One tool, the real one.

Everything else waits until the briefing has earned trust.

Let it tell you what it needs rather than guessing:

Given what this assistant is supposed to do, what does it need access to in order to do it properly? List what's essential, what's nice to have, and what I can skip. For each one, tell me what you can and can't do without it.

That last part is what saves you a wasted afternoon. Some connections do far less than you expect.

Step 2: Write the permissions before the capabilities

This is the step that separates a useful assistant from a liability, and almost nobody does it first.

Decide in writing, in the instructions, what it may do alone, what it must propose first, and what it must never touch.

A working split:

Do it alone: read anything, draft anything, summarize, prepare, organize, flag.
Propose first: anything that sends, books, cancels, spends, or is visible to another human.
Never: anything financial, anything legal, anything involving a person's employment, and anything you'd struggle to explain if it went wrong.

Write it as a section of the instructions with that heading. You'll be glad it's explicit the first time it tries something enterprising.

Step 3: Give it the standing brief

An automated assistant runs the same prompt every day, so that prompt has to be good.

Mine lands at 7am, before I'm out of bed. It's a pre-triage of the day: what's on my calendar with a flag on anything complex or back-to-back (and reminders to do things like eat lunch), where my deep work block should go, whether I have external meetings, anything urgent sitting in either inbox, the weather, a short news and content briefing, and any reminders. What's left, what's blocked.

A version you can adapt:

Every morning at [7], send me my briefing: what's on my calendar with a flag on anything complex or back-to-back, where my deep work block should go, whether I have external meetings, anything urgent in my inbox that needs a reply, the weather, and any reminders. What's left, what's blocked. Remind me to eat lunch on packed days. This is my pre-triage: I want to know what I'm walking into before I get out of bed.

The generic version of a briefing summarizes your calendar, which you can already see. The useful version tells you what you're walking into.

Step 4: Put it on a schedule

An assistant you have to open is a chat. An assistant that arrives is an assistant.

There are several ways to do this depending on your stack, and the mechanism matters less than the discipline: one scheduled run, at a time when the output is actually useful. Before your day starts, not during it.

Then pick where it lands. Mine arrive in Telegram, on a set schedule, and I love that: the briefing sits there like a message from a friend instead of getting buried in an inbox. Email works too. The test is simple: wherever you already read messages first thing in the morning, that's where the briefing goes.

Step 5: Run it for a week without trusting it

Let it draft messages you don't send. Let it propose plans you don't follow. Read every briefing critically rather than gratefully.

You're checking three things. Is it reading the right sources. Is it wrong about anything factual. And is it proposing things you'd actually want.

Correct it in plain language, then move the correction into the instructions. A correction that only lives in a conversation evaporates the next morning.

Step 6: Add the second assistant only when the first is boring

Boring is the goal. Boring means it runs, you trust it, and you stopped thinking about it.

Most people build three at once and end up with three that half work. Build them in sequence, and let the second one earn its existence by being a question the first one keeps answering badly.

The weekend, blocked out

What "it takes a weekend" actually means:

Saturday morning: connections. Calendar, email (read-only, your inboxes only), one work tool. The MCP starter guide covers the mechanics; expect the first connection to take twenty minutes and the rest to take five.
Saturday afternoon: instructions. Run the interview, let it write its own job description, then write the permissions section yourself. Permissions before capabilities, always.
Sunday morning: the first briefing, run by hand. Ask for it in the chat before you automate anything. Correct it until it leads with what matters.
Sunday afternoon: schedule it and pick the delivery. One run, at the hour you'll actually read it.
The following week: trust nothing, correct everything. Read every briefing critically. Move every correction into the instructions. By Friday it's either boring, which is the goal, or you know exactly which instruction to fix.

What it costs to run

Less than people expect. An AI subscription, a dictation tool if you write your instructions by voice, whatever pipes the output where you want it, and any hardware you already own.

The build is the expensive part, and it's a weekend.

What to do when it breaks

It will. Three common failures:

It went quiet. Almost always a connection that expired. Reauthorize and it comes back.

It got worse. Usually the instructions have accumulated contradictions from months of corrections. Read them start to finish and cut the ones that fight each other.

It did something you didn't expect. Go back to step 2. The permissions were not explicit enough, and this is why they get written before the capabilities.

The three I run this way

The specs for my actual three, each with its context list and standing instructions:

The personal chief of staff, calendar + both my inboxes + ClickUp, 7am briefing
The nutrition assistant, Oura + calendar + the running food log
The astrology companion, no connections at all, which is a legitimate answer

Common mistakes

Skipping the evening version. People who jump straight here build something impressive that they don't use.
Connecting everything. Every connection is surface area for confusion. Start with three.
No permissions section. The instructions describe what it can do and never what it must not.
Scheduling it for a time you're not receptive. A briefing at 6am you read at 11am is a briefing you don't act on.
Building the second before the first is boring.

FAQ

Do I need to code? No. Connecting tools and writing instructions is configuration, not programming. If you have set up a Zapier automation, this is the same shape of work.

How is this different from an agent? Mostly permissions and scheduling. An assistant that reads and reports is a very well-configured assistant. One that acts on your behalf inside boundaries is what most people mean by an agent, and step 2 is the line between them.

What if I don't want it reading my email? Then don't connect email. It stays useful with calendar and task tools alone, and the honest cost is that it won't know what people have asked you for.

Is my data safe? It reaches whatever you connect it to, so treat the permission list as a security decision. Connect the accounts you'd be comfortable handing to a new hire on their first day, and nothing else.