How to Set Up Claude Code as a Non-Technical Business Owner

Most business owners are using AI like a smarter chatbot. That is the wrong frame. The real unlock is not asking better questions in a blank chat window. It is giving an agent access to the actual operating system of your business, so it can stop guessing, read the source material, and tell you what is happening across the company before your dashboards do.

This walkthrough is not glamorous. It is menus, logins, and permission screens. Push through it once, because everything valuable that comes later depends on it. This is the counterpart to the argument for going first yourself: see why CEO-first AI implementation wins.

What you are actually building

You are not learning to code. You are building a company brain. More specifically, a connected workspace where an agent can read the same information you read, find files without you knowing where they are, compare CRM data against email and transcripts, spot stalled work, draft proposals from prior examples, surface risks that never reached a dashboard, and eventually run repeatable workflows without you clicking through systems.

The AI model matters, but it is not the moat. Your private business context is the moat. Public AI knows public information. Your agent gets valuable when it can see your company's real work: the emails, transcripts, deals, decisions, files, proposals, pricing, and exceptions no generic model has.

Two expectations before you start:

1. The setup is tedious. You will click through menus that feel intentionally hard to find. That is normal. It is not you.
2. "Connected" does not always mean "fully connected." Some one-click connectors expose summaries, not complete data. A meeting-notes connector may give the agent the call summary but not the full transcript. Enough for basic help, not enough for deep diagnosis. You verify access later.

Part 1: Use a real computer

Do not try to run this on a weak machine. If your computer has 8GB of RAM, it will feel like the system is about to explode the first time the agent starts working across files, browser actions, local folders, and connected tools.

For serious agent work, your computer becomes a home base. It does not need to be cute. It needs to be powerful, stable, and awake. Use a real laptop or desktop with enough memory, avoid underpowered "just for browsing" machines, keep it plugged in during long sessions, and treat it like a workbench. A weak machine makes AI feel flaky. A proper machine makes the whole process feel possible.

Part 2: Choose the right subscription

This is where many owners waste money. The team plan can look like the responsible choice, but it is often the wrong starting point. Some team plans require a minimum number of seats, and you end up paying for people who are not ready to use agents heavily yet.

The better move: the CEO goes first, on a high-usage personal plan. For Claude that usually means a Max plan rather than forcing everyone onto a team setup. Anthropic currently lists Max 5x at $100/month and Max 20x at $200/month, and Claude Code is available on Pro and Max plans. Verify the price before you buy, because AI plan pricing changes quickly.

Why start with the owner: the CEO has the broadest context, and the CEO's email, calendar, files, and CRM view reveal the most. The first agents need to be tested against the real company operating system, and you do not want everyone's agents running wild before permissions, GitHub structure, and logging are in place. Do not give every employee a premium seat on day one. Your agent should become the standard first, then you roll it out deliberately.

Part 3: Open Claude Code

Most people miss this because they keep using Claude like a normal chat app. Open Claude and look for Code or Claude Code, depending on your version and workspace. You have probably been living in Chat. That is not enough. Claude Code is the agentic workspace where Claude can operate against files, tools, and local folders.

Once you are in Code: choose Select folder, pick a workspace folder (Desktop or Documents to start), and if prompted select Trust this workspace. That folder becomes the first local operating area for the agent. Do not overthink the choice. You are not architecting the whole company yet, you are giving the agent a place to work.

Part 4: Turn on the right settings

Go into settings and make sure the agent can actually operate. Turn on:

• Keep computer awake. If the computer sleeps mid-task, the agent stops.
• Allow browser actions. The agent needs to navigate browser windows during setup and later workflows.
• Enable computer use. This lets the agent operate more like a real assistant instead of a passive chatbot.
• Bypass permissions / Accept edits. Critical. If this is off, the agent stops constantly to ask permission for every small action, which destroys flow.

Do not blindly enable remote-control features unless you know exactly why you need them. The practical rule:

Give the agent enough permission to work, but do not open remote-control surfaces you do not understand.

Part 5: Connect your core apps

This is the most important part of the setup. The agent can only help with what it can reach. Start with your core business stack: email, calendar, CRM, meeting notes or transcripts, cloud files, GitHub, a structured knowledge base like Notion, a deployment layer like Cloudflare, your meeting platform, and accounting or billing tools when you are ready.

For many owners the core stack looks like Microsoft 365 or Google Workspace, a CRM like HubSpot, a meeting recorder, a file store like SharePoint, OneDrive, Google Drive, or Dropbox, plus GitHub, Notion, Cloudflare, and accounting software later.

Permission scopes matter

When a connector asks what it can access, look for the small permission options, often a tiny, low-contrast row such as Select all, View only, or None. Choose All / View only during the testing stage. That gives the agent broad visibility without letting it change business data before you have tested the workflow. The correct starting posture:

Read broadly. Write carefully. Automate later.

Part 6: Understand the connector problem

Do not assume a connector gives the agent everything. A tool can say "connected" and still provide only a shallow version of the data. A meeting-notes connector may expose the summary but not the full transcript. A CRM connector may expose deals but not all activity history. An accounting connector may need extra API setup. A file connector may not expose every synced folder.

That does not mean the setup failed. It means you need to test. This is the same distinction that separates a plugin from real access, covered in what a plugin actually is and which AI notetaker actually works with your agent. The rule:

If the agent's answer feels thin, the problem is usually access, not intelligence.

Later you may add API keys or custom integrations for full data. Do not start there. Start with the simple connectors, then verify what the agent can actually see.

Part 7: Install the essential plugins

Plugins are the agent's abilities. You do not need everything, you need the core set that lets the agent work across your business. A strong starter set: Agent SDK (core agent-building), GitHub (repos, history, logs, coordination), Cloudflare (fast deployment and live links), Desktop Commander (local file operations), Playwright (browser automation and testing), Front-end design (dashboards and prototypes), Skill creator (turn a refined workflow into a reusable skill), Session report (logs a session), Security guidance (guardrails), Remember (working memory), Notion (structured knowledge), and Resend (controlled email sending later). Add TypeScript, Vercel, Railway, WordPress, or Zoom based on your stack.

The plugin list is long and annoying to navigate. Do it anyway. This is one of the places AI adoption stalls: setup flows are still designed as if every employee is technical and patient. They are not. That is exactly why the owner pushes through this once, then turns the finished process into a company standard.

Part 8: Install Git and connect GitHub

GitHub becomes the source of truth. Not because every employee becomes a software engineer, but because the company now needs version history, audit logs, shared instructions, agent rules, reusable workflows, approval queues, client playbooks, operating plans, SOPs, and activity logs. GitHub is where the agent stores and updates the structured brain of the company.

In Claude Code, ask: "Help me connect to my GitHub so you can audit it." The agent guides you through it: install Git, restart Claude, reopen as administrator if needed, authenticate GitHub, use device-code login if prompted, authorize, and confirm the agent can read the repository. The device-code login can feel ridiculous: copy a code, open a GitHub link, verify email, paste another code, authorize. That is normal. Push through it. Once connected, ask the agent to audit your repository structure, flag any exposed secrets, recommend organization, and begin building your company's agent home base.

Part 9: Run the first access tests

Now prove the setup is real. Do not start by asking for a generic business strategy. Start by testing whether the agent can find evidence.

• GitHub audit: "Audit my GitHub and tell me if anything is exposed, disorganized, duplicated, or unsafe."
• Business context audit: "You have access to my email, calendar, CRM, local files, and connected tools. Tell me what you can infer about my business, where the operating system is weak, and how you would organize GitHub as the company source of truth."
• Document retrieval: "Pull the most recent proposal I wrote for [client] and summarize the top three things I should reuse in future proposals."
• Weakness analysis: "What is weak in that proposal? What would make it more persuasive, clearer, and easier to close?"
• Revenue-risk analysis: "Based on my CRM, email, calendar, and most recent full transcripts, what deals are stalled because of us, not the client?"

Part 10: Know how to read the signals

When the agent is working, understand the interface. Usually, moving dots mean it is still working, and a finished bubble means it is done or waiting for input. A weak answer often means missing access. A strong answer with real file references means the plumbing works. Do not judge the system from one bad output. First ask: did it have access to the right system, did the meeting actually get recorded, did the CRM contain the field it needed, did the proposal live in a synced folder, did the connector expose summaries or full transcripts, and did I give it permission to read enough. Bad AI outputs are often bad context outputs.

Part 11: The first "aha" moment

The first real breakthrough usually happens when the agent finds something you forgot. During setup it may surface an old proposal from years ago, summarize the useful structure, then critique it with more objectivity than the person who wrote it. That matters, not because proposal review is magic, but because it proves the agent can find old work, understand your business language, identify reusable patterns, expose gaps, and turn a one-off improvement into a repeatable asset. You are not asking AI to "write a proposal." You are asking it to mine the company's history, extract the best parts, and build a better operating standard. That is a completely different use case.

Part 12: The moment it pays for itself

Most pipeline reviews measure the same visible things: deal stage, size, probability, close date, owner, next step. Useful, but incomplete, because they depend on humans updating fields. The real money often gets stuck somewhere else: internal latency, the time between "we know what needs to happen" and "someone actually does it." It usually does not show up in a CRM field. Nobody logs "client is waiting on us because we forgot to send the revised proposal," or "decision was made three weeks ago but stayed in the founder's head," or "deal is forecast to close this week but nobody attached a price."

Stalled pipeline hiding in plain sight

In one setup session, a connected agent surfaced a stack of stalled pipeline that normal dashboard review had missed. The pattern was not bad leads or slow clients. It was internal delay: a deal the client had already agreed to, waiting on a small proposal revision that never went out; an extension opportunity where the brief and feedback existed but the final send never happened; deals sitting in a buying stage with no price attached; a decision made weeks earlier in conversation but never logged; a signature document stuck with no clear owner.

The important part was not the list. It was the pattern: the constraint was internal, not external. The client was not always the bottleneck. The company was. And it only became visible because the agent could read across email, CRM, calendar, files, and transcripts at once. Remove one connection and part of the picture disappears.

Part 13: Why dashboards miss this

Dashboards are not useless, but they are summaries of human-entered data. They show what the system was told. Agents can inspect what actually happened. A CRM might say "verbal yes, close date June 22," while the agent reads the thread and notices the revised proposal was never sent. A CRM might show "deal in buying stage," while the agent notices there is no price attached and no meeting scheduled before the close date. The dashboard is a mirror of the system. The agent can become an inspector of the operating reality.

Part 14: Build the company brain in GitHub

Once the agent sees the business clearly, GitHub becomes the coordination hub. A practical structure uses separate repositories: an agent home base (agent rules, onboarding, approval queues, activity logs, shared prompts, standards, escalation paths); an operating plan (annual plan, financial guardrails, pricing rules, priorities, leadership decisions); a SOP library (checklists, role instructions, delivery and sales standards, onboarding, renewals); client playbooks (one folder per active client with context, stakeholders, current work, risks, open loops, historical proposals, and meeting summaries); and agent logs (daily activity, workflow outputs, items needing approval, exceptions, failed runs, human overrides).

This is how you avoid chaos. If every employee has an agent acting in a different place, the system becomes unmanageable. GitHub gives you one law:

Agents work from the company source of truth, and they leave an audit trail.

Part 15: Do not roll this out to everyone at once

The wrong move is to get excited and give the whole team agents immediately. That creates noise, risk, and inconsistent behavior. The right rollout is top-down: the founder first, to establish the standard; then the finance or operations leader, to unlock billing, collections, projections, and financial visibility; then the revenue or delivery leader, for client follow-up, extensions, and proposal quality; then an executive assistant, once the workflows are clear; and only then the wider team, after onboarding rules, GitHub structure, permissions, and approved workflows exist.

Part 16: Treat employees like agent operators

Once employees have agents, the company needs new rules. This is not casual chatbot usage anymore.

Company-owned accounts. Agents should connect through company-owned email and company-controlled systems. If someone's GitHub or agent account is tied to a personal login, the company can lose access to critical work when that person leaves.

Company-owned machines. If an employee is doing agentic work, consider whether they need a company machine, the same way software engineers work on company hardware. The company needs recoverability, control, and continuity.

One primary operating system. Do not let everyone scatter work across random chat apps. Pick the primary agent environment and enforce it. The reason is not preference, it is traceability. Work that happens in disconnected consumer chats cannot be seen, reused, or audited by the company brain.

Agents need onboarding too. Build an onboarding page or repo. When a new employee gets an agent, the first instruction should point that agent to the company onboarding source, telling it who the company is, the employee's role, what it may access, what it may never do, where to log activity, when to ask for approval, how to follow brand voice, how to handle confidential information, and how to escalate uncertainty. The employee is not the only one being onboarded. The agent is too.

Part 17: Build habits that feed the agent

The agent can only reason from captured context, so your operating habits have to change. If an important decision happens in a meeting that was not recorded, the agent may never know. If a client gives buying signals on a call and nobody documents it, the agent is blind. If a founder makes a decision in their head and writes it nowhere, the system cannot act on it. New rule:

Important business context must be captured somewhere the agent can read.

That means recording key meetings, using meeting-summary tools, logging decisions immediately, keeping CRM notes current, and saving proposals in the right place. One simple habit: after an in-person client meeting, record a two-minute voice memo in the car covering what happened, what the client cared about, what they agreed to, what they resisted, what you promised, and what must happen next. That memo becomes structured context for the agent.

Part 18: Stop forcing anti-agent tools

Many companies try to fix this by buying another project-management tool. That is usually the wrong instinct. The question is not "what dashboard should we make everyone update," it is "what source systems should the agent read so the dashboard updates itself." Rigid project tools force agents into human-shaped workflows, which limits their value. Agents are strongest when they can inspect source data directly: CRM, email, transcripts, calendar, files, accounting, contracts, proposals, and delivery notes.

Special warning: LinkedIn

Do not blindly automate LinkedIn activity. LinkedIn is hostile to automation, and careless automation can get accounts restricted or banned. The safer approach: let the agent identify who to engage, suggest comments or messages, and flag whether someone is already a client or matches your ICP, then let a human perform the actual LinkedIn action. Use the agent for intelligence, not risky automation. The full argument is in how to use AI to comment on LinkedIn (don't).

Part 19: How Claude and Codex can work together

Use the right tool for the job. Claude is often stronger for strategic reasoning, business diagnosis, planning agents, interpreting messy company context, and helping a CEO think through the operating model. Codex is often stronger for careful implementation, repeatable build work, QA, and building from a clear spec. A useful pattern: use Claude to diagnose the issue and design the agent, have Codex build the more technical pieces, use another pass to audit the result, test on real cases, refine the output format, and only then make it recurring. Do not get religious about one tool. Use each where it is strongest, and if you are non-technical and want the more conservative starting point, begin with Codex.

Part 20: The first five agents to build

Do not build twenty agents at once. Pick the five that remove the most pain or recover the most value. For a professional-services business, the first five are often: a daily revenue-risk agent that finds deals stuck by internal delay; a proposal agent that builds and reviews proposals against your best examples; a meeting intelligence agent that turns transcripts into commitments, risks, and next actions; an extension or renewal agent that catches milestones and buying signals before they go cold; and a finance visibility agent connecting project progress, invoices, collections, and projections, built carefully with finance leadership involved. Each should start in review mode. Do not let it act automatically at first. Make it produce recommendations, review the quality, then gradually allow more autonomy.

Part 21: Test before going live

Every agent should go through the same loop. Run it retroactively on five to ten past examples and ask what it would have flagged, recommended, missed, or overstated. Review the output for accuracy, tone, false positives, missing context, formatting, and escalation logic. Refine the format, because most agents are not wrong so much as poorly formatted at first: make it shorter, rank by urgency, include deal value and owner, separate "needs CEO" from "team can handle," show evidence. Test again on another batch. Only after the output is reliable should it become daily, weekly, or trigger-based. This is the discipline in the Test, Refine Method.

Part 22: The mindset shift

This is the hardest part for experienced operators, because you are used to thinking manually. You think "where is that file," when the new question is "can the agent find every relevant file and tell me which one matters." You think "who needs to update the dashboard," when the new question is "can the agent read the source systems and tell me what changed." You think "which project tool should we use," when the new question is "what operating reality are we trying to expose, and where does that evidence already live." You think "I need my old chat history because ChatGPT knows me," when the truth is your email, CRM, proposals, transcripts, calendar, and financial data tell the agent far more than any consumer chat ever could.

Part 23: The reality checklist

Run through this before you roll anything out.

Machine and account

• You are using a real computer with enough memory.
• Claude Code is accessible and you are on the right subscription for heavy use.
• You are not overpaying for unnecessary team seats too early.
• Keep-awake, browser actions, and computer use are on.
• Bypass permissions / accept edits is on for working sessions.
• Remote-control settings are off unless intentionally required.

Connected systems

• Email, calendar, CRM, transcripts, cloud files, GitHub, knowledge base, deployment layer, and meeting platform are connected.
• Accounting is planned or connected carefully.
• Permissions are broad enough to read, controlled for writing.

Verification

• The agent can audit GitHub, find a real historical proposal, and critique it usefully.
• The agent can infer business structure from connected systems and identify stalled deals.
• Weak answers have been traced back to missing access or missing context.

Company rollout and habits

• The founder setup works first; GitHub structure, agent logs, SOP repo, and client playbooks exist or are planned.
• Company-owned accounts are required; personal accounts are not used for company-critical agent work.
• The first five agents are selected and start in recommendation mode before automation.
• Important meetings are recorded or summarized, in-person decisions are captured, and the CRM is treated as evidence, not decoration.

Common questions

Do I need to know how to code to use Claude Code?

No. You are not learning to code. You are connecting an AI agent to the systems where your real work already lives, then reviewing what it finds and approving what it drafts. The work is describing your business clearly and granting access, not writing software.

Which plan should a business owner start with for Claude Code?

Start with the founder on a single high-usage personal plan rather than buying team seats for everyone. Anthropic currently lists Max 5x at $100/month and Max 20x at $200/month, and Claude Code is available on Pro and Max plans. Verify current pricing before you buy, because AI plan pricing changes quickly.

Why does access matter more than which AI model I use?

Public AI models know public information. Your agent becomes valuable when it can read your company's actual work: the emails, transcripts, deals, decisions, files, proposals, and pricing that no generic model has. Your private business context is the moat, and the agent can only use what you connect and permit.

Does connecting a tool mean the agent has all of its data?

Not always. Some one-click connectors expose only a shallow version of the data, like a meeting summary instead of the full transcript. That is enough for basic help but not for deep diagnosis. If an answer feels thin, the problem is usually access, not intelligence, and you may need to add an API key for full data.

Should I roll agents out to my whole team at once?

No. Set the owner up first as the company standard, then cascade top-down: finance and operations, then revenue and delivery, then the wider team, only after onboarding rules, account ownership, and approved workflows exist.

This setup does not build the agents yet. It builds the foundation that makes agents useful, and that distinction is everything. Most companies fail with AI because they stay in chat mode, pasting fragments of context into isolated windows and wondering why the output feels generic. The companies that win connect the agent to the business, give it access to the real work, make GitHub the source of truth, capture their meetings and decisions, and turn one-time insights into standing controls. A team of ten does not move like a team of a hundred because everyone got a chatbot. It happens when the company's context becomes usable, searchable, and auditable by agents. That starts with the boring setup. So do the boring setup.

Start with the strategy behind going first in CEO-first AI implementation, get the ground rules in 5 simple things to get your business ready for AI agents, then turn your processes into agents with how to turn your SOPs into AI agents.