Projects

[placeholder] One line on what's here.

namestackyear
Agent Flare
A Hermes Agent for each person, in its own Cloudflare Container behind Access, on zero trust principles: access only to what it needs, short-lived, when it needs it.
Diagram: the Hermes desktop app on a laptop connects through cloudflared, outbound only, to Cloudflare Access and then a per-person tunnel into that person's container on Cloudflare Containers. A client script signs in through Access to a Worker that provisions tunnels and wakes and stops containers. Each container snapshots its home directory to R2 as squashfs and calls models through AI Gateway with API keys and AI Gateway headers. Some credentials are kept in KV and Worker secrets.
The only way in is Cloudflare Access: sign in, then an outbound-only tunnel to your own container. The agent never runs on the laptop.
Diagram: planned design. A browser opens the Hermes webapp with Cloudflare Access as the first hop and no tunnel. The person's container has internet off and no credentials inside, and still snapshots to R2. The agent's terminal runs in a Sandbox per agent. All outbound traffic from the container and the sandbox goes through outbound handlers in the Workers runtime, then to AI Gateway with DLP for models, and through a Workers VPC binding into Cloudflare Gateway with DLP for web traffic.
Planned: a browser as the only client, a sandbox per agent, and every outbound request under Gateway and DLP.
Cloudflare Containers, Access, Tunnel, R2, KV, AI Gateway, Hermes Agent
Diagram: the Hermes desktop app on a laptop connects through cloudflared, outbound only, to Cloudflare Access and then a per-person tunnel into that person's container on Cloudflare Containers. A client script signs in through Access to a Worker that provisions tunnels and wakes and stops containers. Each container snapshots its home directory to R2 as squashfs and calls models through AI Gateway with API keys and AI Gateway headers. Some credentials are kept in KV and Worker secrets.
The only way in is Cloudflare Access: sign in, then an outbound-only tunnel to your own container. The agent never runs on the laptop.
Diagram: planned design. A browser opens the Hermes webapp with Cloudflare Access as the first hop and no tunnel. The person's container has internet off and no credentials inside, and still snapshots to R2. The agent's terminal runs in a Sandbox per agent. All outbound traffic from the container and the sandbox goes through outbound handlers in the Workers runtime, then to AI Gateway with DLP for models, and through a Workers VPC binding into Cloudflare Gateway with DLP for web traffic.
Planned: a browser as the only client, a sandbox per agent, and every outbound request under Gateway and DLP.
2026
LFM2.5-24B-A2B, quantized to GPTQ
Liquid AI's 24B mixture-of-experts model, quantized to 4-bit GPTQ (13.4 GB) to fit on a single 20–24 GB GPU, and published on Hugging Face.
GPTQModel, Hugging Face Spaces (A100), vLLM, Hermes Agent2026
Inference lab
llama.cpp, Ollama, vLLM and Strata on two machines: an old rig at home with an RTX 4080 Super, and a Lambda Vector workstation at the office with an RTX 4000 Ada.
llama.cpp, Ollama, vLLM, Strata, Hugging Face Spaces2024
CSVAI
Plain-English questions over the federal HMIS CSV export, for non-profits housing people experiencing homelessness. An LLM on Workers AI writes the SQL from the schema; the data is queried where it lives.
Diagram: an agency exports its HMIS data in the standard CSV format, pseudonymized by a tool call to another platform if needed. Staff upload it in the orchestrator's web chat, which sends the ZIP to a Python service on sovereign hosting. The service preprocesses the export once, attaches 24 JSON schemas and caches the tables. Staff then ask questions in the same chat; the orchestrator splits them and picks the files. The PandasAI agent sends the schema and question through AI Gateway to Qwen 2.5 Coder 32B on Workers AI, which returns SQL that runs locally. The orchestrator sends results to Gemma 4 26B A4B or gpt-oss-20b on Workers AI for a summary. Follow-ups may send up to 29 result rows.
The data is queried where it lives. Schema and questions go out through AI Gateway, to Workers AI models only.
Diagram: planned design. Every file in the export is loaded once into a single semantic layer with better definitions and declared one-to-many relations: Client and Project to Enrollment, and Enrollment to Exit, IncomeBenefits and Services. The PandasAI agent joins across the whole model and runs the SQL locally. A chat app replaces the first orchestrator interface; staff still upload the export there, and it still goes to the Python service. Every model call goes through AI Gateway with DLP to Workers AI.
Planned: one semantic layer over every file, a chat app, and DLP on AI Gateway.
Python, FastAPI, PandasAI, Workers AI, AI Gateway
Diagram: an agency exports its HMIS data in the standard CSV format, pseudonymized by a tool call to another platform if needed. Staff upload it in the orchestrator's web chat, which sends the ZIP to a Python service on sovereign hosting. The service preprocesses the export once, attaches 24 JSON schemas and caches the tables. Staff then ask questions in the same chat; the orchestrator splits them and picks the files. The PandasAI agent sends the schema and question through AI Gateway to Qwen 2.5 Coder 32B on Workers AI, which returns SQL that runs locally. The orchestrator sends results to Gemma 4 26B A4B or gpt-oss-20b on Workers AI for a summary. Follow-ups may send up to 29 result rows.
The data is queried where it lives. Schema and questions go out through AI Gateway, to Workers AI models only.
Diagram: planned design. Every file in the export is loaded once into a single semantic layer with better definitions and declared one-to-many relations: Client and Project to Enrollment, and Enrollment to Exit, IncomeBenefits and Services. The PandasAI agent joins across the whole model and runs the SQL locally. A chat app replaces the first orchestrator interface; staff still upload the export there, and it still goes to the Python service. Every model call goes through AI Gateway with DLP to Workers AI.
Planned: one semantic layer over every file, a chat app, and DLP on AI Gateway.
2025
Action Center
A Cloudflare Worker that stands between automation and ConnectWise Manage: every proposed change is audited by an AI supervisor against written playbooks, then approved by a person before it runs.
Diagram: sync scripts and ticket analysis post proposed ConnectWise Manage actions to the Action Center Worker, which stores each one in D1 with three status fields: AI review, human and execution. In the background, the AI supervisor builds a prompt from the playbook knowledge base and sends it through AI Gateway, which returns an approved or rejected verdict with notes. If the call fails, the action stays pending. A reviewer behind Cloudflare Access approves, denies, edits or overrides a single rejected action in the dashboard; bulk approval only runs actions the AI approved. Approved actions go to the ConnectWise Manage API as the approving member, and the result is logged to D1.
Nothing reaches ConnectWise without an AI audit and a human approval.
Cloudflare Workers, Hono, D1, AI Gateway, Access, ConnectWise Manage API
Diagram: sync scripts and ticket analysis post proposed ConnectWise Manage actions to the Action Center Worker, which stores each one in D1 with three status fields: AI review, human and execution. In the background, the AI supervisor builds a prompt from the playbook knowledge base and sends it through AI Gateway, which returns an approved or rejected verdict with notes. If the call fails, the action stays pending. A reviewer behind Cloudflare Access approves, denies, edits or overrides a single rejected action in the dashboard; bulk approval only runs actions the AI approved. Approved actions go to the ConnectWise Manage API as the approving member, and the result is logged to D1.
Nothing reaches ConnectWise without an AI audit and a human approval.
2026
Humanizer
Rewrites text in a specific person's voice, guided by a curated corpus of their own emails placed in the model's context instead of fine-tuning. A Python Worker on Workers AI, R2 and Access.
Diagram: emails from Gmail are filtered by strict rules, then GLM 5.3 on Workers AI acts as a gate on what goes into the corpus, which is uploaded to R2 per voice with a style guide. Per request, a user behind Cloudflare Access sends text and an editable prompt to a Python Worker, which loads the voice's style guide and corpus from R2 into the system prompt and calls GLM 5.3 Flash on Workers AI.
A voice is a corpus and a style guide in R2. Nothing is fine-tuned.
Cloudflare Workers (Python), Workers AI, R2, Access, Gmail API
Diagram: emails from Gmail are filtered by strict rules, then GLM 5.3 on Workers AI acts as a gate on what goes into the corpus, which is uploaded to R2 per voice with a style guide. Per request, a user behind Cloudflare Access sends text and an editable prompt to a Python Worker, which loads the voice's style guide and corpus from R2 into the system prompt and calls GLM 5.3 Flash on Workers AI.
A voice is a corpus and a style guide in R2. Nothing is fine-tuned.
2026
Hermes Agent as an AI harness
Hermes Agent as the daily harness: custom skills for business workflows, and a research profile that browses like a person, gates every page through Clef Flash on Workers AI, and compiles what passes into an LLM wiki.
Diagram: each project starts from its own AGENTS.md (domain, sources, viability question). The agent writes a checkbox plan and waits for approval, then browses in Chromium on X11 with xdotool at human speed, watched over VNC; logins and bot checks are handed to the user. Each page is screenshotted over read-only CDP and sent through AI Gateway to Clef Flash on Workers AI for a yes-or-no viability check. Pages that pass have their DOM text saved to the raw folder, which is compiled into readable concept pages in the wiki folder; answers to research questions go in the derived folder.
One profile, any domain: the project's AGENTS.md says what to look for, and the profile says how to look.
Diagram: two folder trees. The profile at ~/.hermes/profiles/researcher/ holds SOUL.md at its root, and USER.md and MEMORY.md in its memories folder; these apply to every project. The workspace at ~/LLMWiki/ holds one folder per project, such as liquid-ai-origins/, with AGENTS.md at its root and four folders the agent creates as it works: -plans for the checkbox plan, -raw for page text that passed the gate, -wiki for INDEX.md, the concept pages and SOURCES.md, and -derived for answers. The four downloads are SOUL.md, USER.md, MEMORY.md and AGENTS.md.
Where each file goes. The profile stays the same for every topic; each project only needs its own AGENTS.md.
Hermes Agent, Workers AI, AI Gateway, Chromium, xdotool
Diagram: each project starts from its own AGENTS.md (domain, sources, viability question). The agent writes a checkbox plan and waits for approval, then browses in Chromium on X11 with xdotool at human speed, watched over VNC; logins and bot checks are handed to the user. Each page is screenshotted over read-only CDP and sent through AI Gateway to Clef Flash on Workers AI for a yes-or-no viability check. Pages that pass have their DOM text saved to the raw folder, which is compiled into readable concept pages in the wiki folder; answers to research questions go in the derived folder.
One profile, any domain: the project's AGENTS.md says what to look for, and the profile says how to look.
Diagram: two folder trees. The profile at ~/.hermes/profiles/researcher/ holds SOUL.md at its root, and USER.md and MEMORY.md in its memories folder; these apply to every project. The workspace at ~/LLMWiki/ holds one folder per project, such as liquid-ai-origins/, with AGENTS.md at its root and four folders the agent creates as it works: -plans for the checkbox plan, -raw for page text that passed the gate, -wiki for INDEX.md, the concept pages and SOURCES.md, and -derived for answers. The four downloads are SOUL.md, USER.md, MEMORY.md and AGENTS.md.
Where each file goes. The profile stays the same for every topic; each project only needs its own AGENTS.md.
2026
mcp-whatsapp-agent-platform
An open-source MCP server for Meta's WhatsApp Agent Platform: a private WhatsApp line between one person and their own agent, connected to Claude Code through channels.
Diagram: a message from the phone goes to Meta's WhatsApp Agent Platform. The local MCP server long-polls the platform, confirms the sender is the agent profile's creator, and pushes the message into the running Claude Code session. Replies go back through the send and send_file tools and POST /messages to the same chat. No public webhook or inbound port; one poller per profile; sends stay under 12 a minute; media is saved locally and deleted from Meta.
Long polling from the local machine: no webhook, no open ports, and only the creator on the other end.
MCP server (Node), WhatsApp Agent Platform, Claude Code channels
Diagram: a message from the phone goes to Meta's WhatsApp Agent Platform. The local MCP server long-polls the platform, confirms the sender is the agent profile's creator, and pushes the message into the running Claude Code session. Replies go back through the send and send_file tools and POST /messages to the same chat. No public webhook or inbound port; one poller per profile; sends stay under 12 a minute; media is saved locally and deleted from Meta.
Long polling from the local machine: no webhook, no open ports, and only the creator on the other end.
2026
Model lab
[placeholder] Planned: scheduled checks across local, Workers AI, Anthropic, Moonshot and ollama.com.
Workers, AI Gateway, D1
shipleybuilds.ai
This site: EmDash, Cloudflare's Astro-based CMS, on Workers with D1, R2 and KV. Built with help from Claude Code and Hermes Agent.
EmDash, Astro, Workers, D1, R2, KV, Access, Claude Code, Hermes Agent
Nullify
Network-aware access control for Google Workspace Business tenants, built on Cloudflare Workers.
Diagram: Workspace sign-in events flow from an org-level Log Router sink through a Pub/Sub push subscription to an access-bot Worker on Cloudflare. The Worker looks up the ASN over DNS-over-HTTPS, checks rules in D1, and calls the Admin SDK to sign the user out and revoke tokens. A dashboard Worker manages the rules in D1.
Sign-in events are pushed from the customer's Google tenant to a Worker that judges them against rules in D1 and remediates through the Admin SDK.
Screenshot: Nullify access log showing allowed-bypass and blocked-violation entries with their reasons and remediation actions.
The same network judged in log-only mode (allowed and flagged) and with enforcement on (blocked, with OAuth tokens revoked).
Screenshot: Nullify access rules table with an IP rule, an ASN rule and a time-window rule.
Rules for a whole domain: an office IP, an ASN rule set up as a deliberate mismatch for testing, and a business-hours window (UTC).
Screenshot: Nullify third-party apps table with allow and block toggles per app.
Third-party apps discovered at sign-in. Each can be allowed or blocked on its own.
Cloudflare Workers (Python), D1, GCP Pub/Sub, Google Admin SDK
Diagram: Workspace sign-in events flow from an org-level Log Router sink through a Pub/Sub push subscription to an access-bot Worker on Cloudflare. The Worker looks up the ASN over DNS-over-HTTPS, checks rules in D1, and calls the Admin SDK to sign the user out and revoke tokens. A dashboard Worker manages the rules in D1.
Sign-in events are pushed from the customer's Google tenant to a Worker that judges them against rules in D1 and remediates through the Admin SDK.
Screenshot: Nullify access log showing allowed-bypass and blocked-violation entries with their reasons and remediation actions.
The same network judged in log-only mode (allowed and flagged) and with enforcement on (blocked, with OAuth tokens revoked).
Screenshot: Nullify access rules table with an IP rule, an ASN rule and a time-window rule.
Rules for a whole domain: an office IP, an ASN rule set up as a deliberate mismatch for testing, and a business-hours window (UTC).
Screenshot: Nullify third-party apps table with allow and block toggles per app.
Third-party apps discovered at sign-in. Each can be allowed or blocked on its own.
2026
warp-detector
A Docker container that serves the TLS beacon Cloudflare WARP uses to recognize a trusted network, so managed device profiles apply automatically.
Diagram: on the LAN, the warp-detector container serves a self-signed certificate on the host IP, port 443. A laptop running the WARP client opens a TLS connection to it. In Cloudflare Zero Trust, a network location holds that IP and port plus the certificate fingerprint and selects a device profile. When the fingerprint matches, the profile applies: LAN traffic goes direct to local devices and everything else goes through the WARP tunnel. Off the LAN there is no answer within 5 seconds, so the default profile applies.
WARP checks the beacon's certificate. A match switches the device to the on-LAN profile.
Docker, Python, OpenSSL, Cloudflare WARP, Zero Trust
Diagram: on the LAN, the warp-detector container serves a self-signed certificate on the host IP, port 443. A laptop running the WARP client opens a TLS connection to it. In Cloudflare Zero Trust, a network location holds that IP and port plus the certificate fingerprint and selects a device profile. When the fingerprint matches, the profile applies: LAN traffic goes direct to local devices and everything else goes through the WARP tunnel. Off the LAN there is no answer within 5 seconds, so the default profile applies.
WARP checks the beacon's certificate. A match switches the device to the on-LAN profile.
2025
Die Trying
A tabletop campaign companion on Python Workers, D1 and R2, with opt-in Workers AI pipelines for session transcripts and scanning character sheets into templates.
Screenshot: the party board with five character cards showing HP, armor, attack and an HP bar, plus condition tags: Grappled in red; Poisoned and Frightened in orange; Bless, Shield of Faith and Invisibility in blue; Inspired and Concentrating in gray.
The party board mid-fight. Conditions are colored by what they do: red takes a character out of the action, orange weakens, blue helps.
Screenshot: a character page on a phone, with hit point buttons, armor, inventory, the rules currently applying, a private journal and session history.
A character on a phone: HP buttons sized for thumbs, every rule that is changing a number, a private journal, and the sessions the character was part of.
Screenshot: the DM workspace on the Prep & Entry tab, with encounters, sessions, arcs and world entities, each with its own entry form.
The DM workspace. DM notes stay with the DM; an encounter reaches players only when it is marked shared.
Screenshot: the session recorder, with a master file picker, a start recording button, a session link, and a campaign keyterm list.
The session recorder. Audio streams to a local file during play and uploads to R2 when recording stops.
Diagram: players and the DM use browsers on phones, laptops and the TV. On Cloudflare, a SvelteKit Worker serves the new phone-first interface (built, not yet deployed), and a Python Worker running FastAPI on Pyodide serves today's interface and the JSON API, which browsers call directly with a JWT. The API Worker binds to D1 (characters, campaigns, loot ledger, transcripts), R2 (session audio), Workers AI (Nova-3 for transcripts; Llama 3.2 Vision and Qwen2.5-Coder for sheet scans) and Email Service (account verification). Workers Builds runs D1 migrations and deploys on every push to main.
One Python Worker and its bindings, all on Cloudflare. AI runs only when someone asks.
Diagram: the planned architecture. The SvelteKit Worker becomes the interface, calling the Python API Worker with a JWT. The API keeps its D1, R2 and Email Service bindings. AI Gateway is added in front of Workers AI (Nova-3, Llama 3.2 Vision, Qwen2.5-Coder). A self-hosted pyannote container, coded but not built, takes session audio and returns speaker turns matched against player voiceprints.
Where it goes next: the new interface in front, AI Gateway in front of the models, and a pyannote container for who said what.
Cloudflare Workers (Python), D1, R2, Workers AI, SvelteKit
Screenshot: the party board with five character cards showing HP, armor, attack and an HP bar, plus condition tags: Grappled in red; Poisoned and Frightened in orange; Bless, Shield of Faith and Invisibility in blue; Inspired and Concentrating in gray.
The party board mid-fight. Conditions are colored by what they do: red takes a character out of the action, orange weakens, blue helps.
Screenshot: a character page on a phone, with hit point buttons, armor, inventory, the rules currently applying, a private journal and session history.
A character on a phone: HP buttons sized for thumbs, every rule that is changing a number, a private journal, and the sessions the character was part of.
Screenshot: the DM workspace on the Prep & Entry tab, with encounters, sessions, arcs and world entities, each with its own entry form.
The DM workspace. DM notes stay with the DM; an encounter reaches players only when it is marked shared.
Screenshot: the session recorder, with a master file picker, a start recording button, a session link, and a campaign keyterm list.
The session recorder. Audio streams to a local file during play and uploads to R2 when recording stops.
Diagram: players and the DM use browsers on phones, laptops and the TV. On Cloudflare, a SvelteKit Worker serves the new phone-first interface (built, not yet deployed), and a Python Worker running FastAPI on Pyodide serves today's interface and the JSON API, which browsers call directly with a JWT. The API Worker binds to D1 (characters, campaigns, loot ledger, transcripts), R2 (session audio), Workers AI (Nova-3 for transcripts; Llama 3.2 Vision and Qwen2.5-Coder for sheet scans) and Email Service (account verification). Workers Builds runs D1 migrations and deploys on every push to main.
One Python Worker and its bindings, all on Cloudflare. AI runs only when someone asks.
Diagram: the planned architecture. The SvelteKit Worker becomes the interface, calling the Python API Worker with a JWT. The API keeps its D1, R2 and Email Service bindings. AI Gateway is added in front of Workers AI (Nova-3, Llama 3.2 Vision, Qwen2.5-Coder). A self-hosted pyannote container, coded but not built, takes session audio and returns speaker turns matched against player voiceprints.
Where it goes next: the new interface in front, AI Gateway in front of the models, and a pyannote container for who said what.
2026