How to Build a Fully Autonomous Coding Agent That Works Around the Clock

Most "AI coding assistants" wait for you. You open a thread, you describe a task, you review the diff, you ask for the next thing. The agent is a very capable hand, but you are still the one holding it.

This tutorial builds something different: an agent you hand a general set of objectives and then leave alone. It owns a GitHub organization, clones and pushes its own repositories, runs and tests code in an isolated sandbox, writes down what it learns as reusable skills, and - crucially - wakes itself up on a schedule to keep making progress while you sleep. You set the direction; it does the work, around the clock.

We will build a concrete example called Relentless, an autonomous coding agent that maintains a GitHub organization of small, headless, "agentic-first" services. But the architecture is general - swap the mission and the same blueprint becomes a docs-keeper, a dependency-bumper, a refactoring bot, or a green-field product factory.

What You'll Build

An autonomous agent that:

• Owns a GitHub organization through a dedicated GitHub App - it can create repos, open and review pull requests, manage issues, and push commits
• Runs code in an isolated sandbox - clone, build, go test ./..., and commit, all in an ephemeral container with no access to your infrastructure
• Mints its own git credentials on demand via short-lived, repository-scoped tokens - nothing long-lived is ever stored
• Teaches itself skills - it codifies repeatable patterns (project blueprints, CI templates, API conventions) into skill files in a persistent Space so the knowledge survives across sessions
• Researches the web - searches and fetches pages to ground its work in real documentation
• Wakes up on a schedule - a daily heartbeat trigger tells it to "wake up and do your best" against its standing objectives, with no human in the loop

Prerequisites

• A ChatBotKit account
• A GitHub account, and permission to create a GitHub App on an organization you control
• Familiarity with the Blueprint Designer
• Approximately 45-60 minutes

Heads up on autonomy: This agent is designed to act without asking for permission at each step. That is the whole point - but it also means you should scope its GitHub App carefully and start it on a low-stakes organization. We cover guardrails in the Safety section. Read it before you flip on the heartbeat.

The Architecture

An always-on autonomous agent is really a handful of components wired into one bot. Every one of them is a resource you drag and drop onto the Blueprint Designer canvas. Here is the whole system at a glance:

The first five give the agent capability. The last is what turns a capable assistant into an autonomous worker: nobody has to type a message for it to start working. You assemble all of them the same way - drag the resource from the Blueprint Designer sidebar onto the canvas and connect it up.

Step 1: Create the Blueprint

1. In your ChatBotKit dashboard, open Blueprints in the sidebar.
2. Click Create and select Blueprint.
3. Name it "Autonomous Coding Agent".
4. Click Design to open the Blueprint Designer.
5. Choose Blank to start with an empty canvas (a Bot and a Skillset).

You will build up the canvas piece by piece, then import the complete blueprint at the end if you would rather skip ahead.

Step 2: Write the Operating Manual (Backstory)

For a normal chatbot the backstory is a personality. For an autonomous agent it is an operating manual - the agent will re-read it every time it wakes up with no human around to clarify anything, so everything it needs to make good decisions on its own has to be written down here: who it is, what it is trying to achieve, how it should behave, and where the hard lines are.

Open the Bot resource, connect it to your Skillset, and set the Backstory. Here is the full manual for our worked example, Relentless:

A few things to notice about why this manual works for an unsupervised agent:

• The mission is open-ended on purpose. "Build any agentic-first service that fits the philosophy" gives the agent room to pick its own work. That is exactly what you want when there is no human queuing tasks - but it only works because the principles and tech stack are pinned down tightly, so the freedom is bounded.
• It encodes judgement, not just tasks. "Never force push to protected branches without explicit permission" and "never delete repos without confirmation" are the brakes. An agent that acts on its own needs its hard limits written into the prompt, because there is no approval dialog to catch it.
• It names its own tools. The manual references call_github_api and create_github_repository_token so the agent knows what it has and when to reach for each.
• The last rule matters most for autonomy: "You are not allowed to disclose any secrets in github source, comments and other public places." An autonomous agent pushes to public places without you watching - this line is its security conscience.

Choosing a model: Autonomous, multi-step coding work rewards a strong agentic model with solid long-horizon planning and tool use. Our example runs on glm-5.2, but any capable agentic model works well here - Claude 4.6 Sonnet is an excellent choice for this kind of workload. Set it on the Bot's Model field.

Step 3: Add a Sandbox for Running Code

The agent needs somewhere to actually run code: clone a repo, edit files, build, and go test ./.... ChatBotKit gives every agent an isolated, ephemeral sandbox container - it can do anything inside it, but it has no path back to your machines or network.

Everything you add from here on is a resource you drag and drop straight onto the Blueprint Designer canvas. Open the sidebar, grab a Skillset (the Blank canvas already gave you one), then grab an Ability and drop it on the canvas - a line connects it to the skillset, and you fill in its template. Every ability below is added exactly this way: drag, drop, connect, configure. You never write the whole blueprint by hand.

Drag an Ability onto the canvas, connect it to your Skillset, and configure it to install the shell toolset:

Install Shell Tools

• Name: Install Shell Tools
• Description: Installs shell tools into the conversation to execute commands and scripts.
• Instruction:

This single "pack" ability is a bundle - once installed, the agent gains the full shell toolkit (execute commands, read/write files, import from URLs, run scripts) inside the sandbox for that session. This is where the agent will do its git clones, builds, and test runs.

Why a sandbox, not your laptop: Unlike a self-hosted coding agent that runs on real hardware, ChatBotKit's shell runs in a throwaway container with strict CPU, memory, and time limits and no access to your infrastructure. Even if the agent runs something reckless, the blast radius is one disposable container.

Step 4: Connect GitHub

This is the layer that lets the agent live inside a real GitHub organization. ChatBotKit's GitHub integration is backed by your own GitHub App, so the agent's reach is bounded precisely by the permissions you grant and the repositories you install it on.

4a. Register the GitHub App

The setup has a small chicken-and-egg ordering (the App's webhook URL contains the ChatBotKit integration's id), so create the integration first:

1. Drag a GitHub Integration resource from the sidebar onto the canvas and connect it to the Bot. Copy its Webhook Payload URL - it looks like https://api.chatbotkit.com/v1/integration/github/{id}/event.
2. On GitHub, go to Settings → Developer settings → GitHub Apps → New GitHub App (use the organization's developer settings so the App belongs to the org the agent will work in).
3. Under Webhook, tick Active, paste the Webhook Payload URL, and set the Webhook secret (ChatBotKit pre-fills a strong one for you - copy it across).
4. Under Repository permissions, grant what an autonomous coder needs:
   • Contents: Read & write (clone and push code)
   • Issues: Read & write
   • Pull requests: Read & write
   • Administration: Read & write only if you want it to create repositories
   • Metadata: Read-only (mandatory)
5. Under Subscribe to events, select Issue comment and Pull request review comment so you can also @mention it in threads.
6. Create the App, note the App ID, then Generate a private key (a .pem downloads).
7. Back in ChatBotKit, paste the App ID, the full Private Key (.pem contents, including the BEGIN/END lines), and the Webhook Secret into the integration.
8. Finally, Install the App on the organization and select the repositories the agent may touch.

GitHub enforces that scope as a hard ceiling - the agent can only ever act on repos where the App is installed, with the permissions you granted.

Full walkthrough: The GitHub integration docs cover every phase of App registration in detail if you get stuck.

4b. Add the GitHub Abilities

Now give the agent the two abilities it needs to drive the org. Drag two more Ability resources onto the canvas, connect each to the Skillset, and link both to the GitHub integration you just created (the id is resolved for you).

Call GitHub API - the agent's general-purpose GitHub tool:

• Name: Call GitHub API
• Description: Makes an authenticated call to any GitHub REST API endpoint. Advanced - bounded by the App permissions and installed repositories.
• Instruction:

This one ability covers a huge surface: creating repositories (POST /orgs/{org}/repos), opening pull requests, commenting on issues, reading workflow runs - anything in the GitHub REST API, bounded by the App's permissions.

Create GitHub Repository Token - so the agent can actually git push:

• Name: Create GitHub Repository Token
• Description: Mints a short-lived installation access token scoped to a repository, for handing to a CLI or git client.
• Instruction:

The flow ties the two layers together: the agent calls Create GitHub Repository Token to mint a short-lived, repo-scoped token, then uses the shell to git clone https://x-access-token:<token>@github.com/org/repo, make changes, and push. The token is live and write-capable but expires quickly and is scoped to a single repository - there is no long-lived credential sitting around to leak.

Step 5: Add a Space for Self-Authored Skills

An autonomous agent that forgets everything between wake-ups is doomed to relearn the same patterns forever. The fix is a Space - persistent file storage - combined with the skills authoring tools, which let the agent write down reusable know-how as skill files it can read back later.

1. Drag a Space resource from the sidebar onto the canvas. Name it something like "Agent Workspace".
2. Drag another Ability onto the canvas, connect it to the Skillset, and link it to the Space:

Install Space Skills Authoring Tools

• Name: Install Space Skills Authoring Tools
• Description: Installs space skills authoring tools into the conversation. You can list available skills, read their full content, and create new skills in the linked space.
• Instruction:

Like the shell pack, this is a bundle. Once installed, the agent can list_space_skills, read_space_skills, and create_space_skills. The backstory already instructs it to read existing skills before creating new ones and to create skills proactively when it spots a repeatable pattern.

In practice this means: the first time the agent scaffolds a new Go service, it figures out the layout, the Makefile, the CI workflow - then saves that as a skill. The next time it needs a new service, it reads the skill and follows its own recipe instead of reinventing it. The agent's competence compounds over time.

Optional: a skills browser tool. You can drop a Space Skill Browser tool node onto the canvas pointed at the same Space, so you can see and review the skills your agent has taught itself directly from the blueprint view.

Step 6: Add Web Search and Fetch

Coding decisions should be grounded in real, current documentation - an API's actual endpoints, a library's latest release notes. Drag two more Ability resources onto the canvas and connect them to the Skillset to give the agent read-only web access:

Search Web

• Name: Search Web
• Description: Search the web for specific keywords.
• Instruction:

Fetch Web Page

• Name: Fetch Web Page
• Description: Fetch the content of a web page using a URL and convert it to text.
• Instruction:

Now when the agent needs to integrate a third-party API or check how a Go library works, it searches, fetches the relevant page, and reads the actual docs rather than relying on stale training data.

Step 7: The Heartbeat - What Makes It Autonomous

Everything so far makes a very capable assistant. This step is what makes it an autonomous worker: a scheduled trigger that wakes the agent up on its own and tells it to make progress, with nobody typing a message.

Drag a Trigger Integration resource from the sidebar onto the canvas and connect it to the Bot:

• Name: Wake up
• Description: Wake up and do your best.
• Schedule: daily (you can also use cron, e.g. 0 */6 * * * for every six hours)
• Timezone: your timezone, e.g. Europe/London
• Authenticate: on

On every tick, the trigger starts a fresh session and hands the agent a wake-up prompt. Because the agent's standing objectives already live in its backstory, the prompt can be as simple as "Wake up. Review the organization, pick the highest-value work, and make progress on it. Verify everything you ship." The agent then:

1. Reads its skills to remember how it likes to work
2. Surveys the org via Call GitHub API (open issues, stale PRs, gaps in coverage)
3. Decides what is most valuable right now
4. Mints a token, clones, edits, builds, and tests in the sandbox
5. Pushes a branch and opens a pull request
6. Records anything new it learned as a skill

This is the loop that runs "around the clock." Start with daily while you build trust, then tighten the cadence as you confirm it behaves.

The heartbeat is the on/off switch for autonomy. With the trigger disabled, you have an excellent on-demand coding agent you summon in GitHub threads or the chat console. Enable it and the same agent becomes self-directing. Keep it off until you have tested the agent by hand and scoped its GitHub App tightly.

Step 8: Test It By Hand First

Before you turn on the heartbeat, drive the agent manually from the Chat console and watch how it behaves:

Test 1 - It can see the org:

Expect it to call the GitHub API and report back. If it cannot, the App is not installed on the org or the integration credentials are wrong.

Test 2 - It can run code:

Expect it to mint a token, clone in the sandbox, run go test ./..., and report results.

Test 3 - It can ship:

Expect a branch, a commit authored as your agent, and an open PR. Review the diff yourself.

Test 4 - It learns:

Expect a new skill file in the Space. Confirm with "list your skills."

Test 5 - It respects the brakes:

Expect it to refuse or ask for explicit confirmation, per its rules. If it deletes without confirming, tighten the backstory before going autonomous.

Only once all five behave should you enable the Wake up trigger.

The Complete Blueprint

Here is the whole system as one importable blueprint. Replace the GitHub App credentials with your own - never commit a real private key or webhook secret anywhere public, including into a blueprint you share.

Security reminder: The appId, privateKey, and webhookSecret above are placeholders. Fill them in only inside your own ChatBotKit integration, and treat the private key and webhook secret like passwords. If either leaks, rotate it in the GitHub App settings. Because tokens are minted short-lived and repo-scoped on demand, there is no long-lived access token to steal.

How the Pieces Fit Together

The heartbeat (or a human) starts a session; the bot consults its manual and skills; it reaches into GitHub and the sandbox to do work; and it writes back what it learned. Every loop, it gets a little more capable.

Safety and Guardrails

An agent that acts without asking deserves real boundaries. ChatBotKit gives you several layers - use all of them:

• The GitHub App is the hard ceiling. Install it on a single, low-stakes organization to start. Grant only the repository permissions the agent actually needs. It can never act outside the repos and permissions you configured - GitHub enforces this, not the prompt.
• Protect your important branches. Turn on branch protection so the agent must go through pull requests. Its backstory already forbids force-pushing protected branches and deleting repos without confirmation - branch protection makes that a server-side guarantee, not just a request.
• The sandbox contains code execution. Everything the agent runs happens in a throwaway container with no route to your infrastructure.
• Tokens are ephemeral and scoped. The git tokens it mints expire quickly and only cover one repository. Nothing long-lived is stored.
• Start slow, then loosen. Keep the heartbeat daily at first and review every PR it opens by hand. Once you trust its judgement, tighten the schedule and let more of its work merge automatically.
• Watch it work. Every wake-up is a conversation in your dashboard. Review the logs periodically to see what it decided and why.

Customize Your Agent

The blueprint is a template, not a destiny. Make it yours:

• Swap the mission. Replace the "agentic-first Go services" mission with your own: keep a documentation site current, triage and fix flaky tests, bump dependencies and open PRs, or maintain a fleet of small tools. The capability layers stay identical - only the backstory changes.
• Add a reporting channel. Connect Slack, Telegram, or Discord to the same bot so each heartbeat posts a short "here's what I did" summary where your team will see it.
• Give it issue-driven work. With Issue comment events subscribed, you can also just open an issue and @mention the agent - it becomes both self-directed (heartbeat) and directable (you).
• Tune the cadence. A daily heartbeat suits most projects. Add a second trigger with a different prompt - one for shipping work, another for housekeeping (pruning stale branches, tidying skills).
• Seed its skills. Pre-write a couple of skill files in the Space - your project scaffold, your CI template - so it starts competent instead of learning from zero.

Troubleshooting

The agent can't see or act on the organization

• Confirm the GitHub App is installed on the org and the specific repos.
• Check the App ID, Private Key (full PEM, including header/footer), and Webhook Secret are filled in correctly.
• Grant the matching Repository permission for the action (e.g. Contents: Read & write to push), then accept the updated permissions on the installation.

git push fails with authentication errors

• Make sure the agent calls Create GitHub Repository Token and uses it in the clone URL (https://x-access-token:<token>@github.com/...).
• The token is short-lived - for long jobs the agent should mint a fresh one rather than reuse a stale one.

The heartbeat never fires

• Verify the Wake up trigger is connected to the bot and the schedule/timezone are set.
• Check the trigger's run logs in the dashboard to see whether it ran and what happened.

It does too much, or the wrong thing

• Tighten the backstory. Narrow the mission, add explicit "do not" rules, and require confirmation for the actions you care about.
• Reduce the GitHub App's permissions and reinstall - the smallest scope that still lets it work is the right one.

It keeps relearning the same patterns

• Confirm the Install Space Skills Authoring Tools ability is connected to the Space.
• Ask it to "list your skills" - if it errors, the Space connection is missing.

Next Steps

• Read How to Build a Personal OpenClaw Agent for the persistent-identity, self-learning patterns this agent builds on
• Explore the GitHub Integration feature and docs for everything the agent can do inside issues and pull requests
• See How to Build a Personal AI Automation Agent Like Moltbot for more on sandboxes, Spaces, and scheduled tasks
• Try Creating an AI Agent That Can Interact with Shells and Construct Its Own Tools to go deeper on sandbox-driven agents

You now have an agent that does not wait for you. Give it a clear mission and the right brakes, switch on the heartbeat, and let it get to work.