Expect posts on:

• Azure architecture patterns and anti-patterns
• Site reliability engineering practices
• Incident response and postmortems (sanitized, obviously)
• Applied AI in production systems
• Tooling and automation

More to come.

The fix is simple to describe: build AI that does one thing, for one domain, with a defined scope.

This is a field implementation of that idea.

The Substrate

The toolkit lives in a git repository. Every Jira ticket and SDP case has a markdown file. Every action — worklog, comment, investigation finding, stakeholder nudge — is written to that file before anything touches an external system. CI/CD syncs the file state on push. The markdown is the source of truth. Jira and SDP are render targets.

Every AI action is reversible, visible, and auditable. There’s no hidden state evaporating when you close a tab. The human approves the file; the system transmits it. That sequence is the crumple zone.

A Dispatch Table, Not a Chatbot

The toolkit is a set of narrow skills, each with a defined scope:

• Clerk — institutional memory retrieval. Searches issue files, case files, Confluence, and reference repos. Cites sources. Never synthesizes. If it finds nothing, it says so: this is new ground.
• Rounds — kanban station management. Claims one lane, works one ticket, manages all paperwork without touching anything outside that ticket’s scope.
• Ticket Investigator — structured problem decomposition. Runs a six-dimension confidence interview. Won’t proceed below 95%.
• Confluence Writer — documentation only. Drafts to file, publishes on operator approval.

Eleven dispatch situations. Eleven named skills. No open-ended improvisation.

Calibrated Autonomy

Every ticket carries an agentic score (1–5) set at intake — a pre-classification of how much human involvement the work requires. Score-1 tickets run to completion without human checkpoints. Score-5 tickets are context-only: the AI reads, summarizes, and steps back. A constraint:technician label caps autonomy regardless of score.

The short version: OpenClaw is powerful, but it is still very much in the “foot gun” stage.

If you are comfortable with Markdown, Git, scripting, cron jobs, basic Linux administration, API keys, and troubleshooting services, you can probably catch up to where I am in about 40 hours of focused tinkering.

If you are not already doing IT work, systems administration, or software development, the onboarding curve is going to be much steeper. This is not yet a polished consumer product. It is closer to a flexible agent framework for people who are comfortable wiring systems together.

That said, the potential is enormous.

Right now I have two OpenClaw instances running.

Instance 1: Raspberry Pi business agent

The first instance runs on a Raspberry Pi.

This agent has a small business-like workflow. Once a day, it checks whether it has enough money available to cover its cloud subscription costs. It can look at markets for things it might sell, generate small static websites, and experiment with Google Ads to direct traffic to those sites.

At the moment, it makes about $50 a month.

That is not life-changing money, obviously, but the interesting part is not the amount. The interesting part is that the agent operates with a defined business context and a limited set of tools.

I gave it access to:

• Its own Stripe account
• Its own email address
• Its own phone number
• Web search through a Brave API key
• The ability to generate simple static sites
• Some scripted workflows around checking costs and opportunities

The goal is not to create a fully autonomous company overnight. The goal is to explore what happens when an AI agent has a persistent identity, a constrained budget, a few business tools, and recurring tasks.

It is less about “AI replaces a business owner” and more about “AI can become a lightweight operator for a very narrow business process.”

Instance 2: Mac mini personal assistant

The second instance runs on a Mac mini.

The main reason I bought the Mac mini was simple: AppleScript.

That’s it.

I wanted an OpenClaw agent that could interact with Apple services in a private, local way. The Mac mini is not exposed to the public internet. It is basically sitting there waiting for me to text it through iMessage.

When I send it an iMessage, it reads the message, processes it through a local OpenClaw prompt, and replies back to me.

This means I can interact with the agent naturally from my phone without opening up a public endpoint or building a custom chat interface. It only needs access to Apple’s services, not the open internet.

This agent has access to:

• iMessage
• AppleScript
• Its own email address
• Apple Notes, if I share notes with it
• A shared calendar
• Web search through Brave API
• Local Markdown files and scripts
• Cron-based recurring tasks

The private routing is the important part.

The Mac mini does not need to be open to the internet. I do not need to expose a web server. I do not need to punch holes in my firewall. I can text the assistant through iMessage, and the Mac handles the rest locally.

That is a very compelling architecture for a personal assistant.

Why this matters

A lot of AI assistant demos are flashy but shallow. They show an agent answering questions in a browser or calling one API.

What I am more interested in is persistent, tool-using agents that can live inside real workflows.

For example:

• Checking accounts or subscriptions on a schedule
• Reading and writing Markdown notes
• Managing reminders or calendar events
• Running local scripts

1. I start with intent: I want to do this, and I want you to interview me until you’re 95% confident. That forces the conversation out of guesswork and into clarity.
2. I point to prior documentation to manage context. If there’s already a good source of truth, I want the model anchored to that instead of rebuilding the world from scratch.
3. Then I ask: What lack of clarity or blind spots are missing? That’s where the real value shows up — assumptions, constraints, and gaps I hadn’t named yet.
4. After that, I ask for suggestions for each gap, so the model turns uncertainty into action.
5. And then: Do it.

That workflow works because it treats AI like a partner for better thinking, not a shortcut for skipping it.

What do I love most? It’s simple: everyone is working together in the same place, all the time. There’s no confusion about which branch is the “real” code, or whether some half-finished feature is hiding out somewhere. If I want to make a change, I just make it, open a quick branch for review, and merge it back within hours — not days or weeks.

This approach means way fewer merge conflicts, way more collaboration, and quicker feedback on every change. I love that the main branch is always ready to ship; there’s a kind of peace of mind in knowing my code is being tested in the same environment that actually goes to production. When work isn’t finished yet, I can use a feature flag to quietly tuck it away — no need to break up the flow or hide what I’m working on.

Best of all, trunk-based development feels like it keeps me — and the whole team — honest. We’re not waiting around, juggling big “launches” and stressful merges. We’re just… building things, together, one step at a time. It’s helped us ship faster, argue less, and focus more on results than on process.

That’s why I’m such a fan. It’s simple, it works, and it lets me spend more time coding and less time worrying about git trivia. Isn’t that what we all want?

#git #branchingstrategy #cicd #infrastructure