How to Build 24/7 Claude Agents. Easy.

Video: https://www.youtube.com/watch?v=ehg4fhydTgs

Video ID: `ehg4fhydTgs`

Duration: 16:27

Transcript status: ok

Core thesis

Claude Code routines turn Claude from a local, laptop-dependent coding assistant into a remotely triggered automation worker. You can schedule it, call it from APIs/webhooks/GitHub events, give it a repo and cloud environment, and let it run one-shot agent tasks without keeping your computer open.

The video’s deeper point is that “remote agents” require different design habits than local automations: prompts must be self-contained, secrets must live in the cloud environment, authentication must be API-friendly, network permissions must be explicit, and every run should be treated as stateless unless it writes back to GitHub or an external system.

Big ideas / key insights

• Routines are prompts with triggers. The core object is a task definition: name, instructions, model, repo, environment, schedule/trigger, connectors, and permissions.
• Remote execution changes the failure modes. Local scripts may rely on `.env`, cookies, browser state, local files, and previous sessions. Remote routines clone a GitHub repo, run in a cloud environment, and then disappear.
• Secrets must be configured deliberately. Because `.env` should not be committed, API keys need to be placed in cloud environment variables and the prompt should explicitly tell Claude to read from the environment, not from `.env`.
• Network access is a real setting, not a footnote. Trusted mode limits domains to vetted services; full mode allows broader access. Nate’s ClickUp example only worked after switching network access appropriately.
• One-shot prompts need to be specific. Since the user is not there to answer questions mid-run, routines should include exact files, commands, environment-variable names, expected output, and failure behavior.
• Browser/session automations may not migrate cleanly. Anything relying on local cookies or browser state, like a Skool scraper, will likely fail unless authentication is available via headers, API keys, cookies passed securely, or a supported connector.
• Limits shape design. Routine-run quotas mean you cannot blindly move every heartbeat or micro-task into remote Claude. Batch jobs and prioritize high-value automations.

Best timestamped moments with interpretation

• 0:00–0:31 — Nate introduces Claude Code routines as remote/web-running prompts that can be scheduled, API-triggered, or GitHub-triggered. This is the “24/7” unlock.
• 1:02 — He shows the New Task flow: local versus remote tasks, task name, prompt, model, repository, cloud environment, cadence, connectors, and permissions. This is the setup map.
• 1:33 — He emphasizes that these are one-shot prompts. That is the right mental model: no interactive babysitting, no “ask me if stuck.”
• 2:34 — The GitHub clone model is explained. Claude can read the repo, `claude.md`, scripts, and skills, but not uncommitted local secrets or state.
• 3:05 — The `.env` problem appears. Since `.env` is gitignored, remote routines cannot read it. Environment variables in the cloud environment are the correct replacement.
• 3:37–4:07 — Network access and permissions become the blocker. ClickUp only worked after network access allowed the required external call.
• 4:38–5:40 — The YouTube Data API test shows a subtle prompt-design issue: Claude may keep looking for `.env` unless told to use the provided environment variable directly.
• 6:12–6:42 — The Skool automation fails because local cookies/session state are unavailable remotely. This is one of the most important caveats in the video.
• 7:12–7:42 — Nate summarizes the remote-task configuration pattern and shows where schedules, connectors, permissions, models, and environments live.
• 8:12–8:42 — Usage limits are shown. Remote routines are powerful, but quota-constrained.
• 11:14 — Setup scripts and trusted/full network access are discussed in more detail. This is the infrastructure layer that determines whether a routine can actually run.

Practical takeaways / recommended workflow

For building reliable 24/7 Claude routines:

1. Start with a local working script. Make sure the task can run with one command before moving it remote.

2. Commit only safe code and config. Put scripts, skills, docs, and `claude.md` in GitHub. Never commit `.env` or credentials.

3. Create a cloud environment. Add required environment variables there, plus any setup script for dependencies.

4. Write prompts like runbooks. Include exact working directory, commands, env var names, target files, success criteria, and what to do on failure.

5. Tell Claude not to look for `.env`. Example: “Use `YOUTUBE_API_KEY` directly from the environment. Do not search for or require a `.env` file.”

6. Choose network access intentionally. Use trusted/custom where possible; use full only when the task needs domains outside the vetted list and you understand the risk.

7. Avoid cookie-dependent automations unless redesigned. Convert them to API/header-based auth, connector-based auth, or explicitly provided state.

8. Keep outputs durable. If the routine produces anything important, have it write to GitHub, a database, a message, or an external API before the cloud clone is destroyed.

9. Respect quotas. Batch lower-value checks and reserve remote routines for jobs that benefit from cloud execution.

Comment-derived insights

The comments mostly cluster around security, access, and practical follow-up topics.

Useful themes:

• The credential UX is confusing. The most-liked comment jokes that you enter API keys where the UI warns “Don’t add keys or credentials.” That is more than a joke: users need clarity on which box is safe for secrets and which boxes are not.
• Security anxiety is real. One commenter jokes they would have been hacked “15 times already.” This video touches sensitive territory — cloud agents, secrets, network access — so conservative defaults and clear credential handling matter.
• People want local-skill compatibility. A viewer asks whether routines can access locally created skills. The video’s answer is effectively: only if those skills are in the GitHub repo / cloud-readable environment, not just sitting locally.
• Tool-selection questions remain. Nate’s agent reply says Claude Code is better for agentic reasoning tasks, while n8n/Make may be better for multi-app integrations with lots of nodes. That distinction is important: routines are not a universal automation replacement.
• Requested follow-ups: Airtable-style automations, Miro pairing, Claude Cowork, and broader connector workflows show that the audience wants concrete recipes for specific apps.
• Performance/limit concerns. Comments mention model performance drops and routine availability on paid plans. Remote automation is constrained by plan, quota, and model behavior.
• Beginner gaps exist. A commenter asks what an API key is. Any public tutorial on this topic needs a beginner-safe explanation of keys, scopes, storage, and rotation.

Screen-level insights: frames tied to transcript

• 0:31 — Claude/X announcement. The frame shows an official Claude post about “routines in Claude Code” with triggers like Scheduled, Webhook, and API. Nate highlights the web infrastructure angle. This matters because it establishes that routines are remote cloud jobs, not just local cron prompts.
• 1:02 — Scheduled tasks dashboard. The screen shows local and remote scheduled tasks such as Skool engagement, AI news roundup, and YouTube comment replies. Nate is showing the operational hub for recurring agents. The visual matters because it makes “24/7 agents” concrete: a dashboard of repeatable jobs.
• 2:03 — Reference sheet / agenda. A document titled “Claude Code Routines - Reference Sheet” outlines what he will cover. This helps viewers follow the moving parts: triggers, environments, network access, gotchas, and setup.
• 2:34 — Testing ClickUp API routine. The scheduled task screen shows a repo, schedule, instructions, and run history. Nate is demonstrating a simple routine that sends a ClickUp message. The visual matters because it proves the pattern end-to-end: prompt → scheduled run → external side effect.
• 3:05 — VS Code with `.gitignore` and Claude Code. The editor shows `.gitignore` and the Claude Code terminal. Nate is explaining why `.env` is absent from the remote clone. This screen is crucial because it connects secure development hygiene to cloud-agent failure modes.
• 3:37 — Cloud environment settings modal. The modal shows name, network access set to Full, environment variables, and setup script. Nate is explaining where API keys and dependency setup belong for remote execution.
• 6:42 — Skool/session error. The interface shows an error about missing auth/session state. Nate is demonstrating that local cookie-dependent automation does not automatically work in stateless remote routines. This is one of the most valuable visual lessons.
• 7:12 — Running scheduled workflow. The Code interface shows a multi-step automation with instructions to change directory, run a scraper, and parse JSON. The author is showing what a routine actually does when executing a skill-like workflow.
• 7:42 — New remote task configuration. The modal shows schedule, repository, and cloud environment selection. Nate selects a cloud environment so the agent can run remotely. This is the exact setup step that turns a task from local-only to cloud-runnable.
• 11:14 — Remote task / setup script and network access discussion. The UI shows remote-task creation and access settings. Nate explains trusted versus full access and setup scripts. This matters because dependencies and allowed domains often decide whether a routine succeeds.

Visible UI / code / tools

• Claude Code routines / scheduled tasks UI
• Claude desktop / web Code task creation flow
• GitHub repository selection
• Cloud environment settings
• Environment variables panel
• Network access modes: trusted, full, custom
• Setup script field
• VS Code / `.gitignore` / `.env` discussion
• ClickUp API test
• YouTube Data API test
• Skool automation attempt and auth/session error
• Connectors such as Slack/Gmail mentioned

What the author is doing on screen

Nate is migrating local automations into Claude Code remote routines. He creates and inspects scheduled tasks, points them at a GitHub repo, configures cloud environments, tests API access, debugs failures caused by missing `.env` and local cookies, and explains how to write prompts that can succeed without an interactive human nearby.

My read / why it matters

This video is valuable because it focuses on the boring parts that determine whether agents actually work: state, secrets, permissions, network access, setup scripts, and run quotas. The “24/7 agent” promise is real, but only for tasks designed for stateless cloud execution.

The best mental model is: a Claude routine is a fresh contractor dropped into a clean clone of your repo with some environment variables and a job description. If the contractor needs a cookie jar, local file, hidden `.env`, or mid-run clarification, the job will fail. If you give it a clean repo, explicit instructions, scoped credentials, and a durable output path, it becomes a genuinely useful remote automation primitive.