Skip to content

Systems I have shipped

Systems I have designed and shipped: each one starts with the problem it solves, with architecture and technical detail to follow.

# active

OpenFatture

Italian invoicing system for FatturaPA/SDI workflows, with Lightning payments and local-first AI assistance.

#Python#Lightning#Ollama#FatturaPA#CLI
PyPIReleases

Problem

Italian invoicing workflows combine compliance, payment rails, and assistance needs that do not fit generic SaaS automation.

System design

A local-first invoicing system with FatturaPA/SDI compliance, Lightning payments, and controlled AI assistance.

Outcome

Compliant invoices produced and sent without a SaaS subscription: business data stays local and every external effect passes manual review.

Architecture

  • invoice model
  • SDI export
  • payment rail
  • local AI assistant

Runtime model

  • draft
  • validate
  • export
  • send
  • reconcile

Tooling

  • Python
  • Streamlit
  • LND
  • Ollama
  • OpenAI/Anthropic

Reliability

  • local-first control
  • compliance validation
  • manual review before external effects
draftvalidateexportsendreconcile

Constraints

Compliance and accounting correctness are higher priority than autonomous action.

Tradeoffs

Local-first operation limits convenience but improves control over sensitive business data.

Future

Expand workflow checks, reconciliation, and auditable AI assistance.

# active

orka

Rust agent runtime that takes work from chat and HTTP channels, assigns priority, and routes it into bounded LLM workflows with MCP/A2A support.

#Rust#MCP#A2A#RAG#WASM

Problem

AI work arriving from chat and HTTP channels needs routing, priority queues, tool access, and runtime boundaries instead of ad hoc automation.

System design

An agent runtime that turns channel input into prioritized LLM workflows with MCP/A2A protocol adapters, sandboxed execution paths, and explicit runtime boundaries.

Outcome

Requests arriving from chat and HTTP become prioritized, bounded flows: agentic automation that stays observable, interruptible, and protocol-oriented.

Architecture

  • channel ingress
  • runtime scheduler
  • tool layer
  • MCP/A2A adapters

Runtime model

  • receive
  • classify
  • route
  • execute
  • checkpoint

Tooling

  • Rust
  • tokio
  • WASM
  • MCP
  • A2A

Reliability

  • typed runtime boundaries
  • prioritized execution
  • protocol separation
  • interruptible workflows
receiveclassifyrouteexecutecheckpoint

Constraints

The runtime must stay protocol-oriented and avoid coupling to a single interface.

Tradeoffs

A lower-level runtime gives more control but requires sharper product boundaries.

Future

Harden observability, workspace policy, and durable execution semantics.

# active

reasoning-kernel

A Python reference implementation of a reasoning kernel that separates untrusted model text from authorized effects using capability-based control and taint tracking.

#Python#Prompt Injection Defense#Capability Security#Taint Tracking#Agent Security

Problem

LLM agents act on untrusted text, so a prompt injection can trigger tool calls and effects the user never authorized.

System design

A reasoning kernel that separates a privileged planner from quarantined untrusted data and gates every effect behind explicit capabilities and taint tracking.

Outcome

A whole class of prompt-injection effects removed by construction, with auditable decisions.

Architecture

  • privileged planner
  • quarantined data
  • capability tokens
  • taint tracking
  • audited effects

Runtime model

  • receive
  • plan
  • check capability
  • execute
  • audit

Tooling

  • Python
  • capability-based security
  • taint tracking

Reliability

  • effects gated by capabilities
  • untrusted data cannot escalate
  • auditable decisions
receiveplancheck capabilityexecuteaudit

Constraints

Security comes from structure, not model behavior: the planner must never act directly on untrusted content.

Tradeoffs

Explicit capability mediation adds support code but removes a whole class of injection effects.

Future

Broaden the capability catalog and integrate it with real tool runtimes.

# active

emotional-memory

Memory layer for LLM systems with affective state encoding, a PyPI package, Zenodo DOI, and reproducible benchmarks against Mem0, LangMem, and Letta.

#Python#LLM Memory#Research#PyPI#DOI
PyPIReleases

Problem

LLM memory systems often claim persistence without reproducible evidence for recall quality, compression behavior, or state changes across releases.

System design

A research-focused memory layer with affective state encoding, a PyPI package, Zenodo DOI, benchmark artifacts, and comparisons against existing memory frameworks.

Outcome

Memory claims backed by a published package and reproducible benchmark artifacts: rigor that can be inspected instead of accepted on trust.

Architecture

  • memory store
  • affective encoding
  • benchmark runner
  • claim matrix

Runtime model

  • ingest
  • encode
  • retrieve
  • evaluate
  • publish artifacts

Tooling

  • Python
  • PyTorch
  • pydantic
  • pytest
  • Zenodo

Reliability

  • reproducible benchmark runs
  • published DOI
  • test-backed package release
ingestencoderetrieveevaluatepublish artifacts

Constraints

The public language must stay aligned with evidence. Stronger scientific claims require broader external validation.

Tradeoffs

Research rigor has priority over broad framework compatibility or a larger feature set.

Future

Expand human evaluation, semantic confound tests, and longitudinal memory benchmarks.

# active

agentroom

Agent-to-agent chat with end-to-end encryption over a self-hosted relay, designed so the relay cannot read message contents.

#JavaScript#E2E Encrypted#Double Ratchet#A2A#Self-hosted

Problem

Agents coordinating across operators need a private channel where the relay cannot read messages or impersonate a participant.

System design

A self-hosted agent-to-agent chat layer with end-to-end encryption, a blind relay, and Double Ratchet session security.

Outcome

Agent coordination over a private, self-hosted channel: no central party can read or block the messages.

Architecture

  • identity keys
  • Double Ratchet session
  • blind relay
  • message store

Runtime model

  • handshake
  • ratchet
  • encrypt
  • relay
  • decrypt

Tooling

  • JavaScript
  • Double Ratchet
  • self-hosted relay

Reliability

  • relay cannot read plaintext
  • forward secrecy
  • self-hosted control
handshakeratchetencryptrelaydecrypt

Constraints

The relay forwards ciphertext only; identity and confidentiality must never depend on trusting the server.

Tradeoffs

Running your own relay increases operational work but removes a central party that could read or block messages.

Future

Broaden client support, group sessions, and key-recovery flows.

# active

msg2agent

Secure transport layer for agent messages, with end-to-end encryption, DID identity, relay delivery, MCP adapters, and A2A interoperability.

#Go#E2E Encrypted#DID#A2A#MCP
Releases

Problem

Agent systems need a transport layer for cross-boundary messages without shared keys, central trust, or relay access to plaintext.

System design

A protocol layer for agent-to-agent messages using W3C DID identity, end-to-end encryption, relay delivery, MCP connector support, and A2A interoperability.

Outcome

A secure transport pattern for agent integrations: the relay can deliver and queue messages, but message content remains outside its trust boundary.

Architecture

  • DID identity
  • encrypted message envelope
  • relay
  • MCP connector
  • A2A adapter

Runtime model

  • discover agent
  • encrypt
  • sign
  • relay
  • pull inbox
  • acknowledge

Tooling

  • Go
  • X25519
  • Ed25519
  • W3C DID
  • OAuth 2.1 + PKCE
  • MCP

Reliability

  • store-and-forward delivery
  • offline inbox
  • tenant quotas
  • blind relay
discover agentencryptsignrelaypull inboxacknowledge

Constraints

The relay routes messages but must not become the trust anchor for identity or message confidentiality.

Tradeoffs

Cryptographic ownership increases trust clarity while adding connector and key-management complexity.

Future

Broaden connector distribution, production billing, and interoperability paths.

# active

cast

Native Chromecast sender work for LibreWolf and Firefox, with an openscreen backend for media casting and Wayland screen mirroring without third-party desktop tools.

#C++#Chromecast#Firefox#Wayland#OpenScreen
Releases

Problem

Browser casting on Linux often depends on external desktop tools or incomplete paths, especially when screen mirroring enters the workflow.

System design

A native Cast sender path for LibreWolf and Firefox backed by openscreen work, with a focus on media casting and Wayland screen mirroring.

Outcome

A systems-level showcase for browser integration work: protocol boundaries, native media paths, and desktop constraints are handled below the web UI layer.

Architecture

  • browser entrypoint
  • native sender
  • openscreen backend
  • Wayland capture

Runtime model

  • discover device
  • negotiate session
  • capture media
  • encode
  • stream

Tooling

  • C++
  • OpenScreen
  • Wayland
  • H.264

Reliability

  • native protocol boundary
  • no third-party desktop sender
  • release-tagged builds
discover devicenegotiate sessioncapture mediaencodestream

Constraints

The work is platform-sensitive: display server, codec, browser, and Cast receiver behavior all shape the implementation.

Tradeoffs

A native path gives better control than a wrapper, but it exposes lower-level compatibility and maintenance work.

Future

Harden receiver compatibility, capture reliability, and browser packaging paths.

# active

semanticbrowser

Rust semantic browser for AI agents that need structured access to web pages, page state, and interaction surfaces instead of brittle screenshots alone.

#Rust#AI Agents#Browser#Semantic Web#Automation
Releases

Problem

Agents that operate on the web need structured page state and interaction targets instead of relying only on brittle screenshots or raw DOM dumps.

System design

A Rust browser layer that exposes semantic page structure and interaction surfaces so agent runtimes can reason over the page with clearer boundaries.

Outcome

A browser automation proof point focused on inspectable state: the agent sees a structured interface, not an opaque visual stream.

Architecture

  • browser runtime
  • semantic extractor
  • page state model
  • agent interface

Runtime model

  • load page
  • extract state
  • select target
  • act
  • observe result

Tooling

  • Rust
  • semantic extraction
  • browser automation

Reliability

  • structured page state
  • explicit interaction targets
  • agent-facing boundaries
load pageextract stateselect targetactobserve result

Constraints

The browser layer must preserve enough page semantics for agents without pretending that arbitrary web pages are deterministic.

Tradeoffs

Semantic state is easier to inspect than screenshots, but it requires careful handling of dynamic pages and accessibility gaps.

Future

Connect the page model to eval traces and safer browser-control policies.

# active

xllama

Local LLM inference experiment for Xbox Series S|X using UWP development mode and ONNX Runtime GenAI under constrained hardware and platform limits.

#C++#Xbox#Local Inference#ONNX Runtime#UWP
Releases

Problem

Local LLM inference on constrained consumer hardware is limited by memory, runtime APIs, packaging, and platform-specific deployment paths.

System design

An Xbox Series S|X inference experiment using UWP development mode and ONNX Runtime GenAI to test local model execution inside tight platform limits.

Outcome

A concrete edge-inference proof point: model runtime, device limits, and packaging constraints are made explicit instead of hidden behind a generic demo.

Architecture

  • UWP app shell
  • ONNX Runtime GenAI
  • model package
  • device runtime

Runtime model

  • load model
  • allocate runtime
  • run inference
  • stream output
  • inspect limits

Tooling

  • C++
  • UWP
  • ONNX Runtime GenAI
  • Xbox developer mode

Reliability

  • explicit hardware constraints
  • release-tagged experiment
  • local inference path
load modelallocate runtimerun inferencestream outputinspect limits

Constraints

The project is an experiment, not a product claim: platform restrictions and model size limits define the useful boundary.

Tradeoffs

A constrained device makes the engineering limits visible, but reduces model choice and deployment flexibility.

Future

Compare model sizes, memory behavior, and runtime packaging across local inference targets.

# active

langchain-rag-tutorial

A documented LangChain RAG pipeline for comparing OpenAI and HuggingFace embeddings without changing the rest of the retrieval flow.

#Python#LangChain#RAG#Embeddings#Tutorial

Problem

RAG quality depends on chunking, embeddings, and retrieval choices that are hard to compare without a documented baseline.

System design

A reference RAG pipeline on LangChain that runs OpenAI and HuggingFace embeddings over the same documents and queries for side-by-side comparison.

Outcome

A documented baseline for comparing retrieval choices before investing in a production pipeline.

Architecture

  • document ingestion
  • chunking
  • embedding index
  • retriever
  • answer generation

Runtime model

  • load
  • chunk
  • embed
  • retrieve
  • generate

Tooling

  • Python
  • LangChain
  • OpenAI embeddings
  • HuggingFace embeddings

Reliability

  • side-by-side embedding comparison
  • reproducible notebook
  • documented retrieval steps
loadchunkembedretrievegenerate

Constraints

It is a teaching baseline, not a production service: clarity and reproducibility come before scale.

Tradeoffs

A notebook format favors readability over deployment, so production concerns are intentionally out of scope.

Future

Add reranking, evaluation sets, and more embedding backends.