• TrueSpend: n8n + Claude Sonnet 4.6 + PostgreSQL + React. 17 autonomous workflows, 32-table schema (dbmate-migrated), full P2I lifecycle. Role-gated Operations Board (procurement, IT, controlling, legal, admin). 4-agent compliance onboarding, DocuSign JWT Grant, Grafana, Jira ≥€100k. DB-enforced security: NOSUPERUSER PostgREST role, every status transition through SECURITY DEFINER RPCs, PATCH tickets.status → 403 at the database layer. Agent security: inbound email/invoices run under "the LLM advises, deterministic code decides", model output is schema-validated against an action allowlist, ticket/PO ids are derived deterministically (never from the model), and a prompt-injection repro proves the guard inert; money RPCs gated fail-closed off the browser token.
• SpendLens: React 18 SPA + FastAPI. 5-stage AI pipeline persisted to per-client SQLite (immutable raw layer, hash-dedup, recomputable enrichment). 7 screens wired to Hades and Hermes. Security-hardened for public deployment: opt-in shared-secret API auth (constant-time compare, docs disabled in prod), scoped CORS + full security-header/CSP middleware, chunked upload guards (type allowlist + 25 MB cap), per-IP rate limiting on Anthropic-billed endpoints, Pydantic-validated Hades proxy (SSRF surface closed), generic client errors with server-side logging. Production-polished frontend: React production builds + SRI, pre-paint theme, keyboard-accessible shell (focus-visible, ARIA), reduced-motion, error boundary that keeps the shell alive on crashes.
• Negotiation Agent: a deployed procurement negotiator (▶ live) where the LLM has zero authority. A stateless FastAPI backend runs the real deterministic engine: buyer utility U = Σ wᵢ·vᵢ(xᵢ), acceptance on a Boulware concession curve ((t/T)^β, β>1, a spec bug I caught: the original exponent was inverted, conceding early and surrendering leverage), counteroffers via logrolling (an exact fractional-knapsack LP that concedes on terms the buyer weights lightly but the supplier values highly, not a price split). The guard is mechanical, not a prompt: each turn the server folds the transcript, the engine decides, Opus drafts the buyer's email, and a guard-with-redraft loop rejects any figure the engine didn't approve, a violating draft is redrafted (or replaced by a deterministic template) before it's ever sent. Real Opus (buyer) + Haiku (supplier); HMAC-signed mandates; you play either seat. Contract intelligence, the "prepared buyer": upload a contract → deep extraction (price, expiry, licenses, NDA/DPA, units) + supplier due-diligence via my deployed Hades agent → a deterministic finding→mandate transform (21 property tests) that proposes bounded, reversible envelope adjustments tagged give/hold/hedge, the LLM extracts and observes, a pure-Python rule table maps findings to deltas, and a human approves the diff before signing. That's "LLM advises, code decides" extended to mandate construction: the model's confidence is collapsed to a discrete assurance in Python first, so it never becomes a mandate number. Proven +0.27 supplier utility at matched buyer cost (runnable neg-sim --baseline); headless agent-vs-agent simulator with hidden-preference personas and bit-identical audit replay. 183 tests · 92.9% coverage · mypy --strict · CI green (ubuntu+windows × py3.11–3.13). Architecture designed with Claude Fable 5; full design in docs/.
• Hades: POST a company name → 6 parallel LangGraph nodes: OFAC/UN sanctions, NorthData registry, LkSG/CSDDD signals, ESG, news sentiment, Hermes intel. Risk score 1–10 + Approve/Block recommendation, in under 2 minutes.
• Hermes: 5 crawlers (RSS, EDGAR, Tavily, Jobs, Earnings) over a curated 56-supplier / 8-category watchlist, architecture scales to hundreds. Signals classified by Claude Haiku with delta tracking. Semantic RAG via Upstash Vector.
• SCM-Master: FastAPI + SQLAlchemy 2.0 + Pydantic 2 (SQLite→Postgres), JWT role-gating, 52 test files · CI-gated ≥80% coverage, 5-job CI (lint · Postgres · SAST · CVE-audit · agent-safety). Multi-sourcing core: Product decoupled from ProductSupplier, re-sourcing a line is one FK repoint. Serial-tracked Asset traced RECEIVED→…→DISPOSED with an unbroken link to its PO line. Autonomous weekly purchasing run under "the LLM advises, deterministic code decides", the confidence score is itself deterministic and audited, gating auto-place at ≥0.90 & <€200k, proven by a 29-scenario agent-safety harness (unapproved supplier, over-cap spend, prompt injection, poisoned calibration → refuses every time). Inventory science: Syntetos–Boylan demand classifier → Nixtla statsforecast (Croston/SBA) with conformal prediction-interval safety stock, chosen over a hand-rolled TSB on a walk-forward benchmark; service-level safety stock (z × σ) + ABC class service levels. Learning layer: rule-based calibration from human approve/reject, with a LightGBM + SHAP calibrator in shadow mode, advisory, logged, never deciding. Twin-deployed (self-wiring public demo + forge-locked production that refuses to seed/ship demo accounts/run on non-persistent storage, regression-tested). Cost-intelligence: clean-sheet should-cost engine (commodity-indexed → defensible cost floor + target price, DRAM/NAND sensitivity) + per-asset TCO rolling up to TSCMC %, deterministic engines, the LLM only proposes.
• SCM Power BI Cockpit: synthetic-data generator → 7 internally-consistent CSVs feed a live auto-refreshing 7-tab web cockpit (Node + Chart.js) and a Power BI report on the same live API, DAX anchored to SCOR DS, forecast accuracy (WMAPE / Bias / RMSE), should-cost & TCO. Backed by cited research (Stanford AI Index, McKinsey, chip-geopolitics) driving a hype-vs-evidence invest/wait/pilot call with a phased plan + cost/timeline.
• Triage Agent: 5-tier value routing, supplier NDA/DPA/MSA compliance check via RAG, RFQ/RFP generation, multi-supplier outreach, evaluation matrix, award recommendation. 6 importable n8n workflows.
• Marketing Spend Stats: Welch t-tests, Bonferroni + BH-FDR correction, bootstrap CIs, Cohen's d across 7 channels / 14 CPA pairs.
• LLM Eval Lab: LangSmith, custom 20-example dataset, LLM-as-judge correctness + completeness evaluators, A/B (gpt-4o-mini vs gpt-4o).

How I'd scope, build, and hand off this solution for a procurement client, the way I'd run it as a consultant, not just a repo.

The problem. Under Germany's LkSG (and the incoming EU CSDDD), every material supplier must be screened for sanctions, ownership, ESG, and human-rights risk, and re-screened on change. In most teams this is a 1–2 day manual analyst task per supplier: pull the registry, check OFAC/UN lists, scan news, cross-reference ESG databases, write it up. It doesn't scale, it's inconsistent between analysts, and it's the exact task that stalls onboarding.

The approach. I treated it as a decision-support problem, not a chatbot. The rule throughout: the LLM advises, deterministic code decides. Sanctions matching runs in deterministic code before the model sees anything, a hit forces Block, no LLM discretion. The model only summarizes and scores what verified sources return, so the output is defensible to an auditor.

What I built. An agent that takes a company name and runs 6 research pipelines in parallel, sanctions (OFAC SDN + UN), registry (NorthData), LkSG/CSDDD signals, ESG/labour, 90-day news sentiment, and live market intelligence, then returns a 1–10 risk score with an Approve / Conditional / Block recommendation and a plain-language executive summary, with a persistent audit trail.

The result. A 1–2 day analyst task becomes a sub-2-minute, consistent, audit-trailed report, the same rubric every time, defensible to compliance, and wired into the wider spend platform so a flagged supplier is caught at onboarding, not after.

What I'd do for a client. Scope their actual supplier master and risk appetite → map the screening rubric to their LkSG/CSDDD obligations → pilot on one high-risk category → tune the risk weights with their compliance team → integrate to their P2P so screening is a gate, not an afterthought. The tech is done; the engagement is the fit.

See it: Hades repo

Two architecture diagrams from the system's own documentation. German, because that is the language I think and take notes in.

Ingest, and the one gate that separates fuel from map.

Sources on the left flow through stateful sync skills into an immutable raw layer, which is never reorganized and never hand-edited. Everything left of the dashed line may grow without limit, because it costs nothing. Nothing crosses to the right until it has been rewritten as synthesis in my own voice and linked to at least two existing notes. wiki/ sits deliberately on the raw side: it indexes the raw layer, it does not interpret it.

The point of a single gate is that ingest volume stops being a quality risk. Without it, "ingest more" and "understand more" look identical from the outside, right up until the graph is a landfill.

Two memory stores, and the one that was actually alive.

There were two. The documented one held 13 entries and had not been touched in eight weeks. The undocumented one was written on every session. The documented store was not worse-built, it was unpowered: it waited for a human to type "capture memory", and for eight weeks nobody did.

So the store with an engine became the leading one, and a nightly one-way mirror copies it into git and cloud backup. One way, on purpose. A technical failure announces itself, because something is missing. A resurrected memory does not announce itself at all, and a memory store that quietly restores things you deleted is worse than one that loses them. Deleted stays deleted; the history lives in git.

The transferable lesson is not about memory. A component with no engine attached is a component that has already stopped, and nothing will tell you, because "nothing happened" is indistinguishable from "nothing needed to happen." Every subsystem needs a liveness check that treats silence as death until proven otherwise.

The full build: the trust boundary, the local inference hosts, two overnight shifts on two machines, and the supervision layer that makes unattended work trustworthy. Written the way I'd hand it to a client who says "we can't put that data in someone else's cloud."

The problem. A personal AI assistant is only useful if it knows your actual context: notes, decisions, calendar, client thinking. That is exactly the data you cannot paste into a hosted chatbot. So you pick one, an assistant that's useful while your data leaves the building, or one that's private and blind. For regulated procurement work that is not a real choice.

The approach. Split on the trust boundary, not on convenience. One codebase, two deployments, and the split is drawn at the retrieval engine. The embedder and the hybrid index are gated at registration time, not at runtime: the tool is never offered to the model at all unless ICARUS_BRAIN_MCP=1, which only a machine I own sets. That distinction is the whole point. A disabled feature is a config checkbox somebody can flip; an unregistered one has no code path to enable. So the index, the embeddings and every vector never leave the box. Note text is a separate question with a separate answer: the hosted instance can read the vault, but only through an authenticated private-repository path with a read-only credential, and the same read-only rule binds every local job. Being precise about which of those two boundaries you are claiming is the exercise.

The hardware, and why there are two boxes.

• A 2018 Intel MacBook Pro (i7-8559U, 16GB, no GPU, macOS 15.7.8), clamshell, on AC, sleep disabled. Always on. Its job is to be reliable, not fast.
• A Windows desktop (Ryzen 7 9800X3D, 64GB, RTX 5080 with 16GB VRAM). Its job is to be capable. It is not always on, and the design has to survive that.

The lesson I would give a client first: private AI infrastructure is not one machine, it is an honest split of what runs where, including "what happens when the good machine is off."

The line I drew in June, and why I moved it in August. I benchmarked a 7B on the Mac at ~5 tok/s and concluded: embeddings and retrieval run locally, heavy generation does not. That was right about the hardware and wrong about the workload. Tokens per second is a latency measure, and latency only costs you something when a human is waiting. At 02:30 nobody is waiting. Re-framed as throughput-per-night instead of tokens-per-second, a box that is useless for chat is entirely adequate for batch. The line moved, and it was the interactive half that got cut, not the local half.

Two overnight shifts, deliberately not the same job.

The rule both obey: the local model never writes into the note graph. In the sweep, deterministic Python builds the candidate pairs by shared entities (no shared entity, no detectable contradiction) and the model's entire job is to say this pair might conflict. Judgment stays with the cloud model and the write stays with me. Local grinds, cloud decides.

Because the GPU box is not always on, its shift opens with a real idle gate: a GetLastInputInfo P/Invoke for genuine user-idle time rather than Task Scheduler's RunOnlyIfIdle, and it fails closed if idle time cannot be read. It yields the machine between batches the moment a keystroke lands, and it writes state after every batch so an interrupted run resumes instead of restarting.

The benchmark that picked the model. Same sources, same prompt, same guards, same token cap. Only the model varies. Speed is recorded for planning the night, not for scoring.

The column I actually care about is invented, and it is 0 across all twelve runs. Not because the models are honest, but because they were never given the chance. The prompt offers a numbered list of real note titles and asks for integers, and code resolves the integers back into links. An integer cannot be a hallucinated title. It is either a valid index into a list I built or it is discarded. That is the transferable pattern, and it is the same one as the pairing step: when correctness is checkable in code, do not ask the model to be careful, remove the failure mode from the interface.

The eleven nights nobody heard about. The nightly compound job on the Windows box failed eleven consecutive nights on the same one-line error, the board sync behind it never ran once, and nothing said a word. The Mac had had a phone alert since 11 August. The machine actually doing the work had no voice at all. That asymmetry was the bug.

The fix is a watchdog with two rules worth stealing. It reports only on state change, because a job that says "all good" every morning is muted within a week, and a muted channel is strictly worse than no channel: it manufactures the belief that you would have been told. And it never reads exit codes. A 9B routinely exits non-zero on a malformed tool call after the drafts are safely on disk, so each job publishes its own definition of success and the watchdog reads that instead. A watchdog that cries wolf on the one healthy job is how you train yourself to ignore it. Stale counts as broken too: a job that quietly stops firing is precisely the failure this exists to catch.

The failure I did not design for. Two deployments that look identical become a liability the moment one stops updating. The hosted one redeploys on every push; the one I own updates only when I pull. On 11 August my phone was still pointed at the local instance running seven-day-old code. Five health checks reported the hosted side green while the phone answered from the old build, including a flat "I can't send you files", which on that machine was true. Several commits went into repairing a host that was not the one answering.

The fix is not discipline, it is instrumentation. /health now returns the running commit and a fingerprint of the fully assembled system prompt (as I write this: commit 7d26b14, prompt SHA f5225765ba, 19,979 characters). The tool inventory alone was not enough, and that is the transferable part: it does not move when a prompt rule changes, and from the user's seat an outdated instruction is indistinguishable from a missing capability. If you ship agents, version the prompt like you version the code, and expose it.

Writing the prompts, since these run unattended. For anything that runs more than once, I stopped writing the prompt myself. I dump the context, then ask the model what is the best prompt I could give you for this, write the prompt and not the answer, and I run the result after reading it. A prompt written cold carries only what happened to occur to me. One written against the full context routinely adds the parts people forget: freshness constraints, an explicit output shape, and a rule to say UNKNOWN rather than guess. That last one matters most in a job nobody watches, because an unattended prompt built on a guess produces confident wrong output every night, forever.

Honest status, because "runs 24/7" is a claim a reader should be able to check.

• Hosted ICARUS: live at www.icarusai.de, 29 tools, self-reporting its own commit and prompt SHA.
• Drafting shift: running nightly, green on its last run.
• Nightly integrity audit of the knowledge graph: running, read-only, alerts only when the finding-set changes.
• Watchdog: armed, first scheduled run pending.
• Contradiction sweep on the 35B: built and measured, not yet scheduled. Built is not running, and I would rather say so than imply a cron entry that does not exist.
• The self-hosted interactive instance: switched off. Keeping a second always-on front end in sync with the hosted one is what caused the 11 August incident, and of everything here it earned its keep least. The hardware still runs retrieval and the overnight shift. Turning off the half that cost more than it returned is a result, not an outage.

What I'd do for a client. Map the actual trust boundary first: which data legally cannot leave, and which comfortably can. Put local-only tools behind registration-time gating so "private" is structural rather than a checkbox someone can flip. Size local hardware to the job, and separate latency-sensitive work from throughput-sensitive work before buying anything, because the second kind runs fine on hardware nobody would call adequate. Keep judgment in the model you trust and grinding in the model you own. Then the unglamorous 80%: supervision, fail-safe ordering, state-change-only alerting, and success criteria defined per job rather than borrowed from an exit code. The demo is a day. The service layer is what survives contact with production.

See it: ICARUS repo