Research and demos
emotional-memory
Memory layer for LLM systems with affective state encoding, a PyPI package, Zenodo DOI, and reproducible benchmarks against Mem0, LangMem, and Letta.
Open the artifactInspect emotional-memoryProjects and systems
I select a few projects here to show different engineering problems. The complete archive follows, with released software, research and demos, and system notes kept distinct.
Start with the selected work, then inspect the evidence and technical details in the archive. Research prominence does not imply production deployment.
Selected work
Shipped software
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.
Inspect orkaResearch and demos
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.
Inspect reasoning-kernelShipped software
openfatture
Shipped local-first Python system: durable workflow state, event audit trail, recovery before external effects, and inspectable assistant tools.
Inspect openfattureProject archive
All 20 projects remain available below. Research repositories and non-LLM pieces are labelled separately. They are not production work.
Shipped software10
openfatture
active
Shipped local-first Python system: durable workflow state, event audit trail, recovery before external effects, and inspectable assistant tools.
Open evidence and technical details
#Python#FatturaPA#CLI
openfatture runtime workflow. Nodes: draft, validate, human review, SDI export, send, reconcile. Flow: draft to validate (primary); validate to human review (primary); human review to SDI export (primary); SDI export to send (primary); send to reconcile (feedback); validate to draft (loop, correction path).
Problem
How do you persist workflow state, recover a failed export, and keep assistant actions inspectable when those actions can trigger irreversible external effects?
System design
A shipped local-first Python system: persisted workflow state, an event audit trail, recovery before export or send, and inspectable assistant tools.
Outcome
A public package on GitHub and PyPI. The dated Phase 2 test report is a historical snapshot, not a current quality score.
Architecture
- workflow state
- export recovery
- event audit trail
- assistant tools
Runtime model
- draft
- validate
- export
- send
- reconcile
Tooling
- Python
- LangGraph
- SQLAlchemy
- hooks
Reliability
- local-first control
- pre-export validation
- manual review before external effects
draftvalidateexportsendreconcile
Constraints
The Phase 2 test report is dated historical evidence, not a current quality score. External effects stay behind manual review; inspectability outranks autonomous action.
Tradeoffs
Local-first operation limits convenience but improves control over workflow state and side effects.
Future
Expand workflow checks, recovery coverage, and auditable AI assistance.
orka
active
Rust agent runtime that takes work from chat and HTTP channels, assigns priority, and routes it into bounded LLM workflows with MCP/A2A support.
Open evidence and technical details
#Rust#MCP#A2A#RAG#WASM
orka runtime workflow. Nodes: channel ingress, classify, route, scheduler, MCP/A2A, checkpoint. Flow: channel ingress to classify (primary); classify to route (primary); route to scheduler (primary); scheduler to checkpoint (primary); scheduler to MCP/A2A (supporting); checkpoint to route (loop, correction path).
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.
msg2agent
active
Secure transport layer for agent messages, with end-to-end encryption, DID identity, relay delivery, MCP adapters, and A2A interoperability.
Open evidence and technical details
#Go#E2E Encrypted#DID#A2A#MCP
msg2agent runtime workflow. Nodes: discover DID, encrypt, sign, relay, pull inbox, acknowledge. Flow: discover DID to encrypt (primary); encrypt to sign (primary); sign to relay (primary); relay to pull inbox (primary); pull inbox to acknowledge (primary); acknowledge to relay (feedback).
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.
cast
active
Native Chromecast sender work for LibreWolf and Firefox, with an openscreen backend for media casting and Wayland screen mirroring without third-party desktop tools.
Open evidence and technical details
#C++#Chromecast#Firefox#Wayland#OpenScreen
cast runtime workflow. Nodes: start, branch, retry, gate, commit, checkpoint. Flow: start to branch (primary); branch to gate (primary); gate to commit (primary); branch to retry (supporting); retry to branch (loop, correction path); gate to checkpoint (feedback).
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.
llama.cpp-vulkan-bin
active
Arch Linux package for official llama.cpp Vulkan binaries, with automated upstream release checks, reproducible checksums, build verification, and a smoke test for runtime backend loading.
Open evidence and technical details
#Shell#llama.cpp#Vulkan#Arch Linux#Local Inference
semanticbrowser
active
Rust semantic browser for AI agents that need structured access to web pages, page state, and interaction surfaces instead of brittle screenshots alone.
Open evidence and technical details
#Rust#AI Agents#Browser#Semantic Web#Automation
semanticbrowser runtime workflow. Nodes: agent, policy, MCP, adapter, tool, audit. Flow: agent to MCP (primary); MCP to adapter (primary); adapter to tool (primary); agent to policy (supporting); policy to adapter (supporting); tool to audit (feedback).
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.
mcp_python_toolbox
active
MCP server for Python development tools used by AI assistants.
Open evidence and technical details
#mcp#python#ai-tools#developer-tools#model-context-protocol
mcp_python_toolbox runtime workflow. Nodes: agent, policy, MCP, adapter, tool, audit. Flow: agent to MCP (primary); MCP to adapter (primary); adapter to tool (primary); agent to policy (supporting); policy to adapter (supporting); tool to audit (feedback).
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.
mklang
active
A declarative DSL for LLM-driven state machines.
Open evidence and technical details
#llm#dsl#agents#state-machine#python
mklang runtime workflow. Nodes: start, branch, retry, gate, commit, checkpoint. Flow: start to branch (primary); branch to gate (primary); gate to commit (primary); branch to retry (supporting); retry to branch (loop, correction path); gate to checkpoint (feedback).
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.
mcp-manus-server
active
I provide a TypeScript MCP server for Manus.im integration, with Docker, OAuth, Prometheus, monitoring, and security topics.
Open evidence and technical details
#mcp#manus#typescript#oauth#prometheus#docker
mcp-manus-server runtime workflow. Nodes: agent, policy, MCP, adapter, tool, audit. Flow: agent to MCP (primary); MCP to adapter (primary); adapter to tool (primary); agent to policy (supporting); policy to adapter (supporting); tool to audit (feedback).
Problem
I built this repository to connect Model Context Protocol clients with Manus.im through a TypeScript server. The repository metadata identifies deployment, authentication, monitoring, and security as engineering concerns around that integration.
System design
I organize the project as an MCP server in TypeScript with a Manus.im integration. I include Docker as a deployment concern, OAuth as an authentication concern, and Prometheus as a monitoring concern; the available metadata does not document lower-level implementation details.
Outcome
I publish a repository that defines a TypeScript MCP server focused on Manus.im integration. I do not infer performance, adoption, or operational results from the available metadata.
Architecture
- typescript mcp server
- manus.im integration boundary
- oauth authentication concern
- prometheus monitoring concern
- docker deployment packaging
Runtime model
- server process
- container-oriented deployment
- mcp client integration
Tooling
- TypeScript
- Model Context Protocol
- Docker
- OAuth
- Prometheus
- Manus.im
Reliability
- prometheus monitoring topic
- security topic
- oauth authentication topic
- docker deployment topic
server processcontainer-oriented deploymentmcp client integration
Constraints
I limit this case study to the repository metadata. I do not claim specific tools, request flows, persistence behavior, recovery behavior, metrics, or security controls that the metadata does not describe.
Tradeoffs
I keep the technical description at the integration and concern level rather than reconstructing undocumented internals. This avoids treating topic labels as proof of specific implementation choices.
Future
I would need source-level documentation or operational evidence before documenting concrete MCP tools, OAuth flows, Prometheus metrics, Docker configuration, or security mechanisms.
mcp-duckduckgo
active
A Python MCP server that exposes DuckDuckGo web search to LLM clients.
Open evidence and technical details
#mcp#duckduckgo#web-search#llm#python
mcp-duckduckgo runtime workflow. Nodes: agent, policy, MCP, adapter, tool, audit. Flow: agent to MCP (primary); MCP to adapter (primary); adapter to tool (primary); agent to policy (supporting); policy to adapter (supporting); tool to audit (feedback).
Problem
I addressed the integration problem of making DuckDuckGo web search available to LLM clients through a Model Context Protocol server.
System design
I implemented the project as a Python MCP server, using the protocol boundary to present DuckDuckGo web search as a tool available to an LLM client.
Outcome
I provide a repository focused on connecting LLM clients to DuckDuckGo web search through MCP. The available metadata does not document benchmark or deployment results.
Architecture
- python mcp server
- duckduckgo web search integration
- mcp tool interface for llm clients
Runtime model
- runs as an mcp server
- serves llm clients through model context protocol
- forwards web-search requests to duckduckgo
Tooling
- Python
- Model Context Protocol
- DuckDuckGo
Reliability
- no reliability mechanisms documented in repository metadata
- external search availability depends on duckduckgo
runs as an mcp serverserves llm clients through model context protocolforwards web-search requests to duckduckgo
Constraints
I scope the project to DuckDuckGo web search exposed through MCP. The repository metadata does not document caching, authentication, rate handling, or result-ranking behavior.
Tradeoffs
I use MCP as the integration boundary for LLM clients, which keeps the repository focused on a protocol-based search interface rather than a general-purpose search application.
Future
I would evaluate future changes against documented client requirements and the operational behavior of the DuckDuckGo integration.
Research and demos9
reasoning-kernel
active
A Python reference implementation of a reasoning kernel that separates untrusted model text from authorized effects using capability-based control and taint tracking.
Open evidence and technical details
#Python#Prompt Injection Defense#Capability Security#Taint Tracking#Agent Security
reasoning-kernel runtime workflow. Nodes: untrusted input, planner, quarantine, capability gate, execute, audit. Flow: untrusted input to planner (primary); untrusted input to quarantine (supporting); planner to capability gate (primary); quarantine to capability gate (supporting); capability gate to execute (primary); execute to audit (primary); audit to planner (loop).
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
In this Python reference implementation, a class of prompt-injection effects is constrained by construction, with auditable decisions: research, not a production security guarantee.
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.
emotional-memory
active
Memory layer for LLM systems with affective state encoding, a PyPI package, Zenodo DOI, and reproducible benchmarks against Mem0, LangMem, and Letta.
Open evidence and technical details
#Python#LLM Memory#Research#PyPI#DOI
emotional-memory runtime workflow. Nodes: dataset, encode state, memory store, benchmark, claim matrix, artifacts. Flow: dataset to encode state (primary); encode state to memory store (primary); memory store to benchmark (primary); benchmark to claim matrix (primary); benchmark to artifacts (feedback); claim matrix to encode state (loop).
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
In the public Addendum R result, AFT reached 0.595 LLM-judged answer accuracy versus 0.440 for cosine (Δ +0.155, N=200, p<0.001). The repository also records negative results outside affect-discriminative recall, so I treat this as regime-specific evidence rather than general superiority.
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 figures come from the repository’s public Addendum R artifact and apply to affect-discriminative recall with oracle affect labels. 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.
affective-fly
active
Interpretable affect source for emotional-memory, built from a reduced Drosophila mushroom-body circuit with persistent mood, approach/avoid decisions, journal replay, and committed benchmarks.
Open evidence and technical details
#Python#Affective Computing#LLM Memory#Research
agentroom
active
Agent-to-agent chat with end-to-end encryption over a self-hosted relay, designed so the relay cannot read message contents.
Open evidence and technical details
#JavaScript#E2E Encrypted#Double Ratchet#A2A#Self-hosted
agentroom runtime workflow. Nodes: handshake, ratchet, encrypt, blind relay, decrypt, verify. Flow: handshake to ratchet (primary); ratchet to encrypt (primary); encrypt to blind relay (primary); blind relay to decrypt (primary); decrypt to verify (primary); verify to ratchet (loop).
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.
xllama
active
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.
Open evidence and technical details
#C++#Xbox#Local Inference#ONNX Runtime#UWP
xllama runtime workflow. Nodes: start, branch, retry, gate, commit, checkpoint. Flow: start to branch (primary); branch to gate (primary); gate to commit (primary); branch to retry (supporting); retry to branch (loop, correction path); gate to checkpoint (feedback).
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.
langchain-rag-tutorial
active
A documented LangChain RAG pipeline for comparing OpenAI and HuggingFace embeddings without changing the rest of the retrieval flow.
Open evidence and technical details
#Python#LangChain#RAG#Embeddings#Tutorial
langchain-rag-tutorial runtime workflow. Nodes: documents, chunk, OpenAI emb, HF emb, retrieve, answer. Flow: documents to chunk (primary); chunk to OpenAI emb (primary); chunk to HF emb (supporting); OpenAI emb to retrieve (primary); HF emb to retrieve (supporting); retrieve to answer (primary).
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.
harbor-kernel
active
Experimental Rust bare-metal kernel for Raspberry Pi 4 with cooperative tasks, EL0 agents, IPC, and W^X MMU
Open evidence and technical details
#rust#bare-metal#aarch64#kernel#raspberry-pi#no-std
harbor-kernel runtime workflow. Nodes: ingress, router, planner, executor, state, audit. Flow: ingress to router (primary); router to executor (primary); executor to state (primary); router to planner (supporting); planner to state (supporting); executor to audit (feedback).
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 an experimental Rust kernel 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.
pagouse
active
A Python project for a Chromium page agent aimed at coding agents.
Open evidence and technical details
#python#chromium#mcp#cli#accessibility
pagouse runtime workflow. Nodes: ingress, router, planner, executor, state, audit. Flow: ingress to router (primary); router to executor (primary); executor to state (primary); router to planner (supporting); planner to state (supporting); executor to audit (feedback).
Problem
I created pagouse around a focused integration problem: coding agents need a way to work with Chromium pages. The repository metadata identifies the project as a Chromium page agent for coding agents, implemented in Python.
System design
I kept the project boundary centered on a page-agent role rather than describing a broader automation platform. Python is the implementation language, while Chromium, CLI, MCP, and accessibility are explicit repository topics.
Outcome
The public metadata documents a Python repository named pagouse with a defined focus on Chromium page interaction for coding agents. It does not provide benchmark, usage, or deployment data, so I do not infer operational results from it.
Architecture
- python implementation
- chromium page-agent scope
- coding-agent integration focus
Runtime model
- chromium-oriented page interaction
- agent-facing project scope
- runtime details not documented
Tooling
- Python
- Chromium
- CLI
- MCP
Reliability
- reliability mechanisms not documented
- evaluation process not documented
- deployment model not documented
chromium-oriented page interactionagent-facing project scoperuntime details not documented
Constraints
I limited this case study to the repository metadata. The available information names the language, project description, and topics, but does not describe internal modules, browser-control methods, test coverage, or release practices.
Tradeoffs
I describe Chromium, CLI, MCP, and accessibility as repository topics rather than confirmed implementation details. This preserves a useful technical boundary without attributing undocumented behavior to the project.
Future
I would update this case study when the repository documents its page-control model, supported interfaces, test strategy, and evaluation criteria.
ragfs
active
I expose indexed directories through a Linux FUSE mount, with JSON file operations, undo, and local semantic search. Semantic cleanup still needs plan approval. Python bindings and the MCP server are beta.
Open evidence and technical details
#Rust#FUSE#RAG#LanceDB#Embeddings
Systems notes1
gianlucamazza
active
GitHub profile README covering agent systems and production AI infrastructure work.
Open evidence and technical details
#ai agents#agent orchestration#mcp#rust#bitcoin
gianlucamazza runtime workflow. Nodes: ingress, router, planner, executor, state, audit. Flow: ingress to router (primary); router to executor (primary); executor to state (primary); router to planner (supporting); planner to state (supporting); executor to audit (feedback).
Problem
I use this profile repository to state the technical areas I work on: verifiable agent systems and production AI infrastructure. The repository metadata also identifies agent orchestration, LLMs, MCP, Rust, and Bitcoin as relevant topics.
System design
I keep the project as a GitHub profile README rather than presenting it as an application or service. Its role is to provide a concise, version-controlled technical entry point for the areas represented by the repository topics.
Outcome
The repository provides a public, inspectable profile document. Based on the available metadata, I do not infer deployed components, measured results, or operational usage beyond that documentation role.
Architecture
- github profile repository
- version-controlled readme
- topic-based technical index
Runtime model
- static repository content
- rendered by github
- no runtime declared
Tooling
- GitHub
- Markdown
- Rust
- LLM
- MCP
Reliability
- version-controlled documentation
- public repository inspection
- no recovery mechanism declared
static repository contentrendered by githubno runtime declared
Constraints
The available metadata describes a profile README and its topics, but not source layout, integrations, deployment, tests, or evaluation procedures. I therefore limit this case study to the repository’s documented role.
Tradeoffs
A profile README is easy to inspect and maintain through Git history, but it does not by itself specify executable behavior, interface contracts, or evidence from production operation.
Future
I can extend the README with links to implementation repositories, architecture notes, or reproducible evaluation material when those artifacts are publicly available.
Planning a system like these?
Tell me about the operational problem and the constraints you are working with. A few lines are enough for a first technical assessment.