Gianluca Mazza — Systems I have shipped

# active

OpenFatture

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

#Python#Ollama#FatturaPA#CLI

Problem

How do you ship FatturaPA/SDI-compliant invoicing with AI assistance without handing business data to another SaaS subscription?

System design

A local-first invoicing system with FatturaPA/SDI compliance 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

Requests arrive from chat, email, and internal tools, but without a single durable queue there is no reliable path from channel input to a tracked, reviewable LLM workflow.

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

One prioritized queue routes multi-channel requests into bounded LLM workflows with MCP/A2A support.

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

PyPI Benchmarks Releases

Problem

When a business adds an AI assistant, how do you verify that what it remembers today will still recall correctly after the next model or software update?

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

A published package and reproducible benchmarks give you inspectable evidence before trusting an AI memory layer in production.

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 chat and Stable-Diffusion image generation on Xbox Series S|X in UWP development mode, with ONNX Runtime GenAI and DirectML routed per workload.

#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 app in UWP development mode, with ONNX Runtime GenAI and DirectML routed per workload, 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
DirectML
model catalogue

Runtime model

download model
route per workload
run inference
stream output
inspect limits

Tooling

C++
UWP
ONNX Runtime GenAI
DirectML
Xbox developer mode

Reliability

explicit hardware constraints
release-tagged experiment
local inference path

download modelroute per workloadrun 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

Measure new GGUF builds on the console before promoting them to catalogue defaults.

# 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.

# active

mcp_python_toolbox

MCP server for Python development tools used by AI assistants.

#mcp#python#ai-tools#developer-tools#model-context-protocol

Repository

Problem

I wanted a Python-based MCP server that gives an AI assistant a defined toolbox for Python development. The repository metadata supports a narrow scope: an MCP integration surface for developer tools, not a claim about specific workflows, adoption, or performance.

System design

I keep the system boundary at the Model Context Protocol. Assistant clients connect to the server, request development-oriented tools, and receive responses through the protocol interface. Python is the implementation language. The design focus is where the tool boundary sits: what an assistant can invoke is declared by the server, not improvised inside a chat instruction.

Outcome

The repository presents a Python MCP server for AI-assisted Python development. From the available metadata, I can state the outcome at repository level only: a concrete protocol-based place to expose Python development tools to compatible assistant clients.

Architecture

mcp server boundary
python implementation
tool-oriented request handling
assistant-facing protocol interface

Runtime model

assistant client sends a tool request
server handles the request through mcp
python code implements the tool surface
response returns through the protocol

Tooling

Python
Model Context Protocol
GitHub

Reliability

explicit protocol boundary
bounded tool surface
no implicit persistence: the server holds no session state
failures surface as protocol responses, not silent retries
scoped exposure keeps the blast radius of a tool call small

assistant client sends a tool requestserver handles the request through mcppython code implements the tool surfaceresponse returns through the protocol

Constraints

The public metadata does not describe the individual tools, execution model, persistence layer, benchmarks, or production usage. I therefore keep the case study at the integration and system-boundary level.

Tradeoffs

Using MCP gives a clear interface for assistant-tool interaction, but it also means the useful behavior depends on the tool definitions implemented behind that interface. Keeping the scope narrow reduces ambiguity, at the price of pushing persistence and evaluation onto whoever wires the toolbox into a larger system.

Future

The next technical step I would evaluate is documenting each exposed tool with its input contract, failure modes, and expected side effects. That would make the server easier to test and would create a basis for reproducible evals without making unsupported claims about current behavior.

# active

mklang

A declarative DSL for LLM-driven state machines.

#llm#dsl#agents#state-machine#python

Repository

Problem

I wanted a small language boundary for LLM-driven state machines: the state machine should be described as a document, not hidden inside imperative glue code. The repository frames the `.mkl` document as the program and the LLM as the runtime, so the main engineering question is how to make agent-like control flow explicit enough to inspect, edit, and version.

System design

I model the project as a declarative DSL around state-machine structure. The source artifact is a `.mkl` document; Python provides the implementation substrate; the LLM is treated as the runtime component that advances the machine according to the document. This keeps the program representation separate from the execution substrate and makes the repository a place to test language shape, parsing boundaries, and runtime responsibilities.

Outcome

The repository documents an approach for expressing LLM-driven state machines as source files. I do not claim benchmarks, production adoption, or broad model support from the available metadata. The useful result is the architectural constraint itself: a program can be represented as a `.mkl` document while runtime behavior remains attached to an LLM-backed executor.

Architecture

declarative state-machine source
`.mkl` program documents
python implementation layer
llm-backed runtime boundary

Runtime model

document-driven execution
state transitions mediated by llm runtime
explicit program artifact
agent-oriented control flow

Tooling

Python repository
`.mkl` language files
GitHub source history
published project page

Reliability

versionable program documents
inspectable state-machine structure
separation between source and runtime
a diff on the program document is a diff on the behavior

document-driven executionstate transitions mediated by llm runtimeexplicit program artifactagent-oriented control flow

Constraints

I keep the description limited to repository metadata: Python, a declarative DSL, `.mkl` documents, LLM-driven state machines, and the idea that the LLM acts as runtime. I do not infer parser features, execution guarantees, model coverage, or operational metrics that are not stated.

Tradeoffs

A DSL makes the control structure easier to treat as source, but it also introduces language-design work: syntax, validation, runtime semantics, and error reporting must be defined carefully. Keeping the LLM as runtime preserves flexibility, while making deterministic behavior and recovery semantics something the surrounding system must specify explicitly.

Future

The natural next work is to make the contract between `.mkl` documents and the runtime more explicit: state representation, transition rules, validation behavior, and test fixtures. Until a document can be replayed against a fixture and produce the same transitions twice, the language is a shape, not a guarantee.

# active

harbor-kernel

Verified Rust bare-metal kernel for Raspberry Pi 4 with cooperative tasks, EL0 agents, IPC, and W^X MMU

#rust#bare-metal#aarch64#kernel#raspberry-pi#no-std

Repository

Problem

I wanted a small Rust kernel for Raspberry Pi 4 that keeps the core operating-system mechanisms visible: cooperative tasks, EL0 agent execution, IPC, and W^X memory permissions. The repository metadata supports an experimental bare-metal AArch64 scope; I do not claim production use, adoption, or benchmark results.

System design

I structured the project as a no_std Rust bare-metal kernel for AArch64. The design centers on a cooperative task model, an EL0 boundary for agents, IPC primitives, and MMU configuration intended to enforce W^X permissions. I keep the boundaries explicit so that privilege changes, communication paths, and memory permissions can be inspected as kernel mechanisms rather than hidden runtime behavior.

Outcome

The result is a public repository focused on a verified Rust kernel foundation for Raspberry Pi 4. Its supported scope is the kernel architecture described in the metadata: bare-metal execution, cooperative scheduling, EL0 agents, IPC, and W^X MMU work. Where the metadata is silent, I treat the status as unknown rather than inferred.

Architecture

no_std rust kernel
aarch64 raspberry pi 4 target
cooperative task model
el0 agent boundary
ipc primitives
w^x mmu configuration

Runtime model

bare-metal boot context
cooperative scheduling
user-mode agent execution
message-oriented ipc
explicit address-space permissions

Tooling

Rust
no_std
AArch64
Raspberry Pi 4
GitHub

Reliability

w^x memory policy
privilege separation with el0
cooperative control flow
small bare-metal surface
verification-oriented kernel scope

bare-metal boot contextcooperative schedulinguser-mode agent executionmessage-oriented ipcexplicit address-space permissions

Constraints

This is a bare-metal Raspberry Pi 4 project, so the design stays close to hardware and does not assume a hosted OS runtime, a standard library, or a normal process model. The repository metadata does not provide test coverage, proof details, deployment status, or benchmark data.

Tradeoffs

Rust and no_std keep the implementation away from hosted runtime assumptions, but they also make hardware-specific work explicit. Cooperative scheduling is easier to inspect than preemption, while it requires tasks to yield intentionally. W^X and EL0 boundaries support isolation goals at the cost of MMU and context-management complexity.

Future

If I continue the project, I would make the verification story easier to inspect: name the invariants the kernel claims to hold, document how to rerun the checks that establish them, and state what remains unproven.