Lessons learned
Things we learned building an AI operator cockpit.
A running list of practical rules from building with OpenClaw, local tools, external APIs, skills, and a real daily assistant workflow.
Chat is not the system of record
Use chat for interaction, but store tasks, reports, decisions, and artifacts in durable files or a task system. Otherwise the assistant becomes impressive but operationally slippery.
Clearing a chat is not the same as resetting context
Use a real session reset when you need cost/context savings. Treat visible chat cleanup and model context as different things.
Default human-readable output should be boring
Unicode punctuation is pretty until it passes through Windows shells, email bodies, and logs. For public CLI skills, ASCII-safe text is a feature.
Email sending needs fail-closed guardrails
Dry-run first, hash the body, require an explicit send flag, and enforce a recipient allowlist. The model should not be able to casually email the world.
Local models are useful, but not always safe for boot paths
If a local runtime auto-updates or can surprise-load GPU, avoid using it for startup, heartbeats, and critical automation unless intentionally approved.
Use premium judgment where it matters
Cheap or local models can do bulk work. Use stronger models for final external copy, security review, billing/secrets decisions, and hard debugging.
Skills should advertise side effects
If a skill writes to Linear, sends email, caches queries, logs usage, or calls an external API, say so in the metadata and docs. Routing depends on truthful triggers.
A cockpit changes the relationship
Mission Control turns an assistant from a chat toy into an operating layer: tasks, health, artifacts, agents, reports, and approvals become visible.