You bought a stack. You needed an operating system.

The thing nobody admits about their “AI workflow”

Open a random executive’s laptop right now and you will find ChatGPT, Claude, Perplexity, Notion AI, Granola, Gemini in their inbox, Copilot in their IDE, and probably two more they forgot they were paying for. Each one is a fresh chat. Each one has no idea who they are, what company they run, what they were working on yesterday, or what they actually care about.

That is not a workflow. That is twelve strangers in a row, each one introducing themselves to you again every morning.

The reason your AI use feels like productivity theater is that it is productivity theater. The output is fine. The system underneath is empty. You are the only memory in the loop, and you are the bottleneck you were trying to remove.

Why a Personal OS, and why now

I have been writing for two years about what I call the Revenue Nervous System. Six layers, built around a company, that turn AI from a feature into the way the org actually thinks. Data, intelligence, context, memory, orchestration, execution. Companies that build it compound. Companies that buy seats of Copilot and call it strategy do not.

A Personal OS is the same architecture pointed inward. The same six-layer logic, remapped from a revenue org to a single person. The unit of analysis is you.

If you want AI to become part of how your brain actually works, stop shopping and start architecting.

Read more

I watch this happen constantly. A leadership team spends a quarter mapping a transformation roadmap with eleven workstreams, and at the end of the quarter the number of GTM agents actually running in their business is zero. Not because the team is incapable. Because nobody picked one workflow, drew a box around it, and shipped it. The roadmap was the procrastination. The first agent is the work.

Here is the thing about the first agent. It is the hardest one you will ever build, and it has almost nothing to do with the technology. The model is good enough. The tools are good enough. What is hard is the organizational act of choosing one workflow, defining what “good” means precisely enough to measure it, running it next to a human without flinching, and then killing the manual process when it works. The second agent is ten times easier because by then the company has done the hard part once. It has proof. It has a pattern. It has a person who has shipped.

So this playbook is about the first one. Thirty days. One workflow. End to end. Running.

And it is written for the Tactical CEO, which means I want to be precise about your job, because your job is not the one you think it is. You are not building the agent. If you are the CEO and you are in the prompt, something has gone wrong. Your job is to install the conditions under which the agent gets built and survives. You name the owner. You protect the thirty days. You set the cancellation target. You demand the exit criterion. Four moves, and if you make them, the agent ships. If you skip them, you get another roadmap.

Three readers should be following along here, and the job splits cleanly. The individual operator builds the thing. The leader clears the runway. The founder or CEO sets the target and refuses to let the calendar eat it. I will mark who does what as we go.

Here is the sequence.

Days 1-3: Pick the Workflow

Everything downstream is determined by this choice, and most teams get it wrong by picking the workflow that is most exciting instead of the one that is most shippable. The first agent is not where you prove ambition. It is where you prove the company can ship at all.

The move. Map your GTM workflows. Not your org chart. Your workflows. The repeated, nameable units of work that move revenue: lead research, inbound triage, meeting prep, CRM hygiene, follow-up drafting, renewal flagging, deal-desk approvals, onboarding sequences. Then score each one on three axes. Frequency: how many times a week does this run? Manual hours: how much human time does each run burn? Clarity: how cleanly can you describe what “good output” looks like? Multiply, sort, and the top of the list is your candidate. High frequency times high manual-hours times high clarity. Pick ONE.

The clarity axis is the one people undervalue. A workflow that runs two hundred times a week but where “good” is fuzzy and contested will sink your first agent in edge cases. A workflow that runs forty times a week but where good is obvious to everyone is a far better first target. You want frequency for ROI and clarity for shippability. Where they overlap is your agent.

What good looks like. One workflow named on a whiteboard, with a number next to it. “Inbound lead research. Runs roughly sixty times a week. Eats about twenty minutes of an SDR’s time each run. Good output is a five-field brief: company, funding, role fit, recent trigger, and a suggested opener.” That sentence is the deliverable for days 1 through 3. If you cannot write that sentence, you have not picked yet.

The CEO’s role here. You name the owner. This is the single most important thing you do in the entire thirty days, and it takes one decision. One person owns this agent end to end. Call them the Agent Builder. Not a committee. Not “the RevOps team.” A name. The Agent Builder can be a RevOps analyst, a sharp SDR, a sales engineer, anyone close to the work with enough technical comfort to wire tools together. What matters is that the responsibility lands on a person, because agents that belong to everyone get built by no one. If you do nothing else as CEO, do this.

Common mistake. Picking the flashiest workflow instead of the most shippable one. The autonomous outbound agent that personalizes at scale is the dream, and it is a terrible first agent because “good” is contested, the blast radius is your brand, and one bad send is a customer-facing incident. Start somewhere internal, high-frequency, and low-blast-radius. Earn the right to the flashy one by shipping the boring one.

Exit criterion. One workflow is named, scored against the other candidates, and written as a single sentence with a frequency number and a manual-hours number attached. The Agent Builder is named. When that is true, days 1 through 3 are done.

Days 4-7: Define the Contract

This is where most first agents die quietly, before a line of anything gets built. The team skips straight to building because building feels like progress, and they never wrote down what the agent is actually supposed to produce or how they would know if it worked. Then four weeks later there is a thing that runs and no way to say whether it is any good. Define the contract first.

The move. Write the agent’s contract on one page. Four parts.

Inputs: exactly what the agent receives. The lead’s email and company domain. The inbound form submission. The CRM record. Be specific about what is and is not available at runtime, because half of agent failures are the agent reaching for context it was never given.

Outputs: exactly what the agent produces, in what format, to what destination. “A five-field brief written to a Slack channel and appended to the CRM contact record.” Not “research on the lead.” A format a human can check at a glance.

What good looks like: the quality bar, written as something you can actually evaluate. Pull five real past examples that a human did well. Those are your gold standard. The agent’s output gets compared against them.

How you measure it: the metric, against the human baseline. Time saved per run. Accuracy versus the human-done version. Acceptance rate, meaning how often a human ships the agent’s output without rewriting it. Pick the one or two that matter and write down the current human number, because you cannot prove the agent is better than the human if you never measured the human.

What good looks like. A one-page contract that a person who has never seen the workflow could read and then correctly judge whether a given agent output passed or failed. If two people read the contract and disagree about whether an output is good, the contract is not done. Tighten it until they agree.

The CEO’s role here. You demand the exit criterion before a single thing gets built. The Agent Builder brings you the contract, and the question you ask is one sentence: “What number tells us this worked, and what is that number for a human today?” If they cannot answer, the agent is not ready to be built, it is ready to be re-scoped. This is a five-minute conversation and it is the highest-leverage five minutes in the project. You are not reviewing the work. You are refusing to let the work proceed without a definition of done.

Common mistake. No human baseline. The team builds the agent, it produces plausible output, everyone nods, and nobody can say whether it is faster or more accurate than what the SDR was already doing. Without the baseline you have a demo, not a result. Measure the human first, even roughly. A baseline that is approximate beats a baseline that does not exist.

Exit criterion. A one-page contract exists with inputs, outputs, a gold-standard set of five examples, and a named metric with the current human number written next to it. When that is true, days 4 through 7 are done.

The Architecture Every Agent Gets Built Against

The one-page contract is the spine. It is not the whole skeleton. The contract names what goes in, what comes out, what good looks like, and how you measure it, which is a real start, but a contract is not yet an agent. This is where most first agents quietly turn into demos. The team has a contract, they hand it to a model, the model produces something plausible, and nobody can say why it works on Monday and falls apart on Thursday. The reason is almost always a missing layer.

So here is the architecture I build every agent against. Seven layers, plus three things most people leave out, plus one rule that matters more than all of it. Your contract from days 4 through 7 already covers four of these layers. The other three are what separate an agent you can cut over to from a science project you keep babysitting.

Layer 1, identity. Name the agent, its domain, and one thing that decides everything downstream: its authority level. Advisor recommends and a human acts. Operator acts but asks permission for anything with real blast radius. Executor acts on its own inside declared bounds. Your first agent should almost always be an advisor or a tightly scoped operator, because authority is where damage lives. And write the “you do NOT” list. Name the specific ways this agent goes wrong, not generic negatives. “Never fabricate a trigger event it cannot source from the input” teaches the model something. “Be helpful” teaches it nothing.

Layer 2, objectives. The outcome it owns, and the anti-goal. The anti-goal is the part people skip and it is the part that saves you. “Optimize for accuracy even if it means flagging the lead as out of scope instead of guessing” is an anti-goal. It tells the agent what to sacrifice when the two things it wants are in conflict, which is exactly the moment unguarded agents improvise.

Layer 3, context. What is in scope, what is out, and the single most undervalued instruction in agent building: what to do when context is missing. An agent that guesses when it lacks input is an agent that hallucinates on a schedule. The fix is one line: when a required input is missing, do not guess, say what is missing and stop.

Layer 4, reasoning. Here is the counterintuitive part. If you are building on a modern thinking-capable model, do not script its thought process. Telling a reasoning model to follow your five steps usually makes it worse, because it plans better than your script does. Constrain the output, not the thinking. The one piece worth keeping is a verification step: before it answers, have it check its own work against the contract, and when something is ambiguous, ask one clarifying question instead of charging ahead.

Layer 5, tools. What the agent can reach, when to pick one tool over another, and the step nearly everyone omits: post-tool verification. After the agent calls a tool, it has to check that the result is actually what it asked for before it acts on it. Skip this and one bad lookup cascades into a confidently wrong output. This is the single most common hole in a first agent. If you do nothing else technical, make the agent verify its tool results before it trusts them.

Layer 6, output and guardrails. The format, and the hard nevers. Use blast-radius gates: read-only actions can run on their own, anything that writes asks for confirmation, anything customer-facing or irreversible requires a human. That gate, tied to the authority level from Layer 1, is what makes an agent safe to cut over to in week 4.

Layer 7, orchestration. Mostly skip this for agent number one, and that is the point of naming it. Orchestration is how an agent delegates to other agents, compacts a long conversation, and persists what it learned between runs. Your first agent does one thing, so it barely needs this. But know it exists, because agent number five will, and the most common orchestration failure is a fuzzy delegation map. “Hand off to a specialist when needed” is not a map, it is a shrug. When you get there, name exactly who receives what.

Then three things that are not optional, even though everyone treats them as extras.

A role contract, if the agent owns an outcome. For anything modeled on an actual revenue role, write what outcome it is accountable for, what artifacts it emits, what it consumes upstream, what consumes it downstream, and the metrics that prove it works. This is the Signal to Decision to Action to Feedback loop made concrete, and it is what keeps a GTM agent from drifting into a generic chatbot.

Examples. Two to five, every time. Show the agent a standard success, an ambiguous edge case it should ask about, and a bad input it should refuse. On a strong model, two or three real examples shape behavior more than any amount of instruction prose. The five gold-standard examples from your contract are the start of this. Add an edge case and a failure case and you are done.

Observability. Have the agent emit a small structured record every time it runs: what it received, what it did, whether it escalated, and the outcome. Ungoverned agents become ungovernable the moment you have more than a couple. A logging stub on agent one is a habit that pays off at agent ten.

And the rule that matters more than the rest: keep the whole spec tight. There is real research, and my own repeated experience, behind a density ceiling of roughly a hundred and fifty lines. Past that, agents get worse, not better, because the model’s attention degrades across a bloated spec and the redundant lines cost you both accuracy and money. Density beats comprehensiveness. Anything that is a standard process, a template, or a rubric does not belong in the agent itself. It belongs in a skill the agent loads only when it needs it. The agent spec holds identity, judgment, and the things the model cannot figure out on its own. Everything else loads on demand.

That is the difference between a tool and a system, which is the whole game. A tool is a clever prompt that works until it doesn’t. A system is an agent with an identity, a verified set of capabilities, guardrails proportional to what it can break, examples of right and wrong, and a record of every run. The first one takes a few extra hours to build this way. Every one after it inherits the pattern.

For agent number one, you genuinely need only Layers 1, 2, 3, and 6, plus a couple of examples and a verification step. That is the minimum viable agent. Build that, ship it, and add the rest as the workflow earns it. The architecture is the standard you grow into, not a gate you have to clear before you start.

Week 2, Days 8-14: Build the First Version

Now you build, and the entire discipline of week 2 is one word: thin. One workflow, end to end, running, even if it is ugly. The failure mode of week 2 is not building a bad agent. It is building half of an ambitious agent. A thin slice that works beats a thick slice that almost works, every single time.

The move. Build the narrowest version of the agent that takes the real input, does the real work, and produces the real output to the real destination. End to end. If the contract says “lead email in, five-field brief to Slack out,” then by the end of week 2 a real lead email goes in and a real brief lands in Slack. It does not have to handle every edge case. It does not have to be elegant. It has to be whole. One complete path from input to output, running on real data, even if it only handles the clean cases for now.

Resist the urge to build the pretty version. No dashboard. No configuration UI. No handling of the seventeen rare input formats. The clean path, working, on real inputs. The edge cases are week 3’s job, and trying to handle them now is how week 2 turns into week 6.

What good looks like. You can point at it and say “watch this,” paste in a real lead, and a real brief appears in the real Slack channel. It is ugly. It misses some cases. It works. That is the bar. A running thin slice on day 14 is worth more than a beautiful architecture diagram of the full system.

The CEO’s role here. You protect the thirty days. Week 2 is when the organization’s gravity tries to pull the Agent Builder back onto their old job. A fire breaks out, a board ask lands, a customer escalates, and the easiest thing in the world is to grab the most capable person, who is your Agent Builder, and put them on it. Do not. The whole premise of a thirty-day sprint is thirty protected days. If the Agent Builder gets pulled for a week, you do not have a thirty-day agent, you have a sixty-day maybe. Your job is to be the wall between the Agent Builder and the next fire. Leaders, this is yours too: clear their calendar, reassign their tickets, and make it socially expensive for anyone to interrupt the build.

Common mistake. Building wide instead of deep. The team tries to make the agent handle every input variation and every output format in week 2, gets buried in edge cases, and arrives at day 14 with a sophisticated half-thing that has never once run end to end. Ship the clean path first. The agent that runs on Monday teaches you more than the agent that is still being designed on Friday.

Exit criterion. A real input produces a real output to the real destination, on real data, end to end, at least once. When you can demo that live, week 2 is done.

Week 3, Days 15-21: Run It in Shadow Mode

The agent works on the clean path. Now you find out what the clean path was hiding. Week 3 is shadow mode: the agent runs next to the human, on the same real inputs, at the same time, and nobody ships the agent’s output to anyone yet. You compare. You measure. You fix the edge cases the real world surfaces.

The move. Run the agent in parallel with the human on live work. Same leads, same tickets, same inputs, both producing output. The human’s output is what actually gets used this week. The agent’s output gets logged and compared against it and against the contract’s gold standard. Every divergence is a finding. The human caught a trigger event the agent missed. The agent produced a cleaner opener than the human. The agent choked on a lead with no company domain. Each one is either a bug to fix or a boundary to document.

This is also where you measure the contract metric for real. Time per run, agent versus human. Acceptance rate: if a human had shipped the agent’s output, how often would it have been fine as-is? You are building the evidence that the agent is at or above the human baseline, on real work, before you let it touch anything live.

What good looks like. A week of side-by-side logs. The agent matches or beats the human on the named metric across the clean cases, and the edge cases where it fails are documented and either fixed or explicitly ruled out of scope. You know precisely where the agent is trustworthy and where it is not, because you watched it run against a human for a week instead of guessing.

The CEO’s role here. You hold the line on the cancellation target you are about to set, and you ask one question at the week-3 readout: “Is it at or above the human baseline yet?” Not “is it perfect.” At or above the human. Humans miss things too. The bar for cutover is not flawlessness, it is “as good as or better than the person doing it today, on the cases we have scoped.” If you let the team chase perfection here, the agent never ships, because nothing is perfect and shadow mode can run forever. Your job is to define “good enough to cut over” as “beats the human on the metric we agreed to,” and then push for the cutover.

Common mistake. Letting shadow mode become permanent. Shadow mode is comfortable. The agent runs, nobody depends on it, there is no risk, and the team can tweak forever. That is not safety, it is avoidance. Shadow mode has a one-week clock. At the end of the week you make a call: cut over, or kill the project and pick a different workflow. What you do not do is run a fourth week of shadow mode because someone is nervous.

Exit criterion. A week of side-by-side data shows the agent at or above the human baseline on the contract metric, with edge cases documented and either fixed or scoped out. The cutover decision is made. When that is true, week 3 is done.

Week 4, Days 22-30: Cut Over and Kill the Manual Process

This is the week that separates a real agent from a science project, and it is the week most companies never reach, because cutting over means committing. Shadow mode is reversible. Cutover is a decision. You are saying: from now on, the agent does this, and the human stops doing it the old way. The agent is no longer running next to the process. The agent is the process.

The move. Four things, in order.

Cut over. The agent’s output now goes live. The human moves from “doing the work” to “supervising the agent,” which mostly means spot-checking and handling the documented edge cases the agent does not cover. The default is the agent. The exception is the human.

Kill the manual process. Actually kill it. Not pause, not “keep it as a backup just in case.” The manual workflow comes off the team’s plate. If the SDR is still doing lead research by hand “to be safe,” you have two processes and zero leverage, and the agent will quietly atrophy because nobody depends on it. Make the agent the only path.

Hit the cancellation target. Here is where the CEO’s number comes due. If this workflow was being done with a SaaS tool you were paying for, cancel it or earmark it for cancellation at renewal. If it was being done with human hours, those hours are now reclaimed and explicitly redeployed to higher-value work, named, not vaguely “freed up.” The first agent should retire something. A subscription, a contractor line, a chunk of hours. That retirement is the proof the agent is real, and it funds the next one.

Write the runbook and pick agent #2. A one-page runbook: what the agent does, where it runs, how to tell if it is broken, who owns it, what to do when it fails. Then, on day 30, the Agent Builder names the next workflow off the day-1 scoring list. The pattern is now installed. Agent #2 will take half the time.

What good looks like. The manual process is gone. The agent runs in production and a real person depends on its output every day. A line item got cancelled or a block of hours got formally redeployed. There is a runbook. There is a named candidate for agent #2. The company has shipped one, and more importantly, it now knows how.

The CEO’s role here. You set the cancellation target at the start of the month, and in week 4 you collect it. “This agent retires the X subscription,” or “this agent gives the SDR team back ten hours a week that go to live conversations.” You name that target on day 1 and you hold the team to it on day 30. Without a cancellation target, the agent becomes additive: a new thing on top of all the old things, and additive AI is how companies end up paying more and moving the same. The cancellation target is what makes the agent a replacement instead of an addition. That is your number to set and your number to enforce.

Common mistake. Running the agent and the manual process in parallel forever because cutting the manual process feels risky. This is the most common failure in the entire thirty days, and it is fatal in slow motion. Two parallel processes means the agent never becomes load-bearing, nobody truly depends on it, the cancellation target never gets hit, and within a quarter the agent is a curiosity nobody maintains. The cutover is the point. If you are not willing to kill the manual process, you were never serious about the agent.

Exit criterion. The agent runs in production, the manual process is dead, the cancellation target is hit or scheduled, the runbook exists, and agent #2 is named. When all five are true, you have shipped your first GTM agent in thirty days.

Why the First One Is the Hardest, and the Most Important

The first agent costs you a month and teaches you everything. It forces the company to learn the one skill that the entire AI-native transition actually depends on, which is not prompting and is not tooling. It is the organizational muscle to scope one workflow, define done, measure against a human, cut over, and kill the thing it replaced. That muscle is the whole game. Companies that have it ship agent after agent. Companies that do not have it accumulate roadmaps.

Once the muscle exists, the constraint stops being capability and becomes throughput. You will not be asking “can we build an agent?” You will be asking “which workflow next, and who owns it?” That is a completely different company than the one that started the month with a deck and a budget line and nothing running. The first agent does not just automate a workflow. It converts the organization from talking about agents to shipping them. That conversion is worth far more than the twenty minutes a week the agent saves.

The individual operator gets a shipped artifact and a new identity: the person who builds the agents. The leader gets a repeatable thirty-day pattern to run again and again across the revenue org. The CEO gets the only thing that actually matters at the top, which is proof that the company can install AI into its operating model and retire what it replaces, instead of layering AI on top and paying twice.

The window for this is not open forever. The companies building this muscle now are compounding it while everyone else is still mapping. Eighteen months from now the gap between the company that shipped its first agent this quarter and the company that is still planning its transformation will not be a quarter. It will be the difference between an organization that runs on agents and one that runs slides about them.

Pick the workflow. Name the owner. Protect the thirty days. Ship the first one.

Below the line: the build prompt I would hand the Agent Builder on day 1, the SaaS-spend-to-agent mapping worksheet for finding your cancellation targets, and the companion interactive guide that walks the full thirty-day sequence with the templates built in.

Free preview ends here. Everything above is the full 30-day sequence, free to read and free to run: the week-by-week moves, the exit criteria, the CEO’s role at each phase. Below, for paid subscribers, are the copy-paste assets that make it faster: the first-agent build prompt, the SaaS-spend-to-agent mapping worksheet, and the companion interactive guide.

Read more

I watch GTM leaders do this constantly. They try Claude Code, or OpenAI’s Codex, or Anthropic’s Cowork, get a sloppy first result, and conclude the tool isn’t ready. The model is fine. The model is, frankly, astonishing. The problem is they dropped a brilliant operator into a junk drawer of files with no labels and no system, then judged the work that came back out.

Here is the thesis, and I’ll defend it the whole way down: the bottleneck with agentic AI is almost never the intelligence. It is the operating environment you put the intelligence into.

The new hire nobody onboarded

Think about the best person you ever hired. Sharp, fast, eager, ready to go on day one. Now imagine you sat them at a desk, pointed at a wall of unlabeled boxes, and said “the files are in there somewhere,” gave them no idea where finished work goes, no sense of how your team writes things or names things, and then walked away.

A great hire would still try. They’d dig through the boxes, guess at your conventions, produce something. And it would be wrong in a dozen small ways, because you never told them what right looks like. You’d look at the output and think, “maybe this person isn’t as good as I thought.”

That is exactly what happens with agentic tools. The agent is the brilliant new hire. The repo or the folder is the desk and the boxes. And most people skip onboarding entirely, then blame the hire.

Here’s the twist. With a human, that onboarding is fuzzy and slow. It lives in hallway conversations and Slack threads and the slow osmosis of “how we do things here.” With an agent, the onboarding can be a file. One file. Written once, read at the start of every session, applied perfectly every time. The thing that takes a human three months to absorb, you can hand an agent in three hundred lines. That is a gift most people are leaving on the table.

Stop prompting. Start operating a system.

The first mistake is thinking the skill you’re building is prompting. It isn’t. Prompting is what you do in a chat window when you want a one-off answer. Working with an agentic tool is something different, and the leaders who get this pull away fast from the ones who don’t.

You are not prompting anymore. You are operating a system.

In that system, the repo or the working folder is the operating system. It is the environment the agent lives inside, the place where context, history, and output all accumulate. And the conventions file is the constitution. It is the document that tells the agent what the rules are, where things go, and what “done” looks like in your world.

Every serious tool now has a version of this constitution:

• Claude Code reads a CLAUDE.md file at the start of every session. It’s the standing brief the agent gets before it touches anything.

• OpenAI’s Codex uses AGENTS.md, which the team describes as a README for agents. Codex walks from the repo root downward and merges these files hierarchically, so a rule at the top applies everywhere and a rule deeper in applies locally.

• Anthropic’s Cowork, the desktop agentic workspace that operates inside folders you authorize, holds the same thing inside Projects: instructions, scheduled tasks, context, and memory.

Different names, same job. The tool changes. The principle does not. And this is the part that separates people who get leverage from people who get frustrated: a tool is something you buy, a system is something you build. The agent is the tool. The constitution and the folder structure are the system. If you only ever shop for tools, you’ll keep wondering why the magic doesn’t show up. The magic is in the system you wrap around the tool.

The one habit that compounds

If you do nothing else, do this. Keep a conventions file, and give everything a place to live. Then maintain both as the work grows.

That sounds almost too simple to matter. It is the most underrated move in the entire space, and the evidence backs it up. A study comparing human-written conventions files against ones the model generated for itself found the human-curated versions won. The machine-generated files actually reduced task success in five of eight settings tested. Read that again. Letting the agent write its own rulebook made it worse most of the time. The judgment about what matters, what’s non-obvious, what your team actually cares about, that still has to come from you. The agent executes the constitution beautifully. It is not yet the right author of it.

So write a lean one. The teams shipping with Codex say the same thing the Claude Code teams say: keep it tight, focus on the non-obvious rules, commit it and review it like code, because that’s what it is. For CLAUDE.md specifically, keep it under roughly two hundred lines, because the agent reads it every single session and bloat costs you. Boris Cherny, who built Claude Code, has a rule I’ve adopted wholesale: anytime the agent does something wrong, add a line to the file so it never does it again. That’s it. That’s the flywheel. Every mistake becomes a permanent correction instead of a recurring annoyance.

There’s a principle I live by in my own system, and it applies perfectly here: if it won’t exist next session, write it down now. The agent has no memory of yesterday unless you gave it one. The folder is its memory. The conventions file is its judgment. Every time you fix something verbally and don’t write it down, you are paying to teach the same lesson twice.

The compounding works like this. Day one, your conventions file is thin and your output is rough. You correct a few things, you write them down. Day thirty, the file knows where everything goes and how you like it, and the output lands clean on the first try. The system got smarter while you slept. That is the whole game, and almost nobody plays it on purpose.

Where to start

Read more

But “connect Claude Code to Salesforce” isn’t one setup. It’s four, and the right one depends on whether you’re a solo analyst poking at a sandbox or a RevOps leader wiring an agent into production. This guide walks all four, with copy-paste steps for each.

Prefer to click through it step by step? I built an interactive version that remembers what you’ve checked off, with copy buttons on every command:

Read more

Revenue is engineered, not hoped for. The same thing is true for agentic systems. More agents don’t produce more intelligence if the underlying system has no memory.

What I Got Wrong The First Time

I’ll save you the lecture and lead with the confession. My first version of this system was genuinely embarrassing.

I had a folder of agent files. I had prompts I was proud of. I had a handful of skills wired into Claude Code. What I did not have was any way for those agents to know what any other agent had ever done, said, or learned. Every session started at zero. Every question got researched again. The CMO agent would produce a positioning brief on Monday. The sales enablement agent would ask the same positioning questions on Wednesday. I was paying in tokens and time for work I’d already done.

The deeper failure was that I couldn’t see it. The individual outputs looked great. Each agent, on its own, produced a useful artifact. It was only when I tried to chain them that the gaps showed up. A research agent would cite a stat. A writing agent would misquote it by 15%. A review agent would miss the misquote because it had never seen the original. Each agent was locally competent and globally incoherent.

That’s the failure mode nobody talks about when they show off their agent count. Agents that can’t share memory are not a system. They are a cast.

The Extended Analogy, Then The Twist

Most people think about agents like hiring. You’ve got a CMO, a CRO, a controller, a research analyst. Each one is a specialist. Each one has a job description. You build your org chart, you set goals, you run 1:1s, and the work gets done.

That framing is almost right, and the “almost” is the part that kills companies.

A real hire has shared context by default. They sit in the same meetings. They hear the same hallway conversations. They read the same Slack threads. They remember what happened last quarter because they lived through it. An agent has none of that. An agent is a contractor on their first day, every day, forever, unless you build the substrate that gives them continuity. Your org chart of agents is not 104 hires. It is 104 contractors walking into a building with no elevator. They can each do great work on floor 7. They just can’t get to floor 8.

The knowledge graph is the elevator.

Why Memory Is A Layer, Not A Feature

The Revenue Nervous System has six layers: Data, Intelligence, Context, Memory, Orchestration, Execution. I get asked all the time why Memory is a layer and not a capability inside Orchestration or Context. Because Memory is what makes the other layers cooperate.

Data without Memory is a warehouse that forgets yesterday. Intelligence without Memory is a model that re-derives the same pattern every morning. Context without Memory is a retrieval step that never learns which retrievals worked. Orchestration without Memory is routing that treats every request like it’s the first one. Execution without Memory is a writeback that nobody reads.

Memory is what turns a stack of cooperating services into a system that compounds. Without it, every run is independent. With it, the week after produces better answers than the week before, because the week before left a trace.

The shape of the fix is a knowledge graph with four layers that stay in sync whenever anything gets written. Visual, context, vector, temporal. Each answers a different question. Together they are the Memory Layer. Agents that can’t share memory are a cast. Agents that can share memory are a team.

That is the framing. The next question is the only one that actually matters for operators: what does this look like on disk, what runs when, and how do you build it yourself without hiring a platform team.

How You Actually Build It

Read more

A real kitchen has a line. Ticket comes in, the expediter reads it, it goes to the station that can cook that plate, the plate comes back, it ships. The cook doesn’t read every label every time. The expediter does. The cook cooks.

That’s the difference between a prompt library and an orchestrated system. It’s also why most AI rollouts stall the second the novelty wears off.

This guide is how you build the expediter. Three working layers by the end: a registry that lists your specialists, a router that picks the right one for a given task, and an orchestrator that coordinates handoffs when the job needs more than one pair of hands.

You don’t need to be technical. You need to be able to write a clear one-sentence job description and name the things your team actually ships. That’s the whole skill. If you can run a team, you can build this. The parts that look like code (the registry, the instruction files) are patterns your AI can generate for you once you tell it what each specialist does. Your job is the thinking. The typing is automatable.

If you’re a founder, a GTM operator, or an exec who has been watching your people bounce between ten tools and ten chat windows, this is the piece that makes the mess coherent.

The Problem With One Giant Prompt

You’ve probably tried the one-giant-prompt approach. A single system prompt that says “you are a world-class marketer and salesperson and engineer and legal advisor.” It kind of works. Until it doesn’t.

Three things break it:

1. Context dilution. Every capability you bolt on makes every answer a little blurrier. The model can’t specialize in ten things at once, because specialization is depth of frameworks, not just knowledge of terminology.

2. No composability. You can’t hand off a sub-task. It’s one persona, so every task starts from zero context.

3. No accountability. When the output is wrong, you don’t know which part of the prompt failed. You tune the whole thing and hope.

Orchestration fixes all three. Each agent gets a narrow job, a clear handoff interface, and a visible mandate that either works or needs rewriting. The system becomes diagnosable. Diagnosable is the precondition for improvable.

Read more

That’s not a feature. That’s a fundamentally different relationship with AI.

Most people use Claude the same way they use Google — reactively. They have a problem, they open the app, they type something. Claude answers. Session ends. Claude forgets it happened. You come back tomorrow and start over. The model is sitting idle 23 hours a day, waiting for you to remember it exists.

Claude Schedule breaks that pattern. It turns Claude from a tool you pick up into a system that runs alongside your work — processing, monitoring, reporting — whether you’re in the room or not. Cowork has /schedule for recurring task cadences. Claude Code has /loop for tight operational cycles. Together they give you something most executives don’t think to build: a Claude that works the night shift.

Here’s how to set it up.

Step 1: Understand What Schedule Actually Is

Before you configure anything, get the mental model right, because the failure mode here is treating Schedule like a calendar reminder. It’s not.

A calendar reminder says “do this at 9 AM.” Schedule says “run this entire Claude workflow at 9 AM, with no human in the loop.” That’s a different thing. It means the prompt you write today will execute — unchanged — on Tuesday, next Tuesday, and the Tuesday after that. The output quality scales directly with the prompt quality. A lazy prompt produces lazy recurring output. A sharp prompt produces sharp recurring intelligence.

There are two implementations.

Claude Cowork /schedule is designed for business cadences — daily briefings, weekly reports, Monday morning pipeline summaries. You set a natural-language schedule (”every weekday at 7 AM”), attach a prompt or task, and Cowork runs it on that interval. Output lands wherever you’ve configured it: in the conversation thread, in a connected integration, in a document. Think of this as your recurring content and intelligence layer.

Claude Code /loop is designed for operational monitoring — tighter cycles, often measured in minutes rather than days. The syntax is direct: /loop 5m /check-deploy runs the /check-deploy command every five minutes until you stop it. This is your CI/CD babysitter, your deploy watcher, your PR queue monitor. It’s built for the terminal, not the boardroom.

Both share one critical constraint you need to internalize before you build anything on top of them: the computer has to stay awake and the app has to be running. These are not cloud-scheduled jobs. There’s no server executing your tasks while your MacBook is in a bag at 35,000 feet. If your machine sleeps, your schedule sleeps. If you quit the app, the loop dies.

This isn’t a bug you need to work around — it’s a design constraint you need to plan around. Set your energy settings to prevent sleep when these workflows matter. Or run them on a machine that stays on. The executives who get the most out of Schedule have a designated machine — an old MacBook, a Mac Mini, something that never closes — where Claude runs continuously. That’s the move.

Step 2: Set Up Your First Scheduled Task in Cowork

Open Claude Cowork and type /schedule in any conversation. Cowork will walk you through the configuration in natural language. You’ll set three things: the timing, the task, and the output.

Timing. Cowork accepts plain English. “Every weekday at 7 AM.” “Every Monday at 9 AM.” “Daily at 6:30 AM.” Don’t overthink the syntax — it’s genuinely conversational. If it misreads your intent, it’ll confirm before saving.

The task. This is your prompt. Write it like you’re writing for a future version of yourself who forgot everything about this project. Include the context you’d normally carry in your head. If you want competitive intel, don’t just say “check on competitors” — tell it which competitors, what signals matter, how you want the output framed. A good scheduled prompt is more explicit than a live prompt, because there’s no back-and-forth to course-correct.

Output. Where does the result go? By default it surfaces in the conversation thread. If you’ve connected integrations, you can route output to email, Slack, or a document.

For Claude Code /loop, the setup is in the terminal. Navigate to your project directory, make sure you have a /check-deploy skill (or whatever command you want to loop) defined, and run:

/loop 5m /check-deploy

That’s it. Claude Code will execute /check-deploy every five minutes, print the result, and run again. Hit Ctrl+C to stop. You can loop any skill, any slash command, or any plain prompt.

The key discipline with /loop: keep the looped command tight and stateless. It should be designed to run in isolation, give you a clear status in a few lines, and complete cleanly. Don’t loop long analytical tasks — that’s what /schedule is for. Loop status checks, monitors, and watchers.

Step 3: Build a Daily Morning Briefing

This is the first scheduled workflow worth building, because you’ll feel the value immediately and it trains you on what good scheduled prompts look like.

Here’s the prompt structure that works. In Cowork, schedule this for every weekday at 6:30 AM (or whenever you actually look at your phone before your first meeting):

Good morning. Give me a daily briefing covering:

1. What's on my calendar today (if calendar is connected) — key meetings and prep I need to do
2. Any open threads or unresolved questions from our recent conversations
3. One thing I should be thinking about that I probably haven't looked at in the last 48 hours

Keep it under 200 words. Be direct. If there's nothing notable, say so.

Adjust the three bullets to match your actual priorities. The point is specificity. “Daily briefing” without structure produces a vague summary. “These three specific things” produces something you can act on in 90 seconds.

After it runs for a week, you’ll start to notice what’s missing and what’s noise. That’s the signal to edit the prompt. Scheduled prompts are living documents — refine them the same way you’d refine any process that runs repeatedly.

What changes when this is working: you stop starting your day in reactive mode. You come into the morning with a frame already built, which means the first hour of work produces more than the next three would have without it.

Read more

That’s what Claude Dispatch makes possible. And it matters more than it looks like at first glance.

The premise is simple: your desktop is always on. You’re not always at it. Dispatch closes that gap. It’s a feature inside Claude Cowork — Anthropic’s desktop app — that lets you remote-control your Claude session from your phone. You send an instruction from mobile, your desktop Claude executes it. You don’t need to be sitting there. You just need to have left the app running.

Launched March 17, 2026, currently in research preview on Max and Pro plans. Here’s how to get it running and, more importantly, how to actually use it.

Step 1: What Dispatch Is and Why It Changes How You Work

Most people treat AI tools as synchronous. You sit down, you prompt, you wait, you read, you iterate. Everything happens in the same session, at the same desk, in the same window of time. That model made sense when AI was a search replacement. It doesn’t make sense when AI can execute multi-hour research tasks, draft entire documents, or process large datasets without you doing anything.

The problem isn’t that Claude is too slow. It’s that you can’t always be at your desktop when you want to start work — and by the time you get there, you’ve lost the window to queue something meaningful before a meeting, before a flight, before the end of the day.

Dispatch solves the activation gap. The instruction you couldn’t send because you weren’t at your desk can now be sent from wherever you are. Your desktop — which is running anyway — picks it up and executes it.

The practical shift this creates: you stop thinking about AI tasks as things you do at your desk and start thinking about them as things you deploy. You’re in a cab, you remember you need a summary of last quarter’s earnings calls before the board meeting. You send it from your phone. By the time you’re through security, it’s done. You’re in a meeting that runs long, and you want Claude to start pulling together the market sizing you need for your next call. You excuse yourself, send the instruction from the hallway, and it’s running before you’re back in the room.

This is the remote work angle that most coverage of Dispatch misses. It’s not just for people working from home or on the road — it’s for anyone whose best thinking about what they need happens when they’re away from their keyboard. Which is most people, most of the time.

The only hard requirement: your desktop must be running Claude Cowork and connected to the internet when the instruction arrives. Close your laptop and you’ve closed the connection. Leave it running and the desktop becomes a persistent compute resource you can trigger from anywhere.

Step 2: Setup — Enabling Dispatch and Linking Your Mobile

You need Claude Cowork installed on your desktop and the Claude mobile app on your phone. Both need to be signed into the same Anthropic account on a Max or Pro plan. That’s the full requirements list.

On desktop:

Open Claude Cowork. Go to Settings. Under the Cowork section, find Dispatch — it’ll be labeled as a research preview feature. Toggle it on. You’ll see a confirmation that your desktop session is now reachable from your mobile device when this machine is running and connected.

That’s the full desktop setup. No API keys, no configuration files, no webhooks to configure. Cowork handles the connection layer.

On mobile:

Open the Claude app on your iPhone or Android device. In the bottom nav or the menu (varies slightly by platform), look for the Dispatch icon — it appears after you’ve enabled it on desktop. Tap it. You’ll see the connection status: either your desktop is online and reachable, or it isn’t.

If your desktop is running and connected, the status shows green. If you turned off your laptop without leaving Cowork running, it’ll show as offline.

Permissions to know about:

Dispatch respects the same permissions and tool access your desktop Claude session has. If you’ve connected Claude Code, file system access, or any MCP integrations to your Cowork session, those tools are available to instructions you send via Dispatch. If you haven’t, Dispatch can still execute any task that doesn’t require local file access — research, drafting, analysis, synthesis.

One thing worth knowing upfront: Dispatch sends your instruction to your existing desktop session. It’s not spawning a new session — it’s sending a message to the Claude instance already running on your machine. If you had an active conversation open when you left your desk, Dispatch picks up in that context unless you specify otherwise. If you want a fresh task to run without prior context, note that in your instruction.

Step 3: Your First Remote Instruction

Before building out power workflows, run one task end-to-end. This is the step that makes Dispatch real rather than theoretical.

Leave your desktop running with Claude Cowork open. Walk away from it — go to another room, or step outside. Pull out your phone and open the Claude app.

Tap into Dispatch. Confirm your desktop shows as online.

Send this instruction:

Summarize the current competitive landscape for [your industry]. I need: the three most active competitors right now, what each one is doing that’s working, and the one move any of them could make in the next six months that would be a real threat to us. We are [one sentence description of your company]. Use publicly available information. Have this ready when I get back to my desk.

Send it. Put your phone away. Go back to your desk in ten or fifteen minutes.

What you’ll find: Claude executed the task against your instruction, in your desktop session, without you sitting there. The output is waiting for you.

This is the moment that reframes how you use the tool. The instruction you couldn’t send because you weren’t at your keyboard can now be sent from anywhere. The gap between “I need this” and “I’m at my desk to start it” disappears.

Run this once on something real. The mechanics become obvious in one use.

Read more

Old world: you find out in the morning, do triage over coffee, and the fix ships mid-afternoon. The pipeline was broken for twelve hours before anyone touched it.

New world with Claude Channels: the failure hits Telegram, Claude Code wakes up, investigates the logs, traces the error, pushes a fix, runs the build again, and messages you back with a three-sentence summary of what happened and what it did. You wake up to a resolved incident instead of an open one.

That’s not a demo scenario. That’s the literal capability Anthropic shipped on March 20, 2026 — and it fundamentally changes what “agentic” actually means in practice.

Step 1: What Channels Is (and Why the Reactive vs. Proactive Problem Matters)

Every AI workflow until now has been pull-based. You open a session, describe what you need, Claude does the work, you close the session. It’s powerful — but it’s still you initiating every single action. Claude sits idle until you show up.

Channels flips that model. It lets external events — a CI failure, a GitHub notification, a Telegram message from a teammate, a Discord mention in your dev server — push directly into a running Claude Code session as triggers for autonomous action. Claude isn’t waiting for you to ask. It’s listening for events, and when they arrive, it works.

The technical implementation is MCP. Channels are MCP servers — specifically, servers that connect Claude Code to messaging infrastructure. Telegram and Discord are the launch integrations, but the protocol is open, which means the surface area will expand fast.

What this unlocks is a different category of automation. Not “Claude helps me do a thing faster” but “Claude handles a class of things without me.” The reactive vs. proactive distinction sounds academic until you experience the difference in your actual operational cadence. Then it’s obvious.

What you need to get started:

• Claude Code v2.1.80 or later (check with claude --version)

• Bun runtime installed (curl -fsSL https://bun.sh/install | bash)

• A claude.ai account (login required — Channels uses your claude.ai identity for the MCP connection)

• Either a Telegram bot token or Discord bot token depending on which channel you’re connecting

Step 2: Setup — Installing the MCP Server and Configuring Your Channel

The Channels MCP server is what bridges your messaging platform to Claude Code. You’re adding it the same way you’d add any MCP server — a JSON configuration block that tells Claude Code where to find it and how to run it.

Step 1: Install the Channels server via Bun

bunx @anthropic-ai/claude-channels install

This installs the server binary and sets up the local runtime. Bun handles the dependency resolution — the reason Bun is required over Node is startup speed. Channels needs to respond to inbound events fast, and Bun’s cold-start time is roughly 4x faster than Node for this workload.

Step 2: Add the MCP configuration to Claude Code

Open or create ~/.claude/claude_desktop_config.json and add the following under mcpServers:

{
  "mcpServers": {
    "channels": {
      "command": "bunx",
      "args": ["@anthropic-ai/claude-channels", "serve"],
      "env": {
        "CLAUDE_CHANNELS_AUTH": "your-claude-ai-token"
      }
    }
  }
}

Your CLAUDE_CHANNELS_AUTH token is available in your claude.ai account settings under Developer → API Tokens. Generate one scoped to Channels if you want to limit surface area.

Step 3: Configure your first messaging platform

For Telegram, you need a bot token. Get one from BotFather — open Telegram, search @BotFather, send /newbot, follow the prompts. Copy the token it gives you.

claude channels add telegram --token YOUR_BOT_TOKEN --name "claude-ops"

For Discord, you need a bot token from the Discord Developer Portal (discord.com/developers/applications). Create an application, add a bot, copy the token.

claude channels add discord --token YOUR_BOT_TOKEN --guild YOUR_SERVER_ID --name "claude-ops"

Step 4: Restart Claude Code

claude restart

On startup, Claude Code will initialize the Channels server and establish the connection to your configured platform. You’ll see a confirmation in the terminal output: Channels: connected (telegram: claude-ops).

Step 3: Your First Channel — Send a Message, Watch Claude React

With the server running and Telegram connected, you have a live two-way bridge between your phone and a Claude Code session.

Open Telegram. Find the bot you just created — search by the username you gave it during BotFather setup. Send it a message:

@yourbot what's the current state of my project?

Watch your terminal. Claude Code receives the message as an injected prompt, runs against your current working directory, and responds — both in the terminal and back to you in Telegram.

That first response will feel underwhelming if you ask something generic. The capability reveals itself when you send it something with real operational context.

Try this instead:

@yourbot run git log --oneline -10 and tell me what's been committed in the last 48 hours

Claude executes the command, reads the output, and sends you a clean summary in Telegram. You just ran a terminal command from your phone via a chat message. That’s the primitive. Everything else in this guide builds on it.

A few things to understand about how the two-way messaging works before you go further:

Claude Code sends messages back through the same channel that triggered it. If the message came from Telegram, the response goes to Telegram. If it came from Discord, it goes to Discord. The session stays alive between triggers — Claude maintains context across multiple messages in the same channel thread, which means you can have a real back-and-forth from your phone without typing a single character in a terminal.

Message length is capped at Telegram’s standard 4096 characters per message. For longer outputs — log analysis, full reports — Claude will chunk the response automatically. You can override this with an instruction in your trigger message: “respond in under 200 words” keeps things clean for quick status checks.

Read more

Most people accept this as the cost of the tool. It’s not. It’s a design problem, and it has a design solution.

Claude’s memory isn’t missing — it’s distributed across five different mechanisms with completely different persistence characteristics. Once you understand which layer does what, you stop losing context and start building memory that compounds. This guide is the map.

Step 1: How Claude’s Memory Actually Works — The Five Layers

Most people interact with exactly one layer of Claude’s memory: in-conversation context. The rest are either unknown or underused, which means they’re leaving most of the infrastructure untouched.

Here’s the full picture.

Layer 1: In-Conversation Context

Everything in your current session. The model processes everything in the context window — every message, every file you’ve pasted, every response it’s generated — and uses it when responding. This is why Claude can refer back to something you said 40 messages ago in the same conversation.

The catch: when the conversation ends, this layer is gone. Not archived somewhere retrievable. Gone. Claude cannot access a previous conversation’s content when you start a new one. This is the layer most people treat as the only layer, which is why they spend the first five minutes of every conversation re-briefing an AI that has no idea who they are.

Layer 2: Projects Memory (Cowork)

Available on Claude.ai Pro and Team plans. Projects give you a persistent context layer that loads automatically at the start of every conversation inside that project. You write Project Instructions once — who you are, what you’re working on, what constraints apply — and every subsequent conversation inherits that context.

The important nuance: this is not transcript memory. Claude doesn’t read your previous conversations before responding in a new one. It has your instructions and your uploaded files, not a running log of what you’ve discussed. This is a crucial distinction when you’re deciding what to put there.

Layer 3: CLAUDE.md / Instruction Files

The most reliable memory mechanism available if you’re using Claude Code. CLAUDE.md is a markdown file in your project root that Claude Code reads at every session start. It’s not a prompt — it’s persistent instruction infrastructure. Changes you make to CLAUDE.md are available in every future session without any setup.

This is where system-level behavior lives: how you’ve structured your project, what agents you’re using and why, how work should be routed, what constraints apply across the entire environment. In a well-configured Claude Code setup, CLAUDE.md is the brain that orients every session.

Layer 4: Memory Files

Explicitly written markdown files Claude reads as part of its session orientation. The MEMORY.md pattern — writing structured context into a file that gets surfaced at session start — is the closest thing to persistent episodic memory Claude Code has. You write down what Claude needs to remember: key decisions made, current state of active projects, important context that would take 10 minutes to re-establish from scratch.

The difference between Layer 3 and Layer 4: CLAUDE.md holds behavioral instructions (how to work), MEMORY.md holds factual context (what’s been done, what’s true). Both load at session start. Both persist across sessions. Together, they close the gap between “AI that starts fresh every time” and “AI that picks up where you left off.”

Layer 5: MCP-Based Memory

External memory stores connected to Claude via the Model Context Protocol. Vector databases, knowledge graphs, retrieval systems — any structured store that can receive a query and return relevant context. This layer enables semantic memory: Claude can search your accumulated knowledge by meaning, not just by keyword, and retrieve relevant context dynamically instead of dumping everything into the context window at once.

This is the most powerful layer and the most complex to set up. It’s the right tool when your memory store has grown beyond what fits in a context window, when you need semantic retrieval across hundreds of notes or documents, or when you’re building a system where accumulated insights need to compound across a team.

The summary: Layer 1 handles your current session. Layers 2-4 handle what persists across sessions through structured files. Layer 5 handles what scales beyond files. Most people only use Layer 1. The good setup uses all five intentionally.

Step 2: Projects Memory — Setting Up Persistent Context in Cowork

The first thing to understand about Projects is what they’re not: they’re not a memory system that learns from your conversations. They’re a context injection system that ensures every conversation starts from an informed baseline. The distinction matters because it changes what you put there.

Projects Instructions should contain context that is true and stable across many conversations: who you are, what you’re working on, your ICP, your voice, your constraints, your company’s competitive position. Not your current active tasks. Not the status of a specific deal. Not what you discussed with a prospect last Tuesday. Stable context, not dynamic state.

Here’s the test: if the information would still be true six months from now, it belongs in Project Instructions. If it’s the current status of something that changes week to week, it belongs in a specific conversation.

What to write in Project Instructions:

Start with four blocks in this order.

First block — who you are and what this project is for:

You are a [role] assistant for [Name], [Title] at [Company].
[Company] is [one-sentence description].
This project is for [specific type of work — writing, GTM strategy, client work, etc.].

Second block — domain knowledge Claude needs to give specific rather than generic advice:

ICP: [Specific description — industry, size, role, trigger events, not just "SMB"]
Primary competitors: [Names and the one key differentiator against each]
Value props ranked by ICP priority: [Specific outcomes, not category claims]
Sales motion: [How you actually sell — PLG, outbound, channel, hybrid]

Third block — output requirements:

Voice: [Specific constraints — first person, short paragraphs, no passive voice]
Format: [What a good response looks like — length, structure, when to use headers]
When to push back: [Where you want Claude to challenge you, not just comply]

Fourth block — what NOT to do:

Do not: [Re-summarize what I just said. Add caveats I didn't ask for.
Give generic advice when specific context is available in uploaded files.
Use passive voice, jargon, or hedged language.]

That fourth block is the one most people skip. Instructions that only tell Claude what to do don’t prevent the default behaviors that frustrate you. Constraints are what make instructions actually change behavior.

What to upload to a Project:

Upload your reference materials — documents Claude would otherwise need you to paste every time. Brand guide. ICP definition. Competitor battlecards. Past content samples (especially important for writing projects — three to five of your best pieces teach voice better than any description). Case studies. Pricing structure. Product documentation.

The upload is permanent context. The paste is per-conversation context. Move anything you paste in more than three times to a file and upload it.

Step 3: CLAUDE.md — The Most Reliable Memory Mechanism in Claude Code

If you’re using Claude Code and you don’t have a CLAUDE.md, you’re running the most powerful version of the tool without its most fundamental memory infrastructure.

CLAUDE.md is read at the start of every Claude Code session. Not sometimes. Every time. It’s the one memory mechanism with zero maintenance overhead — write it once, and it loads in perpetuity. This makes it uniquely reliable compared to every other layer.

What belongs in CLAUDE.md:

The behavioral architecture of your entire working environment. Not task lists. Not current status. The stable structure of how you work.

Three categories to cover:

How work gets routed. If you’ve built specialized agents, CLAUDE.md is where you define the routing rules. Which agent handles which task type, how to classify ambiguous requests, what the tiers of routing complexity look like. Without this, Claude defaults to doing everything itself, which means it ignores the specialized agents you built.

How the vault and file system are organized. Where notes live. Where inbox items go. Where output goes. What the processing pipeline looks like (inbox → distill → notes, not directly to notes). If the architecture is documented in CLAUDE.md, Claude can navigate and maintain it correctly without you re-explaining it.

What the constraints and guardrails are. Things that should never happen regardless of what’s requested: don’t write directly to notes without processing, don’t commit sensitive files, don’t skip quality gates. Hard constraints belong in CLAUDE.md because they apply to every session.

What doesn’t belong: anything that changes frequently. The current status of a project. Your active tasks. What you worked on last session. That’s what memory files are for.

The principle: CLAUDE.md holds behavior. Memory files hold state. The distinction keeps CLAUDE.md clean and stable while allowing your actual working context to evolve without cluttering your behavioral instructions.

Read more

Claude agents change what’s possible. Not because they’re technically impressive — because they restructure how work actually gets done. The difference between researching five competitors one at a time over an afternoon and having five parallel conversations that all finish in fifteen minutes is not incremental. It’s a different category of output. Same effort, different throughput.

You don’t need to write a single line of code to do any of this.

What You’ll Build

• An understanding of how Claude agents actually work — and why sequential use is leaving throughput on the table

• Your first parallel research project running across multiple Claude conversations simultaneously

• The orchestrator + worker pattern for complex, multi-part projects

• Role specialization techniques that produce better output by giving each conversation a specific job

• Background agent workflows for Claude Code users who want to run projects while doing other work

Step 1: What Claude Agents Actually Are

An agent, in Claude’s context, is a Claude instance with a specific role and task running autonomously. Not a different product. Not a plugin. The same Claude — given a defined job, enough context to do it, and the instruction to complete it and report back.

Here’s the insight that changes how you work: Claude Code — Anthropic’s CLI tool — can spawn multiple agents simultaneously. Each one works on a different piece of a larger project at the same time, then reports back to a coordinating conversation that synthesizes the outputs. A project that would take you three hours of sequential Claude sessions takes forty-five minutes because the work runs in parallel.

But you don’t need Claude Code to apply agent thinking. In Claude.ai, you can run multiple browser tabs — each one a separate Claude conversation with a distinct role and task. It’s the manual version of the same pattern. Same principle. Available to any Claude Pro subscriber today.

The core insight is this: most knowledge work isn’t sequential. The five competitor research briefs you need for Monday’s strategy meeting aren’t dependent on each other. The three draft angles you’re evaluating for a content piece can be written at the same time. The four sections of a long document you need reviewed don’t have to wait in line. Once you see which tasks are genuinely interdependent and which ones just feel sequential because you’ve been doing them one at a time, the pattern becomes obvious.

Sequential vs. parallel isn’t about being faster at the same work. It’s about doing fundamentally more work in the same window of time.

Step 2: Your First Parallel Workflow

Open Claude.ai. Open four browser tabs — each one a new Claude conversation.

You’re going to run a competitive research project. The goal is a research brief on four competitors, all finished at the same time rather than one after another.

In each tab, paste this prompt — swapping the competitor name:

You are a competitive intelligence analyst. Research [Competitor Name] and give me:

(1) Their core product offering — what they do and for whom.
(2) Their primary positioning — how they describe themselves, what problem they claim to solve.
(3) Their pricing model — how they charge (if publicly available).
(4) Their most obvious strengths — what they do well based on reviews, case studies, or public evidence.
(5) Their most obvious weaknesses — where customers complain, where they're thin, where they overstate.
(6) One thing about this competitor that most people in my industry underestimate.

Be specific. Cite what you're observing from publicly available information. Don't summarize — give me the analysis.

My company does [brief description of what you do]. Frame the competitor assessment relative to us.

Run all four tabs simultaneously. You’re not watching them in sequence — you’ve started them all and you’re doing something else while they run.

When they finish, open a fifth tab. Paste all four outputs and run this:

I have four competitor research briefs. Synthesize them into one competitive landscape summary:

(1) Where are these competitors positioned relative to each other — what's the map?
(2) Where is there an uncontested or underserved space in this landscape?
(3) Which competitor should we worry about most and why?
(4) Given my company's positioning [describe it], where do we have the clearest angle of attack?

That fifth conversation is the orchestrator. The four research conversations were the workers. The synthesis is the output you actually use.

Total time: fifteen to twenty minutes. The same work done sequentially would be sixty to ninety minutes with the usual momentum loss between sessions.

Step 3: The First Result

Here’s what changes when you run this for the first time.

The parallel output isn’t just faster — it’s structurally different from sequential output. When you research competitors one at a time over an hour, your framing shifts as you go. By the time you get to competitor four, you’re unconsciously filtering what you notice based on what you already found in the first three. The analysis is path-dependent in a way that introduces bias you don’t notice.

Four simultaneous conversations run with the same prompt and the same framing. The starting point is identical. The synthesis conversation gets genuinely comparable inputs — four analyses built from the same brief, not from four sessions of incrementally shifting context.

This is what makes the orchestrator conversation useful rather than just convenient. When the fifth conversation synthesizes four consistent briefs, the gaps it surfaces are real gaps — not artifacts of the order you happened to research things in.

One pattern I’ve seen consistently: the synthesis step surfaces a competitive insight that none of the individual briefs flagged, because the insight only exists in the comparison. Competitor A and Competitor C are both going after the same adjacent segment. That’s not visible in either brief alone. It shows up immediately when someone reads all four at once.

Run this pattern once on a real project. The structural advantage becomes obvious in the first use.

Read more

Not wrong as in incorrect — wrong as in slow. They’re typing the same complex prompts over and over, hoping they remember the exact framing that worked last time, and losing 10–15 minutes per workflow because there’s no repeatability built into how they work.

Skills fix that. They’re the feature most Claude Code users don’t know exists — and once you build a few, you won’t work without them.

This guide walks you through exactly what Skills are, how to use the ones that ship with Claude Code, and how to build your own custom workflows triggered by a single slash command.

Step 1: What Skills Actually Are

A Skill is a markdown file that defines a reusable workflow. Store it in .claude/skills/ inside your project (or globally), and it becomes a slash command you can invoke from anywhere in Claude Code.

Type /commit and Claude doesn’t just write a commit message — it follows a specific workflow: checks staged changes, reads recent commit history to match your style, drafts a message, and creates the commit. That entire workflow is defined in a Skill file.

Here’s what a Skill file looks like:

---
name: review
description: Check content against house style guide and flag issues
---

You are reviewing content against the following style guide rules:
[your style guide here]

When invoked, ask for the content to review if not already provided.
Then check against each rule and return a structured report:
what passes, what flags, and specific suggested edits for each flag.

That’s it. A YAML header with a name and description, followed by whatever instructions you want Claude to execute. When you type /review in Claude Code, Claude loads those instructions and runs the workflow.

The .claude/skills/ directory is just a folder. Files in it become commands. The command name is the filename without the .md extension — so review.md becomes /review.

Skills can include:

• Multi-step workflow instructions

• Specific output formats Claude should produce

• Domain knowledge and context Claude should carry into the task

• Tool use patterns (read these files, run these commands, check this)

• Conditional logic — “if the content type is X, apply format Y”

• Parameters — /competitive-brief Salesforce passes “Salesforce” as an argument to the skill

They’re not macros. They’re not shortcuts. They’re saved playbooks — the same level of precision you’d give a new hire walking through a task for the first time, available on demand, every time.

Step 2: Your First Skill (Built-In)

Claude Code ships with several built-in Skills. The most useful one to understand first is /commit — not because it’s the most impressive, but because it demonstrates exactly what makes Skills valuable.

Before Skills: you’d manually stage your files, think about what changed, write a commit message that may or may not match your project’s conventions, and hope it was good enough.

With /commit: you type one command. Claude checks what’s staged, reads your recent commit history to match the style, drafts a message, and executes. The whole thing takes about 10 seconds instead of 2 minutes.

Try it now. Make a change to any file in a project, stage it with git add, then type /commit in Claude Code.

Watch what happens. Claude doesn’t just string words together — it follows the workflow defined in its Skills file. It checks git status, runs git diff, reads git log to see how you’ve written messages before, then drafts something consistent with your history.

That’s a Skill doing its job.

Step 3: Understanding the Mental Model

Here’s the shift that makes Skills click: stop thinking about prompts and start thinking about workflows.

Every repetitive task you do in Claude Code has a shape. A content review has the same steps every time: load the content, check against the rules, flag the issues, suggest edits. A competitive brief has the same structure every time: company overview, product positioning, pricing, strengths, weaknesses, how to beat them in a deal. A weekly summary pulls from the same sources every time: commit history, notes, decisions made.

The problem isn’t that Claude can’t do these things. The problem is that every time you describe the workflow from scratch, you’re introducing variability. You’ll forget a step. You’ll frame it slightly differently. You’ll get a slightly different result.

A Skill locks the workflow down. The instructions are the same every time. The output format is the same every time. The quality floor doesn’t move.

Think of it this way: you don’t explain to a good employee how to do the same task from scratch each time they do it. You document the process once, they follow it reliably. Skills are that documentation — except Claude executes it automatically every time you call it.

Built-in Skills give you the pattern. Custom Skills give you the leverage.

Read more

Not because they’re writing bad prompts. Because they’re spending half the conversation copying and pasting content that already lives somewhere — a Google Doc, a Notion page, a GitHub repo — just so Claude can read it.

MCP fixes that. And almost nobody outside of developer circles knows it exists.

Here’s what changes once you understand it: Claude stops being a tool you feed information and starts being a tool that goes and gets it.

Step 1: What MCP Actually Is (and Why It’s Not a Developer Thing)

MCP stands for Model Context Protocol. Anthropic released it as an open standard so that Claude — and any other AI — can connect to external tools and data sources in a consistent, predictable way.

Without MCP: Claude only knows what you paste into the chat window. Period.

With MCP: Claude can read a file from your Google Drive, pull up a Notion page, check the status of a GitHub issue, fetch a webpage — all without you touching a single thing. You just ask.

The connectors that make this work are called MCP servers. Each one handles a specific tool. Google Drive has an MCP server. Notion has one. GitHub has one. Slack has one. There are hundreds of them built already, and more appear weekly.

The part nobody tells business professionals: Claude.ai has several MCP integrations built directly into the interface. They call them Connectors. Zero technical setup. You connect your account, and Claude can access your data.

That’s where we’re starting — no command line, no config files, no developer required.

What you need before Step 2:

• A Claude.ai account (Pro or Team tier — Connectors are not available on the free plan)

• Access to at least one of: Google Drive, Notion, GitHub

Step 2: Connect Your First Tool (Google Drive or Notion)

Go to Claude.ai. In the left sidebar, look for Integrations or the connector settings — the exact label has shifted in recent UI updates, but it’s in the main navigation. As of early 2026, it lives under your account settings or the project settings panel.

If you’re using Google Drive:

1. Click the Google Drive connector

2. Authenticate with your Google account — standard OAuth flow, same as connecting any app

3. Grant the requested permissions (read access to Drive files)

4. That’s it

If you’re using Notion:

1. Click the Notion connector

2. Authenticate with your Notion workspace

3. Select which pages or databases Claude can access — I’d recommend starting broad and narrowing later if privacy is a concern

4. Done

Once connected, Claude can see those files. You don’t have to paste anything. You just reference them in your prompt.

One important thing to understand: Claude doesn’t browse your entire Drive proactively. It reads what you point it to. The connection enables access — you still direct it.

Step 3: Get Claude Reading One of Your Files

This is where it clicks.

Open a new conversation in Claude.ai. Make sure you’re in a project that has your connector enabled (if you set it up at the project level) or that you’ve enabled it at the account level.

Try one of these prompts exactly as written — just substitute your actual file or page name:

Google Drive:

“Read my file called [exact file name] in Google Drive and give me a one-paragraph summary of the main argument.”

Notion:

“Pull up my Notion page called [page title] and tell me the three most important decisions documented there.”

Watch what happens. Claude fetches the file, reads it, and responds — without you touching a single thing.

If you get an error, the most common fix is re-authenticating the connector. Occasionally the OAuth token expires and needs a refresh. Go back to connector settings, disconnect, reconnect.

Once that works, you’ve crossed the threshold. That’s MCP. That’s what the rest of this guide builds on.

Read more

Projects fix this. One setup, persistent context, every conversation in that project starts informed. It’s the difference between having an assistant who knows your business and having a stranger who needs a full briefing every single time.

This guide is not about what to use Claude for — there are separate guides for that. This is about how to set up the infrastructure that makes Claude consistently useful instead of occasionally useful.

What You’ll Build

• A working Project with custom instructions that shape every conversation without you having to set the stage

• Uploaded files Claude can pull from every time — your brand guide, product docs, ICP definition, competitor intel

• An organized conversation structure within the project so different workstreams don’t bleed into each other

• By the end of this guide, four concrete Project setups for the highest-value use cases

Step 1: What Claude Projects Are (and What They’re Not)

Every new Claude conversation normally starts from zero. The model has no memory of what you discussed yesterday, last week, or five minutes ago in a different tab. That’s not a bug — it’s how the model works. But it creates friction when you’re doing recurring work and the same context needs to be present every time.

Projects solve this problem with three components:

Project Instructions — a custom system prompt that runs in every conversation inside the project. This is where you define who you are, what you’re working on, how you want Claude to behave, and what constraints apply. Every conversation in the project inherits this context automatically.

Uploaded files — documents, PDFs, and text files that Claude can reference in any conversation in the project. Brand guidelines, product documentation, competitor battlecards, pricing sheets, style guides, ICP definitions — upload them once and they’re always there.

Conversation history — all conversations within the project are stored together. Claude cannot automatically read a previous conversation while you’re in a new one, but the Project Instructions and uploaded files create an informed baseline that every conversation starts from.

Projects are available on Claude.ai Pro ($20/month) and Team plans. The free tier does not include Projects.

What Projects are not: they’re not magic memory that carries conversation context from one chat to the next automatically. They’re a persistent context layer — instructions and reference materials always present, not a conversation transcript Claude reads before responding.

The use case is simpler than the feature sounds. Instead of starting every conversation with “I’m a VP of Marketing at a B2B SaaS company focused on mid-market healthcare, here’s our ICP, here’s our messaging framework, here’s our style guide” — you write that once in Project Instructions and never type it again.

Step 2: Setting Up Your First Project

Go to claude.ai. In the left sidebar, you’ll see a “Projects” section with a “Create project” option. Click it, give it a name, and you’re in.

The two things to configure immediately:

Project Instructions. This is the highest-leverage thing you’ll do in this entire guide. Click “Set project instructions” (or “Edit project instructions” if you’ve been here before) and write your context. Be specific. A vague instruction produces vague improvement — or none at all.

Most people write something like: “You are a helpful assistant for my marketing work.” That’s not an instruction. That’s ambient noise.

A useful instruction looks like this:

You are a writing and strategy assistant for [Name], VP of Marketing at [Company].
[Company] is a B2B SaaS platform for mid-market healthcare operations. Our ICP is:
Operations directors and CMOs at independent physician groups (20-200 physicians),
$5M-$50M revenue, typically running Epic or athenahealth.

Core product: [product name]. Key outcomes we sell: [outcome 1], [outcome 2], [outcome 3].
Primary competitor: [Competitor]. Our main differentiators vs. them: [differentiator 1], [differentiator 2].

When helping with written content, match our brand voice: direct, clinical without being cold,
evidence-based. We do not use passive voice, we do not use jargon like "leverage" or "synergies,"
and we do not make claims we can't support with data.

When helping with strategy, push back on assumptions. Ask for the data before accepting a premise.

That’s an instruction. It shapes every single conversation in the project without you having to re-establish context.

Uploaded files. Once instructions are set, upload your reference documents. Click the paperclip or file icon inside the project to add files. Start with the documents you re-paste most often.

Step 3: Your First Working Result

With instructions set and at least one file uploaded, open a new conversation inside the project. Notice that you don’t need to introduce yourself or explain what you’re working on. Claude has the context from your instructions.

Ask it something you’d normally spend two minutes front-loading with context. “Review this email against our brand voice guidelines” — paste the email, nothing else. Claude knows your voice guidelines from the instructions. “Does this positioning statement align with how we differentiate from [Competitor]?” — paste the statement. Claude has the competitor context.

This is the shift. The context is infrastructure now, not a prompt tax you pay every conversation.

If something comes back off, it means your instructions need to be more specific. Edit them. Add a constraint. Add an example of what you want. Instructions are a living document — the best Project Instructions are ones that have been refined through five conversations, not written once and never touched.

The rule: if you find yourself correcting Claude for the same thing in multiple conversations, that correction belongs in your Project Instructions.

Read more

The work is real. The problem is that it’s reactive. Something slips through onboarding because no one checked. A performance calibration runs long because no one did the distribution analysis ahead of time. A pulse score drops and leadership finds out in the all-hands instead of in the HR report.

Cowork threads know your cycles. You seed them once — with your hiring context, your review rubric, your onboarding checklist — and every time that cycle comes back around, the thread already has everything it needs to get you to the analysis fast. The work still happens. Cowork makes sure it happens systematically, not reactively.

This guide sets up five persistent threads for the recurring rhythms HR owns: recruiting pipelines, onboarding readiness, performance review prep, employee pulse, and headcount planning.

What You’ll Build

Five persistent threads, each with a job:

1. Recruiting Pipeline Monitor — weekly view of which roles are at risk and what sourcing needs to happen

2. Onboarding Readiness Tracker — weekly flag of what’s not ready before Day 1

3. Performance Review Prep Thread — calibration-ready summaries with distribution analysis and equity flags

4. Employee Pulse Monitor — monthly survey analysis that surfaces what leadership needs to act on

5. Headcount Planning Thread — quarterly scenario modeling against budget and attrition data

Step 1: Setup

Claude Cowork runs inside Claude.ai. On desktop, find Projects in the left sidebar — that’s the persistent context layer where threads live. On mobile (iOS and Android), same app, same threads.

Name your threads clearly. You’ll be checking some of these from your phone between meetings:

• HR: Recruiting Pipeline

• HR: Onboarding Readiness

• HR: Performance Review

• HR: Employee Pulse

• HR: Headcount Planning

No integrations required. No API keys. No IT ticket. The threads work from copy-paste — whatever you can pull from your ATS, HRIS, or survey tool, you drop in.

Step 2: Recruiting Pipeline Monitor

The weekly recruiting sync happens because someone needs to ask the questions that should already be answered: which roles are behind, where the pipeline is thin, what sourcing isn’t working. It’s a reactive meeting. It doesn’t have to be.

Open your HR: Recruiting Pipeline thread and paste this to seed it:

You are my recruiting pipeline analyst. I'm going to give you context on our open roles,
hiring manager priorities, target start dates, and sourcing channels. Hold this context
across all future updates I give you.

Open roles: [paste your current open req list with department, level, hiring manager,
target start date, sourcing channels active]

For each role, track: stage distribution (applied / screened / interview / offer),
days open, and any sourcing context I give you.

Then each week, paste your pipeline update and use this prompt:

Here's the recruiting pipeline update: [paste — role, stage, count, status]

Produce:
1. Which roles are at risk of missing the target start date and why
2. Where the pipeline is thinning — stages with fewer candidates than needed
3. Recommended sourcing actions for the 2 most critical open roles
4. What I should communicate to hiring managers today

Recruiting updates that used to require a 30-minute weekly sync get to the point in 5 minutes. The thread remembers your roles, your hiring managers, your timelines. You’re not re-explaining context every week — you’re just dropping in new data.

Step 3: Your First Result

Before you read further, run the pipeline thread once with a real update.

Paste your current open roles and one week of pipeline data. Review what comes back. You’re looking for the thread to flag the right risks — roles that are old and thin at the top of funnel, or roles where the interview stage has stalled.

The output won’t be perfect on the first pass. Add context where it’s missing: tell the thread which roles have the most pressure, which hiring managers need proactive communication, whether you’re capacity-constrained on the sourcing side. The thread holds all of it.

On mobile, the thread is right where you left it. Before your Monday morning recruiting review, open the app, pull up the thread, check the flags. You walk into the meeting knowing what matters.

That’s the first win. The rest is below the line.

Read more

Claude Cowork adds a proactive layer. Persistent agent threads that maintain context across sessions — running on Desktop, iOS, and Android — mean the contract queue is visible before stakeholders complain, the renewal window is caught before it closes, and the regulatory update is briefed before leadership asks. The legal team that knows what’s coming has more leverage than the one that finds out when it lands.

One important framing before we get into the setup: Cowork assists with legal workflows — drafting, organizing, summarizing, tracking — but does not provide legal advice. Every output from these threads should be reviewed by qualified legal counsel before use. These are operational tools for managing the volume and visibility of legal work, not substitutes for legal judgment.

What You’ll Build

By the end of this guide you’ll have two persistent Cowork threads running without you touching them again: a weekly contract queue monitor and a monthly regulatory update tracker. You’ll also have the exact prompt templates to build three more threads — matter status digest, contract renewal monitor, and policy review queue — copy-paste ready, not illustrative sketches.

Step 1: Get Set Up

What plan you need: Claude Cowork requires Claude Teams or Claude Max. For a legal team with 2–6 attorneys and paralegals, Claude Teams at $30/user/month is the right tier. Solo in-house counsel can run it on Max.

Accessing Cowork: On Desktop (Mac/Windows), open Claude and look for “Cowork” in the left sidebar — it’s a dedicated section below your regular conversations. On iOS and Android, it’s under the same sidebar menu. The interface is a thread list, not a single chat. Each thread has a name, a schedule, and its own persistent context.

The one setup step that changes everything: Go to Settings → Notifications → Cowork Delivery. Turn on “Notify me when a scheduled thread completes.” You want a push notification when the contract queue lands on Monday morning, not to remember to go look for it. The difference between a tool you use and a tool that works for you is whether it interrupts you with results or waits for you to remember to check.

Step 2: Create Your First Thread — Contract Queue Monitor

This is the one that solves the most immediate pain. Contract requests pile up. SLAs slip. Business stakeholders send follow-up emails that start politely and get less polite. The queue monitor makes the backlog visible before it becomes a relationship problem.

Click “New Cowork Thread” in the sidebar. Name it “Contract Queue Monitor.” Schedule it weekly — Mondays at 7 AM is the right call. You want this before the week starts, not after your inbox has already filled with questions about it.

Seed the thread with four things before the first run:

• The contract types you handle (MSA, NDA, SOW, vendor agreement, etc.)

• The standard SLA for each type (NDA: 3 business days; MSA: 10 business days, etc.)

• Your escalation criteria (deal size threshold, counterparty risk tier, regulatory exposure, etc.)

• Key stakeholders waiting on contracts (Sales, Procurement, Finance — whoever you need to communicate status back to)

Here’s the full prompt:

You are my weekly contract queue manager. I'll paste the current contract queue into this thread each Monday. Use the following context to analyze it:

CONTRACT TYPES AND SLAs:
[Paste your contract types and turnaround standards here]

ESCALATION CRITERIA:
[Paste your escalation triggers here — e.g., contracts over $500K, contracts touching regulated data, deals in final-stage pipeline]

KEY STAKEHOLDERS:
[Name the teams/roles waiting on contracts and what they need to know]

Each Monday when I paste the queue (format: contract name, type, requestor, date received, current status), produce four outputs:

1. CONTRACTS PAST SLA — List every contract past its turnaround standard. For each: how far past SLA it is, and what the downstream business impact is (deal at risk, vendor relationship, compliance deadline).

2. ESCALATION FLAGS — Any contracts that meet the escalation criteria we defined. Why they qualify and what action is needed.

3. STAKEHOLDER COMMUNICATIONS — Draft the status update to send to business stakeholders waiting on contracts. Specific by team: what's done, what's in review, what they should expect and when.

4. ONE-THING CALL — The single action that would most reduce queue backlog this week. Not a list of things. The one thing.

All outputs should be reviewed by qualified legal counsel before use or communication.

After pasting the prompt, hit “Schedule.” Then reply to the thread with your SLA table and escalation criteria. Claude will hold that context for every future run — you don’t re-explain it every week.

Step 3: Your First Result

The first queue run will land Monday morning. You paste the queue list (contract name, type, requestor, date received, status — takes 5 minutes to pull from your tracker), and Claude returns four outputs: the past-SLA report, escalation flags, stakeholder communications, and the one-thing call.

After the first run, do one thing: reply to the thread with a sentence or two about your team’s current capacity constraints. Something like: “We’re currently a team of two with one attorney on leave through month-end.” The prioritization gets sharper when Claude understands what’s actually available.

From your phone mid-week, you can reply to the thread with a follow-up: “What’s the downstream impact if the Acme MSA slips another week?” Claude knows the context — the contract, the SLA, the stakeholder — and gives you a specific answer rather than a generic one.

Read more

And through all of it, the data team is expected to do analysis. Strategic work. The work that actually moves the business. Instead, they’re triaging Slack messages at 9 PM because someone noticed a metric changed and nobody knows why.

Claude Cowork is persistent agent threads in Claude Desktop, iOS, and Android. You build a thread once — teach it your data sources, your quality thresholds, your metric definitions, your stakeholder context — and it runs. Every week, you paste in the data. What comes back is a structured brief that replaces 90 minutes of manual work with 10 minutes of review. The analysis doesn’t live in your head anymore. It lives in the thread. And the thread remembers.

What You’ll Build

Five persistent threads that cover the data team operating cadence:

1. Data Quality Monitor — Weekly thread that catches quality issues before they become dashboard disasters

2. Metric Anomaly and Insight Digest — Weekly brief that turns raw numbers into the insight leadership actually needs

3. Reporting Cadence Manager — Weekly thread tracking every report, every SLA, and every delivery risk

4. Stakeholder Request Queue Manager — Weekly prioritization of the ad hoc request queue — by logic, not FIFO

5. Data Strategy and Roadmap Thread — Monthly thread that turns recurring pain points into a roadmap your leadership will approve

Step 1: Setup

Time required: 20 minutes. No developer. No API.

Access: Claude.ai Pro or Team plan. Desktop app is recommended for data work — you’ll be pasting exports and reports regularly, and the desktop clipboard handling is faster than mobile.

The one thing to do before you build threads: Document your context once in a master setup note. Your data sources. Your key metrics and their definitions. Your stakeholders and what they care about. Your team capacity. You’ll paste pieces of this into each thread seed — having it in one place means setup takes 20 minutes instead of an hour.

Thread naming convention:

• Data Quality Monitor — [Team/Quarter]

• Metric Digest — Weekly

• Reporting Cadence — [Quarter]

• Request Queue — [Month]

• Data Strategy — [Quarter]

Step 2: Data Quality Monitor Thread

This is the thread that catches what your dashboards miss — before your stakeholders find it first.

Create a thread named Data Quality Monitor. No schedule needed; you’ll trigger this manually each week when you run your quality checks.

Seed prompt — paste this first:

DATA QUALITY MONITOR SETUP

You are my weekly data quality analyst. I'll paste a data quality report each week.
Your job is to flag issues before they reach stakeholders or break downstream reports.

My key data sources and their SLAs:
- [Source 1 name]: refreshes [daily/hourly], SLA is [X hours after expected refresh], downstream: [reports/decisions it feeds]
- [Source 2 name]: refreshes [weekly], SLA is [X], downstream: [...]
- [Source 3 name]: refreshes [real-time], SLA is [X], downstream: [...]

Quality dimensions I track:
- Completeness: [key fields that must not be null — e.g., "customer_id, transaction_date, revenue"]
- Accuracy: [fields with known ranges or validation rules — e.g., "revenue should not exceed $500K for a single transaction"]
- Freshness: [last-refresh timestamp per source, acceptable lag]
- Consistency: [cross-source checks — e.g., "order count in Shopify should match order count in warehouse"]

My quality thresholds:
- [Source] completeness: flag if [field] null rate exceeds [X]%
- [Source] freshness: flag if last refresh is older than [X hours]
- [Source] accuracy: flag if [metric] outside [range]

Weekly prompt — paste this each week with your report:

Here's this week's data quality report: [paste — source, metric, current value, threshold]

Flag:
1. Any metric below threshold — how far off, and which downstream reports or decisions are affected
2. Any data source that's stale — last refresh timestamp and business impact
3. The one data quality issue most likely to cause a business stakeholder to lose trust in our data
4. What the data engineering team needs to prioritize this week

The thread builds a running record of quality patterns across weeks. By month three, you’ll know which sources fail on the same day every month, which fields are structurally unreliable, and which downstream reports are most exposed. That’s the intelligence that turns reactive firefighting into proactive infrastructure work.

Step 3: First Run

Paste the seed prompt. Then paste your first quality report — even if it’s just a rough export from your monitoring tool or a manual check. Claude will map the structure to your setup.

After the first run, add two things to your seed prompt: (1) the names of the specific dashboards or reports that are downstream of each source, and (2) the names of the stakeholders who own those dashboards. When a quality issue hits, the output changes from “this affects the revenue dashboard” to “this affects the revenue dashboard that Sarah’s leadership team reads every Monday.” That specificity is what makes the brief actually actionable.

Quality issues caught before the dashboards are wrong. That’s the job.

Read more

The problem isn’t data. You have more data than you can act on. The problem is the gap between the data existing and the data meaning something — and that gap is filled by a small team of analysts who are already maxed out.

The backlog looks familiar: the EDA your lead analyst started but hasn’t finished because three other things landed. The data quality audit that’s been “on the roadmap” for two quarters. The metric definitions that live in nobody’s head and everywhere’s Slack. The dashboard spec that gets handed to engineering missing half the decisions, then comes back missing half the insight.

Claude Code doesn’t replace your analysts. It removes the parts of their day that don’t require them — the mechanical first passes, the formatting, the query scaffolding, the document structuring — so they can spend their time on the judgment calls that actually do.

The 1M token context window is the thing that makes this different for data teams specifically. You can paste the full schema, the messy CSV, and the stakeholder request simultaneously and get output that’s grounded in the actual data structure — not a generic template that assumes a clean warehouse you don’t have.

What You’ll Build

1. An exploratory data analysis brief (from raw CSV to insight summary in 20 minutes)

2. A data quality audit report with a prioritized remediation plan

3. A metric definition document your data catalog has been waiting for

4. A dashboard specification that actually guides engineers

5. SQL queries with plain-English explanations and performance flags

Step 1: What You Need and How to Start

Claude Code is available on the Max or Team plan, inside Claude.ai.

Before you paste data or give a task, set context first. Data analysts skip this and then wonder why the output reads like it was written for a general audience.

I'm a [Data Analyst / Analytics Engineer / Head of Data] at [Company Name].
We sell [what you sell] to [who you sell to]. Our data stack is [Snowflake/BigQuery/
Redshift + dbt / Looker / etc.]. When I ask you to analyze data or write queries,
prioritize business interpretability over technical precision — flag tradeoffs when
they exist. I'll give you specific tasks in a moment.

That context statement changes what you get back. Do it every session.

Step 2: Exploratory Data Analysis Brief

You’ve received a new dataset. Maybe it’s from a product team handoff. Maybe it’s a vendor export. Maybe it’s your own data that nobody has formally characterized. The first move is always the same: understand what you have before you analyze it.

Paste your CSV — or a representative sample (1,000–5,000 rows) if it’s large — and use this prompt:

Run an exploratory data analysis on this dataset and produce:

1. Dataset overview — number of rows, columns, data types, and what each column
   appears to represent based on its name and values
2. Data quality issues — nulls by column (flag anything >5%), potential duplicates,
   and values that look like outliers or errors
3. Key distributions — for numeric columns: mean, median, range, and any notable
   skew; for categorical columns: top values and their frequencies
4. Correlations — pairs of variables with notable relationships, positive or negative
5. The 3 most interesting findings in this data — what a senior data analyst would
   flag for further investigation
6. Recommended next analysis questions based on what you see

Format the output as a structured brief I can share with stakeholders or use to scope
the next phase of analysis.

Here is the dataset:
[paste CSV]

EDA that would take a full day of Pandas and matplotlib — building the environment, writing the profiling code, formatting the output, writing the summary — in 20 minutes. The output isn’t a replacement for deep analysis. It’s the starting point you’d spend a day building before you could even get to the interesting questions.

The 3 most interesting findings prompt is the part most EDA tools skip. You don’t just want the statistics. You want the interpretive layer — the thing that tells you where to look next.

Step 3: Save Your Data Profile as a Reusable Reference

Before you close the session, ask Claude Code to produce a one-page data dictionary from the EDA output — column names, inferred data types, description of each field, and any quality flags. Save it.

Based on the EDA you just ran, produce a data dictionary in table format:
| Column Name | Data Type | Description | Quality Flags |

This will serve as the canonical reference for this dataset going forward. Keep
descriptions to one sentence. Flag any columns with quality concerns in the
Quality Flags column.

Now you have documentation that didn’t exist five minutes ago — and every analyst who touches this dataset in the future doesn’t have to reverse-engineer it from scratch.

Read more

A contract sits in the queue for a week because the attorney is handling three deals and a regulatory filing. An NDA that should take 20 minutes to review is still waiting on Thursday because Monday’s stack never cleared. The GC knows there are auto-renewals triggering next month — they just haven’t had time to pull the report and look.

Claude Code doesn’t fix the law. It fixes the bandwidth problem. It handles the first pass — the summary, the comparison, the risk flag — so that when the attorney’s time arrives, it’s spent on judgment, not on reading the same boilerplate for the fourth time.

That’s the trade. Not AI as lawyer. AI as first-pass analyst that compresses the pre-work.

One caveat that I’ll say once and mean throughout: Claude Code assists with legal workflows. Every output produced using these prompts requires review by qualified legal counsel before use. This is a tool for the first pass — not the final word.

What You’ll Build

1. A contract summary generator — plain-English review of any agreement in minutes, not days

2. A contract clause comparator — side-by-side analysis across multiple vendor agreements

3. A contract database audit — visibility across your full contract portfolio before things expire

4. A policy gap analyzer — systematic identification of what your policy library is missing

5. An NDA redline analyzer — pre-negotiation analysis that compresses the back-and-forth

Step 1: Understand What You’re Working With

Claude Code is Anthropic’s AI environment at claude.ai. You describe what you want to analyze — in plain English — and Claude works through it. No legal software required, no specialized tools. The skill is learning to be specific about what you paste in and what you want to come out.

The 1 million token context window is what makes this practical for legal work. You can paste an entire contract — full text, every exhibit, every schedule — and Claude Code has the whole thing in front of it at once. It’s not summarizing what it skimmed. It’s reading all of it.

To get started: Go to claude.ai, start a new project, and open Claude Code. You need a paid plan (Pro or Teams).

Step 2: Build Your Contract Summary Generator

This is where most legal teams find the immediate win. Take any contract — NDA, vendor agreement, customer agreement, SOW — and paste the full text. Then run this prompt:

I'm reviewing this contract and need a structured first-pass analysis to inform discussion
with counsel. Please produce:

1. One-paragraph plain-English summary — what this agreement does, who the parties are,
   what each party commits to

2. Key commercial terms — term length, payment terms, termination rights, auto-renewal
   clauses, notice periods

3. Top 5 risk provisions — clauses that favor the other party or create material exposure
   for us. For each: quote the relevant language, explain the risk in plain English

4. Missing standard protections — what's absent that we'd typically expect in this type
   of agreement (indemnification, limitation of liability, IP ownership, etc.)

5. 3 questions I should ask before signing or before sending to counsel for review

Note: this is a first-pass review to inform discussion with counsel, not legal advice.

[PASTE FULL CONTRACT TEXT HERE]

What you get back: A structured analysis that tells you what you’re looking at, where the risk lives, and what’s missing — in language anyone on the team can act on. The attorney who reviews it next is starting from a flagged document, not a cold read.

This isn’t a lawyer replacement. It’s the first-pass that saves the lawyer time. The difference between “here’s a contract, what do you think?” and “here’s a contract — here are the five clauses I flagged, here are the three missing protections, what’s your take?” is about four hours of attorney time per agreement.

Step 3: Your First Result

Most teams run this the first time on a contract they already know. An NDA they’ve reviewed. A vendor agreement that’s been signed for two years. They want to verify the output before they trust it.

What usually happens: the summary is accurate. The commercial terms section catches the auto-renewal they’d forgotten about. The risk provisions flag something the team knew was there but hadn’t articulated clearly. And the “missing standard protections” section surfaces something they’d missed — or a conversation they should have had before signing.

Take that result seriously. The point of the first pass isn’t the final answer — it’s making sure nothing gets through unchecked because the queue was too deep.

Read more

Compensation data sits in a spreadsheet that nobody has time to audit for equity. Engagement survey verbatims pile up unread because tagging takes too long. Attrition data lives in an HRIS export that nobody has analyzed since the last time someone left. Headcount modeling happens in a CFO conversation nobody prepped for. Job architecture stays inconsistent because the job that would fix it takes a week no one can find.

Claude Code reads all of it. The 1 million token context window means you can paste three years of attrition data, the full compensation file, and the engagement survey results simultaneously — and ask a single question that connects all three. No SQL. No data analyst. No six-week consulting engagement.

This guide walks through five data-heavy HR workflows that live in spreadsheets and never get the analysis they deserve.

What You’ll Build

1. A compensation equity analyzer — flags pay gaps, market risk, and recommended adjustments in a format you can bring to the CFO

2. A headcount and org design model — span of control, layer analysis, cost concentration, and two headcount scenarios

3. An engagement survey analyzer — themes from verbatims, score movements, and the one intervention most likely to move the needle

4. A job architecture builder — titles, families, levels, and career pathing from your current role inventory

5. An attrition analysis and prediction model — who’s leaving, when, and the leading indicators in your current workforce

Step 1: Understand What You’re Working With

Claude Code is the AI environment inside Claude.ai. You describe the analysis you want — in plain English — and Claude builds it. No Python required. No pivot table expertise. The skill is learning to be specific about two things: what data you’re putting in, and what output you need to do something with.

The 1 million token context window is what makes this work for HR. It means you’re not sampling your compensation data or summarizing your survey results before Claude sees them. You’re pasting the full file — every row — and asking Claude to find what’s actually in it.

To get started: Go to claude.ai, open a new project, and start Claude Code. You need a paid plan (Pro or Teams).

Step 2: Compensation Equity Analyzer

Compensation equity analysis is one of those things HR knows needs to happen and rarely gets done because it requires either a consultant or a data analyst who doesn’t have the bandwidth. Claude Code turns it into an afternoon.

Pull your compensation data from your HRIS. You want at minimum: employee ID (anonymized as needed), role, level, department, base salary, bonus target, tenure, and gender or other demographic dimensions if tracked and if your organization has a policy for including them in equity analysis. Remove names. You can keep anonymized IDs if you need to trace back to specific employees later.

Paste the data and use this prompt:

Analyze this compensation data for equity issues. Produce:

1. Average and median compensation by role and level — flag any roles with wide ranges
   that suggest inconsistency in how we've been setting pay
2. Any statistically significant compensation gaps by demographic dimension (if data is
   included)
3. Employees most likely to be at market risk — below the 25th percentile for their
   role and level
4. Recommended adjustments by priority — highest flight risk first
5. An equity summary I can bring to the CEO and CFO with the business case for
   adjustments

[PASTE COMPENSATION DATA]

What you get back: Compensation equity analysis that used to require a consultant takes an afternoon. The summary section is particularly useful — it frames the adjustments as a retention and risk story, not just a fairness story, which is the frame that moves budget conversations.

One thing to do next: ask Claude Code to model the cost of bringing the flagged employees to the 50th percentile for their role. That number is almost always smaller than leadership expects, and having it ready turns a principle discussion into a budget decision.

Step 3: Your First Result

Run the compensation analysis before you read further. Use real data — even if it’s just one department to start.

What you’re looking for in the output: is the analysis surfacing things your team already suspects but hasn’t been able to quantify? Are there roles where the pay range is so wide it suggests the title is being used for two distinct levels of work? Is there a tenure band where employees are clustering at below-market pay?

The equity summary section matters most. Before you take anything to the CEO or CFO, read it like they will. If the business case isn’t clear in the first paragraph, ask Claude Code to sharpen it: “Rewrite the executive summary to lead with retention risk and cost, then move to the equity case.”

That’s the first output worth taking somewhere. The rest is below the line.

Read more