Building an Autonomous Agent for Your Personal Website in 2026

Most personal websites are static. You write content, push a commit, a CI pipeline deploys it, and nothing happens until you do it again. That model treats the website as an artefact rather than a system. In 2026, it is reasonable to treat it as a system — one where an agent handles the tedious operational work so you handle the decisions that actually require judgment.

OpenClaw is the agent running on calvinkennedy.com. It takes GitHub webhook events, triages them, runs Claude against the task, validates the proposed actions through Portarium, and executes the approved ones. The website has been running this way in production since early 2026. This post explains the full architecture, what it costs, and why the design intentionally keeps a human in the loop on anything that matters.

Project page: /projects/openclaw. Validation layer: /projects/portarium. Consulting: /consulting.

The Architecture

The system has five layers. Nothing here is novel individually — the value is in the composition and the governance boundaries between them.

GitHub Event
     │
     ▼
┌─────────────────┐
│  Webhook Server │  port 3042, AWS Lightsail
│  (Express)      │  validates signature, enqueues
└────────┬────────┘
         │
         ▼
┌─────────────────┐
│  Message Queue  │  in-memory queue with persistence
│                 │  rate-limits upstream pressure
└────────┬────────┘
         │
         ▼
┌─────────────────┐
│  Agent Loop     │  Claude claude-sonnet-4-6
│                 │  triage → plan → tool calls
└────────┬────────┘
         │
         ▼
┌─────────────────┐
│  Portarium      │  Zod schema validation
│  Validation     │  approval gates, audit log
└────────┬────────┘
         │
         ▼
┌─────────────────┐
│  Execution      │  file writes, git ops,
│                 │  content transforms, deploys
└─────────────────┘

The webhook server receives events from GitHub and validates the HMAC signature before anything else happens. Invalid or unsigned requests are dropped before they reach the queue. The queue sits between intake and execution so that a burst of GitHub events — say, 12 commits in rapid succession — does not translate into 12 simultaneous Claude API calls.

The agent loop is where Claude runs. It receives the event context, the current state of the relevant files, and a system prompt that defines its role, its available tools, and its constraints. It produces a plan and a sequence of tool calls. Those tool calls do not execute directly — they pass through Portarium first.

The Webhook Handler

The entry point is a standard Express route with HMAC validation:

import express from "express";
import crypto from "crypto";

const app = express();
app.use(express.raw({ type: "application/json" }));

app.post("/webhook/github", (req, res) => {
  const signature = req.headers["x-hub-signature-256"] as string;
  const expectedSignature =
    "sha256=" +
    crypto
      .createHmac("sha256", process.env.GITHUB_WEBHOOK_SECRET!)
      .update(req.body)
      .digest("hex");

  if (!crypto.timingSafeEqual(Buffer.from(signature), Buffer.from(expectedSignature))) {
    res.status(401).send("Invalid signature");
    return;
  }

  const event = JSON.parse(req.body.toString()) as GitHubPushEvent;
  const eventType = req.headers["x-github-event"] as string;

  // Acknowledge immediately — GitHub expects a fast 200
  res.status(200).send("Accepted");

  // Enqueue for async processing
  eventQueue.enqueue({ eventType, payload: event, receivedAt: new Date().toISOString() });
});

app.listen(3042);

The 200 response goes back to GitHub before any processing happens. GitHub will retry events if it does not get a response within 10 seconds, so the webhook handler does exactly two things: validate the signature and enqueue. Everything else is async.

Portarium Validation Before Execution

Before any tool call executes, it passes through the Portarium validation layer. This is the same pattern described in detail in the AI safety guardrails post — Zod schema enforcement, approval gates for high-risk operations, and a full audit trail.

For OpenClaw specifically, the tool call schemas enforce what the agent is allowed to do:

import { z } from "zod";

const openClawToolSchemas = {
  write_content_file: z.object({
    path: z
      .string()
      .startsWith("apps/portfolio/src/content/")
      .refine((p) => !p.includes(".."), "Path traversal not allowed"),
    content: z.string().max(50_000),
    commitMessage: z.string().min(10).max(200),
  }),

  run_build_check: z.object({
    scope: z.enum(["portfolio", "api", "full"]),
    dryRun: z.boolean().default(true),
  }),

  trigger_deployment: z.object({
    environment: z.enum(["staging"]), // production requires manual promotion
    reason: z.string().min(20),
    confirm: z.literal(true),
  }),
};

Note that trigger_deployment is hard-coded to staging only. Promotion to production is not a tool call — it is a manual step. That boundary is enforced in the schema, not in a system prompt the model could reason its way around.

High-risk tool calls route through an approval gate that posts to a review channel before execution. Low-risk calls — read operations, content transforms, build checks in dry-run mode — execute immediately after schema validation passes.

Why Governed, Not Fully Autonomous

The goal is not to eliminate human oversight. It is to eliminate the tedious parts while keeping meaningful approval gates on the parts that matter.

OpenClaw handles everything that is tedious and low-stakes: generating draft content from project journal entries, running build validation after a push, formatting and linting content files, creating structured summaries of technical decisions. That is the work where the bottleneck is not judgment — it is time. The agent is faster and more consistent than doing it manually.

The things that stay human-gated: production deployments, changes to configuration that affect all site visitors, and anything where the downstream consequence of a mistake is not trivially reversible.

This is a governance philosophy, not a technical limitation. Claude could be given the tools to deploy to production directly. The decision not to do that is intentional. Autonomous systems fail in ways that are hard to predict and expensive to reverse. The meaningful question is not “how much can the AI do?” but “which decisions benefit from human sign-off and which ones are pure friction?”

At the current operating scale, the ratio is roughly 80/20 — 80% of the operational work goes through the agent with no human touch, and 20% routes through approval before execution. The 20% is where the interesting decisions live.

Infrastructure and Cost

OpenClaw runs on a single AWS Lightsail micro_3_2 instance — 2 vCPUs, 2GB RAM, $7/mo. The webhook server listens on port 3042 with a static IP. That is the only Lightsail-specific configuration required; everything else is just Docker.

AWS Lightsail micro_3_2  — $7/mo
Static IP                — included
Claude API usage         — variable, typically $3–8/mo at current volume
Total                    — ~$10–15/mo

The Docker setup is two containers: the OpenClaw agent service and a lightweight Postgres instance for the audit log and approval queue. Both are managed with Docker Compose. Deployments are a docker compose pull && docker compose up -d behind an SSH jump.

There is no Kubernetes here, no load balancer, no auto-scaling group. The traffic profile does not require it. An agent running operational tasks on a personal website is handling tens of events per day, not thousands per second. Right-sizing the infrastructure to the actual load is part of what makes this affordable to run indefinitely.

What This Looks Like as a Consulting Model

The OpenClaw architecture generalises. The specific tools change — instead of writing Markdown content files, maybe the agent is routing support tickets, generating draft proposals, or running post-meeting summaries into a project management system. The structure stays the same: event intake, queue, agent loop, validation layer, governed execution.

The interesting constraint is scope. This works well for one bounded workflow with clear inputs and outputs. It works poorly when you try to make the agent responsible for everything. The discipline is identifying the one workflow where the tedious-to-judgment ratio is highest, governing it well, and running it in production long enough to learn what needs adjusting.

If you want this for your own business — one bounded workflow, governed, production-grade, running on infrastructure you actually understand — that is what the consulting engagement covers. The deliverable is a running system, not a prototype.