A few selected projects and systems.

What this work is meant to prove

The strongest through-line in my work is not a single launch story. It is the habit of turning ambiguous ideas into systems that can be inspected, used, improved, and maintained.

• Executable systems: moving from idea, prompt, or prototype into workflows with state, verification, and a repeatable path forward.
• Human-governed automation: using agents and automation as bounded leverage while keeping framing, review, and accountability with the operator.
• Public honesty: distinguishing linkable shipped surfaces from private or in-flight work instead of making everything sound equally launched.

Agent tooling and MCP infrastructure

I maintain a set of agent-facing tools that are meant to make AI work more operational than theatrical: installable skill bundles, MCP servers, and local workflow surfaces that give agents concrete tools, bounded permissions, and repeatable install paths.

The public pieces include a portable agent library, MCP servers for local command and workspace integrations, and experiments in memory, retrieval, and tool use. The private pieces include a local ChatGPT history index that turns a large personal archive into searchable source material without treating the archive itself as public content.

The pattern I care about is simple: agents are useful when the surrounding system makes state, boundaries, review, and ownership explicit.

OpenClaw and NanoClaw assistant work

I have also spent time in the personal-assistant layer: always-on local assistants, messaging channels, scheduled work, memory, tools, and the security questions that appear when an agent can touch real parts of a person's life.

The public work around OpenClaw and NanoClaw reflects two versions of that question. One is a broader assistant platform with channels, tools, skills, and device surfaces. The other explores a smaller, more inspectable path with container-isolated agents and a bias toward code that an individual can understand and adapt.

The interesting part is not the novelty of another assistant. It is the operating contract: what the assistant can see, what it can do, what stays isolated, and how a person stays responsible for the outcome.

Captain Calico and Bookforge

Captain Calico is a children's adventure series, and Bookforge is the local-first publishing pipeline behind it. The repository is not just a manuscript folder. It has project state, series continuity, cover and art conventions, packaging outputs, and build commands that can take a checked-in book toward ebook, print, booklet, audio, and vendor-ready artifact families.

The useful engineering problem is turning a creative series into a production system without pretending creativity can be reduced to a single prompt. The pipeline keeps source prose, canon, cover metadata, manual art inputs, generated artifacts, and operator checklists separate enough that each part can be improved without losing the thread.

This is still a private production effort, but it is real work: a series-scale content system with local builds, verification, state, packaging, and release discipline.

Shepherd Online Homeschool

Shepherd is a Christian homeschool operating system for grades 6-12. The product work brings curriculum, weekly planning, student workflow, parent oversight, records, source transparency, and AI-assisted support into one governed surface rather than scattering the week across disconnected tools.

The current build has a public preview surface, marketing and curriculum routes, protected parent/student/admin workflows, readiness checks, course data, and a growing content-engine layer. The important constraint is honesty: public curriculum claims are tied to route data and readiness evidence, not just aspirational copy.

I think of this less as an edtech landing page and more as a product-platform problem for families: the system has to be academically serious, parent-governed, operationally simple, and explicit about the worldview shaping it.

Unnamed automated trading platform

I am building a private platform for declarative trading strategies across options and multi-asset workflows. The system centers on strategy specifications, plugin-driven market data and execution paths, broker adapters, risk controls, journaled events, and paper-trading promotion paths before anything can approach live operation.

The work is intentionally cautious. Trading software needs auditability, idempotency, risk gates, and language that does not confuse tool building with financial advice. The interesting engineering surface is not prediction theater. It is how to make strategy authoring, broker capability checks, execution state, and operator review fit together without hidden magic.

The repo is private while the product is still in flight, but it has a working web app, runtime services, end-to-end tests, Alpaca-paper integration paths, and a current milestone backlog. Publicly, I write about the decision-quality lessons without exposing private financial details or implying guarantees.

This site as an ongoing proof surface

I wanted a place to collect writing that felt quieter and more durable than scattered posts or profile copy. The project is not just the front-end of the site. It is the operating rhythm behind it: identifying the next missing artifact, writing pieces that feel honest and useful, and improving the surface in small steady steps instead of waiting for a large redesign moment.

It has also become a useful place to think through what belongs in public writing versus what only sounds polished. That distinction matters more than it first appears.

The site is intentionally repo-driven, reviewable, and incremental. That matters because the medium should match the message: serious proof surfaces are maintained through judgment and cadence, not through one-time branding passes.