Systems I have built, and designs to study

A pilot plant is moving towards continuous production. It has new starters and new shift patterns to train, one IT person, and process knowledge that it cannot send to a public chatbot. Operators learn from whichever revision of a standard operating procedure (SOP) is to hand. Nothing links a training answer to the approved document.

DeepTutor runs in Docker on a server on site, with local models through Ollama. Web search and every outbound feature are switched off, and a packet capture at commissioning proves that nothing leaves. A scheduled sync copies into the knowledge base only the revisions that the document controller has approved in SharePoint, and it removes superseded ones. Supervisors write test questions, and the knowledge base must pass DeepTutor's retrieval test (kb eval) on them before anyone learns from it. Each role gets a mastery path, quizzes and answers that cite their source. When the tutor's gate passes, a supervisor watches the task on the real equipment and records the sign-off in a SharePoint list. Questions that the tutor could not answer from an approved document go to the coordinator as document-control actions.

An integrator's engineers can now get an AI coding agent to write a commissioning-report tool in an afternoon. The result is a script with no plan, no record of which limits it checks and no test that anyone has walked through.

GSD Core turns a spec for the commissioning-report tool into requirements, a roadmap and phases, all kept in the repository. For each phase the engineer answers the questions the spec leaves open, using the firm's own acceptance limits and report template. The plans are checked before any code is written. Each task is committed separately. A verifier and the engineer's acceptance test decide whether the phase ships. The agent runs in a sandboxed container with its permission prompts on, the GSD Core version is pinned, and CI runs on the pull request before merge.

The record of a battery-room retrofit is spread across client emails, site calls, the crew channel, the drawing register and the risk assessments and method statements (RAMS). Every Friday someone writes the client's status report from memory. A hold point that nobody wrote down is left out of it.

Each site gets a Macro project. The client is set up as a CRM company and the crew gets a channel. The engineer files client email threads into the project, and Macro records and transcribes site calls. A Friday routine reads the week's emails, calls and documents from the original items through Macro's MCP tools. It searches for a list of site terms that the firm maintains. It drafts the status report as a Macro document, with an @-mention on every line that links to the source. Where Macro's nightly memory disagrees with the latest source, the draft flags the line. The routine then opens a send-email review card. The engineer corrects and approves the report, and nothing reaches the client before that.

A formal connection application costs money and takes months. A parcel that fails on flood zone or protected land should never reach one. The public data that would rule it out sits in a dozen portals, each with its own format and its own ways of failing.

A screening agent runs each candidate parcel through Luminus's MCP tools. They cover terrain, flood zone, protected land, grid proximity, distribution headroom from the five DNOs' published data, queue depth at the nearest grid supply point, and a rules-based Gate 2 checklist. Where an ENTSO-E key exists, they add a revenue sketch from price spreads. Every layer is graded pass, warn or fail. A layer that failed to load is graded unknown, not clear. A person decides which parcels go forward, and every report says it is not a connection offer.

A developer asks one question: does a 50 MW battery at this bus overload anything when a line trips? To answer it, a planner must build a base case, a variant with the battery, and an N-1 run, which tests the loss of each line in turn. In a desktop tool that still takes hours.

An agent on PyPowSyBl MCP loads the network model into its own session and runs a base-case load flow. It clones a variant and applies the battery's export by setting target_p on a generator already at the bus. Then it runs a security analysis with N-1 line contingencies generated automatically. Before it reports any result, it checks that the model carries ratings at all. It lists post-contingency overloads and voltage violations, draws the substation's single-line diagram and asks for a Python script the engineer can rerun. The engineer signs the study. The agent never writes back to an operational model.

A battery on the five-minute wholesale market earns money by charging and discharging at the right times. The obvious way to automate that is to let an AI model decide. A model that picks the charge window will sometimes invent a number. The battery, its warranty and the site's bill then bear the cost.

An agent reads four inputs: AEMO dispatch and five-minute predispatch prices from NEMweb, the retailer's price feed where the customer has one, a solar forecast derived from the weather, and the battery's state of charge. A plain optimiser, not an AI model, builds a rolling charge and discharge schedule from them. The model writes only the explanation. Writes reach the inverter through Home Assistant on the Sigenergy local Modbus integration. They pass limits that no model output can move: a state-of-charge floor and ceiling, a write rate limit, a kill switch checked before anything else, dry-run by default and an audit line for every attempt. The design adds three things to the published project: a guard on cell temperature and state of health, a count of cycles against the warranty, and a staged go-live. The owner or installer approves each step out of dry-run.

A site's flexible loads run when people plug them in or when a fixed timer starts them, usually in the evening peak. The carbon report then multiplies a year of bills by an annual average factor. Nothing in that report could have changed when any load ran.

An agent reads NESO's 48-hour regional carbon intensity forecast for the site's postcode. For each flexible load (fleet charging, a battery's grid charge, batch jobs, a nightly sync) it picks the lowest-intensity window that still meets the load's deadline. It writes the schedule to the charge controller or the job scheduler. A person sets every deadline and can override any slot. Each half-hour of metered energy is logged against the forecast, and against NESO's estimated actual where one exists. Every figure carries its source, method and fetch time for Scope 2 reporting.

An operations agent that drafts work orders starts every conversation knowing nothing. An engineer corrects the same mistake at the same site week after week, and none of those corrections is kept where the next draft can use it.

A Hindsight memory layer runs on the firm's own servers, beside the operations agent. The agent stores every engineer correction and every failed tool call against the site and the asset. Before it drafts the next work order, it reads what happened there last time. A scheduled pass, which Hindsight calls reflect, groups repeated corrections into proposed rules. An engineer approves each rule before the agent may treat it as standing practice. Everything runs on Postgres with local embeddings and an Ollama model, so site records stay in-house.

A tender for a substation battery replacement arrives with drawings, site constraints and a deadline. If someone pastes it into a public chatbot to scope it faster, the customer's documents and the firm's own rates go to someone else's server.

Scoper's Standard chain of four agents runs on a local model behind Ollama. ARIA parses the tender and extracts the requirements and the ambiguous scope. NOVA drafts phases, hours per role and risks. CHRONOS builds the programme and flags timelines that assume an outage nobody has booked. PRISM writes acceptance criteria. The design makes three changes. It replaces the rates that Scoper hardcodes in a prompt with a version-controlled rate file the firm owns. It pins the provider to Ollama and checks the pin on every start. It adds a statement-of-work template filled from the JSON estimate, which an engineer prices, edits and signs.

Installers hand-fill a PDF panel spec, scan it and email it in; sales engineers retype it into a spreadsheet and the ERP, so a quote takes days while installers are trying to win same-day tenders — and the design knowledge that sizes loads, fusing and batteries safely lives only in the engineers' heads.

A self-hosted web configurator built on React Flow (the actively maintained open-source canvas library, chosen because no catalogue tool offers a drag-and-drop schematic editor) walks installers through the same guided sections as the form, lets them drag fused output cards, batteries and extension boxes onto a 2D canvas, and validates load, fusing and battery-runtime maths live. An n8n pipeline prices the BOM only for authenticated approved accounts, pushes the design as a draft quotation into ERPNext for a sales engineer's approval, and generates wiring drawings plus an Ollama-drafted commissioning pack stored in Nextcloud, where the installer reviews, marks up and e-approves the drawings online before paying against the ERPNext quote. Installers can free-issue my company some components and sub-assemblies for us to fit for them. This would require them to mark space on the panel for their gear, including dimensions and locations of input/output terminals, etc...

Hundreds of dual-string VRLA banks across NSW age at block-level rates that nobody can see: discharge tests live on paper forms, impedance surveys pile up in spreadsheets, and the 80%-capacity moment arrives as a surprise — colliding with a supplier who is sometimes eight to ten weeks from having stock. Every year the capex bid for replacements is an educated guess, and the two battery teams route themselves across the state by calendar rather than by which strings actually need attention.

A per-block digital twin of the entire fleet: field readings are captured on a tablet or phone, normalised and temperature-corrected by an n8n pipeline, and written to TimescaleDB (chosen over a vector store because impedance and discharge curves are numeric time-series needing continuous aggregates, and it is a mature open-source Postgres extension) while Neo4j holds the structure — which block sits in which string, at which site, of which generation, with what criticality. An Ollama-hosted model fits each block's impedance and capacity trend to forecast its 80% date; forecasts feed a wave planner that groups whole-string replacements, flags gen-one blocks worth redeploying to lower-criticality sites, checks contracted supplier stock, and drafts purchase orders in ERPNext far enough ahead of the ten-week China lead time. The same forecasts drive a rolling three-year capex view and route the two test teams to the strings closest to end of life first, with the existing DNP3 charger 'battery fail' alarms ingested as an early-warning overlay.

A stock alert in the ERP still becomes a purchase order by hand. Someone looks up the preferred supplier, phones for a price and drafts the order days later. By then the stockout has already cost a job.

A workflow watches stock levels in ERPNext. When stock runs low, it asks the preferred suppliers on file for stock and price. It uses Firecrawl to search for alternatives only when the preferred suppliers cannot fill the order. Then it drafts the purchase order for a manager to approve. Nothing goes to a supplier without that approval.

A technician at a remote site needs the manual, the safety procedure and the last diagnostic reading, usually with both hands occupied. A previous technician has already answered most of the questions. The system still takes the slow route through the full retrieval and sensor stack every time.

An agent runs on the edge device. It first checks a local Qdrant cache of recent diagnostics and common procedures, and answers from it when the match is confident. Only on a miss does it fall back to live ChromaDB retrieval and sensor fusion. The technician asks by voice and hears the answer, and the agent keeps working without a network.

A requirements document is written once and then retyped into tickets by hand. From the first sprint the two drift apart.

A pipeline parses the requirements document and generates a structured task tree. It syncs the tree both ways with OpenProject over MCP, so a status change in either place shows up in the other.

The documents that would make an AI assistant useful are the ones that cannot leave the building.

A self-hosted retrieval system searches the documents in Nextcloud. Qdrant holds the vectors and a local model writes the answers. Access control is checked on every query, and an audit log records who asked what.

Contact-form submissions go unanswered, and calculator users leave without a follow-up. The same person is scored as a new lead each time they fill in a different form, so the CRM holds three partial histories of one prospect.

Every capture point checks ERPNext for an existing contact by email, company and phone before it scores anything. A match is merged and sent to the account executive who already owns it. Only a new contact starts the three-email welcome sequence, the scoring and the lifecycle stage changes.

Useful details are lost faster than anyone can type them. A name from a site visit, a promise made in a corridor, a battery that will be past its end-of-life date by winter: each is lost between the moment it happens and the next time someone sits at a desk. The tools sold for this assume a structured capture session that rarely happens. Automated outreach products fill a prospect's inbox with mail that nobody read before it was sent. I wanted neither, so I built the opposite.

This is a sales-intelligence system that I control from one phone. It runs on a VPS and a home lab, and it sends nothing to a prospect until a person taps a button. At seven each morning one Telegram message reports what the lead scorer and the equipment monitor did overnight. A separate cron job, outside the workflow engine, confirms that the engine itself is still running. During the day I send a thirty-second voice note. The home GPU transcribes it, and a local model pulls out the names, sites, equipment and standards. The result is written three times, to the graph, the vector store and the CRM, and each copy points at the other two. A follow-up draft arrives on the phone with two buttons and waits up to a day. If I do nothing, it is skipped. Whatever I tap, a second, independent lock must also read true before any mail leaves. Two crawlers look for prospects. One searches the public web with Anthropic's model, and the other is sandboxed behind a metered proxy. Neither can write to the CRM. Their finds wait in a quarantine queue until I press Approve in the browser, which commits a find to all three stores at once or rolls the write back. A sequencer wakes every ten minutes, finds leads that have changed stage and picks one of eighteen templates along four axes. On Monday morning the phone offers three episode topics, ranked from what prospects have said. After one tap the script is written from sources it can cite, narrated in a cloned voice, animated scene by scene and staged for a Wednesday contact sheet.

A capacity discharge test or a cell impedance survey follows IEEE 450, 1188 or 1106, depending on the chemistry, with manufacturer thresholds and temperature corrections on top. Meanwhile the engineer manages arc-flash and hydrogen hazards from a paper checklist. What she noticed on site reaches the maintenance system days later, when the paperwork is filed, or not at all.

A guided workflow picks the IEEE procedure for the battery type. It trends impedance against the baseline as the readings come in. During a discharge it watches each cell for reversal or a sudden fall, and it corrects capacity for temperature. It produces the report to the standard before the engineer leaves site. A Telegram bot takes voice or text notes from any engineer on the crew and passes them through the same workflow, so no laptop is needed.

Teams that let coding agents run unattended meet the same two failures. The agents stop and nobody notices for hours. Or the agents report success and nobody checks. A pipeline has to survive its own restart, and it has to be caught when it reports something false.

A durable orchestrator, built on DBOS and Postgres, runs a pipeline of eight Claude Code agents: planner, builder, reviewer, an injected security stage, tester, deployer and docs, plus a spec-author off the main line that turns plans into dependency graphs of specs. Every step is checkpointed. Every dispatched model call is idempotent against a crash. Every human gate is a durable wait that survives a redeploy. The orchestrator checks the deployer's claim of success against the remote's file tree before the run may continue. A halt leaves a marker with one of thirteen named reasons. A reviewer that rejects twice hands the run to a person and does not try a third time. Four projects run on isolated worker containers from one Compose stack.