A simple plan for your personal AI operating system

The goal

Build a small, dependable system that:

• automates recurring work;
• gives AI a safe set of reusable tools;
• keeps data in formats you control;
• shows health, outcomes, and costs in one Grafana home dashboard.

The important idea is: this is not one giant application. It is a collection of small programs with stable interfaces. Grafana observes them. Pi helps you operate them. Deterministic code does the recurring work.

North star: if the AI model, Grafana, or internet is unavailable, scheduled work should still run and your data should still be readable.

You already have the foundation

Your current setup already contains:

• cron-managed command and Pi jobs;
• scripts for backups, reminders, stocks, exchange rates, reports, and system checks;
• failure email handling through alert-on-fail.sh;
• Pi skills and extensions for reusable AI workflows;
• separate SQLite databases for stocks, rates, and Pi usage;
• provisioned Grafana data sources and dashboards.

Do not replace this. Standardize it gradually.

The architecture

Inputs ──> small CLI tools ──> domain SQLite ──> Grafana
                 ^                    ^
                 |                    |
              cron / Pi          run ledger

Rules that keep it suckless

1. Automate a stable manual process, not an unclear wish. Write the steps down and run them manually first.
2. Prefer deterministic code over AI. Use AI only where language, ambiguity, or judgement is actually involved.
3. One tool, one contract. Support explicit arguments, useful --help, non-zero failure exits, and JSON output when another program consumes it.
4. The same tool serves humans, cron, and AI. Do not create separate implementations for each caller.
5. Store facts, not presentation. Grafana queries data; scripts do not generate dashboard-specific blobs.
6. Read-only by default. Split read and write tools. Require approval for sending, deleting, purchasing, publishing, or changing infrastructure.
7. Make failure visible. Every scheduled run records start, finish, result, duration, and a log location.
8. Add infrastructure only after a measured need. No Kubernetes, message bus, vector database, multi-agent framework, or workflow platform by default.

The roadmap

Phase 1 — Inventory and choose one vertical slice

Create a short inventory with these columns:

Rank candidates by time saved × frequency, then reduce the score for risk and implementation complexity.

Choose one workflow that is frequent, read-only or reversible, and easy to verify. Good candidates from your current system are the hourly system review or market-data updates. Do not begin with autonomous email sending or financial actions.

Done when: one workflow has a written input, output, failure condition, and acceptance check.

Phase 2 — Add a tiny run ledger

Create one new database, automation.sqlite, for execution metadata only. Start with one table:

job_runs(
  id, job_name, trigger, started_at, finished_at,
  status, exit_code, duration_ms, summary, log_path
)

Add one small runner around scheduled commands. It should:

1. record the start;
2. run the existing command unchanged;
3. capture exit status and duration;
4. record success or failure;
5. preserve the current email-on-failure behavior.

Avoid a generalized event platform. A run ledger answers the immediate questions: Did it run? Did it work? How long did it take? Where is the log?

Done when: the chosen workflow can fail deliberately and the database records the failure correctly.

Phase 3 — Build the Grafana home dashboard

Provision it from Git like your existing dashboards. Add only panels that cause a decision:

• failed jobs in the last 24 hours;
• jobs whose last successful run is too old;
• recent run history and duration;
• Pi cost and token usage;
• links or compact summaries for stocks, exchange rates, reminders, and system health;
• one small “needs attention” section.

Keep domain dashboards separate and link to them from the home dashboard. Do not squeeze every chart onto one page.

Continue opening SQLite data sources in query-only mode. Grafana’s SQLite plugin reads databases available on the Grafana host.¹ Your existing provisioning already follows this model. Grafana also supports file-provisioned dashboards and data sources, so definitions can remain version controlled.²

Done when: opening one page tells you what needs attention in under 30 seconds.

Phase 4 — Standardize reusable tools

For each workflow you touch, use this shape:

tool-name check ...      # read-only inspection
tool-name run ...        # perform the bounded action
tool-name status --json  # machine-readable result

A tool should validate inputs itself. Never depend on the model to enforce permissions or business rules.

Turn repeated Pi operating knowledge into small skills. A skill should explain when to use a tool, the safe workflow, and verification steps. Keep implementation in scripts rather than duplicating code inside prompts.

Do not add MCP immediately. Your current local tools and Pi skills are simpler. Add a local stdio MCP adapter only if the same tools genuinely need to work across several AI clients. MCP standardizes tools, resources, and prompts, but it is an interoperability layer—not an operating system or workflow engine.³

Done when: the same command works interactively, from cron, and through Pi.

Phase 5 — Add AI only at judgement points

Use a three-level autonomy model:

Start every capability at Observe. Promote it only after reviewing a useful sample of runs and defining rollback or recovery.

Keep untrusted content—emails, web pages, documents—separate from instructions. OWASP identifies excessive functionality, permissions, and autonomy as root causes of damaging agent actions, and recommends narrow tools, least privilege, downstream authorization, logging, and human approval for high-impact actions.⁴

Done when: every AI-enabled write action has a narrow permission boundary and an explicit approval rule.

Phase 6 — Expand one workflow at a time

For every new automation, repeat this loop:

1. document the manual process;
2. implement the smallest deterministic tool;
3. test success, duplicate execution, and failure;
4. schedule it;
5. record runs;
6. add one useful dashboard signal;
7. add a Pi skill only if natural-language operation helps;
8. review after real use and delete what is not useful.

A sensible order for your system is:

1. existing job health;
2. backups and stale-data checks;
3. reminders and personal administration;
4. read-only email/news summaries;
5. finance and stock reporting;
6. work/Jira assistance;
7. carefully approved outbound actions.

When to adopt heavier tools

Keep cron while jobs are local, independent, and understandable. systemd timers become useful if you need missed-run catch-up with Persistent=, stronger service supervision, or journal integration.⁵

Consider Windmill only when you need multi-step workflows, retries, approvals, secret handling, and a web interface often enough to justify another service. It is code-first and self-hostable, but also introduces a worker runtime, orchestrator, and application platform.⁶ Consider n8n when visual SaaS integration is the dominant need.⁷

Do not adopt either merely to replace ten readable cron entries.

Operations and safety checklist

• Keep secrets in pass or environment files with restricted permissions; never in dashboard JSON, prompts, logs, or Git.
• Give Grafana read-only database access.
• Back up domain databases, run history, notes, and configuration; test restore periodically.
• Make jobs idempotent where possible: rerunning should not duplicate side effects.
• Set timeouts on network and AI calls.
• Record model, cost, tool name, result, and duration—but do not store sensitive prompt bodies by default.
• Alert only on actionable conditions to avoid notification fatigue.
• Review enabled AI tools quarterly and remove unused permissions.

What not to build now

• a custom chat frontend;
• a central “god” agent with shell and all credentials;
• a multi-agent hierarchy;
• a vector database for notes that ordinary search can find;
• a universal event schema;
• a plugin system around already-scriptable CLI tools;
• a Grafana write/control interface;
• a migration from SQLite or cron without a demonstrated problem.

Your next five actions

1. Write the workflow inventory.
2. Pick one low-risk vertical slice.
3. Define the minimal job_runs schema and runner contract on paper.
4. Sketch the Grafana home page with no more than eight panels.
5. Decide the acceptance test before writing code.

Then implement only that slice end to end. Let actual friction—not architecture enthusiasm—choose the next feature.

Sources and further reading