Claude

The chat box grew hands

You have probably used Claude to clean up a draft, summarize a document, or find something in a connected app. That is the first experience most of us had with AI: I ask, you tell me, and that is the game. The next step is handing it a real piece of work.

Take a monthly marketing review. Website traffic and search data live in one place, advertising and lead reports in HubSpot, email results in Constant Contact, and sales in Square. Somebody has to go to all four, pull the numbers, reconcile them in their head, and explain what happened.

With the right connections and instructions, Claude can do that legwork and hand you an analysis: what changed, which campaigns look like they are working, which spending can be linked to sales, and where that connection is uncertain. You read it, ask a couple of follow-up questions, and decide where next month’s budget goes.

That is what we mean when we say the chat box grew hands. You describe the outcome, give Claude access to the tools and information it needs, and set boundaries around what it is allowed to do. Then it works through the steps.

Most people go through the same progression: asking for help, then delegating a task, then making that task repeatable, and sometimes letting it run on its own. Each step is easier once you understand a handful of ideas underneath, and that is what this article is about.

A word on scope. We use a range of AI tools — Gemini, ChatGPT/Codex, Copilot — but Claude is the one we build with most, for our own operations and for client work, so this guide focuses on Claude. The ideas carry over: every major provider has some version of connectors, saved instructions, and agents, under different names. The specifics here are Anthropic’s.

For the background — how a language model works, how Claude compares to the alternatives — see Understanding AI. Here we start where chat leaves off.

Getting Claude access: connectors

Out of the box, Claude cannot read your analytics, your ad spend, or your sales. It has no access to anything. The marketing review only works because each of those systems has a connector.

A connector hands Claude a short menu of things it can do in one application: read a report, list the campaigns, create a document. Most connectors use MCPAPIs define how software communicates with software. MCPs (Model Context Protocol) let AI models connect to tools directly — no custom integration code needed., the Model Context Protocol, an open standard Anthropic introduced. Every application has its own way of exchanging information; MCP is the Rosetta Stone, one common way for an AI tool to work with any of them. You do not need to know how the application works underneath, and neither does Claude.

Some connectors are published by the application’s own developers and reviewed by Anthropic, the way apps get into an app store — Slack, Zoom, and the Google tools, for example. There are far fewer of those than there are applications in the world, so for everything else your organization can build a custom connector. That is infrastructure your IT team provides. If you have a useful workflow in mind and the connection does not exist yet, asking for one is a reasonable next step.

A connector is also a filter. An application will usually let an integration do everything the application can do, including things nobody should be able to do by accident. Google Drive can permanently delete everything. Our connector for it offers “move to trash,” which gives you 30 days to recover, and simply does not offer permanent deletion. Permanent deletion was unnecessary for the work, so we left it out.

Which actions a connector exposes is the first layer of control. A good connector gives Claude enough access to do the job and keeps everything else out of reach; the other layers are covered below, under permissions.

Where the work happens

Claude comes in a few forms, and the practical difference between them is where the work runs. That determines which files and applications it can reach, what it can change, and whether the task keeps going after you close your laptop.

Chat is where you already are. It is a natural fit for questions, drafts, analysis, and conversations that build over time, and it can use any connector you have enabled. The marketing review may need nothing more than this.

Cowork carries a task through several steps — reading files, using connected applications, working through a web page — without you sequencing each one. Through the desktop app it can also reach files on your computer, subject to the access you grant. Anthropic is merging chat and Cowork into a single conversation, rolling out plan by plan, so the handoff happens as the work gets more involved. Longer tasks keep running in the cloud after you close your laptop; steps that need files or apps on your computer still need it open. Anthropic’s overview explains the current arrangement.

Claude CodeAnthropic's agentic coding tool. Runs in your terminal, reads files, writes code, and executes commands directly in your development environment. works through a computer’s command line to build software, connect systems, and maintain websites. It runs on your laptop or on a virtual machineA software-based emulation of a physical computer. Multiple VMs run simultaneously on one physical host, each with its own OS, sharing CPU, RAM, and storage through a hypervisor. — a separate computer set up for the work. It can make lasting changes to that computer’s files and software, within the permissions and isolation configured for it. This is the one to reach for when the result is a working tool, an integration, or a website.

Claude for Chrome covers the gap the others cannot: applications where somebody has to click through a website. Claude navigates the pages, enters information, and looks at what appears on screen. It is also the tool most worth respecting. A signed-in browser can reach a lot, so start with a narrow task and follow along while an unfamiliar workflow runs.

Teaching it the job

Access gets Claude to the information. Instructions tell it what to do with it.

For the marketing review, that might mean: compare this month with last, exclude traffic from our own office, treat the campaign dates as the window for measuring lift, and say plainly when the data cannot support a conclusion. These are the same things you would tell a colleague taking over the work, and you write them the same way, in ordinary language. If you can explain to a colleague how to do a thing, you can probably explain it to Claude.

A useful handoff includes three things: the information to use, the result you expect, and the decisions that still belong to you. Say what to do when something is missing or contradictory. Often the most important instruction is when to stop and ask.

Some instructions should apply to everything: how to refer to your organization, which writing conventions to follow, what needs a review before it goes out. Put those in project or organization instructions and every session starts already knowing them, instead of you repeating them in every request.

Memory is the same idea pointed the other direction: carrying forward what Claude learned. Within one conversation, everything said so far is context. Across conversations, what it keeps depends on the product, the settings, and the workspace. Claude’s chat memory and conversation search are a separate thing from instructions you deliberately save.

The deliberate kind is a text file. In Claude Code, a file named CLAUDE.md holds standing instructions for a project; the .md means Markdown, which is plain text with light formatting. It may as well be an essay. A workflow can also add to its own notes. If the marketing review discovers that a tracking tag was missing for two weeks in March, it can write that down so next month’s comparison accounts for it, instead of somebody rediscovering it. That takes a little design — a place to save the notes and an instruction to read them. For a repeatable workflow, make explicit what should be saved and read next time.

Skills: teach it once

The first time you run the marketing review, you explain the job in a conversation. The second time, you should not have to. A skill is that explanation, saved.

At its simplest a skill is one file of instructions. It can grow to include supporting documents, scripts that do part of the work, and a list of the connectors it depends on. Skills can be personal or published to the whole organization, and the difference is usually whether the rules inside are specific to one person’s job. A personal skill might carry one person’s billing conventions; an organization-wide skill might define how everyone prepares a report.

Two details matter in practice. Every skill has a short description, and the description is how Claude knows when to use it. You do not have to name the skill; if what you ask for matches the description, Claude picks it up on its own. Ask for a network diagram and the skill holding your documentation standards comes along, even though nobody mentioned standards. Tuning the description is how you make a skill fire more or less often, and naming it outright is the surest way to invoke it.

And you do not have to write skills from scratch. Once a workflow is producing something useful, tell Claude, “I want the outcome of this to be a skill,” and it will draft the steps, the rules, the exceptions, and the description. Read that draft as carefully as you would read the output. It is the version of the job every future run will get.

What it is told versus what it is allowed

As you hand over more, one distinction becomes essential: instructions describe what Claude should do; permissions decide what it can do.

A skill might say to prepare the marketing summary as a draft and wait for review. Taking away its ability to send anything makes that boundary a lot stronger than the instruction alone.

Permissions stack, and it helps to see the layers once.

The connected account comes first. Claude cannot do anything in a system that the account it signed in with cannot do.

The connector filters what that account is offered. When we build one, we build role-based access control into the connector itself: who may connect, and which tools each role can see, is decided by the person’s directory group and enforced by the connector before Claude ever sees a menu. A technician and a bookkeeper connecting to the same system get different tools, and that holds no matter what either of them sets in Claude.

Claude’s own settings come last. An administrator sets the ceiling — locking a connector’s write tools so nobody in the company can, say, create calendar events through it. Inside that ceiling you set your own defaults per tool: allow it, ask me first, or block it. Reading a report can be “always allow.” Publishing its conclusions to a shared channel deserves a separate decision. The exact options depend on the tool and the plan.

Claude Code adds a permission mode for the whole session, plus sandboxing controls that restrict where commands can operate. On supported plans and configurations, Claude Code now starts in auto mode. A second model reviews actions that would otherwise require approval, assessing whether they fit your request. This reduces interruptions — a real convenience on a long task with two hundred predictable file changes — but it does not replace carefully limited access or your judgment. Manual mode, one keystroke away, gives you more direct control when a workflow is unfamiliar or mistakes would be costly. Keep unfamiliar workflows under supervision; do not take your hand off the wheel until the workflow has earned it.

Picking the model, and paying for it

Claude offers several models with different balances of speed, capability, and cost. Right now the range runs from Haiku through Sonnet and Opus to Fable; the names change with each release, the tiers do not. The question is how much reasoning the job needs. Moving names between two well-structured spreadsheets is a job for the fast one. An analysis with conflicting evidence justifies a more capable one. A hard security review wants the best model and more time to think.

Start with a capable everyday model. If a task repeatedly misses important distinctions or struggles with conflicting information, try a stronger model or higher effort, and compare the results before making the more expensive option your default. Model choice is one more part of tuning the workflow, not a hierarchy to memorize.

Usage is metered in tokens — the small units of text a model reads and writes — and the more capable the model, the more each token costs against your allowance. That allowance depends on your plan, the model, how much material is involved, and how much work is done. Most plans have limits that reset over time, and a demanding task can eat a big share of one, which is a reason to start the big job at the end of the day rather than at nine in the morning.

Where it is available, the effort setting controls how long the model spends challenging its own first answer before committing to it. Higher effort helps on hard problems, takes longer, and costs more, and it is not a guarantee of a better answer. Anthropic’s guide covers the current controls.

Teams, Enterprise, or the API

Everything above assumes your organization has a Claude account, and there are three ways to get one.

Claude for Teams is where most small and mid-sized organizations should start. It is priced per seat, sets up in an afternoon, and includes the pieces this article depends on: organization instructions, shared projects, connectors, and Claude Code. Premium seats add access to the top-tier model. Administrators manage members and decide which connectors are available. It supports single sign-on. What it lacks, at the time of writing, is the full compliance layer — automated provisioning and deprovisioning from your directory, audit logs, data retention controls, and the compliance interface a security team uses to export activity.

Claude for Enterprise adds that layer, along with larger context windows and finer-grained administrative roles. It is also dramatically more expensive. Pricing is negotiated rather than published, it is per seat with usage billed on top, and it usually comes with a minimum seat count. For an organization with regulatory obligations, or a security team that needs the audit trail, it is the right answer. For a team of twenty that wants to find out what these tools can do, it is a large check written before you know what you are buying.

The API is a different thing altogether: no seats and no chat interface, just Claude as a component inside software you build, billed per token. It is the fit when there is no person in the conversation at all — a workflow that runs entirely inside your own application. Our own agents run on their own Team seats today; the API is where that goes when the work is fully headless.

Start with Teams. Move to Enterprise when a compliance requirement, not a feature list, tells you to.

Agents: when it runs without you

So far, you have been initiating and supervising the work. The last stage is a task that runs when you are not there.

“Agent” gets used two ways. Technically, an agent is one instance of Claude working on a task, and a big task can be split among several. Ask for the top ten issues across six months of support tickets and the volume may be too large to review in one pass; Claude can hand out slices to sub-agents, each reads a batch, and an orchestrator assembles what they found.

The more interesting meaning is the autonomous agent: a system that does assigned work on its own, on a schedule or when something happens. It might prepare the marketing review on the first of every month, check the ticket queue every hour, or read equipment logs each morning and flag anything wrong.

Not every workflow should get here. Some are most useful with a person reviewing every result; a skill that prepares something for review is often the finished solution, not a stage on the way to something else. Others can eventually run unattended. The right stopping point depends on the consequences of a mistake and how easily you can detect it.

For ongoing organizational work we give an agent its own identity: its own account in the directory, its own permissions, its own accounts in each system, and its own computer. That makes its access deliberate and its activity distinguishable from any person’s. A skill defines what it does; the infrastructure around it is what lets it run reliably, and that infrastructure is something your organization provides.

Our first one is a support agent. It has its own accounts in the ticketing, monitoring, and management systems, its own virtual machine running Claude Code, and a chat connection so team members can ask it questions directly. Someone who wonders what is going on at a site they have no console access to can ask the agent that does. Its answers need care too: an agent with broad system access should only share what the person asking is authorized to see.

A finance agent is next on our roadmap. It would read invoices and receipts out of email, work out what was purchased, and create the purchase order in our internal database — read-only everywhere except the one system it updates, and running as itself, not as the person who happens to have write access everywhere. A person still confirms the package arrived and closes the order. Nobody on our team is stimulated by copying tracking numbers into a database. That part can go to the robot. The decision stays with the person.

What this looks like in practice

A network problem. A ticket says “the Wi-Fi is bad.” A diagnostics skill reads the site’s documentation, queries the firewall, switches, and access points through their connectors, and comes up with a theory. Then it goes looking for evidence, challenges its own assumptions, and if it needs to, captures network traffic straight from the access points to test itself — a thing that is genuinely annoying for a person to do and easy for it. What comes back is a summary: what it thinks is wrong, what evidence supports that, what it assumed, and what to check next. The engineer decides whether the theory holds and what to change. This is the skill the support agent runs when a network ticket comes in.

A timesheet draft. Work leaves traces in the calendar, email, chat, and meeting recordings, and those traces rarely make it into a complete timesheet. A skill pulls them together, figures out the client from the event title or the attendees’ email domains, and applies the person’s billing conventions — prep and follow-up around client meetings, travel billed to the site, quarter-hour rounding, no overlaps — while skipping anything that is not billable. What comes back is a dated tab in the person’s working sheet with weekly totals, a warning if a week looks light, and the entries it could not resolve flagged for a decision. The person confirms the entries reflect work actually done, then submits. The judgment calls are specific to one job, which is why this stays a personal skill.

A hiring inbox. Applications arrive in a shared mailbox, dozens or hundreds of them, each with a résumé attached. A skill pulls each attachment out of the mailbox, converts scanned pages to readable text, reads the résumé, and records the details the hiring team compares — years of experience, current role, relevant skills — as a row in the candidate tracking sheet. Then it renames the file to the house convention and files it in the candidate’s folder in Drive. It took about two hours to build. Nobody was ever excited about moving PDFs; the person who used to do it now spends that time evaluating the applications.

A website. This site was built with Claude Code on a virtual machine. A person described changes in ordinary language; Claude wrote the code and recorded every revision in GitHubA platform for hosting and managing code with Git version control — it stores the project, tracks every change, and serves as the source of truth a hosting platform deploys from.. Each change was reviewed on a preview site before it went live. Vibe Coding, Done Right tells that story.

What would you hand off?

The question that ties this together: what would you hand off if you could explain the job, give someone the right access, and review the result?

Start with what annoys you. Necessity is the mother of invention, and the easiest place to begin is the clerical thing you do every week that you never loved doing. Then look for the tasks you ruled out years ago because they were slightly too irregular to script. The exceptions that used to break a script are now things Claude can interpret, or at least flag for you.

Look for work where you pull data from one place, reconcile it with another, and put the result somewhere else. That is three connectors. If one does not exist, it can probably be built.

Revisit the tools your organization decided were too expensive or slow to build. The estimate has changed. And then think bigger: some things are only possible with software. Applying a new rule across a hundred pages, or combining more data sources than a person would ever reconcile by hand. Not just making your life easier — doing the work with more information than you use today.

There is a chicken-and-egg problem here. You learn what these tools can do by using them, and you cannot use them well until you have learned. The answer is to just go do it. Start with one bounded piece of real work and the connections you already have. Refine it through repeated use, including the awkward cases. Once the process is useful, capture it as a skill and keep refining it as exceptions appear. If colleagues would use it, say so.

Guardrails

These are early days and the guidance will change, but the principles below are the ones to start with. They apply across the tools. Some are habits for the person using Claude; others are responsibilities for the organization providing access.

You are the accountable party. If you used Claude to send the email, deploy the machine, or onboard the hire, the result is yours — the credit and the mistakes. Whoever built the robot is responsible for the robot. Check the evidence behind an important conclusion and the changes a task proposes before you act on them.

Supervise prototypes. Do not grant full access and walk away. Watch how a workflow handles real cases, approve actions as they come up, and only let it run unattended after it has proven itself. A good demo is a beginning; the exceptions are what tell you whether the instructions are complete.

Read before write. Gathering and analyzing information is a lot safer than changing it. Start there, add narrowly defined write actions as the workflow proves itself, and be explicit about which results need a person to look at them before anything goes out.

Mind the blast radius. Before you let something run, ask how much damage it could do if it went wrong. Give it the files, systems, and accounts it needs and no more. One client’s credentials, not a key to every client. A senior administrator’s login is exactly the wrong identity for unattended work.

Sandbox it when in doubt. Your organization can give an experiment its own low-privilege account and its own virtual machine. A separate environment limits the impact of local mistakes; carefully scoped accounts limit what it can change elsewhere. Ask for one rather than assuming it is not allowed.

Keep access and ownership organized. Access follows the organization’s directory groups, internal tools use its sign-in system, and code lives in an organization-owned repositoryThe container for a project's code and its complete change history. — a shared home for the files and their history. Connector design needs a clear owner, because a connector decides what Claude can reach and change.

The products will keep changing; the protocol underneath all of this is still young. The habit is already clear: explain the outcome, provide the right access, set the limits, review the result. As the process proves itself, more of the work moves from your hands to Claude’s.

Get in touch if you would like help finding where that starts for your team.