Agentic operating layers · platform / internal tools

Agentic operating layers for messy internal systems.

I take the parts of an internal operation that usually live in someone’s head — tickets, logs, repos, runbooks, dashboards, and human review loops — and turn them into agent-assisted workflows that produce useful, auditable work.

The default shape is Platform / Internal Tools: internal agent workflows that connect those sources into repeatable, observable, reviewable triage loops. The proof is a running control plane, an evidence router, a capability catalog, a model-routing substrate, and a production triage engine.

See the control plane Get in touch

Current focus

Turning operational mess into auditable agent loops.

The work right now is one connected system:

Capability Control Plane — the reconciler that runs the loop
Personal Router — activity into reviewed, cited evidence
Agent Catalog — reusable capabilities and agent profiles
Fusion — a self-hosted, cost-metered model substrate

Flagship

The Capability Control Plane.

Internal operations rot in the gaps between systems. The control plane is a reconciler that lives in those gaps: it compares the desired state of an agent operation against the actual state, surfaces the one move that matters, and only acts behind an approval and dry-run gate. Every decision is written back to repo-owned files, so the trail survives the agent that made it.

PIPELINE
  Sources → Catalog → Builds → Evidence → Decisions → Actions → Repo state

RECONCILER LOOP
  Observe → Detect gaps → Propose → Approve → Dry-run → Apply → Verify → Record  ⟲

A 90-second walkthrough:

Today — desired-vs-actual, with the single recommended next move.
Evidence — model-routing cost, router captures, and source health on one timeline.
Decisions — a 150-item review queue bucketed into an actual triage list.
Actions — every mutation typed, dry-run by default, approval-gated, and recorded.

Live on Fly and Tailscale (data reads are operator-token gated), with a read-only npm run demo that narrates the whole pipeline against sample data — no credentials required.

Selected work

One system, built from real parts.

Capability Control Plane

The strongest proof in the system, and the one that ties the rest together: an agent operation whose state was scattered across a capability catalog, model-routing logs, and human review queues that quietly grew to 150+ items.

A reconciler, not a dashboard. It compares the desired state of the operation against the actual state, names the single next move, and only acts behind an approval and dry-run gate — writing each decision back into repo-owned files so the trail outlives the agent that made it.

Observe → detect gaps → propose → approve → dry-run → apply → verify → record
Live on Fly + Tailscale; data reads are operator-token gated
A read-only `npm run demo` walks the whole pipeline

Ask for a walkthrough

Personal Router

Recent project truth is buried in session logs, git history, and scattered notes — almost none of it in a form you can review, cite, or trust.

An evidence router that turns raw session, git, and vault activity into distilled, confidence-tagged facts behind an explicit approval queue. Markdown is the durable artifact; SQLite is a rebuildable index over it.

capture → classify → distill → route → store → next action
LLM distillation runs through the self-hosted Fusion router
Nothing mutates project state until a human approves it

Ask about Personal Router

Fusion

A panel of models gives better answers than any single one — but only if you own the routing, the cost ledger, and the synthesis step.

A self-hosted, OpenAI-compatible multi-model fusion router: it fans a prompt out to a panel of models in parallel, a judge model synthesizes a structured answer, and every call’s cost lands in a SQLite ledger.

OpenAI-compatible — point any SDK at it with model: "fusion"
Per-call cost and latency recorded for every request
Deployed at fusion-router-mdumas38.fly.dev/v1

Ask about Fusion

Agent Catalog

Reusable agent capabilities decay into one-off prompts unless something gives them a durable, validated shape.

A git-native registry of 38 capabilities — primitives, workflows, and products — checked against a typed ontology, with profiles that bundle them into agent roles. No database and no backend: YAML in, validated catalog out.

A Zod ontology plus CI validation is the source of truth
Profiles resolve to install (attach) vs. wire (invoke) steps
Feeds the control plane’s Builds and Capabilities lenses

Ask about the catalog

Compass

A lot of small decisions become messy because the input, the criteria, and the final choice are scattered across notes and memory.

A local-first Go CLI for turning raw signal into an explicit decision record: collect candidates, evaluate them, choose, and leave a reviewable trail with provenance attached to the outcome.

Raw notes become candidates, evaluations, and decisions
Each phase is visible instead of hidden in a transcript
Cobra + Bubble Tea TUI; decision records on disk

View repository

Platform Pilot

Standing up a new service means re-deciding the same platform questions — runtime, CI, containerization, validation — every single time.

A guided DevOps build advisor: a senior-platform-engineer agent API that scans a repo, recommends a path, generates a roadmap and artifacts (Dockerfile, GitHub Actions, runbook), and validates them. It is the reusable demo pattern for the rest of the system.

scan → recommend → roadmap → generate → validate
Honest MVP framing with a real `npm run demo` path
Fastify + SQLite + the Anthropic SDK

Ask about Platform Pilot

Case study · what this proves

The pattern predates the tooling: the AppCard triage engine.

Years before any of the current agent tooling, the same operating-layer pattern was already running in production. Support and engineering teams were investigating the same production tickets by hand — roughly 50 a month, 20–60 minutes each, with no reproducible process.

I built a Python CLI and Jira-webhook triage engine with a scoped tool registry over Loki, Aurora PostgreSQL, and S3. It used fallback resolution, early exits, validation checks, and explicit uncertainty in its outputs so it could survive missing identifiers, noisy logs, and schema drift instead of guessing.

Investigation time for the covered ticket classes dropped from 20–60 minutes to 5–15, and the outputs became structured and auditable instead of ad hoc. The control plane above is that same idea, generalized: messy operational system → observable workflow → automation paired with human review → a business outcome.

Messy operational system → observable workflow
Automation paired with human review, never blind
Structured, auditable outputs over ad-hoc heroics

Ask about this work

What tends to matter

The hard part is rarely just the code.

Observable

Every claim the system makes points back at its evidence — the model call, the log line, or the git event behind it.

Reviewable

Proposed changes sit in a queue a human approves or rejects. Nothing load-bearing happens silently.

Reversible

Mutations are typed, dry-run by default, and recorded — so an action can be understood and undone, not just executed.

About

I like making agentic work easier to inspect.

I’m Mason Dumas, a New York–based engineer working across production engineering, data systems, developer tooling, and agent-assisted workflows.

I’m drawn to operational mess: tickets that need too much context, reports that disagree, debugging paths that live only in someone’s head, and agent workflows that need better evidence, review, and audit trails before anyone can trust them near real systems.

Contact

Want to compare notes?

For project conversations, a walkthrough of the control plane, or questions about the private work behind any of the projects above, email is best.

mdumas38@gmail.com