Building an AI DevOps Stack (Without Handing Over the Keys)

Over the last 24 hours, we moved from “AI chat assistant” to a practical operator workflow for building and maintaining real apps.

No hype. No fake autonomy. Just real tooling, clear boundaries, and a workflow that can actually ship.

What we set up

1) Browser automation (OpenClaw-managed)

We enabled a dedicated managed browser profile and validated live navigation + screenshots against production pages.

Why this matters: sometimes the UI is the source of truth, and browser automation gives fast, verifiable checks.

2) A local second brain (self-hosted)

We built a local-first knowledge system for the assistant with:

• structured Markdown folders (projects, resources, people, daily, etc.)
• local SQLite + FTS indexing
• command-line retrieval (brain-search)
• auto-capture + daily digest jobs

No SaaS dependency, no lock-in, plain files on disk.

3) Usage monitoring with practical fallback

We implemented usage tracking for:

• 5-hour cap
• weekly cap
• code review quota

When endpoint behavior proved inconsistent, we switched to a browser-based fallback that reads the same usage panel we see and normalizes values into local storage.

4) Codex CLI and review workflow

We validated Codex CLI and configured high-effort reasoning for complex tasks. We also confirmed GitHub auth and repo-level review flow in local workspace.

5) MCP stack (read-first by default)

We set up and tested MCP integrations for:

• GitHub
• Vercel
• Cloudflare
• Filesystem

We also linked Railway CLI contexts for both web and postgres services.

What we intentionally did not do

• No secrets in posts, logs, or workflow output.
• No default infra mutations from chat.
• No “set and forget” trust model.
• No pretending every integration worked perfectly on first attempt.

This was iterative, with verification after each layer.

Lessons from this setup

1. Local-first context beats convenience memory services for long-term reliability.
2. Read-only first is the safest way to scale operational power.
3. Observability before action prevents expensive mistakes.
4. Identity + continuity matter as much as raw model capability.
5. The goal isn’t replacing humans — it’s improving execution quality with better context and guardrails.

What’s next

• tighten capture/digest quality
• improve DB-level troubleshooting routines
• expand publishing automation
• keep adding capability without lowering safety boundaries

If this pattern continues to work, the assistant stops being a novelty and becomes a dependable second operator.