The part of an agent worth copying
I spent a weekend picking apart Praxis, an open-source database agent that a developer posted to help DBAs cut repetitive work. The pitch is familiar: hand a routine inspection to an AI in plain language, let it read the schema and step through the usual checks — table sizes, index usage, storage, anomalies — so nobody starts from a blank query every time.
What stuck with me wasn't the live inspection. It was one line buried in the post: *a check flow that ran successfully should be saveable, so next time you just pick it up again.* Save the passed flow, tweak it later, run it by hand or on a schedule, and load DBA "skills" to steer deeper analysis. That's the durable idea. The clever agent orchestration is the flashy half; the *replayable* half — the saved playbook and the record of what happened when you ran it — is the part that keeps paying off.
And it's not just Praxis. Look across the same batch of maker posts and the pattern repeats. A screenshot tool keeps a "history projects" list so you resume old drafts instead of rebuilding them. A chat-driven agent runs scheduled tasks and remembers skills you asked it to write. Another has a task board tracking queued, running, needs-action, failed, cancelled, done. Different domains, same instinct: people want the work they already got right to survive and re-run without re-deriving it.
What you can actually build on VicroCode — and where the wall is
Here's the honest boundary, stated up front so nobody gets surprised. Praxis connects to real MySQL and PostgreSQL and folds in an external monitoring stack. VicroCode does not reach out to external MySQL or PostgreSQL, and it doesn't wire into an outside monitoring system. If your need is "agent logs into my production Postgres and inspects it," that falls outside what I can build here. Full stop.
So I didn't try to clone the whole thing. I rebuilt the half that VicroCode is genuinely good at: the saved-and-versioned check *playbook* and the *run-history ledger*. The engine that reads your live database stays external; what lives on VicroCode is the definition of each check, its version history, and the record of every run. The reach-into-production piece is unverified and out of scope — treat this as the memory and replay layer, not the inspection layer.
That maps cleanly onto the confirmed toolset. This kind of save-and-replay work is squarely in the lane of AI agent development, where the assistant helps you shape the orchestration logic rather than hand-writing every branch. The data model is small and relational, which is exactly what an in-platform SQLite store is for.
The data model
Two tables carry most of the weight.
A `playbook` table holds each check as a named, versioned document — the ordered steps, the SQL or skill each step expects, and a version number so an edit never silently overwrites what already passed. When a DBA adjusts a check, you write a new version row instead of mutating the old one. That's the whole point of "the thing that worked should stay recoverable."
A `run` table is the ledger. Each row records which playbook version ran, when, who or what triggered it, a status (I'd borrow that queued / running / needs-action / failed / done vocabulary straight from the task-board post, since it's proven and readable), and the captured output. Now "did last week's check pass?
is a query, not a memory.
Because it's plain SQLite, you can open the store directly in the SQLite editor to eyeball a botched run, patch a status by hand, or prune old versions without writing a migration script. That immediacy matters when you're still figuring out the schema and changing your mind twice a day.
Wiring it together
The orchestration is a hosted Python backend. You run Python online to expose a few endpoints: register a playbook version, kick off a run, append results to the ledger, list run history for a playbook. The external inspection engine — Praxis, a cron job, a laptop script, whatever actually touches your database — calls in through an API endpoint to say "here's what this run found." VicroCode holds the definitions and the history; the outside world does the touching.
A rough shape of the run-recording endpoint:
import sqlite3, json, time
def record_run(playbook_id, version, status, output):
conn = sqlite3.connect("checks.db")
conn.execute(
"INSERT INTO run "
"(playbook_id, version, status, output, created_at) "
"VALUES (?, ?, ?, ?, ?)",
(playbook_id, version, status, json.dumps(output), int(time.time())),
)
conn.commit()
conn.close()
return {"ok": True}Parameterized queries throughout — you're storing output that originated from a database, so treat every field as untrusted and never string-format it into SQL. One note before you ship anything: an endpoint that writes run records needs authentication. Without a token check, anyone who finds the URL can pollute your ledger with fake runs. Add a shared-secret header or key check on write endpoints before this goes anywhere real.
Why this is worth doing
The replay layer is small, boring, and exactly the thing that erodes first in a hand-rolled setup. Checks live in someone's shell history, results live in a Slack thread, and six weeks later nobody can say whether the storage check actually ran or just felt like it did. Pulling the playbook definitions and the run ledger into one queryable SQLite store — hosted, shareable, versioned — turns that fog into something you can point at.
I'd keep the scope tight. Don't try to make VicroCode reach your production database; it won't, and pretending otherwise sets up a broken demo. Build the memory, let the external engine do the reaching, and let the two meet at an authenticated endpoint. That division is honest about the boundary and still captures the part of the Praxis idea that's genuinely reusable — the half where work you already got right gets to run again without being rebuilt.